現在のソフトウェア開発環境では、オープンソースソフトウェア(OSS)が多くの企業や開発者にとって第一の選択肢となっています。しかし、オープンソース ソフトウェアを使用すると潜在的なリスクも伴うことをご存知ですか?ソフトウェア構成分析 (SCA) は、開発者がコードに埋め込まれたオープン ソース コンポーネントをレビューして、それらが最新であるか、セキュリティ上の脆弱性がないか、ライセンス要件に準拠しているかどうかを確認するのに役立つ方法です。
オープンソース ソフトウェアは、柔軟性と開発コストの削減により広く支持されていますが、その背後にあるリスクは見過ごされがちです。
異なるコンポーネントからソフトウェアを開発するこのアプローチは、オープンソース ソフトウェアの台頭により、1990 年代後半からますます一般的になってきました。このアプローチでは、大規模なコードベースの複雑さを小さな部分に分割して、柔軟性を高め、開発プロセスを高速化します。ただし、オープンソース ソフトウェアがもたらすリスクは、使用されるコンポーネントが増えるにつれて明らかに増大し、これらのリスクは主に次の 5 つのカテゴリに分類できます。
オープンソース コンポーネントを広範に活用する組織にとって、自動分析とリスク管理は必須になりつつあります。
SCA 製品は通常、次のように動作します。まず、スキャン エンジンがソフトウェア ソース コードとそれをコンパイルするために使用される関連成果物を調べ、使用されているオープン ソース コンポーネントとそのバージョンを識別します。この情報はデータベースに保存され、使用されているオープンソース コンポーネントのカタログが形成されます。次に、このカタログは、既知のセキュリティ脆弱性、ライセンス要件、および履歴バージョンのデータベースと比較されます。
たとえば、セキュリティの脆弱性検出を実行する場合、この比較は多くの場合、National Vulnerability Database (NVD) で追跡されている既知のセキュリティの脆弱性と比較されます。一部の製品では、チェックのために追加の独自の脆弱性データベースが使用される場合があります。知的財産と法令遵守のために、SCA 製品はオープン ソース コンポーネントで使用されるライセンスの種類を抽出し、評価します。これらの結果は通常、さまざまなデジタル形式でユーザーに提供され、さまざまな製品のニーズ、特に強力な共有ライセンスまたは弱い共有ライセンスの要件に基づいたリスク評価と法的要件の推奨事項が含まれます。
結果には、ソフトウェア アプリケーションで使用されるオープン ソース コンポーネントとそのプロパティの詳細を示すサービス コンポーネント マニフェスト (SBOM) も含まれる場合があります。
SCA はさまざまな組織機能に影響を与えるため、組織の規模や構造に応じて、さまざまなチームがこのデータを活用します。 IT 部門は SCA を使用してテクノロジを実装および運用します。主要な関係者には、最高情報責任者 (CIO)、最高技術責任者 (CTO)、最高エンタープライズ アーキテクト (EA) が含まれます。セキュリティおよび承認データは、最高情報セキュリティ責任者 (CISO) がセキュリティ リスクを管理するためによく使用されますが、最高 IP/コンプライアンス責任者は知的財産リスクに重点を置いています。 SCA 製品の機能に応じて、これらのツールは開発者の統合開発環境 (IDE) で直接使用することも、ソフトウェア品質管理プロセスの必要なステップとして使用することもできます。
SCAの利点と欠点米国などの一部の国では、ベンダーが政府機関に提供するソフトウェアのセキュリティを確保するために、SBOM の生成が必須となっています。
自動化は SCA 製品の主な利点です。開発者がオープンソース コンポーネントを使用して統合する場合、追加の手作業を行う必要はありません。これには、他のオープンソース コンポーネントへの間接参照の自動処理も含まれます。しかし、現在のSCA製品には、導入プロセスが複雑で時間がかかり、完全に運用できるようになるまでに数か月かかる場合があること、各製品が独自のOSSコンポーネントライブラリを使用していること、これらのライブラリのサイズと範囲が狭いことなど、いくつかの重要な弱点もあります。制限されています。割合は大きく異なる可能性があり、脆弱性データは、NVD で正式に報告された脆弱性のみの報告に限定されることがよくあります。
さらに、SCA 製品には、自動化されたガイダンスが不足していることが多く、レポート内のデータに対して実行するアクションに関する推奨事項が不十分で、検出された OSS ライセンスの法的要件に関するガイダンスがほとんどありません。
このような背景から、オープンソース ソフトウェアの潜在的なリスクをより効果的に管理し、脅威からコードを保護する方法についても考えていますか?