ソフトウェアBOM（ソフトウェア部品表）とは何か？

Aug 19, 2020 / 1 min read

Table of Contents

誰がソフトウェア部品表を必要としているのか？
ソフトウェア部品表には何が含まれているのか？

ソフトウェア部品表は、コードベースに存在するすべてのオープンソースおよびサードパーティ・コンポーネントのリストです。ソフトウェアBOMには、それらのコンポーネントを管理するライセンスの種別、コードベースで使用されるコンポーネントのバージョンとそれらのパッチの提供状況もリストされます。

ソフトウェアの部品表の概念は製造に由来します。部品表は、製品に含まれるすべての部品の詳細を示す目録です。たとえば、自動車業界では、メーカーは各車両の詳細な部品表を管理しています。このBOMには、OEMによって作られた部品と、サードパーティのサプライヤからの部品が一覧表示されます。欠陥のある部品が発見された場合、自動車メーカーは影響を受ける車両を正確に把握し、修理または交換の必要性を車両所有者に通知することができます。

同様に、ソフトウェアを構築するスマートな組織は、コードが高品質で、規格に準拠し、安全であることを保証するために、サードパーティおよびオープンソース・コンポーネントの目録を含む正確で最新のソフトウェア部品表を維持しています。

誰がソフトウェア部品表を必要としているのか？

2021年には、Codecov、Kaseya、最近ではApache Log4jなど、注目を集めるセキュリティ侵害がいくつか発生しました。この種のサプライチェーン攻撃により、バイデン大統領は、政府と取引を行う連邦政府機関、政府機関、請負業者がソフトウェアを保護する方法に関するガイドラインを詳述したサイバーセキュリティに関する大統領令（EO）を発令しました。推奨事項の中には、連邦政府が使用するソフトウェアアプリケーションの安全性と整合性を確保するためのSBOMが要件に挙げられています。

EOは政府とビジネスを行う組織を対象としていますが、SBOMを含むこれらのガイドラインは、すべての組織がソフトウェアアプリケーションを構築、テスト、保護、および運用する方法の事実上のベースラインになる可能性があります。

ソフトウェアを開発する組織は、コードベースのソフトウェア部品表を保守管理する必要があります。組織は通常、カスタムビルドのコード、市販のコード、オープンソース・コンポーネントを組み合わせてソフトウェアをビルドします。実際、大手ソフトウェア・サプライチェーン・プロバイダーのアーキテクトは、「ソフトウェアの部品表により、組織はコードベースのすべてのコンポーネントを追跡できます。」と述べています。

ソフトウェア部品表には何が含まれているのか？

オープンソース・コンポーネント

開発者はオープンソース・コンポーネントを使用しましたか?

ある調査では90％以上のソフトウェアにオープンソース・コンポーネントが使用されているとのこと。なぜなら、オープンソースを利用することで、ソフトウェア開発の時間を短縮し、開発者のみならず、顧客がメリットを享受できるからです。

しかし、使用しているソフトウェア部品をきちんと把握している企業はほとんどありません。オープンソース・コンポーネントを含む、正確で最新のソフトウェア部品表を作成できる企業の数はさらに少なくなります。包括的なソフトウェア部品表には、アプリケーションのすべてのオープンソース・コンポーネントと、それらのコンポーネントのライセンス、バージョン、およびパッチの状況が一覧で表示される必要があります。

オープンソース・ライセンス

アプリケーションに含まれているオープンソース・コンポーネントのライセンスの種類がパーミッシブかウィルス性（バイラル）かを知っていますか？上位のオープンソースライセンスの1つまたは1回限りの派生物を使用しているか分かりますか?

オープンソース・ライセンスに準拠していない場合、訴訟や知的財産（IP）の侵害という重大なリスクにさらされる可能性があります。ソフトウェア監査サービスチームが実施した調査の95％で、ターゲットがそこに含まれていたと知らなかったオープンソースを見つけました。さらに、2018年に監査したコードベースの68％には、ライセンスの競合があるコンポーネントが含まれていました。ソフトウェアの部品表には、使用するコンポーネントを管理するオープンソース・ライセンスがリストされているため、法的リスクとIPリスクを評価できます。

オープンソースのバージョン

自身のコードベースに含まれるオープンソース・コンポーネントが今でも保守されているかどうか知っていますか?運用リスクは、オープンソースを使用する際に避けては通れない課題です。そして、多くのオープンソース・コンポーネントは放棄され保守されていません。つまり、そのコンポーネントは貢献し、パッチを当て、改善してくれる開発者のコミュニティを持っていないということです。最近のGartner社の調査では、「オープンソース・プロジェクトの長期的な生存可能性」が開発組織の最大の関心事であることがわかりました。

コンポーネントの更新がなされておらず、誰もそれを保守していない場合、当然のことながら脆弱性などの潜在的な問題に対処できていません。監査サービスチームは、2018年にスキャンしたコードベースの85％に、4年以上古くなっているか、過去2年間に開発活動がなかったオープンソース・コンポーネントが含まれていることを発見しました。ソフトウェア部品表には、コードベース内のオープンソース・コンポーネントのバージョンがリストされる必要があるのは、古くて安全性が低い可能性のあるコードを使用しているかどうかを判断するためです。

オープンソースの脆弱性

使用しているオープンソース・コンポーネントに既知の脆弱性があるかどうか知っていますか?オープンソースの脆弱性の数は、専有ソフトウェアと比べれば少ないものの、2018年だけで7,000個以上が、過去20年間で50,000個以上の脆弱性が発見されています。監査サービスチームは、2018年に調査したコードベースの60％に少なくとも1つのオープンソースの脆弱性が含まれ、40％以上にはよりリスクの高いオープンソースの脆弱性が含まれていることを発見しました。

Apache StrutsやOpenSSLのほんの一部のオープンソースの脆弱性が、広く悪用される可能性があります。しかし、このようなエクスプロイトが発生すると、2017年のEquifaxで起こったデータセキュリティ侵害と同様に、オープンソース・セキュリティの必要性がたちまちニュースとなります。ここで、ソフトウェア部品表が役立つはずでした。「部品表がなかったために、Equifaxがネットワークに脆弱性が存在するかどうかを知ることは、不可能ではないにしても困難になりました」と結論付けられました。「脆弱性が見つからなければ、パッチを当てることはできないからです。」