昨日のSBOMはただの紙 — OpenSSL 6月9日アドバイザリが教えたこと

2026年6月8日と9日で、当サイトのコードは1行も変わっていない。変わったのは世界の側だ。それでも、昨日まで「問題なし」だった行が、今日は「要対応」になった。SBOMの価値はここにしかない、という話をする。

みんな作ってる。でも誰も使ってない

ENISAが2026年6月に公開した「SBOM Adoption State of Play 2026」(334組織を調査、65%がEU拠点)の数字が興味深い。

• 78%の組織がSBOM対応に着手済み
• しかし生成と活用の間に「中程度のギャップ」が44%、「重大なギャップ」が23%
• ギャップを解消できているのはわずか7%

ENISAの結論はこうだ — SBOMは主にコンプライアンス目的で使われており、アーティファクトリポジトリに置かれたまま読まれないSBOMはただの書類である、と。

なぜこうなるのか。製造業のBOMと比べると理由が見えてくる。

製造業のBOMはなぜ死なないのか

製造業には2つのBOMがある。設計部品表(E-BOM)と製造部品表(M-BOM)、そして工順(作り方)。この3つから原価積上げが回る。BOMが間違っていれば原価が狂い、原価が狂えば利益が狂う。だから誰に命令されなくてもBOMは保守される。BOMの精度がそのまま経営数字の精度だからだ。

SBOMにはこの「金の流れ」がない。SBOMが3ヶ月古くても、誰のP/Lも壊れない。CRA(欧州サイバーレジリエンス法)は罰則という形で人工的に金を絡めようとしているが、罰則駆動のBOMは監査の前日にしか更新されない。

しかも、鮮度の問題は製造業より深刻

製造の部品表は設計変更がなければ動かない。SBOMは npm install 一発で変わる。

さらにAIコーディングの時代、エージェントが依存パッケージを次々と追加していく。依存が増える速度が人間のレビュー速度を超えた。手動でSBOMを最新に保つのは、もう埒が明かない。

「提出が義務づけられたら」と仮定してみてほしい。提出した瞬間からSBOMは古くなり始める。昨日のSBOMは、もう今日の自分のソフトウェアを表していないかもしれない。

6月9日、OpenSSLで起きたこと

2026年6月9日、OpenSSLプロジェクトがセキュリティアドバイザリを公開し、18件の脆弱性が修正された。筆頭はCVE-2026-45447 — PKCS#7署名検証(PKCS7_verify())におけるheap use-after-free。細工されたPKCS#7/S/MIME署名メッセージを処理させることで、クラッシュやheap破壊、最悪リモートコード実行に至る可能性がある脆弱性だ(OpenSSL公式の深刻度レーティングはHigh)。影響は4.0系から旧1.0.2系まで広範な系列に及ぶ。

ここで重要なのは: 6月8日と6月9日で、あなたのコードは1行も変わっていないということだ。

変わったのは世界の側だ。昨日まで「問題なし」だったSBOM上の openssl の行が、今日は「要対応」になった。これを検知できるのは、最新のSBOM(自分が何を使っているか)と最新の脅威情報(世界で何が起きたか)を常時突き合わせている場合だけだ。

SBOMは、今の脅威と比較して初めて威力を発揮する。そこで初めて防御線が引ける。

SBOMはレーダーである。提出書類ではない

防空に例えるとわかりやすい。

レーダーは「昨日の空の記録」では防空にならない。探知から要撃までの時間がすべてだ。そしてこれは一回のイベントではない。明日も明後日も、どこかで新しいCVEが公開される。防空とは連続である。

「提出」はフライトプランの届出のようなもので、防空そのものではない。問われるのは書類ではなく、レーダーを回し続ける運用力だ。

経産省は、意外なほど正しかった

実は経産省の「SBOM導入に関する手引 ver2.0」(2024年8月)は、この核心を突いている。

ver2.0で新設された第7章は「脆弱性管理プロセスの具体化」— SBOMを脆弱性管理に接続する具体的手順に丸ごと一章を割いた。手引は、作成・共有・運用・管理という全体プロセスのうち特に脆弱性管理のフェーズが重要だと明記している。経産省自身の実証実験でも、SBOM最大のメリットは「脆弱性発覚から対応完了までの時間短縮」— つまり探知から要撃までの時間だった。

さらに付録の「SBOM対応モデル」は、SBOMを導入する/しないの二択ではなく「どこまで運用できているか」の成熟度で可視化するフレームワークだ。CRAが罰則で駆動するのに対し、日本は運用成熟度で語っている。書類ではなく運用力を問う、という方向性は正しい。

問題は、その運用を手作業でやるのは不可能だということだ。

実録: 当サイトでレーダーが鳴った

理屈はここまで。実際に当サイト(aikido-community.jp)で起きたことをお見せする。

当サイトのリポジトリはAikidoに接続してある。Reports > Licenses & SBOM でリポジトリを指定すると、約100パッケージがライセンスタイプとリーガルリスク評価つきで一覧される。「ssl」で絞るとこの2行だ。

openssl@3.0.20-1~deb12u1 と libssl3@3.0.20-1~deb12u1。Legal Risk: Low。ライセンス的にはまったく地味な、誰も気に留めない2行である。ちなみにこれはnpmで自分がインストールしたものではない。DockerベースイメージのOSパッケージだ。「入れた覚えのないもの」までインベントリに載っている — これがSBOMの第一の仕事だ。

リポジトリを接続しておけば、このインベントリは継続的に更新され、新しい脆弱性情報と照合される。該当するパッケージがあれば、アラートとして浮かび上がる。

そして6月9日のアドバイザリ公開後、問題タブにこれが点灯した。

「openssl — DoS or RCE possible due to use after free」。Aikidoの深刻度評価はCritical(OpenSSL公式レーティングはHigh。スキャナ側は環境を加味して独自に評価する)。検知場所はコンテナ claude-code-community-app、修正時間の見積りは30分。

詳細を開くと、CVE-2026-45447を筆頭に9件のSubissueが束ねられ、修正パスまで提示されている: 3.0.20-1~deb12u1 ⇒ 3.0.20-1~deb12u2。つまり「Debianのパッチ版にアップグレードしてDockerイメージを再ビルドせよ」。AutoFixボタン付きだ。

6月8日まで、この行はLegal Risk: Lowの静かな在庫だった。6月9日、世界が変わり、同じ行がCriticalとして浮かび上がった。私のコードは1行も変わっていない。レーダーが回っていたから探知できた。あとはスクランブル — 30分のパッチ作業だけだ。

なお、SBOMのファイルエクスポート(CycloneDX/SPDX/CSV)も可能だが有料プランの機能だ。ただ正直に言えば、エクスポート文書は本質ではない。価値は文書ではなく、このアラートが上がる状態を維持していることにある。

まとめ

• SBOMが使われないのは、製造BOMと違って金が絡まないから。書類としてのSBOMに価値はない
• 価値関数は「探知から対応までの時間」。最新のSBOM × 最新の脅威の常時突合で初めて防御線が引ける
• 6月9日のOpenSSLが実例。コードは変わらなくても、世界が変わる
• 経産省ver2.0の方向性(脆弱性管理への接続、運用成熟度)は正しい。ただし手作業では回らない
• レーダーは自動で回し続けるもの。スクランブルできる体制までがSBOM運用