SBOMの義務化まであと15か月。あなたのSBOMはおそらく正しくない。

2026-09-09

投稿者: Ingo Kegel

2027年12月11日から、EUサイバーレジリエンス法（Cyber Resilience Act）におけるSBOMの義務が適用されます。つまり、EUでソフトウェアをリリースしたいなら、間もなくSBOMが必要になります。これはEUに限った話ではなく、この宣言型のアプローチによってサプライチェーンセキュリティを強化する世界的な潮流です。米国では2021年から連邦政府向けソフトウェアベンダーにSBOMが義務付けられており、CISA/NSA/FBIは今年7月にSBOM最小要素の改訂版を公表しました。

SBOMを正しく作成するのは容易ではありませんし、ソフトウェアにインストーラーを付けて出荷する場合には、その難易度はさらに上がります。今、何をすべきでしょうか。見ていきましょう。

そもそもSBOMとは何か？

SBOMとは、ソフトウェアを構成するコンポーネントのリストを機械可読な形で表したものです。形式は2つあります。2017年に開始され、2024年にEcma標準となったOWASPプロジェクトのCycloneDXと、2021年からISO標準となっているLinux FoundationのSPDXです。規制当局はどちらの形式も受け付けます。

SBOMの中身は、主に次の3つの情報で構成されています。

Package URL形式で表したコンポーネントの識別情報。例： pkg:maven/org.apache.commons/[email protected]
ハッシュとライセンス
どのコンポーネントがどのコンポーネントに依存しているかを示す依存グラフ

SBOMを手作業でまともに作成することはできず、ツールによる出力とする必要があります。典型的なSpring Bootアプリケーションでは、すでに100を超える推移的依存関係が引き込まれています。ビルドツールは推移的依存グラフ全体をすでに把握しているため、SBOMは通常プラグインによって生成されます。JVMでは主に、Gradleならcyclonedx-gradle-plugin、Mavenならcyclonedx-maven-pluginが使われます。

なぜ今なのか？

サプライチェーンへの攻撃は増加の一途をたどっています。特に深刻だった事例を挙げると、2024年3月に発生したxz-utilsのバックドアがあります。これはほぼすべてのソフトウェアが出荷しているライブラリでした。2025年9月にはnpmでchalk/debugメンテナを狙ったフィッシング攻撃があり、そのわずか1週間後には、自己複製する初めてのnpmワームでMaven Centralにも飛び火したShai-Huludが発生しました。

Sonatypeは2025年だけでも、約50万個の新しい悪意のあるパッケージを記録しています。LLMのサイバー攻撃能力が高まるにつれ、この状況はさらに悪化するでしょう。今すぐ対策を強化する必要があります。

SBOMは魔法の解決策ではありませんが、ソフトウェアがどの依存関係を出荷しているのかを即座に確認できるため、外部の脅威に最小限の遅れで対応できます。

では、なぜ難しいのか？

SBOMを生成するプラグインが見ているのは、ビルド時点の依存グラフです。しかし、それは通常、実際に出荷するものではありません。SBOMは、実際に出荷するものをバイト単位で正確に記述しなければなりません。依存関係の解決後にバイトを変えるような変換が一切あると、そのSBOMは無効になります。

このようなバイト変更変換には、どのようなものがあるでしょうか。最も単純な例がファットJARです。すべての依存関係を1つのJARにパッケージングしてしまうと、SBOMが依存関係ごとに提供するハッシュはすべて不正なものになります。

しかし、インストーラーを出荷する場合には、事情はもっと厄介になります。WindowsのAuthenticode署名、macOSのMach-O署名、JARのシュリンクやパッキングなど、そのどれもがハッシュを変更します。「依存関係の解決時点」で生成されたSBOMは、最終成果物に対して常に不正なものになります。

さらに厄介なのは、インストーラーによって追加される目に見えないコンポーネントの存在で、まったく把握していない場合もあるでしょう。例えばWindowsランチャーに含まれるネイティブのzlibライブラリや、インストーラーランタイム内のシェーデッドJARなど、これらはすべてSBOMに欠けています。

このzlibの例は、まったく理論上の話ではありません。私たち自身のinstall4j Windowsランチャーから来た例です。ライブラリは改変されて埋め込まれるため、スタンドアロンの実行可能なzlibアーティファクトは配布されません。そのため、詳細なスキャンをしない限り事実上見えませんが、それでも脆弱性の影響を受けるため、SBOMに含めなければならないものです。

「最後のアセンブラー」の問題

インストール型ソフトウェアの場合、インストーラーは顧客が受け取る成果物を組み立てる最終段階です。その段階より前で、あるいはその段階を経ずにSBOMを作成すると、それは製品を記述したものにならず、現行または間もなく発効する規制に違反している可能性が高くなります。

つまり「最後のアセンブラー」とは、インストーラーをビルドするツールであり、SBOMに対して何らかの処理を行える必要があります。できないのはSBOM自体の生成です。それは依存グラフを知っているビルドツールにしかできません。その代わりに必要なのは、少なくとも自身のコンポーネントのSBOMを書き出すことです。さらに良いのは、既存のSBOMに自身の追加コンポーネントを統合できることで、そうすればSBOMをインストーラーに組み込んだまま出荷できます。

install4jのSBOM機能

install4j 13.1では、各メディアファイルに含まれるinstall4jランタイムコンポーネントについて、JSONおよびXML形式のCycloneDX SBOMを生成できます。ファイルは、メディアファイルの隣に<media file>.install4j_runtime.cdx.json / .xmlという外部ファイルとして書き出すことも、ディストリビューションツリー内のパスに埋め込むこともできます。

埋め込み先のパスにすでにSBOMが存在する場合（CycloneDX仕様のバージョン1.2から1.7までをサポート）、install4jはそれを置き換えるのではなく、ランタイムコンポーネントとその依存グラフをそのSBOMにマージします。さらに、install4jはコンパイル中のバイト変更変換（署名、シュリンク、パッキング）をすべて追跡してハッシュを書き換えるため、SBOMは最終的な署名済みメディアファイルと一致します。