Software Composition Analysis (SCA)は、コードベース、コンテナ、クラウド全体でオープンソースの依存関係を保護するための最前線のツールです。このガイドでは、SCAが何をするのか、なぜ重要なのか、最新のツールがノイズをどのように削減するのか、そして単なるノイズの多いアラートではなく、実際の脅威を見つけて修正するための実践的な手順を説明します。
要約
- アプリケーションコードの約70～90%は、多くの場合オープンソースの依存関係に由来します。これにより、広範な攻撃対象領域が生まれます。
- SCAツールは、依存関係（推移的なものを含む）をスキャンし、CVEデータベースと照合し、修復ガイダンスやSBOMを生成します。
- 誤検知は一般的ですが、最新のSCAは到達可能性分析と開発環境と本番環境の検出を利用することで、ノイズを約80%削減します。
- 修正戦略：非破壊的な変更を自動アップグレードし、破壊的なアップグレードをトリアージし、autofix/PR生成を使用して修正を加速します。
SCA (ソフトウェアコンポジション分析) とは何ですか？
SCAは、依存関係スキャンまたはオープンソース依存関係スキャンとも呼ばれ、アプリが使用するすべてのオープンソースパッケージを特定し、それらのパッケージ（および特定のバージョン）が既知の脆弱性に関連付けられているかどうかを確認します。その結果は、チームが何をパッチ適用、更新、または無視すべきかを決定するのに役立ちます。
SCAが重要である理由
現代のアプリケーションは階層化されており、アプリケーションはライブラリに依存し、そのライブラリはさらに別のライブラリに依存しています。これは、依存関係の入れ子構造です。基盤となるプロジェクトの脆弱性は、サプライチェーン全体に波及する可能性があります。Log4jインシデントはその典型的な例です。広く使用されているロギングライブラリにおける重大なリモートコード実行の欠陥により、インターネットの広範な部分が悪用可能になりました。
SCAの仕組み — 基本
- インベントリ：SCAは依存関係マニフェスト（package.json、package-lock.json、requirements.txt、Pipfile.lock、Gemfile.lockなど）を解析し、直接的および推移的な依存関係をリストアップします。
- マッチング: パッケージ名とバージョンを脆弱性フィード（NVD、MITRE CVE、GitHub Advisory Database、その他のソース）と照合します。
- 優先順位付け：最新のSCAは、到達可能性、環境（開発対本番）、エクスプロイト可能性といったコンテキストを追加し、発見事項の優先順位付けを行います。
一般的な依存ファイル
- Node: package.json (直接依存) および package-lock.json (推移的依存)
- Python: requirements.txt, pipfile.lock
- Ruby: GemfileとGemfile.lock
SBOMs — 役立つサイドクエスト
ソフトウェア部品表（SBOM）は、ソフトウェアで使用されるコンポーネントとバージョンの機械可読インベントリです。
SBOMは、多くのコンプライアンス体制や政府契約で義務付けられています。ほとんどのSCAツールは、脆弱性レポートと並行してSBOM（SPDX、CycloneDX）を生成できます。
CVEと脆弱性フィード
セキュリティ研究者が問題を発見すると、CVE識別子を割り当て、影響を受けるバージョンを含む詳細を公開します。SCAツールは、NVD、MITRE、GitHub Advisoriesなどの情報源からCVEデータを集約し、依存関係のバージョンが既知の脆弱な範囲と一致するかどうかを判断します。
クイックスキャン例 — 依存関係のスキャン
軽量スキャナー（例：TrivyスタイルのCLI）は、依存関係を列挙し、数秒で脆弱性データベースとの一致を報告できます。スキャン結果はJSONとしてエクスポートされ、ダッシュボードや自動化されたワークフローに供給できます。
結果の解釈：修正、破壊的変更、スケール
一見すると、修正は単純で、脆弱性のないバージョンへのアップグレードに見えます。しかし実際には、アップグレードによって破壊的変更が導入され、回帰を引き起こしたり、広範なテストが必要になったりする可能性があります。アプリケーションに何百もの脆弱な推移的パッケージがある場合、無計画なアップグレードは非現実的であることが多いです。
2つの修正バケット
- 動作を破壊しないアップグレード: 動作を変更しない簡単なアップグレード — これらを優先し、最初に自動修正します。
- 破壊的アップグレード: より詳細なトリアージ、互換性テスト、またはコード変更が必要です。これらは、より小規模ながらもより大きな労力を要する項目です。
フォールス・ポジティブと到達可能性分析
多くのフラグ付けされた脆弱性は、現在のコンテキストではエクスプロイト可能ではありません。一般的な2つの理由：
- 開発専用の依存関係: ビルド時のみ使用されるパッケージは、プロダクション環境では到達不能です。
- 到達不能な関数: パッケージ内に脆弱な関数が存在しても、アプリ（および他の依存関係）がそれを呼び出さない場合があります。
到達可能性分析（コールツリー分析）は、トップレベルの依存関係がダウンストリームパッケージをどのように取り込み、脆弱なコードパスがランタイムによって実際に呼び出されるかどうかをマッピングします。これにより、ノイズが除去され、チームは真のリスクに集中できます。
実用的な例：エクスプロイトできないプロトタイプ汚染アラート
広く使用されているNodeパッケージに、setLocaleという関数にプロトタイプ汚染の脆弱性があるとします。コールツリー内のどのコードパスもsetLocaleを呼び出さない場合、その脆弱性はアプリケーションにとって実質的にエクスプロイト不可能であり、検証後には安全に優先順位を下げることができます。
状況を一変させる最新のSCA機能
- 理由付き自動無視: 依存関係が開発環境でのみ使用されている場合や、影響を受ける関数に到達できない場合、ツールは検出結果を自動的に抑制でき、誤検知を大幅に削減します。
- 到達可能性 / コールツリー可視化: プロジェクトから脆弱なパッケージへの依存関係パスを可視化し、エクスプロイト可能性を検証します。
- 破壊的変更フラグ: 互換性の問題を引き起こす可能性のある修正にフラグを付け、チームが安全なアップグレードを優先できるようにします。
- 自動修正 / PR生成: リスクの低い修正に対して、依存関係のアップグレードコミットまたはプルリクエストを自動的に生成します。
推奨される修正ワークフロー
- 問題を早期に検出するために、CIの一部としてSCAスキャンを実行してください。
- autofix/PR生成を介して破壊的変更のない修正を自動適用し、テストを実行します。
- 破壊的変更のトリアージ：チケットを作成し、互換性テストをスケジュールし、または段階的なアップグレードを計画します。
- トリアージには到達可能性分析を使用してください。検証済みの到達不能なCVEは無視し、その正当性を文書化してください。
- コンプライアンスおよび迅速なインシデント対応のためにSBOMを維持します。
ツール選択 — 実用的な視点
オープンソースのCLIスキャナー（Trivy、Grype）は、迅速なチェックとCI統合に優れています。エンタープライズプラットフォームは、到達可能性分析、自動優先順位付け、PRベースの自動修正、およびノイズを管理しチーム全体で修復を拡大するための集中型ダッシュボードを追加します。コードベースの規模、コンプライアンス要件、および修復における自動化の度合いに基づいて選択してください。
主要なポイント
- ほとんどの最新アプリケーションがオープンソースコンポーネントに大きく依存しているため、SCAは不可欠です。
- すべてのフラグ付けされたCVEが悪用可能であるとは限りません。到達可能性分析と開発/本番環境のコンテキストは、実際の脅威をノイズから区別するために不可欠です。
- 非破壊的なアップグレードに優先順位を付け、可能な限り自動化します。より深いエンジニアリング作業を必要とする破壊的なアップデートには、手動での作業を確保します。
- 透明性とコンプライアンスのためにSBOMを生成および維持します。
開始する
今すぐSCAをCI/CDパイプラインの一部に組み込みましょう。定期的なスキャンを実行し、SBOMを生成し、安全で迅速な修復のために自動修正を有効にします。まず、軽量なCLIスキャナーでリポジトリをスキャンし、最も重大度の高いアラートの到達可能性結果を確認し、その後、自動修正をプルリクエストワークフローに組み込みます。
ソフトウェアサプライチェーンの保護は、技術的およびプロセス上の課題です。適切なSCAツールと実用的な修正ワークフローにより、リスクを軽減し、開発を迅速に進めることができます。今すぐAikido Securityをお試しください！
