Loading article…
ソフトウェア構成分析（SCA）は、情報技術とソフトウェアエンジニアリングの分野における実践であり、カスタムビルドのソフトウェアアプリケーションを分析して、埋め込まれたオープンソースソフトウェアを検出し、それらが最新であるか、セキュリティ上の欠陥が含まれているか、ライセンス要件があるかどうかを検出します。[1]
背景
さまざまなコンポーネントを使用してソフトウェアを開発することは、ソフトウェアエンジニアリングの一般的な手法です。[2]ソフトウェアコンポーネントを使用すると、大きな要素の複雑さが小さなコードに分割され、新しい要件に対応するためにコンポーネントを簡単に再利用できるため、柔軟性が向上します。[3]この手法は、オープンソースソフトウェア(OSS)の普及により、ソフトウェア開発プロセスの高速化と市場投入までの時間の短縮に役立つため、1990 年代後半から広く普及しています。[4]
しかし、オープンソースソフトウェアを使用すると、開発中のソフトウェアアプリケーションに多くのリスクが生じます。これらのリスクは5つのカテゴリに分類できます。[5]
- OSS バージョン管理: 新しいバージョンによって導入される変更のリスク
- セキュリティ: コンポーネントの脆弱性のリスク -共通脆弱性識別子(CVE)
- ライセンス:知的財産(IP) の法的要件のリスク
- 開発: 既存のコードベースとオープンソースソフトウェア間の互換性のリスク
- サポート: ドキュメントが不十分でソフトウェア コンポーネントが古くなるリスク
1998年2月にオープンソース・イニシアティブが設立されて間もなく[6] 、 OSSに関連するリスクが指摘され[7]、組織はスプレッドシートやドキュメントを使用して開発者が使用するすべてのオープンソース・コンポーネントを追跡し、これを管理しようとしました[8] 。
オープンソース コンポーネントを広範に使用している組織では、オープンソース リスクの分析と管理を自動化する支援が必要でした。その結果、組織がオープンソース リスクを管理するのに役立つソフトウェア コンポジション分析 (SCA) と呼ばれる新しいカテゴリのソフトウェア製品が生まれました。SCA は、ソフトウェア アプリケーション内で使用されているすべてのサードパーティ コンポーネントを検出し、セキュリティの脆弱性、IP ライセンス要件、使用されているコンポーネントの陳腐化に関連するリスクを軽減することを目指しています。
動作原理
SCA製品は通常、次のように機能します。[9]
- エンジンは、ソフトウェアのソース コードと、ソフトウェア アプリケーションのコンパイルに使用される関連成果物をスキャンします。
- エンジンは OSS コンポーネントとそのバージョンを識別し、通常はこの情報をデータベースに保存して、スキャンされたアプリケーションで使用されている OSS のカタログを作成します。
- 次に、このカタログは、各コンポーネントの既知のセキュリティ脆弱性、コンポーネントを使用するためのライセンス要件、およびコンポーネントの過去のバージョンを参照するデータベースと比較されます。[要出典]セキュリティ脆弱性の検出の場合、この比較は通常、 National Vulnerability Database (NVD)で追跡されている既知のセキュリティ脆弱性 (CVE) に対して行われます。一部の製品では、追加の独自の脆弱性データベースを使用しています。IP / 法令遵守の場合、SCA 製品は、OSS コンポーネントに使用されるライセンスの種類を抽出して評価します。[10]コンポーネントのバージョンは、 GitHub、Maven、PyPi、NuGetなどの一般的なオープンソースリポジトリから抽出されます。
- 結果は、さまざまなデジタル形式でエンドユーザーに提供されます。内容と形式はSCA製品によって異なりますが、リスクを評価および解釈するためのガイダンスや、特に強弱コピーレフトライセンスなどのオープンソースコンポーネントの法的要件に関する推奨事項が含まれる場合があります。出力には、ソフトウェアアプリケーションで使用されるすべてのオープンソースコンポーネントと関連属性の詳細を示すソフトウェア部品表（SBOM）も含まれる場合があります[11]
使用法
SCA は組織内のさまざまな機能に影響を与えるため、組織の企業規模や構造に応じて、さまざまなチームがデータを使用する場合があります。IT 部門は、最高情報責任者 (CIO)、最高技術責任者 (CTO)、最高エンタープライズ アーキテクト (EA) などの共通の利害関係者とともに、テクノロジを実装および運用するために SCA を使用することが多いです。 [12]セキュリティとライセンスのデータは、セキュリティ リスクについては最高情報セキュリティ責任者 (CISO)、知的財産リスク管理については最高 IP/コンプライアンス責任者などの役割によってよく使用されます。[13]
SCA製品の機能に応じて、OSSコンポーネントを使用および統合する開発者の統合開発環境（IDE）内に直接実装することも、ソフトウェア品質管理プロセスの専用ステップとして実装することもできます。[14] [15]
SCA製品、特にSBOMを生成する能力は、米国などの一部の国では、ベンダーが自国の機関に納品するソフトウェアのセキュリティを強化するために必要とされています。[16]
SCAのもう一つの一般的な使用例は、テクノロジーデューデリジェンスです。合併と買収（M&A）取引の前に、アドバイザリー会社は対象企業のソフトウェアに関連するリスクをレビューします。[17]
強み
SCA製品の自動化は、その主な強みです。開発者は、OSSコンポーネントの使用や統合時に手動で余分な作業を行う必要がありません。[18]自動化は、コードや成果物内の他のOSSコンポーネントへの間接参照にも適用されます。[19]
弱点
逆に、現在の SCA 製品の主な弱点としては、次のようなものが挙げられます。
- 複雑で労働集約的な展開であり、完全に運用できるようになるまでには数か月かかることがある[20]
- 各製品は、OSSコンポーネントの独自のデータベースを使用しており、そのサイズや範囲は大きく異なる可能性がある[21]
- 脆弱性データの報告をNVDで公式に報告された脆弱性のみに限定する（脆弱性が最初に発見されてから数か月経過している可能性がある）[22]
- SCAレポートとデータに基づいて取るべき行動に関する自動ガイダンスの欠如[23]
- OSSライセンスの法的要件に関するガイダンスの欠如が検出された[24]
参照
参考文献
- ^ Prana, Gede Artha Azriadi; Sharma, Abhishek; Shar, Lwin Khin; Foo, Darius; Santosa, Andrew E; Sharma, Asankhaya; Lo, David (2021年7月). 「見えないと忘れられる？脆弱な依存関係がオープンソースプロジェクトに与える影響」. Empirical Software Engineering . 26 (4). Springer: 1– 34. doi :10.1007/s10664-021-09959-3. S2CID 197679660.
- ^ Nierstrasz, Oscar; Meijler, Theo Dirk (1995). 「ソフトウェア構成の研究方向」ACM Computing Surveys . 27 (2). ACM: 262– 264. doi : 10.1145/210376.210389 . S2CID 17612128.
- ^ Nierstrasz, Oscar; Dami, Laurent (1995年1月).オブジェクト指向ソフトウェア構成. Prentice Hall International. pp. 3– 28. CiteSeerX 10.1.1.90.8174 .
- ^ デ・フン、ミシェル・JL;井本誠也ノーラン、ジョン。宮野悟（2004年2月） 「オープンソースのクラスタリングソフトウェア」。バイオインフォマティクス。20 (9): 1453–1454。書誌コード:2004Bioin..20.1453D。CiteSeerX 10.1.1.114.3335。土井：10.1093/バイオインフォマティクス/bth078。
- ^ Duc Linh, Nguyen; Duy Hung, Phan; Dipe, Vu Thu (2019). 「オープンソースソフトウェアに基づくプロジェクトにおけるリスク管理」。 2019年第8回国際ソフトウェアおよびコンピュータアプリケーション会議の議事録。pp. 178– 183。doi :10.1145 / 3316615.3316648。ISBN 9781450365734.S2CID 153314145 。
- ^ 「OSIの歴史」Opensource.org、2006年9月19日。
- ^ Payne, Christian (2002). 「オープンソースソフトウェアのセキュリティについて」(PDF) . Information Systems Journal . 12 : 61– 78. doi :10.1046/j.1365-2575.2002.00118.x. S2CID 8123076.
- ^ Kaur, Sumandeep (2020 年 4 月). 「オープンソース ソフトウェアのセキュリティ問題」(PDF) . International Journal of Computer Science & Communication : 47– 51.
- ^ Ombredanne, Philippe (2020年10月). 「フリーおよびオープンソースソフトウェアライセンスコンプライアンス：ソフトウェア構成分析ツール」. Computer . 53 (10): 262– 264. doi : 10.1109/MC.2020.3011082 . S2CID 222232127.
- ^ Duan, Ruian; Bijlani, Ashish; Xu, Meng; Kim, Taesoo; Lee, Wenke (2017)。「大規模なオープンソースライセンス違反と1日のセキュリティリスクの特定」。2017 ACM SIGSACコンピュータおよび通信セキュリティ会議の議事録。ACM。pp. 2169– 2185。doi :10.1145/3133956.3134048。ISBN 9781450349468. S2CID 7402387。
- ^ Arora, Arushi; Wright, Virginia; Garman, Christina (2022). 「運用技術のセキュリティ強化: 現代の部品表の理解」(PDF) . Journal of Critical Infrastructure Policy . 3 : 111–135 . doi :10.18278/jcip.3.1.8.
- ^ Bailey, T.; Greis, J.; Watters, M.; Welle, J. (2022年9月19日). 「ソフトウェア部品表：ソフトウェアのサイバーセキュリティリスクの管理」. McKinsey & Company . 2024年1月6日閲覧。
- ^ Popp, Karl Michael (2019年10月30日). オープンソースソフトウェアの商用利用に関するベストプラクティス。BoD – Books on Demand、2019年。p. 10。ISBN 9783750403093。
- ^ Imtiaz, Nasif; Thorn, Seaver; Williams, Laurie (2021年10月)。「ソフトウェア構成分析ツールによる脆弱性報告の比較研究」。第15回ACM / IEEE国際シンポジウム実証的ソフトウェア工学および測定(ESEM )の議事録。ACM。pp . 1– 11。arXiv : 2108.12078。doi :10.1145 / 3475716.3475769。ISBN 9781450386654. S2CID 237346987。
- ^ Sun, Xiaohan; Cheng, Yunchang; Qu, Xiaojie; Li, Hang (2021 年 6 月)。「DevSecOps に基づくセキュリティ テスト パイプラインの設計と実装」。2021 IEEE第4 回高度情報管理、通信、電子および自動化制御会議 (IMCEC)。第 4 巻。IEEE。pp. 532– 535。doi :10.1109/ IMCEC51613.2021.9482270。ISBN 978-1-7281-8535-4. S2CID 236193144。
- ^ 「ソフトウェア部品表の要素と考慮事項」。連邦官報。2021年2月6日。 2024年1月6日閲覧。
- ^ Serafini, Daniele; Zacchiroli, Stefano ( 2022 年 9 月)。 「オープンソース コードの効率的な先行公開識別」。第 18 回オープン コラボレーション国際シンポジウム。第 4 巻。ACM。pp. 1– 8。arXiv : 2207.11057。doi : 10.1145 / 3555051.3555068。ISBN 9781450398459. S2CID 251018650。
- ^ Chen, Yang; Santosa, Andrew E; Sharma, Asankhaya; Lo, David (2020 年 9 月)。「脆弱性データからのライブラリの自動識別」。ACM/IEEE 第 42 回国際ソフトウェア工学会議の議事録: 実践的なソフトウェア工学。pp. 90– 99。doi : 10.1145 / 3377813.3381360。ISBN 9781450371230. S2CID 211167417。
- ^ 岡 健吾、デニス (2021)。「自動車業界におけるソフトウェア構成分析」。安全な自動車の構築。Wiley。pp. 91– 110。doi : 10.1002 /9781119710783.ch6。ISBN 9781119710783. S2CID 233582862。
- ^ Rajapakse, Roshan Namal; Zahedi, Mansooreh; Babar, Muhammad Ali (2021). 「DevOps へのセキュリティツールの統合に関する実務者の視点の実証分析」。第15 回 ACM / IEEE 国際シンポジウム実証ソフトウェア工学および測定 (ESEM )の議事録。pp . 1– 12。arXiv : 2107.02096。doi :10.1145/3475716.3475776。ISBN 9781450386654. S2CID 235731939。
- ^ Imtiaz, Nasif; Thorn, Seaver; Williams, Laurie (2021). 「ソフトウェア構成分析ツールによる脆弱性報告の比較研究」。第15回ACM / IEEE国際シンポジウム実証ソフトウェア工学および測定(ESEM)の議事録。pp . 1– 11。arXiv : 2108.12078。doi :10.1145 / 3475716.3475769。ISBN 9781450386654. S2CID 237346987。
- ^ 「コンポーネント分析」。owasp.org。
- ^ Foo, Darius; Chua, Hendy; Yeo, Jason; Ang, Ming Yi; Sharma, Asankhaya (2018). 「ライブラリ更新の効率的な静的チェック」。2018年26回 ACM 欧州ソフトウェア エンジニアリング会議合同会議およびソフトウェア エンジニアリングの基礎に関するシンポジウムの議事録。pp. 791– 796。doi :10.1145/3236024.3275535。ISBN 9781450355735. S2CID 53079466。
- ^ Millar, Stuart (2017 年 11 月)。「オープンソース ソフトウェアの脆弱性検出: 解決策と原因」(PDF)。クイーンズ大学ベルファスト。