本文の内容は、2022年8月23日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/sbom-101-software-bill-of-materials/)を元に日本語に翻訳・再構成した内容となっております。
最近の多くのセキュリティインシデントにおいて、コードの依存関係、ソフトウェアのサプライチェーンへの攻撃、ソフトウェア部品表（SBOM）、デジタル署名、証明書、認証などに関する知識の欠如についてのメッセージを多く耳にします。
実際、新しい脆弱性が登場するたびに、私たちの環境で稼働しているアプリケーションやサービスに対する実際の影響を検出するために、多くの時間と労力を費やす必要があるのが通常です。
もし、私たちが使用し、生産しているすべてのソフトウェアコンポーネントを列挙する方法があり、それを簡単に配布し、コンシュームすることができるとしたらどうでしょうか。
これを解決しようとしているのがSBOMであり、その説明をしたいと思います。それでは、SBOMの詳細に飛び込んでみましょう
SBOMとは？
ソフトウェア部品表は、簡単に言えば、パッケージの依存性、ファイル、ライセンス、およびソフトウェアの一部を一緒に構成する他の資産の包括的なリストを含む成果物です。NTIA SBOM FAQによると
ソフトウェア部品表（Software Bill of Materials: SBOM）は、ソフトウェアのビルドに使用される様々なコンポーネントの詳細とサプライチェーン関係を含む正式な記録です。ライブラリーやモジュールを含むこれらのコンポーネントは、オープンソースでもプロプライエタリでも、無料でも有料でもよく、データは広く利用可能でもアクセス制限されていてもかまいません。
このコンセプトは新しいものではなく、BOM（Bills of Materials、「ソフトウェア」は含まず）は産業プロセスの一部として常に存在してきました。BOMは「成分表」に非常に似ていますが、BOMには通常「階層」という概念があり、すべての部品はサブコンポーネントのリストに分解され、そのサブコンポーネントにはまたそれぞれのBOMが含まれます。
ソフトウェア部品表では、「部品」は一般に抽象的なライブラリー、モジュール、バイナリ、コンパイラ、ファイルなどであり、通常はライセンス情報（Apache 2.0、GNU、BSD、…）や追加のメタデータを含みます。
SBOMは最近のものですか？
そうでもありません。かなり新しく見えるかもしれませんが、オープンソースコミュニティは10年以上前にSBOM作成の必要性に気付き、その問題に取り組む最初の取り組みとして2010年にSPDXオープンスタンダードが開始されました。
SBOMのタイムライン実のところ、近年のサプライチェーンに関連する攻撃の増加により、事態は急速に動き始めています：
- 2015年10月 – SWIDタグの規格、NISTから、ISO/IEC 19770-2:2015として発行される。
- 2017年5月 – OWASP SBOM規格であるCycloneDXの初期ドラフトが公開される。
- 2020年12月 – オープンソースライセンス準拠のためのISO国際規格（ISO/IEC 5230:2020 – Information technology – OpenChain Specification）が発行され、供給されたソフトウェアの部品表を管理するためのプロセスが要求される。
- 2020 – 2021年 – NTIAs がソフトウェア部品表 (SBOM) に関する進行中のソフトウェア部品透明化の取り組みの一環として最新作を発表。
- 2021年2月 – 米国のサプライチェーンに関する大統領令14017。
- 2021年5月 – ナショナルサイバーセキュリティの改善に関する大統領令14028号。
- 2021年7月 – NISTが、大統領令（EO）14028に基づくソフトウェアのベンダーまたは開発者の検証（テスト）のための推奨最低基準を発表。
- 2021年8月 – SPDXがISO/IEC 5962:2021規格として発行される。
- 2021年9月 – SLSA (Supply-Chain Levels for Software Artifacts) フレームワークの最初のドラフトが公開される。
- 2022年2月 – 国防総省がソフトウェアサプライチェーンを含む防衛上重要なサプライチェーンの安全確保に関する計画を発表。
というわけで、特に2021年以降は、誰もが関心を持ち、話題にしているようです。そして、これはほんの始まりに過ぎません。2022年は、業界がSBOMとソフトウェアサプライチェーンセキュリティの課題にどのようにアプローチするかについての転換点になりつつあるのです。
SBOMはどこに適用されるのか？
SBOMは、ソフトウェア製品の構築に使用される、外部または内部、オープンソースまたは専有（ファイル、パッケージ、モジュール、共有ライブラリー、…など）のあらゆるソフトウェア・コンポーネントに適用されます。これには、ファームウェアと組み込みソフトウェアも含まれます。ハードウェアは、ソフトウェアの配布または実行に参加するかもしれません（ネットワーク機器、暗号化装置、チップなど）が、それはSBOMの一部とは見なされません。ただし、CycloneDXのような標準はデバイスもコンポーネントの一種としてサポートします。理想的な世界では、すべてのソフトウェア会社が各製品にSBOMを添付し、誰もがソフトウェアに使用されているコンポーネントを完全に可視化し、どの脆弱性がそのソフトウェアに影響を与えているかを正確に把握できるようになります。
しかし、庭のすべてがバラ色というわけではありません。
SBOMが付随する可能性のある典型的な資産には、どのようなものがあるでしょうか：
- 開発の依存関係。開発者がサードパーティの依存関係（オープンソースまたは内部コンポーネント）を含むたびに、依存関係自体が使用しているモジュールまたはパッケージである推移的依存関係を追加することがよくあります。したがって、詳細なSBOMは、それらの推移的依存関係を可視化します。
- ソフトウェアアプリケーションやパッケージ。アプリケーションが配布されるとき、SBOMは、消費者がアプリケーションのバージョン、パッケージに含まれるヘルパーツール、およびビルドプロセスに関与したすべての部品をすばやく特定するのに役立ちます。これにより、脆弱性の特定や、ソフトウェアの依存関係などが原因で発生する可能性のある問題のトラブルシューティングが、より容易になります。
- コンテナイメージ。基本的には、ベースとなるイメージディストリビューションと、ビルドプロセスで追加されたパッケージやコンポーネントのセットで構成されるファイルシステムです。
- ホスト（Virtual machine appliance image、AWS AMIなど）。SBOMは、基本オペレーティングシステムの種類、ベンダー、バージョン、および、基本オペレーティングシステム（Linuxディストリビューションなど）から、または、外部ソースから手動でデプロイされた、ホストにインストールされた各パッケージの包括的なリストを含みます。
- ハードウェアデバイス。例としては、ソフトウェアを実行しているファイアウォール、IoTデバイス、または携帯電話などがあります。
また、製品のリリースごと、あるいはビルドごとに、資産の1つが変更されるたびに、そのバージョンの変更に合わせて新しいSBOMを作成する必要があることを指摘することが重要です。
なぜSBOMが必要なのか？
第一に、SBOMがなければ可視化を行うことができません。ソフトウェアの断片は、それを組み立てているパッケージやライブラリに関してはブラックボックスです。SBOMが必要な理由は、基本的に、食品の成分表が必要な理由と同じです。アレルゲンの有無、菜食主義者のための動物性物質、化学防腐剤などをチェックすることができます。確かに、原材料のリストを確認しなくても食品を食べることはできますが、何らかのリスクを負うことになります。ソフトウェアについても同様です。サンドボックス環境での迅速なテストでは、どのような依存関係でも使用することが正しいかもしれませんが、重要なサービスを本番環境にデプロイしたり、強いコンプライアンス規制のある環境でソフトウェアを配信したりする場合は、絶対に中身を確認したいはずです。
サードパーティの依存関係のためのSBOMが利用可能であることは、依存関係からリストを構成し、独自の成分を追加するだけで、あなたのソフトウェアのSBOMを簡単に構築できるようにします。あなたのソフトウェアは、より複雑な製品の入力または依存関係になる可能性もあり、消費者はサプライヤーの最小要件の一部としてSBOMの存在を要求するかもしれないことに注意してください。
異なるソフトウェア部品のライセンスを知ることも非常に重要です。さもなければ、サードパーティのライブラリーを使用しているソフトウェアを複数の種類のライセンスの下で配布すると、使用条件が破られたり、ソースコードの公開を余儀なくされたりして、不便な思いをしたり、企業がトラブルに巻き込まれる可能性さえあります。
最後に、SBOMは脆弱性スキャンの重要なピースです。正確な SBOM と、さまざまなベンダーやソースからの信頼できる最新の脆弱性フィードがあれば、ソフトウェアに存在する脆弱性を見つけるのは、かなり簡単です。
SBOMがなければ、脆弱性スキャナーのソフトウェアは、SBOMを計算して推測する必要がありますが、これはかなり厄介で、不透明なコンポーネントでは不可能でさえあるかもしれません。
良いSBOMは、「私はCVE-2022-22965（Spring4Shell）の脆弱性に対して脆弱か」というような質問に答えることもできるはずです。リンク先の記事にあるように、この脆弱性を悪用するには、悪用可能なJavaパッケージを実行しているホストまたはコンテナで、一連の条件が同時に発生することが必要です。
- SpringCoreバージョン5.3.0～5.3.17、5.2.0～5.2.19またはそれ以前の未サポートバージョンを使用している。
- JDK 9以降を使用している
- サーブレットコンテナとしてApache Tomcatが動作している
- ライブラリがWAR形式でパッケージ化されている
- spring-webmvcまたはspring-webfluxの依存関係を使用している
これらの条件のほとんどは、包括的なSBOMの内容で確認することができ、悪用可能なアプリケーションの修正に最初に集中することで、環境のリスクを容易に評価することができます。
SBOMはどのように作成するのか？
SBOMの作成は複雑なテーマで、複数の競合する規格や流通などがあるため、導入が思うように進まないのが現状です。ソフトウェアのSBOMを作成するのに役立つツールは多く存在します。しかし、SBOMの作成を検討する前に、ビルドプロセスが完全に自動化され（これはSLSAフレームワークのレベル1です）、SBOMの作成がビルドパイプラインの一部として統合されていることが非常に重要なポイントになります。
次に、オープンソースツールの実行と出力の例と、それに対応するSPDXまたはCycloneDX（切り捨て）のSBOMを紹介します。
Syft
SyftはファイルシステムやコンテナイメージからSPDXまたはCycloneDX形式のSBOMを生成でき、Docker sbomコマンドを使用してデフォルトでDockerに組み込まれます。$ syft neo4j:latest ✔ Parsed image ✔ Cataloged packages [376 packages] NAME VERSION TYPE CodePointIM 11.0.15 java-archive FastInfoset 1.2.16 java-archive ... util-linux 2.36.1-8+deb11u1 deb wget 1.21-1+deb11u1 deb zlib1g 1:1.2.11.dfsg-2+deb11u1 deb zstd-jni 1.5.0-4 java-archive zstd-proxy 4.4.8 java-archive
oフラグで出力をspdx-json形式にすると、次のような文書が生成されます：
$ syft -o spdx-json neo4j:latest
✔ Parsed image
✔ Cataloged packages [376 packages]
{
"SPDXID": "SPDXRef-DOCUMENT",
"name": "neo4j-latest",
"spdxVersion": "SPDX-2.2",
"creationInfo": {
"created": "2022-06-23T10:09:26.751733Z",
"creators": [
"Organization: Anchore, Inc",
"Tool: syft-0.48.1"
],
"licenseListVersion": "3.17"
},
...
"packages": [
{
"SPDXID": "SPDXRef-fd9f083cc189cf0c",
"name": "CodePointIM",
"licenseConcluded": "NONE",
"checksums": [
{
"algorithm": "SHA1",
"checksumValue": "50a6f2c46702b14cb129aac653d9abfcdc324363"
}
],
"downloadLocation": "NOASSERTION",
"externalRefs": [
{
"referenceCategory": "SECURITY",
"referenceLocator": "cpe:2.3:a:oracle-corporation:CodePointIM:11.0.15:*:*:*:*:*:*:*",
"referenceType": "cpe23Type"
},
...
{
"referenceCategory": "PACKAGE_MANAGER",
"referenceLocator": "pkg:maven/CodePointIM/[email protected]",
"referenceType": "purl"
}
],
"filesAnalyzed": true,
"licenseDeclared": "NONE",
"sourceInfo": "acquired package info from installed java archive: /usr/local/openjdk-11/demo/jfc/CodePointIM/CodePointIM.jar",
"versionInfo": "11.0.15"
},
{
"SPDXID": "SPDXRef-80979ce84b1617b2",
"name": "FastInfoset",
"licenseConcluded": "NONE",
...
},
...
],
"files": [
{
"SPDXID": "SPDXRef-9e950849d3fbc974",
"comment": "layerID: sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be",
"licenseConcluded": "NOASSERTION",
"fileName": "/bin/bash"
},
{
"SPDXID": "SPDXRef-d1fd1bc48eedeaba",
"comment": "layerID: sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be",
"licenseConcluded": "NOASSERTION",
"fileName": "/bin/cat"
},
...
],
"relationships": [
{
"spdxElementId": "SPDXRef-a124711c55c5b5ec",
"relationshipType": "CONTAINS",
"relatedSpdxElement": "SPDXRef-9f73084aac22b0b3"
},
{
"spdxElementId": "SPDXRef-a124711c55c5b5ec",
"relationshipType": "CONTAINS",
"relatedSpdxElement": "SPDXRef-23989aa2a193ea3d"
},
...
]
}パッケージだけでなく、イメージ内のファイル、要素間の関係、ライセンス情報なども含まれます。
cyclonedx/bom
nodeJSパッケージのcyclonedx/bomは、NodeプロジェクトからCycloneDX形式のSBOMを生成することができます。github.com/fastify/fastifyからSBOMを生成する際の出力例は以下のようになります：$ cyclonedx-bom
$ cat bom.xml
<?xml version="1.0" encoding="utf-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" serialNumber="urn:uuid:be53de33-6897-49ca-855d-926383866c21" version="1">
<metadata>
<timestamp>2022-06-23T10:03:17.018Z</timestamp>
<tools>
<tool>
<vendor>CycloneDX</vendor>
<name>Node.js module</name>
<version>3.10.1</version>
</tool>
</tools>
<component type="library" bom-ref="pkg:npm/[email protected]">
<author>Matteo Collina</author>
<name>fastify</name>
<version>4.1.0</version>
<description>
<![CDATA[Fast and low overhead web framework, for Node.js]]>
</description>
...
</component>
</metadata>
<components>
<component type="library" bom-ref="pkg:npm/%40fastify/[email protected]">
<author>Manuel Spigolon</author>
<group>@fastify</group>
<name>ajv-compiler</name>
<version>3.1.0</version>
<description>
<![CDATA[Build and manage the AJV instances for the fastify framework]]>
</description>
<licenses>
<license>
<id>MIT</id>
</license>
</licenses>
<purl>pkg:npm/%40fastify/[email protected]</purl>
<externalReferences>
<reference type="website">
<url>https://github.com/fastify/ajv-compiler#readme</url>
</reference>
<reference type="issue-tracker">
<url>https://github.com/fastify/ajv-compiler/issues</url>
</reference>
<reference type="vcs">
<url>git+https://github.com/fastify/ajv-compiler.git</url>
</reference>
</externalReferences>
</component>
...
</components>
<dependencies>
<dependency ref="pkg:npm/[email protected]"/>
<dependency ref="pkg:npm/[email protected]"/>
<dependency ref="pkg:npm/[email protected]"/>
<dependency ref="pkg:npm/[email protected]"/>
<dependency ref="pkg:npm/[email protected]">
<dependency ref="pkg:npm/[email protected]"/>
</dependency>
<dependency ref="pkg:npm/[email protected]">
<dependency ref="pkg:npm/[email protected]"/>
<dependency ref="pkg:npm/[email protected]"/>
<dependency ref="pkg:npm/[email protected]"/>
<dependency ref="pkg:npm/[email protected]"/>
</dependency>
...
</dependencies>
</bom>snyk2spdx
snyk2spdx ツールは、Snyk オープンソース API を活用して、コードリポジトリから SBOM を作成します。残念ながら、執筆時点ではこのリポジトリは古く、メンテナンスされていません。その他
https://sbom.democert.org/sbom/ のようなオンラインツールもあり、異なるフォーマットをインポートしたり、SBOM定義にコンポーネントを手動で追加してダウンロードしたりすることが可能です。また、NTIAは、SBOMの生成方法に関する簡単な手順とガイダンスを集めた「How to Guide for SBOM Generation」を公開しています。このガイドでは、一部のコンポーネントの依存関係が欠落している場合のために、「完全性アサーション」の概念が含まれているのが興味深いです。
ベンダーが提供するSBOM or 推測されるSBOMか？
理想的には、製品のベンダーはすべてのコンポーネントを教えてくれ、改ざんや変更を防ぐためにデジタル署名された文書で提供してくれるはずでです。しかし、私たちはまだそこから遠く離れており、多くのベンダーがSBOMを作成し提供しているわけではありません。SBOMは複数のツールや部品を含む複雑なプロセスであり、SBOM配布のための規格も複数存在します。夢の国では、すべてのベンダーが100％正確で包括的な部品表を、共通の規格で、デジタル署名付きで提供することになっています。しかし、現実の世界では、通常、「推測された」部品表を作成できるスキャニングツールが必要です。多くの部品は不透明で、ビルド中に使用される依存関係やライブラリを発見することが困難なため、これはより困難です。
それでもスキャンが必要なのは、ベンダーからのSBOMが誤っている可能性があるからです。ベンダーのビルドプロセスに問題があり、ベンダーのSBOMからいくつかのコンポーネントが意図的に省略されている可能性があります。
SBOMは間違っていたり、不正確だったりするのでしょうか？
はい。 SBOM の品質は、SBOM を構築するプロセスの品質と自動化に依存します。直接ビルドするソフトウェアのバージョンと詳細のようなルートレベル、および依存関係の第1レベル（パッケージとサードパーティライブラリー）を作成するのは簡単です。多くのコンポーネントがそれ自身のSBOMを提供しないかもしれず、依存関係の検出は複雑ですが、情報が除去された静的リンクバイナリのように明らかに不可能であるため、推移的依存関係ではより難しくなり、ツリーの奥に進むほど困難になります。
ビルドの段階で完璧なツールチェーンと完璧なSBOM情報があっても、攻撃者はSBOMの内容を改ざんして（つまり、保管中のコンパニオンファイルまたはアーティファクトを変更します）、脆弱なコンポーネントまたは悪意のあるコンポーネントを含むという事実を隠蔽することができるのです。消費者はその後、SBOMの変更されたバージョンを取得し、これらの危険なコンポーネントを見逃すでしょう。
一般的に推奨される方法は、消費者がその真正性と完全性を確認できるように、SBOM成果物にデジタル署名を追加することです。
さらに悪いことに、攻撃者がビルドパイプラインを危険にさらし、SBOMの作成プロセスを変更できる可能性があります。
これはビルド側の話です。スキャンツールの観点からは、ソフトウェアコンポーネントは通常ブラックボックスであり、あるいは、（pom.xmlやgo.modファイルのように）そのほとんどがビルド中に利用できるが最終成果物では削除されるので、分析から得られる情報の量はかなり限定的かもしれません。
比較するために、分析またはスキャナーは定量的データを生成しますが、提供されたSBOMは定性的データを含む可能性があり、これらは分析で失われたり見えなくなったりする可能性があります。
質の悪いSBOMや攻撃のリスクを最小化するために、ベンダーが提供したSBOMがある場合でも、スキャンソリューションを使用することが推奨されるのです。
SBOMと脆弱性はどのように関係しているのか？
脆弱性とは、攻撃者がセキュリティ境界を迂回したり、システムにアクセスしたりするために悪用できる弱点や欠陥のことです。これらは、ソフトウェアのサプライチェーンを攻撃したり、侵害したりする典型的な方法です。
ソフトウェアの一部（または実行中のホストやコンテナイメージなど）の脆弱性を見つけるには、「既知の」脆弱性とソフトウェアコンポーネントの集合を照合する仕組みが必要です。これを脆弱性スキャンと呼びます。そして、ソフトウェアを構成するパッケージとバージョンの包括的なリストを含むSBOMの出番となるわけです。
そして、もう1つの大きな疑問が生じます。「既知の」脆弱性はどこから来るのでしょうか？脆弱性は事前に知っておく必要があり、未知の欠陥は検出することはできないのです。
リサーチャーやハッカーが脆弱性を発見し、人間やコンピュータが利用できる脆弱性データベースに蓄積されています。脆弱性のソースは主に2つあります。
ベンダーは、主要なLinuxディストリビューションや、Go、NPMなどのパッケージリポジトリのように、自社製品の脆弱性のフィードを提供することができます。ベンダーは、その脆弱性が製品にどのような影響を与えるかについて、良いコンテキストを持っています。しかし、深刻度に関しては偏っている可能性もあります。
NIST、Mitre、Open Source Vulnerabilities Database、Snyk や VulnDB のような独立したプロバイダーは、脆弱性に関する情報を収集、分析し、提供しています。欠点は、スコアが客観的で、その脆弱性が異なる製品でどのように適用されるかという具体的なコンテキストがないことです。場合によっては、フォークされたり、パッチがバックポートされたりして、脆弱性がベンダー固有の製品バージョンに影響を与えないこともあります。
脆弱性情報の交換には、次のようなさまざまな形式や標準が存在するため、脆弱性フィードを統合することは困難です。
- Redhat OVAL – Redhat Enterprise Linux、Openshift、その他の Redhat 製品で使用されている XML フォーマットで、Ubuntu でも使用できます。
- Debian Security Tracker のようなさまざまな JSON フィード。
- OSVのような、特定のオープンソースパッケージのバージョンをクエリーできるAPI。
- Gentoo セキュリティのような自動処理ではなく、人間向けのセキュリティ勧告。
- NVD CVE JSON v5.0 は、標準的な CVE フォーマットを作成する試みです。
- CSAF (Common Security Advisory Framework) – 「サイバーセキュリティの脆弱性問題の自動的な開示の標準化」。
- VEX (Vulnerability Exploitability eXchange) – CSAFのプロファイルとして実装されたもの。
VEXは興味深いもので、ベンダーがある種の「ネガティブ」なセキュリティ勧告を提供することができます。例えば、パッケージ内のサブモジュールが製品で使用されていないため、ある脆弱性はコンポーネントに適用されないというようなものです。
脆弱性の優先順位付けに役立つもう 1 つの情報源は、CISA の KEV (Known Exploited Vulnerabilities Catalog)、割り当てられた CVE ID、実際に積極的に悪用されているという信頼できる証拠、および明確な修復 (ベンダーの更新など) を含む脆弱性の更新リストです。
次の図は、脆弱性管理の完全なフローを説明しています：
SBOMと脆弱性の管理典型的なフローは、コンテナイメージ、ホスト、またはワークロードを分析してSBOMを作成することができるスキャンツール、あるいは事前に計算されたSBOMを直接取り込むスキャンツールで構成されています（またはその両方！）。次に、スキャンツールは、さまざまなソース（通常は、対応する Linux ディストリビューションのベンダーが提供するソースと、NVD のような汎用ソース）から既知の脆弱性を照合し、ソフトウェアに影響を及ぼす脆弱性のリストを報告します。
spdx-to-osvツールを使って、KubernetesのSBOM（各バージョンで公開されている）とOSVの既知の脆弱性を照合した例を見ることができます。
検出された脆弱性のリストは、VendorからのVEX（not exploitable vulnerabilities）、KEVリスト（Known Exploited Vulnerabilities）、またはワークロードの実行中に効果的にロードされたパッケージを検出できるSysdigからのRisk Spotlight情報などの追加情報でキュレーションして優先順位を付けることができます。これにより、コンテナイメージの中にあっても実行されないパッケージがフィルタリングされ、悪用されることはありません。
落とし穴は何ですか？
サプライチェーンのセキュリティに関する多くの文献があり、ツールや製品のセットが増え続けているにもかかわらず、これらのツールの多くは、コンポーネントを分析し、依存関係を推測してSBOMを生成しています。上流にあるすべてのコンポーネントでSBOMを生成するという最適なアプローチは、ほとんどの場合、まだオーダーメイドのソリューションを必要とします。これは、不完全または不正確なSBOMを生み出すことになります。これは、異なる既存のフォーマット（CycloneDX、SPDX、SWID）と標準化された配布メカニズムがないため、SBOMのコンシュームをかなり難しくしていることは言うまでもないことです。
もう一つ考慮すべき問題は、SBOMの制約が脆弱性スキャナーに伝播することです。
例えば、SBOM にないパッケージは false negative (既存の脆弱性が報告されない) となり、カスタムパッケージのバージョンにパッチを適用すると false positive となる可能性があります。一般に、脆弱性データベースに反映されないバージョンのパッケージカスタマイズは、FP/FN問題の原因となる可能性があります。また、脆弱性情報のプロバイダは1つではなく、交換標準も1つではありません。理想的には、すべてのベンダーが独自のセキュリティ勧告の情報源を提供し、既存の弱点の完璧な特定を可能にするVEX（悪用可能性）を提供することです。
まとめ
SBOMは、ソフトウェアサプライチェーンを保護するための重要な要素であり、脆弱性の照合と管理のための基礎となるものです。ソフトウェアの消費者と政府が、プロバイダーに対するセキュリティ要件とソフトウェア品質の水準を高めるにつれて、SBOMの重要性はますます高まっています。この記事を書いている時点では、まだ競合するさまざまな標準、多数のツール、多くの不確実性があり、ほとんどの関係者はまだそこに到達するために苦闘しています。しかし、一般的なコンセンサスは、私たちはサプライチェーンを確保し、共通の標準に収斂し、SBOMをビルドプロセスの不可欠な部分にする必要があるということです。
サプライ チェーンの保護を開始するためにフォローアップする興味深いイニシアチブは、ソフトウェア サプライ チェーンにさまざまなレベルの成熟度を導入する Salsa フレームワークです。 そのため、何もないところから始めて、さまざまなメカニズムを段階的に実装して、チェーン内の任意のリンクで可能な限り回復力を高めることができます。
Sysdigを使えば、どの脆弱性が本当のリスクなのかを迅速かつ簡単に特定することができます。
もう、脆弱性を一行ずつスクロールしたり、スプレッドシートに延々と書かれた問題からリスクを推定するのに苦労する必要はありません。リスクスポットライトを使用すれば、重要な脆弱性を簡単に見つけ、集中的に修正することができます。
30 日間の無料トライアルに登録し、ご自身の目でお確かめください！