ソフトウェア部品表（SBOM）を解説：SBOMがサイバーセキュリティに不可欠な理由

SBOMは、次のような場面で役立ちます。

• 規制への準拠

• 古いソフトウェアパッケージとOSSのアップデートとの互換性

• ソフトウェアサプライチェーンを狙ったサイバー攻撃からの顧客保護

• ソフトウェアやライセンスが関わる合併におけるセキュリティ対策

SBOMとCBOMの違い

2018年のサイバーセキュリティ部品表（CBOM）は、1つの大統領令の中でソフトウェアとハードウェアの両方を対象としています。SBOMが記録するのは、コード内のソフトウェアコンポーネントと、そのバージョン履歴、パッチ、ライセンス、アップデート、変更のみです。

サイバーセキュリティにおいてSBOMが重要な理由

ソフトウェアサプライチェーンを狙ったサイバー攻撃は増加しています。こうした攻撃の半数以上は、実績のある高度持続的脅威（APT）犯罪グループによるものです。彼らは、ユーザーやサプライヤーが自社のシステムを信頼していることにつけ込もうとします。

サプライチェーンが攻撃を受けやすい要因の1つは、サイバーインシデントをめぐる透明性の欠如です。開発者が潜在的な脆弱性に気づいていない場合もあり、その結果、ユーザーも危険にさらされる可能性があります。オープンソースライブラリは、ほかのソフトウェアコンポーネントに依存しています。Log4Shellの脆弱性は、その一例です。このケースでは、多くの開発者が、直接のソフトウェア依存関係ではなく、ほかのコンポーネントが依存する間接的な依存関係であることから、ログ記録ライブラリの確認を怠っていました。

開発チームはすでにアプリケーションセキュリティの必要性を認識していますが、SBOMによってソフトウェアサプライチェーンと潜在的な脆弱性の可視性がさらに高まります。ソフトウェア製品のどこに脆弱性が潜んでいる可能性があるか、またソフトウェアのコンポーネント、特にオープンソースのコンポーネントを把握することで、ユーザーは潜在的な攻撃を検出し、対処するセキュリティツールをより効果的に導入できます。

サイバー攻撃が発生した場合、SBOMを使って、脆弱なコンポーネントを含むソフトウェアと、関連するリスクの種類を特定できます。これにより、ユーザーは開発者と連携して、パッチやその他の緩和策を検討できます。

SBOMと大統領令14028

Log4Shell以前にも、SolarWindsのサプライチェーン攻撃やApache Strutsに関連するEquifaxのインシデントなどのサイバーインシデントが発生し、重要インフラ全体において、政府機関や大企業、企業がいかに脆弱であるかが明らかになりました。また、あらゆる組織がソフトウェアサプライチェーンにどれほど依存しているか、そして1つの脆弱性が悪用されるだけで広範囲に連鎖的な影響が及ぶことも示されました。

大統領令14028は、National Institute of Standards and Technology（NIST）、National Security Agency（NSA）、Office of Management and Budget（OMB）、Cybersecurity & Infrastructure Security Agency（CISA）、Director of National Intelligence（DNI）を含む政府機関に対し、ソフトウェアサプライチェーンのセキュリティを強化する基準とベストプラクティスの策定を求めています。ガイドラインには次の内容が含まれます。

• ソフトウェアセキュリティを評価する基準

• 開発者やサプライヤー自身のセキュリティ対策を評価する基準

• セキュアなプラクティスへの準拠を示す革新的なツールや方法

2022年2月までに、NISTなどの機関がソフトウェアサプライチェーンのベストプラクティスに関するガイドラインを公開する予定です。それまでの間に、今すぐ実践できるサプライチェーンセキュリティのベストプラクティス一覧をご覧ください。

ソフトウェア部品表はいつ使うべきか

ソフトウェアコンポーネントを新たにリリースするたびに、新しいSBOMを作成する必要があります。同様に、コンポーネントに変更を加えるたびに、変更内容を反映してSBOMを更新する必要があります。

NTIAが定めるSBOMの最低要件には、次の情報が含まれます。

• 作成者名

• サプライヤー名

• コンポーネント名

• コンポーネントのハッシュ値

• バージョン文字列

• 識別子

• 関係性

最低要件を満たすため、複数のツールで利用できる共通フォーマットを提供するSBOM標準が策定されました。次の標準があります。

• SPDX：Software Product Data Exchangeは、ソフトウェアパッケージに含まれるコンポーネント、ライセンス、セキュリティ情報を伝達するためのオープン標準です。SPDXでは複数のサービスが標準化されており、それぞれに独自のSBOMがあります。

• SWID：Software Identification Tagsは、ライフサイクルを定義する標準です。ソフトウェアのインストール時に、タグがエンドポイントに追加されます。タグは4種類あります。インストール前の段階で使用するCorpusタグ、製品名を示し、グローバル一意識別子と見なされるprimaryタグ、ソフトウェアに適用されたパッチを記述するpatchタグ、追加情報を示すsupplementalタグです。

• OWASP Cyclone DX：サプライチェーンのコンポーネント分析やアプリケーションセキュリティに使われる、軽量なSBOM標準です。

• VEX：Vulnerability Exploitability Exchangeは、製品に関する追加情報を提供します。具体的には、コンポーネントに見つかった脆弱性を特定し、修復に向けた対応を推奨します。

SBOMとソフトウェアの完全性

SBOMはソフトウェアサプライチェーンの完全性を判断し、収集した情報に基づくリスク評価を可能にするよう設計されています。大まかに言えば、SBOMはサプライチェーン内のソフトウェアコンポーネントの一覧です。一方、標準を適用すると、SBOMによってOSSのコンプライアンス基準を満たせます。たとえば、SPDX標準では各コンポーネントのライセンスを特定し、ライセンスへの準拠を確認できます。

ソフトウェア成果物のサプライチェーンレベル（SLSA）は、サプライチェーン内のオープンソースソフトウェア成果物の完全性を維持するための基準と管理策です。Googleが立ち上げたSLSAは、サプライチェーンセキュリティに関するNISTの推奨事項を満たしています。SLSAは、開発プロセス全体で使われる膨大なオープンソースソフトウェアを保護するための取り組みにおいて、SBOMを補完します。

SBOMを使って依存関係と脆弱性を見つける

SBOMの主なセキュリティ上の目的は、ソフトウェアサプライチェーン全体の脆弱性とリスクを特定することです。コンポーネントの追加や変更によって、脆弱性に関するデータは常に変化し、新たな攻撃につながる可能性があります。SBOM自体は基本的に静的なものですが、作成に使用するデータは絶えず変化し、進化しています。

SBOMは、脆弱性を分析し、開発者が依存関係を更新してリスクを軽減しているかを確認したいソフトウェア利用者にとって有用なツールです。ただし、すべての脆弱性が同じレベルのリスクをもたらすわけではなく、リスクがないものもあります。この問題に対処するため、NTIAは次の2つのステップを示しています。

• 開発・供給側では、脆弱性が特定のソフトウェア領域に影響するかどうかを含め、その影響を判断する必要があります。

• 脆弱性に関する情報はSBOMデータを通じて適切に伝達し、その脆弱性がリスクをもたらさないことを確認する必要があります。

サプライチェーンセキュリティのためのSBOM

SBOMは、次の方法でソフトウェアサプライチェーンのセキュリティを高めます。

• システム間の関係も含め、ソフトウェア製品全体の可視性を向上

• 脆弱性に関する情報共有

• 開発者からユーザーまで、サプライチェーン全体のコミュニケーションを改善し、セキュリティリスクを特定しやすくする

• コンプライアンス基準と監査の詳細な記録

SBOMは、ソフトウェアサプライチェーン全体の保護とリスク検出を強化する、進化し続けるセキュリティツールです。ソフトウェア内の各コンポーネントについて、より正確で詳細な情報を提供することで、ソフトウェア製造ライフサイクルの早い段階で脆弱性を発見できます。その結果、被害が発生する前にリスクを軽減できます。

SnykはSBOMの作成プロセスを自動化し、組織が利用するオープンソースコンポーネントや依存関係を簡単に追跡できるようにします。また、個々のコンポーネントをスキャンして潜在的な脆弱性を検出し、修正に役立つ具体的な推奨事項を提示します。