2021年に発表されたソフトウェアコンポーネントの管理に関する調査によると、現代のソフトウェアのうち75%はOSSでできていると報告されています。もちろん、業種や業態による違いはありますが、自動車業界においては70%、IoT領域では90%近くがOSSで構成されているそうです。このように多くのOSSが使われる状況では、その製品・サービスがどのような構成で、どこにどんなOSSが入っているのかを正確に把握することは、非常に困難です。

そして、中身がわからないということは、その製品・サービスの安全性やセキュリティ、品質に大きな影響を及ぼします。例えば、製品で使用しているOSSに脆弱性や不具合があったらどうでしょう。長期間メンテナンスが行われていないものや、悪意のあるマルウェアが仕込まれている可能性もあります。

このような背景から、ソフトウェアの透明性についての議論が始まりました。この議論は、製品やサービスの構成要素を可視化し、正確に把握することで、脆弱性や不具合を早期に検知し対策を講じようという考え方に基づいています。2018年に米国NTIA、電気通信情報管理局により始まったSoftware Component Transparencyの議論は、ソフトウェアの脆弱性情報の理解と処理、成長するIoTマーケットへの対処、安全なソフトウェア開発ライフサイクルの促進について検討し、それを実現する具体的な実行手段としてSoftware Bill of Materials、SBOMが有効であるという方針が出されています。

SBOM（「えすぼむ」と読みます）は、製品やサービスを構成する一つひとつのパーツであるコンポーネントの構成情報の一覧です。OSS界隈では「ソフトウェアに含まれているOSSの一覧」を指すこともあるのですが、一般的には「ソフトウェアを構成するコンポーネント（OSSに限らない）の一覧」という定義が正しいと思います。

SBOMという概念は10年以上前から存在しており、個人的には非常にクラシックなものだと思っています。SBOMを生成することができるツールなども当時からあったのですが、このころのSBOMは、単なる「OSSコンポーネントの一覧」として当該ソフトウェアのライセンス遵守の目的で使われており、正直なところ、あまり重要視されていませんでした。SBOMが近年のように注目されるようになった理由は、その活用方法と有用性が認知され、みんながその情報を欲しがるようになったからだと思います。

SBOMは、既知の脆弱性情報と組み合わせることで製品のセキュリティ対応に、End of Life情報と組み合わせることでライフサイクル管理に、サプライチェーンの情報と組み合わせることでサプライチェーンマネジメントにと、さまざまな外部情報と組み合わせることで効果を発揮します。きちんとメンテナンスされたSBOMを持っていれば、随時更新される外部情報を都度引当てし、最新の情報を用いたリスクマネジメントがいつでも行えるため、特にセキュリティの目的で活用されることが増えています。

SBOMは今年、2021年5月に署名されたアメリカの大統領令で言及されたことにより、大きな話題になりました。この大統領令は、サイバーセキュリティ対策の改善に関するものとして、連邦政府の情報システムに求められるサイバーセキュリティ対策の基準と要件について述べられており、システムを構成するソフトウェアの部品表、すなわちSBOMの作成と提供を求め、それを元に脆弱性のチェックと修復を行うべし、ということが明確に記載されています。

この大統領令に関する情報は、経済産業省　商務情報政策局　サイバーセキュリティ課が発表した「サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォースの検討の方向性」というドキュメントにわかりやすく纏められていますので、興味のある方は読んでみてください。

また、本ブログにも米国連邦政府から発表された「SBOMの最小構成」に関するブログ記事がありますので、合わせてチェックしてみてください。

当社の「OSS検証支援プラットフォーム　レポーティングツール」は、SBOMの構成情報をもとにNVDの脆弱性情報と任意のタイミングで引き当てを行い、関連する脆弱性情報を特定してレポートを作成することができます。また、SBOMを読み込んで蓄積することもできますので、サプライヤから提供されたSBOMの格納庫としても有用です。

According to a survey on software component management, which was published in 2021, 75% of all source code was composed of Open Source Software (OSS). There is difference among industries, of course, but it is 70% in the automotive industry, and it is more than 90% in the IoT industry. Under the circumstances where most software is depending on hundreds or thousands of OSS libraries, knowing correctly what components are in your source code (of products or services) is nearly impossible.

Your uncertainness of the contents of the software seriously affects the safety, security and quality of the products or services. What if there is a vulnerability or a defect in the OSS which you use in your product? What if the OSS has not been maintained for a long time? What if some malware sneaked in?

Those situations led people to start discussing software transparency. This discussion is based on the idea that creating a visualization of software components of products or services helps to identify and remediate vulnerabilities and defects at an early stage. The discussion of Software Component Transparency, started by the U.S. National Telecommunications & Information Administration in 2018, is focusing on understanding and handling vulnerability information, addressing the insecurities in the growing IoT marketplace, and fostering a secure development lifecycle. As a concrete method for that, SBOM enables better software security and supply chain risk management.

SBOM (which is pronounced “ess-bomb”) is “a formal record containing the details and supply chain relationships of various components used in building software”. OSS-related people sometimes refer to the list of OSS components in the software as SBOM, but “the list of Software Components (not limited to OSS) in the software” is a more appropriate definition for our understanding.

The idea of SBOM has existed since over 10 years ago, the idea itself is very classic for me. Some tools to create SBOM automatically have existed from that time. SBOM at that time was just “a list of OSS components in your products”, used for license compliance, so it was not regarded as important (to be honest). The reason why SBOM became a focus of every industry’s attention is people came to know how to use it and noticed its usefulness, then came to desire it.

SBOM enables better security risk management when it is associated with known vulnerability information. SBOM enables better software lifecycle management when it is associated with the information of End of Life. SBOM also enables better supply chain risk management when it is associate with the information of their dependency relationship and the origin. Mapping SBOM to other sources of information has a beneficial effect on company’s risk management and remediation. Recently SBOM is commonly used for security risk management.

SBOM became famous because it was referred to in the Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity which was issued by the President of the United States on May 12, 2021. It is stated that all Federal Information Systems should meet or exceed the standards and requirements for cybersecurity that are described in this EO. As a guidance identifying practices that enhance the security of the software supply chain, creating and offering SBOM for each product to check for known and potential vulnerabilities and remediate them was clearly recommended.

For any further details, I would like recommend you to read the document “サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォースの検討の方向性” published by Ministry of Economy, Trade and Industry. Another article in our blog, regarding “The Minimum Elements for an SBOM” published by the United States Department of Commerce, is also helpful.

With “OSS検証支援プラットフォーム　レポーティングツール”, customers can check for known vulnerabilities on a regular basis and create a security risk report. It is also useful as a repository for SBOM that you have received from others.