ソフトウェア構成分析(SCA)とは?
ソフトウェア構成分析(SCA)は、アプリケーションで使用されているオープン ソース パッケージを詳細に分析します。リスク評価やコンプライアンス評価のために、依存関係の脆弱性とライセンスを明確にします。また、すべてのリソースのソフトウェア部品表(SBOM)を生成し、社内の利害関係者や社外の顧客と共有することができます。
ソフトウェア構成分析とは?
開発者は、ソフトウェア構成分析を使用することで、組織を不要な脆弱性または法的およびコンプライアンス上の問題にさらすことなく、オープン ソース パッケージを利用できます。
現代のソフトウェア開発ではオープン ソース コンポーネントが浸透しており、最新のアプリケーションのコードベースの大部分はそれらのパッケージで構成されています。これらのコードは自由に利用でき、コミュニティによって十分に検証されていて、再作成する必要がないため、開発作業にかかる時間を短縮できます。ただし、このプロセスには固有の一連のリスクも伴います。
オープン ソース コンポーネントを使用するリスクとは?
開発者は、オープン ソース コンポーネントを使用してコンテナ イメージを構築する前に、パッケージでこれまでに発見された脆弱性に由来するセキュリティ上の懸念について認識する必要があります。また、ソフトウェア使用ライセンスに関するコンプライアンス要件を満たしていることを確認する必要もあります。
コミュニティのメンバーは頻繁に脆弱性を発見してパッチを適用しますが、コードを更新する責任は開発者にあります。脆弱性が発見された場合、パブリック エクスプロイトが公開されるのは時間の問題であり、低レベルの攻撃者でもその問題を利用できます。
この問題は、ソフトウェアの脆弱性の大部分は、直接参照しているパッケージまたはルート パッケージにあるのではなく、依存関係の依存関係に(複数の層の奥深くに)存在しているという事実によって悪化します。使用しているルート パッケージだけを修正しても、使用中のライブラリが常に安全であるとは限りません。
さらに、オープン ソース ライセンスは多数存在し、使用されるルールもさまざまです。たとえば、帰属要件があるライセンスや、コンポーネントを使用するアプリケーションもそのソース コードを公開する必要があるライセンスがあります。ライセンスとそのルールをすべて追跡し続けるのが難しい場合があります。
ソフトウェア構成分析によるオープン ソース パッケージのリスクの特定
SCAツールは、アプリケーション内のすべてのオープン ソース パッケージおよびそれらのパッケージのすべての既知の脆弱性を特定します。この情報は、開発者が作成したコードに存在する問題を、それが悪用される前に開発者に通知するために使用できます。優れたソフトウェア構成分析プロセスは、パッケージ マネージャだけでなく、Infrastructure as Code (IaC)やKubernetesマニフェストも調査し、イメージをプルしてその脆弱性を特定します。
IaCテンプレートへの接続と無制限の依存関係スキャンを備えたSCAツールは、脆弱性が未検出または未解決にならないことを保証します。
ソフトウェア構成分析ツールは、アプリケーションで使用されているすべてのオープン ソース コンポーネントを含むソフトウェア部品表(SBOMまたはソフトウェアBOM)を生成することもできます。SBOMには、パッケージ バージョンの詳細や、使用されている各コンポーネントの既知の脆弱性とライセンスに関する詳細がリストされます。たとえば、Pythonの場合、BOMには、httplib2など、import文で指定されるすべてのパッケージが、そのバージョン番号、発見されている脆弱性、およびライセンスとともにリストされます。
SCAプログラムにより、エンジニアリング、DevOps、セキュリティ、コンプライアンスの各チームなど、利害関係者間のコラボレーションが可能になります。多くの組織はSCAプログラムを使用して、露出を制御するための組織のコンプライアンス義務に違反するオープン ソース コンポーネントがコードに含まれている場合にアラートを生成したり、コードがリポジトリにマージされないようブロックしたりします。脆弱性およびライセンス タイプの許容可能な重大度レベルを決定するには、関連する利害関係者が関与する必要があります。
開発プロセスでSCAを使用する方法
優れたSCAプロセスは、開発プロセス全体に組み込まれています。開発者は、ローカル環境で作業するときから、コードを書きながらその脆弱性やライセンスのコンプライアンスをチェックできる必要があります。
SCAツールは、統合開発環境(IDE)プラグインを使用することで、開発者がパッケージを追加する際に脆弱性について通知できます。コードがリポジトリにコミットされる前に、チェックおよび自動化されたプル リクエスト コメントによって、新たに発生する問題が通知され、要件を満たさないコードがブロックされるようにする必要があります。
これを導入環境にも引き継いで、事前定義されたレベルの脆弱性または事前定義された種類のライセンスを使用するソフトウェアの導入をブロックできるようにする必要があります。また、セキュリティ チームは、環境内のコンポーネント状況を幅広く可視化する必要があります。
ソフトウェア構成分析は、コードからクラウド、インフラストラクチャからアプリケーション レイヤーまでカバレッジを拡大して、開発ライフサイクル全体で脆弱性を追跡します。
すべての領域で、パッケージが暴露する可能性があるリスクについて開発者に通知する必要があります。脆弱性には、重要性とインフラストラクチャへの影響(プライベートVPCに脆弱なパッケージが存在する場合など)に基づいて(たとえば、CVEスコアおよび脆弱性報告後の経過時間を使用して)、ランク付けと優先順位付けが行われる必要があります。ライセンスは、許可される(ただし帰属などの追加の詳細を示す必要がある)ライセンスおよび組織のポリシーの下では許可されないライセンス(「コピーレフト」ライセンスなど)に分類する必要があります。
ソフトウェア構成分析のメリット
チームにとって重要なのは、アプリケーション環境の状況を認識することです。ソフトウェア構成分析は、ライセンスのコンプライアンスおよび脆弱性について早期段階で数多くフィードバックすることで、アプリケーションでオープン ソース コンポーネントを使用するリスクの一部を軽減するのに役立ちます。パッチを完全に適用することは困難ですが、リスクを把握し、脆弱性を修正するコストを検討することは、セキュリティ体制を改善するために不可欠です。
現在の開発プロセスの保護については、「DevSecOpsとは何か」をご覧ください。