依存関係
ソフトウェアコンポジション解析（SCA）とは？
ソフトウェアコンポジション解析は、ソフトウェアに含まれるオープンソースやサードパーティのコンポーネントを特定し、既知の脆弱性、ライセンス上の問題、古いバージョンがないかを確認します。出荷するコードの大半は依存しているコードであるため、SCAはコードの大半をカバーします。ただし、分析できるのは特定できたコンポーネントだけです。
更新日
SCAの仕組み
- コンポーネントを特定する。ツールは対象として指定されたもの、つまりリポジトリ内のマニフェストやロックファイル、インストール済みのパッケージ、コンテナイメージやバイナリの中身を読み取ります。その結果がコンポーネントとバージョンの一覧で、多くの場合SBOMとしてエクスポートされます。
- 既知のリスクと照合する。各コンポーネントをGitHub Advisory Database、OSV、NVDなどの脆弱性データベースで調べ、宣言ライセンスを自社のポリシーと照らし合わせます。
- 優先順位を付ける。検出結果は深刻度でランク付けされ、一部のツールは到達可能性分析を加えて、コードが脆弱な関数をそもそも呼び出せるかどうかを確認します。
- 修正する。多くのツールは修正済みバージョンを提案したり、DependabotやRenovateのようにプルリクエストを作成したりします。脆弱な推移的依存関係の場合、修正は通常それを取り込んでいるパッケージ側で行います。それを示すのが依存関係グラフです。
SCAが見つけるもの
- 既知の脆弱性：使用しているバージョンに含まれるもので、それを記述したアドバイザリとともに示されます。
- ライセンスリスク：プロプライエタリ製品に含まれるコピーレフトライセンスなど。
- 古いパッケージやメンテナンスされていないパッケージ：セキュリティ修正が提供されないもの。
- 悪意のあるパッケージ：アドバイザリとの照合だけでなく、パッケージの振る舞いも分析するツールの場合。
SCAとSASTの違い
SCAと静的アプリケーションセキュリティテスト（SAST）はセットで販売されることが多いものの、対象とするコードも答える問いも異なります。
| SCA | SAST | |
|---|---|---|
| 分析対象 | 依存しているオープンソースやサードパーティのコンポーネント | 自社チームが書いたコード |
| 見つけるもの | 既知の脆弱性、ライセンス上の問題、古いパッケージ | インジェクションや安全でない入力処理など、コードの欠陥 |
| 読み取るもの | マニフェスト、ロックファイル、インストール済みパッケージ、イメージ、バイナリ | ソースコード |
| 新たな検出のきっかけ | 依存関係の変更、またはすでに出荷しているバージョンに対する新しいアドバイザリ | コードの変更 |
| 一般的な出力 | 修正済みバージョン付きの脆弱なコンポーネントとSBOM | 欠陥のあるコードの位置と修正案 |
両方が必要です。SASTの検出がないコードベースでも脆弱な依存関係を出荷することはありますし、依存関係ツリーがクリーンでも自社のコードについては何もわかりません。詳しい比較はSASTとSCAの違いをご覧ください。運用の仕方に関わる違いが1つあります。SASTの検出はコードが変更されたときに現れますが、SCAの検出は、新しいアドバイザリが公開されたその日に、数か月前に出荷したリリースに対して現れることがあります。
SCAの限界
SCAの結果はすべて、最初のステップであるコンポーネントの特定に依存します。ツールが特定できなかったコンポーネントは、照合も優先順位付けも修正もできず、抜け漏れとして表示されることもありません。よくある死角は次のとおりです。
- ファイルに書かれていないもの。多くのSCAツールはマニフェストとロックファイルを読み取ります。欠落した、あるいは古いロックファイル、CIキャッシュから復元されたパッケージ、ビルドツール、ダウンロード、インストールスクリプトは、一覧に載りません。ロックファイルが出荷したものの記録にならない理由をご覧ください。
- ツールによって結果が異なる。同じコミットを対象にしても、2つのスキャナーは異なるコンポーネント一覧を返します。何を読み取り、どう命名するかのルールがツールごとに異なるためです。オープンソースのSBOM生成ツールが見落とすものをご覧ください。
- バイナリ。ビルド済みバイナリとして配布されるソフトウェアは、マニフェストを読むツールから見える情報をほとんど、あるいはまったく宣言していません。
- 既知の脆弱性のみ。照合で見つかるのは公開済みのものです。新しい悪意のあるパッケージや未公表の欠陥には、まだアドバイザリがありません。
- スナップショットにすぎない。プルリクエストでのスキャンはその時点の状態を示すだけです。すでに本番環境にあるバージョンに対する新しいアドバイザリには、出荷したものを継続的にチェックする仕組みが必要です。
これは特定の製品の欠陥ではなく、商用でもオープンソースでも、スキャンという手法そのものの性質です。CRACIは、SnykやAikidoが報告しなかった脆弱なパッケージを見つけています。それらのコンポーネントが、両ツールのスキャン対象にそもそも含まれていなかったためです。
ビルドを記録し、SCAも維持する
CRACIは、コンポーネント特定の抜け漏れをビルドの側から埋めます。CRACIはGitHub Actionsランナーであり、各ジョブが取得したすべてのパッケージを、ツリーのあらゆる階層で、CIキャッシュから復元されたパッケージも含めて、自らの完全性を示すSBOMに記録します。新しい脆弱性が公開されるたびに出荷したもののSBOMを再評価し続け、ビルド履歴から、どの過去のビルドに脆弱なパッケージが含まれていたかがわかります。
CRACIは設計上、SASTや到達可能性分析は行いません。チームはCRACIを、プルリクエストや自社のコードをカバーするSCAツールやSASTツールと併用しています。SCAツールの比較、SCAツールと併用する場合のCRACIの位置付けをご覧いただくか、デモを予約して、記録されたSBOMと現在のスキャン結果を比較してください。
ソフトウェアコンポジション解析に関するよくあるご質問
サイバーセキュリティにおけるSCAとは何ですか？
ソフトウェアコンポジション解析（SCA）とは、ソフトウェアに含まれるオープンソースやサードパーティのコンポーネントを特定し、既知の脆弱性、ライセンス上の問題、古いバージョンがないかを確認する取り組みです。自分たちが書くコードではなく、依存しているコードを対象とします。
SCAとSASTの違いは何ですか？
SASTは、自社チームが書いたコードにインジェクションのバグなどの欠陥がないかを分析します。SCAは、依存しているコンポーネントに既知の脆弱性やライセンス上の問題がないかを分析します。答える問いが異なるため、多くのセキュリティプログラムでは両方を実施しています。
SCAスキャンとは何を意味しますか？
SCAスキャンは、プロジェクトのマニフェスト、ロックファイル、インストール済みパッケージ、またはコンテナイメージを読み取り、どのコンポーネントが含まれているかを割り出して、脆弱性やライセンスのデータと照合します。結果は検出結果の一覧で、特定したコンポーネントのSBOMが付くことも多くあります。
SBOMとSCAは同じものですか？
いいえ。SBOMは構成一覧、つまりリリースに含まれるコンポーネントのリストです。SCAは分析、つまりコンポーネントを特定してリスクを確認することです。多くのSCAツールは途中でSBOMを生成し、SBOMはリリース後の脆弱性監視に活用できます。
SCAの限界は何ですか？
分析できるのは、通常はマニフェストやロックファイルから特定できたコンポーネントだけです。CIキャッシュから復元されたパッケージ、ビルドツール、ダウンロード、パッケージメタデータのないバイナリは見落とされることがあります。見つかるのは既知の脆弱性であり未知のものではありません。また、ツールが出荷したものを再チェックし続けない限り、スキャンはスナップショットにすぎません。
おすすめのSCAツールは何ですか？
基本機能以外に何が必要かによります。到達可能性分析、悪意のあるパッケージの検出、ライセンスポリシー、開発者のワークフローなどです。13のSCAツールの比較で、それぞれがカバーする範囲と限界をご覧ください。