令14028、ソフトウェア部品表 (SBOM) の作成を義務化するための大規模な規制の動きが始まりました。 この新しいバズワードが広まるにつれて、それは安全を確保するための奇跡の治療法だと思うでしょう。 ソフトウェアサプライチェーン. 概念的には、それは理にかなっています — 製品に何が含まれているかを知ることは合理的な期待です. ただし、SBOM が正確に何であるか、およびそれがセキュリティ ツールとして客観的に役立つかどうかを理解することが重要です。
SBOM について
SBOM 食料品店の商品の裏にある栄養ラベルのようなもので、製品を作るために使用されたすべての成分がリストされています. 現在、公式の SBOM 標準はありませんが、いくつかのガイドライン形式が最有力候補として浮上しています。 最も人気があるのは Software Data Package Exchange (SPDX)、Linux Foundation が後援しています。
SPDX は、他のほとんどの形式と同様に、ソフトウェアの生産に使用される要素に関する基本的な情報 (名前、バージョン、ハッシュ、エコシステム、既知の欠陥やライセンス情報などの補助データ、および関連する外部資産) を表す共通の方法を提供しようとします。 . ただし、ソフトウェアはシリアルの箱ほど単純ではなく、推奨されるガイドラインへの準拠を強制する食品医薬品局に相当するものはありません。
すべてがオプションであるため、何も必要ありません
SPDX およびその他の標準における最大かつ最も明白なギャップの XNUMX つは、オープン ソース エコシステム全体と同様に、検証済みの標準ではなく、一般的なガイドラインに基づいて構築された一連のコミュニティであることです。 オープン ソース コミュニティは広く無秩序に広がっており、世界中から貢献者が集まっています。 多くの場合、パッケージ マネージャーとホスティング環境は別々の委員会によって設計され、それぞれが独立して運用されています。 SBOM 指令は、これらの多くの情報サイロを統合するための初期の試みを表していますが、基準をさかのぼって適用するという根本的な制限のいくつかに悩まされています。
何よりもまず、SPDX が実際に提供するものを検討すると、亀裂が現れ始めます。 結局のところ、標準のほぼすべてのフィールドはオプションです。 このフィールドの選択性は明らかに、フォーマットがカバーしようとしている多くのソフトウェア エコシステムが実際にどれほど異なるかを示す人工物ですが、暗号化ハッシュやその他の情報を許可する必要がない場合、SBOM は真の情報源としての価値を失います。ライブラリを SBOM 文書に提示された情報と積極的に関連付けるため。
SBOM は出所のマークを逃しています
不完全であることに加えて、入力の多くは、特にバージョン管理システムのリポジトリなどから、現在の形式で適切に表すことができません。 いくつかの新しいフレームワークは SLSA 来歴の概念を適用しようとしても、的を射たフォーマットはありません。 消費しているソフトウェアの中身を合理的に把握できるようにするために、SBOM 形式に正確な来歴データを組み込む必要があります。 これには、少なくとも次のものが含まれている必要があります。
- 著者の身元情報: 保守者と貢献者の両方が、ソフトウェア サプライ チェーンの重要な部分です。 彼らは王国へのことわざの鍵を保持し、下流で使用するソフトウェアがどのようにリリースされるかを選択します。 完全なデータを取得できなくても、現在提供されているものよりも確実に優れた結果を得ることができます。
- 開発ツール： これには、ビルド ツール、CI/CD インフラストラクチャ、アップストリーム ソフトウェアの開発中に使用されるツールが含まれます。 使用しているライブラリの侵害が依然として内部侵害を引き起こす可能性がある場合、内部開発インフラストラクチャを保護しても何のメリットがありますか?
- コントロールと保護: 目標の XNUMX つがサード パーティのリスク管理である場合、開発チームのセキュリティ体制はどのようになっているのかを確認する必要があります。 分岐保護は使用されていますか? どのような審査プロセスが適用されますか?
- アーティファクトの証明: SBOM ドキュメント内のエントリを実際のアーティファクトに関連付けることが絶対にできなければなりません。 これには、コンパイルされたパッケージなどの実際のビルド アーティファクトと、バージョン管理システムでタグ付けされたブランチなどの継続的に開発されるアーティファクトの両方を含める必要があります。
現実的には、SBOM を運用する方法を検討する前に、これらの各要素を理解して、使用しているソフトウェアに何が含まれているかを理解する必要があります。
時間内の単純なスナップショットに頼ることはできません
最後に、幅広い SBOM の採用に伴う最大の課題は、静的な形式がその瞬間にのみ真実を提供することです。 意味のあるものにするために、SBOM は継続的に配信およびアクセスできる必要があります。
たとえば、クラウド ストレージ プロバイダーからベンダー SBOM を受け取ったとします。 この SBOM は、何万もの個別のソフトウェアを含むドキュメントになるだけでなく、それらのソフトウェア パッケージの多数のバージョンを含むことにもなります。 さて、その情報を受け取る頃には、すでに古くなっている可能性が高いことを考慮してください。 これは、大企業が XNUMX 日に数百または数千のビルドを出荷することが多いためです。 大手ベンダーの SBOM を処理、消費、および推論した時点で、データは既に古くなっています。
バージョンが変更され、新しいパッケージが追加され、一部のパッケージが削除される可能性があります。 最新の開発のベスト プラクティスは、ビルドとデリバリが継続的に行われることを意味し、これによりイテレーションとリリース サイクルが高速化されます。 これは、単一の SBOM の配信がほとんど無意味であることも意味します。 これが実際に意味することは、SBOM が真の価値を提供するためには、SBOM に関するスケーラブルな自動化が強く求められているということです。
SBOM の背後にある意図は、内部と外部の両方で可視性を改善する道を開くことです。 ただし、彼らがあなたのソフトウェア サプライ チェーンを保護してくれると思い込まないでください。 真の影響を与えるには、不完全なスナップショット以上のものが必要です。
