世界各国の政府関係機関が連携し、組織がソフトウェア部品表(SBOM)に含めるべき最小限の要素に関する新たなガイドラインを発表しました。
この文書は、今週公開されたもので、米サイバーセキュリティ・インフラセキュリティ庁(CISA)と、4大陸にまたがる16の政府機関が共同で作成しました。これは、米国政府がSBOMに含めるべき内容を定めていた、米国家電気通信情報局(NTIA)の2021年版ガイドラインを置き換えるものです。今回の改訂版は2025年に草案が作成され、その後Google、Microsoft、Amazon Web Services(AWS)といった大手企業を含む90名のコメンテーターからの意見を反映して、今回の文書として完成しました。
SBOMとは、あるソフトウェアを構成する部品やサプライチェーンの詳細を記した、いわば「原材料表」です。独自開発のソフトウェアコンポーネントやオープンソースのコンポーネント、API、ユーティリティなどが含まれる場合があります。リスク管理ツールとして、ソフトウェアスタックのどこに脆弱性が存在するのか、そしてパッチ適用の優先順位をどう付けるべきかなどを可視化することを目的としています。
今回刷新された枠組みに革新的な内容はないものの、10個の新しいデータフィールドが追加され、既存の要素についても大小様々な十数個の更新が加えられています。こうした変更の方向性自体は前向きなものですが、OWASPの創設者であり、Contrast Securityの創業者兼CTOでもあるJeff Williams氏は、こうした細かな手続き上の変更では本質的な問題を見落としていると指摘します。
「私たちが本当に目指すべき成果について、考え直す必要があります」と同氏は述べます。「真の成功の尺度は、問題をどれだけ網羅的に目録化したかではありません。実際のリスクをどれだけ効果的に低減できたかです。CISAは、ベンダーが自社のセキュリティを透明化できるような仕組みづくりに、もっと積極的に取り組むべきです。しかし残念ながら、セキュリティに関する大抵の物事と同様、完璧を求めるあまり、より良いものを実現する妨げになっています」
なお、CISAは新しいSBOMガイダンスを発表した翌日に、オープンソースソフトウェア(OSS)のセキュリティに関するベストプラクティスについて、関連する別のガイダンスも公開しています。
SBOMの新たな変更点
SBOMには今後、10個の新たに定義された要素を含める必要があります。例えば、SBOMの完全性と真正性を証明するデジタル署名や、そのSBOMを生成するために組織が使用したツールの名称とバージョンなどが挙げられます。
既存の要素の一部にも変更が加えられており、些細なものから重要なものまで様々です。中でも特に注目すべき変更は、意味合いとしては曖昧ながらも運用上は重要な、SBOM内の「深さ(depth)」という要素を「網羅範囲(coverage)」という要素に置き換えた点です。つまり、SBOMには今後、プログラムが直接取り込む依存関係の最上位層だけでなく、その依存関係がさらに依存する要素についても、どこまでも際限なく含めるべきということになります。
「『深さ』から、より広範な依存関係の『網羅範囲』へという方向転換自体は正しいものですし、生成コンテキストやツールのバージョンを記録することも有用です。ですが、これによって大きな違いが生まれるとは思えません」とWilliams氏は述べます。同氏によれば、実務上、既存のSBOM標準はすでにこうした「推移的依存関係」をサポートしており、大半のSBOMツールは生成コンテキストとあわせて、それを捕捉しようと試みているといいます。「CISAは、標準やツールのエコシステムがすでに実現していることを、書面に落とし込んでいるにすぎません」と同氏は語ります。
新ガイダンスにまだ欠けているもの
個別の新要素や改訂内容云々よりも、今回の発表にはさらに根深い問題があるとWilliams氏は主張します。
例えば、抜け落ちている項目があります。新ガイダンスは、SBOMプロセスの一般的な構成要素である脆弱性悪用可能性交換(VEX)を制度として盛り込んでいません。VEXは、NTIAがSBOMの姉妹概念として開発したもので、特定のスタックにサプライチェーンの脆弱性が存在するかどうかだけでなく、それが実際に悪用可能なものなのか、あるいは呼び出されていない、もしくは外部に露出していないものなのか、といった文脈情報を付与する役割を担っています。
さらに同氏は、「CISAは、正確性、完全性、網羅性の保証について、この文書の対象範囲外としています」と指摘します。「しかし、そここそがほぼ問題の全てなのです。SBOMにどのフィールドを含めるべきかについて、これ以上の合意は必要ありません。必要なのは、その目録が正確であり、実際に出荷または展開されたものを表しており、実際のセキュリティ上の意思決定を支えられるものかどうかを知ることです」
もちろん、CISAのガイドラインが法律で強制力を持つ要件ではないという事実もあります。サプライヤーにベストプラクティスの順守を求める役割は、規制当局、そしてより多くの場合は顧客が担うことになります。
公式な規制による後押しがない以上、「(組織は)相互運用可能なCycloneDXまたはSPDX形式のSBOMを義務付け、測定可能な品質基準を確立し、適時の更新を求め、不完全あるいは使用不能な提出物を拒否しなければなりません。何より重要なのは、組織が調達やぜい弱性管理、インシデント対応において、その情報を実際に活用しなければならないということです。SBOMを作成すること自体を、セキュリティ上の成果として扱うことはできません」
CISAが最新のOSSガイダンスを発表
ソフトウェアサプライチェーンを論じる上で中心となるのが、オープンソースソフトウェア(OSS)です。これには、組織が直接利用するソフトウェアコンポーネントだけでなく、その組織のベンダー、さらにはベンダーのベンダーが利用するコンポーネントも含まれます。そこでCISAは、「2026年版SBOM最小要素」の精神的な後継として、OSSの利用、評価、公開の方法に関するガイダンスを別途公開しました。
この文書は、SBOMの重要性や、OSSに関して一般に認められている他のベストプラクティスを強調するだけでなく、いくつかの点で新たな領域に踏み込んでいます。まず、政府機関が自ら開発するものについて「デフォルトでオープンソース化する」というアプローチを採用するよう提案しています。この考え方によれば、独自開発したソフトウェアをオープンソース化すべきかどうかをその都度判断するのではなく、政府機関はデフォルトでオープンソース化する方向を選び、そうしない場合には相応の正当な理由を示すべきだとしています。
CISAはまた、AIシステムについても厳格な姿勢を示しています。AIモデルの学習データは、様々なサイバーリスクの温床となり得るにもかかわらず、例えばSBOMにおけるサプライチェーンのソフトウェアコンポーネントほどには、同程度の透明性をもって扱われていないと指摘しています。
「本ガイダンスは、学習データを含む関連する全てのコンポーネントについて、各機関が十分な透明性を確保するよう促すものです」とCISAは7月30日付のプレスリリースで述べています。「透明性とアクセス手段があって初めて、各機関はソフトウェアを理解・調査し、脆弱性を分析し、発見された脆弱性やリスクを修復することができるのです」
翻訳元: https://www.darkreading.com/cybersecurity-operations/cisa-issues-fresh-sbom-guidance
