オープンソース ソフトウェアを評価するための簡潔なガイド
（このページは Concise Guide for Evaluating Open Source Software の参考訳です。）
Open Source Security Foundation (OpenSSF) Best Practices Working Group, 2023-06-14
ソフトウェア開発者として、オープンソースソフトウェア（OSS）の依存関係やツールを使用する前に、候補を特定し、あなたのニーズに照らして主要なものを評価します。セキュリティと持続可能性のために、潜在的OSの依存関係を評価するには、以下の質問を考慮してください（リストアップされたすべてのツールやサービスは例としてご覧ください）。
- その追加を避けることができるか？代わりに既存の（場合によっては間接的な）依存関係を使えないか？新しい依存関係が増えるたびに、攻撃対象が増加します（新しい依存関係による破綻や依存関係の増加が、システムを破壊するかもしれません）。
- 意図したバージョンを評価しているか？
個人的なフォークや攻撃者が管理するフォークではなく、そのソフトウェアの意図したバージョンを評価していることを確認してください。これらのテクニックは、よくある「タイポスクワッティング」攻撃（攻撃者が「ほぼ正しい」名前を作成する）に対抗するのに役立ちます。- i. 名前とプロジェクトのウェブサイトをチェックし、URLを確認する。
- ii. GitHub/GitLabのフォーク関係を確認する。
- iii. プロジェクトが財団または基金と提携しているか確認してください（この場合、財団のウェブサイトから公式のソースにアクセスできるはずです）。
- iv. 作成時間と人気をチェックする。
- メンテナンスされているか？
メンテナンスされていないソフトウェアはリスクとなります。ほとんどのソフトウェアは継続的なメンテナンスが必要です。もしメンテナンスされていなければ、セキュアでなくなる可能性があります。- i. 最近1年以内に重要な活動（コミットなど）がありましたか？
- ii. 最後にリリースされたのはいつですか（1年以内ですか）？
- iii. 複数のメンテナがいますか？理想的には異なる組織からの参加であることが望ましいです。
- iv. 最近のリリースやメンテナからのアナウンスはありますか？
- v. バージョン文字列が不安定であることを示していますか（例えば、”0 “で 始まる、”alpha “や “beta “を含むなど）？
- 開発者が安全性を高める努力をしているという証拠はありますか？
- i. プロジェクトが、Open Source Security Foundation（OpenSSF）のベストプラクティスバッジを獲得しているか（または、獲得に向けて順調に進んでいるか）を確認する。
- ii. https://deps.devの情報を調査し、OpenSSF Scorecard のスコアや既知の脆弱性などの情報を調べる。
- iii. パッケージの依存関係が（比較的）最新かどうかを判断する。
- iv. なぜ安全なのかを説明する文書（別名「アシュアランス ケース」）があるかどうかを判断する。
- v. CIパイプラインに自動テストが含まれていますか？テストのカバレッジはどのくらいですか？
- vi. そのプロジェクトはバグ（特にセキュリティバグ）をタイムリーに修正していますか？古いリリースのセキュリティ フィックスをリリースしていますか？LTS (Long Time Support) バージョンがありますか？
- vii. 開発者は、利用可能なコードのホスティング サービスが提供するセキュリティ機能を使用していますか（例えば、GitHubやGitLabを使用している場合、ブランチ保護機能を使用していますか）？
- viii. セキュリティ監査と、発見された問題が修正されたかどうかを確認する。セキュリティ監査は比較的まれですが、OpenSSFのセキュリティレビューを参照してください。
- ix. SAFECodeのガイド、ソフトウェア保証アセスメントの原則 (2019) を利用し、ソフトウェアのセキュリティを調査するために多層的なアプローチを取ってください。
- x. 現在のバージョンに既知の重要な脆弱性（特に古くから知られている脆弱性）はありませんか？組織は、既存の脆弱性が含まれたり、新しい脆弱性が世の中にリリースされた際の体系的なチェックのためにOpenChainのセキュリティ保証仕様 1.1を実装したいと考えるかもしれません。
- xi. より安全なソフトウェアを開発するための簡潔なガイドの多くのプラクティスを適用していますか？
- 安全に利用できるか？
- i. デフォルトのコンフィギュレーションや「簡単な例」は安全ですか（例えば、ネットワークプロトコルの暗号化がデフォルトでオンになっているなど）？もしそうでなければ、利用は避けてください。
- ii. そのインターフェイス/APIは安全に使いやすいように設計されていますか？（例えば、インターフェイスが言語を実装している場合、パラメータ化されたクエリをサポートしていますか）。
- iii. 安全な使用方法についてのガイダンスはありますか？
- 脆弱性を報告する方法についての指示はありますか？
OSSプロジェクトへの指針については、オープンソース プロジェクトのための連携した脆弱性開示プロセスの実施ガイドを参照してください。 - 重要度の高いシステムでの利用がありますか？
多くのユーザーや大規模なユーザーを持つソフトウェアは、あなたの使用には不適切かもしれません。しかし、広く使われているソフトウェアほど、安全に使うための有用な情報を提供している可能性が高く、そのソフトウェアのセキュリティに関心を持つ人も多いでしょう。対象のソフトウェアと似た名前で人気のあるものがあるかどうかをチェックしてください – それはタイポスクワッティング攻撃を示している可能性があります。 - ソフトウェアのライセンスとは何ですか？
ライセンスは技術的にはセキュリティではありませんが、ライセンスはセキュリティと持続可能性に大きな影響を与える可能性があります。すべてのコンポーネントにライセンスがあること、OSSであれば広く使われているOSIライセンスであること、そして、あなたの意図する使用方法と一致していることを確認してください。明確なライセンス情報を提供しないプロジェクトは、セキュアなソフトウェアにつながる他の優れたプラクティスに従う可能性が低くなる場合があります。 - コード評価とその結果とは？
ソフトウェアの簡単なレビュー（あなた、あなたが雇った誰か、または他の誰かによる）でも、ソフトウェアの最近の変更により、いくつかのインサイトを得ることができます。以下は、考慮すべき点です。- i. ソースコードを見直したとき、開発者が安全なソフトウェアを開発しようとした証拠がコードの中にありますか（信頼できない入力に対する厳密な入力検証や、パラメータが適切に処理された実行の記述など）？
- ii. 安全でない/不完全なソフトウェアの証拠がありますか（例：多くのTODOの記述）？
- iii. 静的解析ツールが報告する「トップ」の問題はなんですか？
- iv. そのソフトウェアが悪意のあるものであるという証拠はありますか？ Backstabber’s Knife Collectionに従って、インストール スクリプト/ルーチンに悪意がないかチェックし、~/.sshや環境変数からのデータ流出をチェックし、実行されるエンコード/難読化された値を探します。不審なコードがないか、最新のコミットを調べます（攻撃者が最近追加している可能性があります）。
- v. サンドボックス内でソフトウェアを実行し、悪意のあるコードのトリガーと検出を試みることを検討してください。
- vi. 定義されたテスト ケースをすべて実行し、ソフトウェアが合格することを確認してください。
- vii. OpenSSFのセキュリティ レビューのリストをご覧ください。
このほかにも、以下のようなリソースがあります。
提案やアップデートを歓迎します！issueを開くか、プルリクエストを投稿してください。
翻訳協力：松本央
このサイトはオープンソースです。このページを改善する
