ソフトウェア部品表（SBOM）の導入は難しくありません：これらのツールがソフトウェア部品表を自動で作成します。
中身を知ってこそ、すべてが正しく行われていると確信できます。これはファストフードにもソフトウェアにも当てはまります。
写真：Geka – shutterstock.com
ソフトウェアを安全に保つには、そのコードに何が含まれているかを知る必要があります。このため、ソフトウェア部品表（SBOM）は今や不可欠です。SolarWinds攻撃やLog4j脆弱性は、特にオープンソースソフトウェアにおいて、ソフトウェアサプライチェーンのセキュリティに注目する重要性を明らかにしました。Tidelift社の調査（PDF）によると、現在92％のアプリケーションがオープンソースコンポーネントを含んでいます。現代的な平均的アプリケーションは、その70％がオープンソースソフトウェアで構成されています。
Linux Foundation、Open Source Security Foundation、OpenChainによれば、潜在的なリスクへの答えはSBOMです。SBOMは、ソフトウェアパッケージとその内容を一意に識別する正式かつ機械可読なメタデータです。ソフトウェア部品表には、著作権やライセンス情報などの他の情報も含めることができます。SBOMは組織間で交換できるように設計されています。特に、ソフトウェアサプライチェーンの参加者が提供するコンポーネントの透明性を確保するのにSBOMは非常に役立ちます。
SBOM – ベストプラクティス
-
アプリケーションのオープンソースライブラリ；
-
プラグイン、拡張機能、その他の追加モジュール；
-
社内開発者が自ら記述したソースコード；
-
これらのコンポーネントのバージョン情報、ライセンス・パッチ状況；
-
コンポーネントの自動暗号署名と検証；
-
CI/CDパイプラインの一部としてSBOMを自動生成するスキャン。
-
Software Package Data Exchange（SPDX）、
-
Software Identification（SWID）タグ付け、および
-
OWASP CycloneDX。
現時点では、これら3つの標準のいずれも他を凌駕してデファクトスタンダードにはなっていません。SBOMを実用的にするためには、SBOMの作成を自動化するだけでなく、CI/CDパイプラインに統合する必要があります。米国商務省電気通信情報局（NTIA）が表現している（PDF）ように、「究極の目標は、SBOMを機械のスピードで生成すること」です。
ソフトウェア部品表（SBOM）のユースケース
SBOMにも3つの異なるユースケースがあります。一般的には以下の通りです：
