ソフトウェアコンポジション解析（SCA）とは？

ソフトウェアコンポジション解析（SCA）は、アプリケーションポートフォリオ全体のオープンソースコンポーネントに対して、脆弱性、ライセンスリスク、サプライチェーン脅威をスキャンします。

ソフトウェア構成分析（SCA）とは？

開発チームが本番環境に重要なアップデートをリリースしました。デプロイは成功しましたが、3週間後、そのアップデートに攻撃者によって積極的に悪用されている脆弱なオープンソースコンポーネントが含まれていたことが判明します。そのライブラリは複数バージョン遅れており、National Vulnerability Databaseで重大とされ、存在すら知らなかった推移的依存関係に含まれていました。

現在、オープンソースソフトウェアはエンタープライズのコードベースの大部分を占めており、アプリケーションは数百の依存関係を持っています。ソフトウェア構成分析（SCA）は、これらの見落としが侵害経路になるのを防ぐために存在します。SCAは、ソフトウェアを分析し、オープンソースおよびサードパーティコンポーネントのリスクを特定、評価、管理するプロセスです。ソースコード、バイナリ、またはパッケージマニフェストをスキャンしてすべてのコンポーネントを棚卸しし、脆弱性データベースと照合し、ライセンスコンプライアンスを確認し、実用的なレポートを生成します。CI/CDパイプラインに統合することで、SCAは脆弱なコンポーネントが本番環境に到達する前に阻止します。

SCAが何をするかを理解するだけでは不十分です。現代のソフトウェア開発におけるオープンソースリスクの規模が、SCAが任意のツールではなくセキュリティ要件となった理由を説明しています。

ソフトウェア構成分析が重要な理由

オープンソースコンポーネントは、ほとんどのチームが過小評価している規模で実際のリスクを伴います。 CISAのオープンソースソフトウェアセキュリティロードマップによると、ある調査では、さまざまな業界の調査対象コードベースの96%にオープンソースソフトウェアが含まれていることが判明しました。NISTは、 NVDに提出され分析を要する脆弱性のバックログが増加していることを認めており、2024年だけでCVEの提出が32%増加しています。このバックログにより、組織は標準化された深刻度ガイダンスを用いたリスクの適切な優先順位付けができなくなっています。

最近の サプライチェーン攻撃がその必要性を示しています：

• 2020年のSolarWinds攻撃では、ソフトウェアビルドプロセスが侵害され、米国政府機関やフォーチュン500企業を含む18,000以上の組織に影響を与えました。
• 2021年12月のLog4Shell脆弱性（CVE-2021-44228）では、Log4jライブラリを使用する数百万のアプリケーションがリモートコード実行の危険にさらされました。CISAはこれを史上最も深刻な脆弱性の一つと呼びました。
• 2021年のCodecov侵害では、CI/CDパイプラインが侵害され、2か月以上にわたり29,000以上の顧客の認証情報やソースコードが流出しました。

これらのインシデントはすべて、SCAが発見することを目的としたオープンソースコンポーネントやビルドプロセスの弱点を悪用しています。SCAは、単なる時点スキャンではなく、継続的な監視としてセキュリティ運用に統合されます。SCAプラットフォームは、新たな脆弱性が本番コンポーネントに影響を与えた際にアラートを発し、既知の脆弱性や非互換ライセンスを含むビルドをブロックします。攻撃者が悪意のあるパッケージを公開リポジトリに注入した場合、SCAツールはコンポーネントのハッシュを既知の正規署名と照合し、 サプライチェーンの改ざんを検出します。

SCAはアプリケーションセキュリティテスト手法の一つです。SASTやDASTとの違いを理解することで、それぞれがセキュリティプログラムのどこに適合するかが明確になります。

SCAとSASTとDASTの違い

アプリケーションセキュリティテストは、コードベースの異なる攻撃面を対象とする3つの分野に分かれます。

1. ソフトウェア構成分析（SCA）は、アプリケーションにバンドルされたサードパーティのオープンソースコンポーネントやライブラリを調査します。自チームが作成していないコードに存在する既知の脆弱性、ライセンスリスク、サプライチェーン脅威を特定します。SCAはパッケージマニフェスト、バイナリ、依存関係ツリーをスキャンし、NVDやGitHub Security Advisoriesなどの脆弱性データベースと照合します。
2. 静的アプリケーションセキュリティテスト（SAST）は、自社のソースコードに存在するセキュリティ欠陥（インジェクション脆弱性、不適切なデータ処理、認証の弱点など）を分析します。SASTはアプリケーションを実行せずに、ソースコードやバイトコードをスキャンして実行前に問題を検出します。
3. 動的アプリケーションセキュリティテスト（DAST）は、実行中のアプリケーションに対して外部から実際の攻撃をシミュレートします。DASTは、クロスサイトスクリプティング（XSS）、認証の破損、サーバーの設定ミスなど、デプロイ後にのみ現れるランタイム脆弱性を発見します。

機能	SCA	SAST	DAST
スキャン対象	サードパーティ／オープンソースコンポーネント	自社ソースコード	実行中のアプリケーション
実行タイミング	ビルド時、CI/CD、継続的監視	開発／ビルド時	デプロイ後
脆弱性の種類	既知のCVE、ライセンス競合、悪意のあるパッケージ	コードレベルの欠陥（インジェクション、認証問題）	ランタイムの悪用（XSS、設定ミス）
ソースアクセス要否	パッケージマニフェストまたはバイナリ	完全なソースコードまたはバイトコード	ソースアクセス不要

エンタープライズのコードベースは主にオープンソースコンポーネントで構成されているため、3つすべてが必要です。CI/CDパイプラインでまずSCAを実行し、脆弱な依存関係を検出した後、SASTで自社コードを検査し、最後にDASTでデプロイ済みアプリケーションを検証します。この多層的アプローチにより、自分で書いたコードと継承したコードの両方をカバーできます。

これらの違いが明確になったら、次はSCAプラットフォームを効果的にする中核要素を理解しましょう。

ソフトウェア構成分析の中核要素

SCAプラットフォームは、4つの補完的な機能を組み合わせ、コンポーネントの棚卸しを実用的なセキュリティインテリジェンスに変換します。

1. オープンソースの棚卸しと脆弱性特定が基盤となります。SCAツールは、package.jsonやpom.xmlなどで明示的に宣言されたライブラリと、それらが引き込む推移的依存関係をマッピングする深い依存関係解決を行います。 OWASP依存関係ガイダンスによると、脆弱性の大半は直接依存関係ではなく推移的依存関係に存在します。ツールは、National Vulnerability Database（NVD）、MITRE CVEデータベース、GitHub Security Advisories、ベンダー固有のセキュリティ情報など複数の脆弱性データベースと照合します。
2. ライセンスコンプライアンス管理は、ソフトウェアポートフォリオ全体のオープンソースライセンスを自律的に追跡します。ツールはライセンスタイプを特定し、非互換ライセンス間の潜在的な競合を警告します。独立系アナリストの評価では、ライセンス分析とガイダンスがエンタープライズ向けSCAプラットフォームと基本的なスキャニングツールを区別する重要な基準とされています。
3. ソフトウェア部品表（SBOM）の生成により、すべてのコンポーネント、バージョン、ライセンス、関係性をカタログ化した完全な棚卸しを作成します。SCAツールはCycloneDXやSPDXなどの標準フォーマットでSBOMをエクスポートし、セキュリティツール間の相互運用性や規制要件への対応を可能にします。 NISTのSecure Software Development Framework（SSDF）ガイダンスによれば、組織は開発中にSBOMおよびSLSAプロビナンス文書を自律的に生成し、ソフトウェアサプライチェーンリスクを特定・評価・阻止する必要があります。
4. ポリシー施行とリスク優先順位付けが他の3つの機能を統合します。SCAプラットフォームは、重大な脆弱性、未承認ライセンス、不正なソースからのコンポーネントを含むビルドをブロックする設定可能なポリシーを適用します。高度な実装では、到達可能性分析や悪用予測スコアリングを追加し、単なる脆弱性数ではなく実際のリスクに基づいて検出結果を優先順位付けします。

これらの機能が、実際のSCAスキャンと分析を駆動するエンジンとなります。

ソフトウェア構成分析の仕組み

スキャン手法

最新のSCAは、ソフトウェア構成の全体像を構築するために4つの補完的なスキャン手法を使用します：

1. マニフェスト解析は、package.json、pom.xml、requirements.txtなどのパッケージマネージャファイルを調査し、宣言された依存関係を確認します。
2. ソースコードスキャンは、アプリケーションコードを分析してインポートされたライブラリを特定します。
3. バイナリ解析は、ソースアクセスが制限されている場合にコンパイル済みアプリケーションを調査します。
4. 依存関係ツリーのマッピングは、複数レイヤーにまたがる完全な依存関係グラフを構築します。

SCAはCI/CDパイプラインの早い段階、 SASTやDASTの前に配置し、脆弱なライブラリが本番環境に到達するのを防ぎます。プルリクエスト内のすべてのアーティファクト（依存関係マニフェストを含む）に対して自律的なチェックが実行されます。

マッチングと修正

SCAツールは、NVD、CVEデータベース、GitHub Security Advisories、ベンダー固有のセキュリティ情報を照会し、カバレッジを最大化する多重データベース相関を行います。マッチングワークフローでは、すべてのコンポーネントを正確なバージョン情報とともにカタログ化し、統合脆弱性データベースを照会してインストール済みバージョンが脆弱範囲に該当するかを判定し、ライセンスタイプを分析してポリシー競合を検出します。

効果的なSCAは、バージョンアップグレード経路、パッチの有無、リスクスコアリングなどの修正推奨も生成します。プラットフォームは、脆弱性に対応する最小限の安全バージョンに関する自律的なガイダンスを提供する必要があります。このワークフローは継続的に動作し、すでに本番環境にあるコンポーネントを監視し、新たな脆弱性が公開された際にアラートを発します。

これらのスキャンとマッチング機能が技術的基盤を形成します。その上に構築されたツールが、セキュリティチームが日々頼る運用価値を提供します。

SCAツールの主要機能

SCAツールは、生のスキャンデータをチームが実行可能な運用セキュリティワークフローに変換します。効果的なSCAツールと基本的な依存関係スキャナを分ける5つの機能があります。

• 継続的監視とアラートは、デプロイ済みコンポーネントを新たに公開された脆弱性とリアルタイムで照合します。ビルド時にすべてのチェックを通過したコンポーネントでも、研究者が新しいCVEを公開した瞬間に重大なリスクとなる可能性があります。SCAツールは数時間以内にアラートを発するべきであり、次回の定期スキャンまで待つべきではありません。
• CI/CDパイプライン施行は、重大な脆弱性や未承認ライセンスが検出された場合に自動的にビルドを失敗させるポリシーゲートを提供します。これにより、修正は本番環境での発見後ではなく、導入時点で行われ、修正コストが大幅に削減されます。
• 到達可能性分析は、アプリケーションが実際にフラグ付けされた依存関係内の脆弱なコードパスを呼び出しているかどうかを判定します。ライブラリに既知のCVEがあっても、アプリケーションが該当関数を呼び出さなければ実質的なリスクは大幅に低下します。この分析により、アラートノイズを削減し、実際に悪用可能な箇所に修正作業を集中できます。
• 自動修正ガイダンスは、最小安全バージョン、パッチの有無、破壊的変更の警告など、各検出結果に対する実用的なアップグレード経路を提供します。単に脆弱性リストを開発者に渡すのではなく、効果的なSCAツールは具体的な修正方法と依存関係ツリーへの影響を提示します。
• SBOMエクスポートとコンプライアンスレポートは、CycloneDXやSPDX形式の機械可読な棚卸しを生成し、監査証跡や規制要件に対応します。これらのレポートは、アプリケーションポートフォリオ内のすべてのコンポーネント、バージョン、ライセンス、関係性をマッピングし、内部監査、顧客要求、または政府への提出に備えます。

これらの運用機能により、アプリケーションポートフォリオ全体で測定可能なセキュリティとコンプライアンス成果が得られます。

ソフトウェア構成分析の主なメリット

効果的に導入された場合、SCAはセキュリティ、コンプライアンス、開発チーム全体で採用を正当化する3つの測定可能な成果をもたらします。

• サプライチェーン全体の脆弱性可視化：SCAは依存関係の可視化を提供し、脆弱性、ライセンス、コンポーネントのソースを特定します。オープンソースレジストリに公開される悪意のあるパッケージの数は年々急増しており、攻撃者はnpmやPyPIなどを標的にしてソフトウェアサプライチェーン経由でマルウェアを配布しています。NISTは、 NVDのバックログ増加により、多くの新規CVEに深刻度スコアが付与されず、既存のセキュリティツールがリスクを適切に評価できないことを認めています。SCAは独自の脆弱性インテリジェンスと到達可能性分析でこのギャップを埋めます。
• 規制コンプライアンスの実現：政府フレームワークは現在、SCAツールが提供するSBOMおよび脆弱性監視機能を要求しています。 NISTのSecure Software Development Frameworkは、組織が開発中にSBOMおよびSLSAプロビナンス文書を自律的に生成することを求めています。 大統領令14028は、ソフトウェアサプライチェーンセキュリティを任意のベストプラクティスから連邦契約資格に影響するコンプライアンス要件へと格上げしました。EUサイバーレジリエンス法は、デジタル要素を持つ製品にセキュア・バイ・デザインの開発を要求しています。
• AIによるリスク防止の強化：AI支援開発により依存関係の変更速度が増す一方で、新たなエラーも発生しています。 USENIXで発表された査読付き研究によると、コード生成LLMは平均19.6%のパッケージ幻覚率を示し、実在しないソフトウェアパッケージを推奨しています。AIエージェントは、出所、ポリシー、既知の悪意指標を確認しないため、リスクを増幅させます。SCAは、AIコーディングアシスタントが脆弱または悪意のあるコンポーネントを機械的に導入するのを防ぐガバナンスレイヤーを提供します。

これらのメリットがあっても、ライセンスコンプライアンスはSCAが対処する中で最も過小評価されているリスクの一つです。

ソフトウェア構成分析とオープンソースライセンスコンプライアンス

オープンソースライセンス違反は、実際の法的・財務的な影響を伴います。 CISAのSBOM活用ガイダンスによると、オープンソースライセンス違反は、ソフトウェアの販売停止やリコール、罰金、評判の失墜につながる可能性があります。これらの影響は、予期せぬコストやサポートの突然の喪失を通じて下流組織にも波及します。

すべてのオープンソースコンポーネントにはライセンスが付与されており、ライセンスは大きく2つのカテゴリに分かれます：

• パーミッシブライセンス（MIT、Apache 2.0、BSDなど）は、最小限の義務（通常は帰属表示のみ）で、プロプライエタリアプリケーションでの利用・改変・配布を許可します。
• コピーレフトライセンス（GNU General Public License（GPL）など）は、より厳格な要件を課します。プロプライエタリコードがGPLライセンスコンポーネントの派生物となり、かつ配布する場合、その派生物もGPLで公開しなければなりません。この「伝染」効果により、意図せずプロプライエタリソースコードの公開を強いられる可能性があります。

このリスクは推移的依存関係によって増幅します。1つのパッケージをインストールするだけで、各自が独自のライセンスを持つ数十の追加依存関係が引き込まれることがあります。アプリケーションには、依存関係ツリーの複数レイヤーにわたり数百のライセンス義務が存在し、3階層下に埋もれた1つのコピーレフトコンポーネントが製品全体にコンプライアンス要件を引き起こすこともあります。この規模での手動追跡は現実的ではありません。

SCAツールは、コードベースを自律的にスキャンし、直接および推移的依存関係すべてのライセンスを特定し、本番環境に到達する前に競合を警告します。SCAプラットフォームは、CI/CDパイプラインでライセンスポリシーを施行し、未承認ライセンスタイプの導入をブロックし、コピーレフトコンポーネントがプロプライエタリコードベースに現れた際には法務チームにアラートを発します。このレベルのガバナンスは、 サプライチェーンリスクをエンタープライズ規模で管理する組織に不可欠であり、特にM&A時には、デューデリジェンスで未申告のGPL利用が発覚し、取引が破談または大幅な評価減となる事例もあります。

これらの機能があっても、SCA導入には計画すべき課題が存在します。

ソフトウェア構成分析の課題と限界

SCAは導入して終わりのソリューションではありません。組織は、十分な予算があってもSCAの効果を損なう4つの課題に直面します。

1. 誤検知とデータ精度の問題：脆弱性インテリジェンスの質が低く、マッチングが不正確だとSCAの有効性が損なわれます。ツールが数千件の検出結果を生成し、実際に悪用可能な脆弱性と理論上のリスクを区別しない場合、アラート疲れが発生します。多くの新規脆弱性にNVDスコアが付与されない深刻度スコアギャップは、エンタープライズアプリケーションポートフォリオ全体での優先順位付けをさらに困難にします。
2. 修正優先順位付けの複雑さ：アプリケーションごとに多数存在する依存関係のうち、実際に悪用可能なリスクを持つものを区別する必要があります。CVSSスコアだけでは不十分です。EPSS（Exploit Prediction Scoring System）データ、脆弱なコードパスが呼び出されているかを示す到達可能性分析、アプリケーションの重要度などのビジネスコンテキストが必要です。多くのSCA実装ではこのような優先順位付けが不足しています。
3. 推移的依存関係の複雑さ：依存関係の依存関係が、修正作業の連鎖的な課題を生みます。1つのコンポーネントをアップグレードすると、新たな脆弱性が発生したり、アプリケーションの機能が壊れることがあります。 OWASP依存関係ガイダンスによれば、開発チームは一次依存関係から複数レイヤーを経て脆弱なコンポーネントに至るまでの完全な関係性を理解する必要があります。これは多くの開発チームが持たないアプリケーションセキュリティスキルを要します。
4. 開発者ワークフロー統合の摩擦：セキュリティスキャンが開発速度を低下させると回避されます。SCAツールが開発者に手動で別プラットフォーム上のレポートを確認させる場合、修正作業が停滞します。IDE統合、プルリクエストスキャンによるインラインフィードバック、到達可能性分析によるリスク優先順位付けが必要です。自律的に特定されても、開発者体験が悪いと運用上の障壁となり、重大な脆弱性の修正が長期間遅れることもあります。

これらの課題は現実的ですが、多くはSCAの本質的な限界ではなく、実装上の意思決定に起因します。どこで導入が失敗するかを知ることで、自社の展開時に最も一般的な落とし穴を回避できます。

ソフトウェア構成分析のよくある導入ミス

エンタープライズのセキュリティチームは、SCA導入時に一貫して5つのミスを犯します。これらを回避することで、SCA投資のリターンが大幅に向上します。

• 推移的依存関係の無視：脆弱性の大半は推移的依存関係に存在しますが、多くのチームは直接依存関係にのみ注目します。攻撃者は、可視性が低く開発者の直接管理外にあるこれらの隠れたレイヤーを狙います。
• 悪用可能性による優先順位付けの失敗：すべてのCVEを同等に扱うと、アラート疲れが発生します。脆弱なコードが到達可能でも、重要なのは悪用可能性です。しかし、多くのチームはCVSSスコアだけに頼り、実際に自社環境で悪用可能かどうかを考慮しません。不正確な脆弱性マッチングは修正リソースを浪費し、実際に悪用可能な脆弱性が未対応のまま残ります。
• ライセンスコンプライアンスの軽視：多くのチームは、SCAツールを脆弱性特定のみに利用し、ライセンスコンプライアンスリスクを無視します。商用ソフトウェア監査では、ライセンスが付与されていないオープンソースコンポーネントや、法的義務が曖昧なカスタムライセンスを含むライセンス競合が頻繁に発見されます。これらのリスクはM&A取引を頓挫させたり、知的財産訴訟を引き起こす可能性があります。
• CI/CD統合の不備：開発ライフサイクルの遅い段階でスキャンを実行すると、修正コストが増加します。重大な脆弱性が検出されてもビルドを失敗させず、単にレポートを生成するだけではギャップが生じます。IDE統合を怠ると、開発者の作業場所から検出結果が切り離されます。SCAを時点スキャンとして扱い、本番環境のコンポーネントを継続的に監視しないと、新たに公開された脅威を見逃します。
• 開発者トレーニングの不足：適切なトレーニングがなければ、開発者はセキュリティ検出結果を障害とみなし、実用的なインテリジェンスと認識しません。推移的依存関係リスクを理解せず、修正戦略の知識がなく、脆弱性レポートを解釈して実際のリスクを判断できません。 OWASP依存関係ガイダンスによれば、開発チームは脆弱性の影響分析や複雑な推移的関係の理解に必要なアプリケーションセキュリティスキルを要します。

これら5つのミスを回避することで、ほとんどのエンタープライズSCA導入より一歩先を行くことができます。実績あるベストプラクティスを適用することで、さらにプログラムを強化できます。

ソフトウェア構成分析のベストプラクティス

SCAを単なる形式的な作業から効果的なセキュリティコントロールに変える違いは、5つの運用プラクティスにあります。

リスクベースの脆弱性優先順位付けを実施：単純な脆弱性件数から高度なリスク評価へ移行しましょう。推移的依存関係を通じたコールパスを静的にモデル化し、自社コードから脆弱なコンポーネントへの到達経路が存在するかを判定できるツールを導入します。複数のシグナルで優先順位付けを行います：

• 基礎的な深刻度のためのCVSSスコア
• 実際の悪用可能性のためのEPSSスコア
• 自社コードベース固有の到達可能性分析
• 影響を受けるアプリケーションの重要度などのビジネスコンテキスト

完全なSBOM管理：各ビルドで標準フォーマット（CycloneDXまたはSPDX）のSBOMを生成し、相互運用性と規制コンプライアンスを確保します。SBOMには、コンポーネントの出所、ダウンロード場所、暗号ハッシュなどセキュリティ関連メタデータを付加し、 脆弱性管理やライセンス義務の追跡を強化します。

シフトレフト型セキュリティ統合： NIST SP 800-204Dガイダンスによれば、組織はプルリクエストでカバーされるすべてのアーティファクトに対して自律的なチェック（セキュリティスキャンを含む）を実行すべきです。SCAは開発ライフサイクルの早期、CI/CDパイプラインに統合して本番到達前にスキャンを実施します。重大な脆弱性が検出された場合はビルドを失敗させ、開発者が無視する可能性のあるレポート生成にとどめないようにします。

効果的な修正ワークフロー：OWASPガイダンスに従い、修正前に完全な依存関係関係性を理解します。 オープンソース依存関係については、自組織を保護しつつ他者のアプリケーションも安全にするパッチやプルリクエストの作成を検討します。SCAプラットフォームによる継続的監視を実装し、本番環境のコンポーネントに新たな脆弱性が公開された際に検出できるようにします。

開発者トレーニング：オープンソースリスクに関する教育を推進し、チームがSCAプラクティスを効果的に統合できるようにします。推移的依存関係が開発者の認識なしに脆弱性を導入することが多いことを教育します。CVSS、EPSS、到達可能性分析を組み合わせ、すべての脆弱性を同等に扱わないフレームワークを提供します。さまざまなオープンソースライセンスの法的影響や、組織の許容ライセンスタイプに関するポリシーもカバーします。

これらのプラクティスを導入することで、適切なプラットフォームがSCAを手動負担から自律的な防御レイヤーへと変えます。

SentinelOneでソフトウェア構成分析を強化

Singularity Cloud Securityは、エージェントレススキャンとOffensive Security Engine™を組み合わせることで脆弱性管理を強化します。プラットフォームは、Verified Exploit Paths™を生成し、実際の攻撃者行動をシミュレートして、どの脆弱性が実際に到達可能かつ悪用可能かを判定し、理論上のリスクと実際に悪用可能な弱点を区別します。このアプローチにより、セキュリティチームは重要なエクスポージャーに修正作業を集中でき、低リスクの検出結果に追われることがなくなります。

CI/CDでシフトレフト

CNSをCI/CDパイプラインに統合し、IaCテンプレート、コンテナイメージ、レジストリをビルドごとにスキャンして設定ミス、脆弱性、漏洩したシークレットを検出します。ポリシーコントロールにより、悪用可能なリスクを導入するビルドのみをブロックし、健全なリリースを維持し、リスクの高いホットフィックスやロールバックの必要性を低減します。

コードリポジトリ、IaC、SaaSアプリのセキュリティ

CNSスキャンを設定したリポジトリやパイプラインを継続的にスキャンし、クラウドプラットフォーム、決済プロバイダ、AI/LLMサービス、SaaSアプリケーション、開発者ツールにわたる750種類以上のシークレットを検出します。デプロイ前にこれらの問題を検出することで、認証情報の漏洩による高額なデータ漏洩、サービス中断、インシデント対応コストのリスクを低減します。

AWS CloudFormation、Terraform、Kubernetes（K8s）マニフェスト、Helmチャートなどの主要プラットフォームにわたるスキャンポリシーを提供します。SentinelOneは、CIS、NIST、GPDR、PCI-DSSなどのコンプライアンスフレームワークに基づく1,000以上のプリセットルールを含みます。カスタムポリシーエンジンにより、セキュリティチームはOPA/Regoスクリプトを用いてビジネス基準に合わせたカスタムルールを作成・施行できます。また、IaCファイルやリポジトリ内のAPIキー、クラウド認証情報、認証トークンも自動検出可能です。

シークレットのアクティブ検証

従来のシークレットスキャンツールは、すでにローテーション済み、失効済み、廃止されたテストサービスに紐づく認証情報を多数検出します。CNSは、漏洩したシークレットが依然として有効か、どこで使用されているかを検証し、古い・冗長な検出結果や影響の小さいキーに時間を浪費するのを防ぎます。修正作業は、実際にデータ損失、不正、サービス中断につながる現役の高価値認証情報に集中できます。

コードからクラウドまでの悪用経路コンテキストを取得

開発者に、コードやCI/CDのリスク（設定ミス、脆弱なベースイメージ、漏洩シークレットなど）が、どのように特定のクラウドリソースや機密データに到達し得るかを正確に示します。CNSは、各検出結果に悪用経路の詳細と影響を受ける資産を付与し、一般的なアラートを理解しやすく、実行可能で優先順位付けしやすい修正チケットに変換します。

ハイパーオートメーションによる修正ワークフロー

ハイパーオートメーションを活用し、優先順位付けされた悪用裏付け付き検出結果を、担当者・深刻度・コンテキスト付きでJiraなどのワークフローツールにルーティングします。セキュリティとエンジニアリングが単一のバックログで作業できます。

Purple AI は、エージェント的推論を用いてアラートを自律的に調査し、アナリストに手動調査を恒久的なハイパーオートメーションワークフローへ変換するよう促すことができます。SentinelOneは、Jira、Okta、Slack、ServiceNowなど100以上のサードパーティツールとの事前構築済みインテグレーションを通じて、セキュリティアクションを自動化できます（Singularity Marketplace経由）。

プラットフォームは、コンテナ化およびクラウドワークロード全体のコンポーネント、ライブラリ、依存関係をカタログ化するSBOMを生成し、NIST SSDFおよび大統領令14028に基づくソフトウェアサプライチェーンの透明性要件に対応します。Singularity Cloud Native Securityは、コードリポジトリ、インフラストラクチャ・アズ・コードテンプレート、コンテナレジストリをスキャンし、本番到達前に脆弱性を特定します。また、シークレットスキャンエンジンは750種類以上のハードコード認証情報を検出します。これにより、 セキュリティチームはクラウド全体の可視性を獲得し、どのアプリケーションに脆弱なコンポーネントが含まれ、どれが即時修正を要するかを特定できます。

SentinelOneのデモをリクエストし、Singularity Platformがどのようにソフトウェアサプライチェーンを保護するかをご確認ください。

主なポイント

ソフトウェア構成分析は、NISTのSecure Software Development Frameworkおよび大統領令14028に裏付けられた、任意ツールから連邦レベルで義務付けられたセキュリティプラクティスへと進化しました。エンタープライズのコードベースは主にオープンソースコンポーネントで構成され、アプリケーションごとに数百の依存関係が存在し、業界調査では大多数に脆弱なコンポーネントが含まれていることが示されています。SCAは不可欠な可視性を提供します。 

効果的な導入には、到達可能性分析を用いたリスクベースの優先順位付け、標準フォーマットでのSBOM管理、プリコミットスキャンによるシフトレフト統合、サプライチェーンリスクに関する開発者トレーニングが必要です。

よくある質問

SCA（ソフトウェアコンポジション解析）とは何ですか？

ソフトウェアコンポジション解析（SCA）は、ソフトウェアをスキャンして、オープンソースおよびサードパーティコンポーネントにおけるリスクを特定、評価、管理するプロセスです。SCAツールは、コードベース内のすべてのコンポーネント（推移的依存関係を含む）をインベントリ化し、NVD、MITRE CVE、GitHub Security Advisoriesなどの脆弱性データベースと照合します。

出力には、脆弱性の検出結果、ライセンスコンプライアンスチェック、実行可能な修正ガイダンスが含まれます。CI/CDパイプラインに統合することで、SCAは脆弱なコンポーネントが本番環境に到達する前に阻止します。

ソフトウェアコンポジション解析はサイバーセキュリティとどのように関連していますか？

SCAは、オープンソースコンポーネントが現代のアプリケーションにおける主要な攻撃対象領域であるため、重要なサイバーセキュリティコントロールです。攻撃者は、古いライブラリの既知の脆弱性を悪用し、悪意のあるパッケージをパブリックレジストリに注入し、開発者が直接管理しない推移的依存関係を標的にします。

SCAは、継続的な監視としてセキュリティ運用に統合され、新たな脆弱性が本番コンポーネントに影響を与えた際にアラートを発し、既知のCVEを含むビルドをブロックし、コンポーネントのハッシュを既知の正常な署名と比較してサプライチェーンの改ざんを検出します。

DevSecOpsにおいてSCAが重要な理由は何ですか？

SCAは、現代の開発スピードに合わせてセキュリティチェックを自動化するため、DevSecOpsに不可欠です。チームが1日に複数回コードをプッシュする場合、手動による依存関係のレビューでは対応できません。CI/CDパイプラインに組み込まれたSCAツールは、すべてのプルリクエストやビルドをスキャンし、重大な脆弱性や未承認ライセンスが検出された場合はデプロイメントを失敗させます。

これにより、修正作業が本番環境での発見後ではなく、コード導入時点で行われるため、修正コストを削減し、リリース速度を落とすことなく継続的なセキュリティ強化を実現します。

SCAはどのような種類の脆弱性を検出しますか？

SCAは、NVD、MITRE CVE、GitHub Security Advisoriesなどのデータベースにカタログ化された既知の脆弱性を検出します。これには、リモートコード実行、インジェクションの脆弱性、認証バイパス、オープンソースコンポーネントにおけるサービス拒否の脆弱性が含まれます。

また、パブリックレジストリに仕込まれた悪意のあるパッケージや、サプライチェーンの侵害を示す署名改ざん済みコンポーネント、法的リスクを生じさせるライセンス違反も特定します。高度なSCAツールは、リーチャビリティ分析を用いて、これらの脆弱性のうち実際にアプリケーションが呼び出すものを判定します。

SCAは規制遵守のために必要ですか？

連邦および国際的なフレームワークは、SCAが提供する機能をますます義務付けています。NISTのセキュアソフトウェア開発フレームワークは、組織に対して開発中にSBOMおよびSLSAプロビナンスドキュメントの生成を求めています。大統領令14028は、ソフトウェアサプライチェーンセキュリティを連邦契約の適格性に影響するコンプライアンス要件へと引き上げました。

EUサイバー・レジリエンス法は、デジタル要素を含む製品に対してセキュア・バイ・デザインの開発手法を要求しています。規制がSCAをツールカテゴリとして明示しない場合でも、SBOMの生成、脆弱性の監視、サプライチェーンリスク管理は、すべてSCAツールが直接対応する要件です。

SCAは推移的依存関係を検出しますか？

はい。推移的依存関係の検出は、SCAの主要な機能です。1つのパッケージをインストールすると、追加の依存関係が多数取り込まれ、それぞれが独自の脆弱性やライセンスを持っています。

SCAツールは、複数のレイヤーにわたる完全な依存関係グラフを構築し、アプリケーション内のすべての直接的および間接的なコンポーネントをマッピングします。この可視性は非常に重要であり、脆弱性の大半は、開発者が明示的に追加せず、ほとんど監視しない推移的依存関係に存在するためです。

SCAとSASTの違いは何ですか？

ソフトウェアコンポジション解析は、アプリケーション内のサードパーティ製オープンソースコンポーネントやライブラリを調査し、自分で記述していないコードの脆弱性を特定します。静的アプリケーションセキュリティテストは、自社のソースコードに存在するセキュリティ上の欠陥を分析します。

エンタープライズのコードベースは主にオープンソースコンポーネントで構成されており、アプリケーションごとに数百の依存関係が存在するため、両方が必要です。これらは補完的な機能であり、CI/CDパイプラインの早い段階で統合する必要があります。SCAをSASTより先に実行することで、まず脆弱な依存関係を検出できます。

最も一般的なSCAの統合ポイントは何ですか？

開発ライフサイクル全体の複数のポイントでSCAを統合します。宣言された依存関係を特定するマニフェストおよびパッケージファイルの分析、インポートされたライブラリを検出するソースコードスキャン、バージョン管理に到達する前に脆弱なコンポーネントをブロックするプリコミットフック、コードレビュー中にインラインフィードバックを提供するプルリクエスト自動化、重大な脆弱性を含むビルドを失敗させるCI/CDパイプラインのステージ、デプロイ済みコンポーネントに新たな脆弱性が公開された際にアラートを発する継続的な本番環境モニタリングなどが含まれます。

SCAは誤検知をどのように処理しますか？

高度なSCA実装では、リーチャビリティ解析を使用して、脆弱なコードパスが実際にアプリケーションのランタイムで呼び出されるかどうかを判断します。この手法は、コードから依存関係を経由して脆弱な関数へのコールツリーをマッピングし、未使用コード内の脆弱性が実際には最小限のリスクしかもたらさないことを特定します。 

リーチャビリティ解析を、悪用可能性を示すEPSSスコアやアプリケーションの重要度に関するビジネスコンテキストと組み合わせることで、修正対応の優先順位付けを行います。

SCAスキャンはどのくらいの頻度で実行すべきですか？

SCAは定期的なスケジュールではなく、継続的に実行します。すべてのプルリクエスト、コミット、ビルドごとに自律的にスキャンを実行し、コード統合前に脆弱性を検出します。 

アプリケーションポートフォリオ全体に対する毎晩のスキャンで、前日まで安全だったコンポーネントに新たに公開された脆弱性を発見します。SCAプラットフォームは本番環境を継続的に監視し、研究者が新しいCVEを公開した際、数時間以内にデプロイ済みアプリケーションへの影響を通知します。