SBOMの盲点「ソフトウェア・ダークマター」とは？SCAツールが検知できないリスクと対策
公開日
セキュリティ
ソフトウェアサプライチェーンの安全性を確保するため、ソフトウェア部品表（SBOM）の導入が世界的に進められています。しかし、現在のSBOM生成ツールやソフトウェア構成分析（SCA）ツールの多くは、パッケージマネージャーの宣言ファイルなどの「メタデータ」のみを基準に部品を特定しています。この仕組みには、実際のファイルシステム上に存在するものの、メタデータに記録されていないファイルを見落としてしまうという重大な死角が存在します。
本記事では、パデュー大学のアビシェク・レディパレ氏らによる研究論文「Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations」に基づき、このメタデータと実ファイルの乖離がもたらすセキュリティ上のリスクについて解説します。
ソフトウェア・ダークマター（SDM）の定義と4つの発生パターン
なぜSBOMと実ファイルに乖離が生まれるのか
現在の一般的なSCAツールは、パッケージマネージャーのデータベースや依存関係のマニフェストファイルをスキャンしてSBOMを自動生成します。しかし、実際のソフトウェアビルドやデプロイ環境では、手動でのファイルコピー、パッケージマネージャーを介さないスクリプトによるインストール、複数の依存関係を一つにまとめるリパブリッシングなど、多様な手法が用いられています。その結果、マニフェスト（メタデータ）に記載されている情報と、コンテナやサーバーの実際のファイルシステムとの間に不一致が生じます。
この「実ファイルとしては存在するが、SBOMには記載されないセキュリティ上重要なファイル群」が、ソフトウェア・ダークマター（SDM）です。
SDMを発生させる4つの主な要因
研究グループは、SDMが発生する原因として以下の4つのパターンを特定しています。
- ビルドコンテキストの回り込み
ファイルのコピーやパッケージングを行う際に、意図しない不要なファイルが成果物に含まれてしまう現象です。たとえば、Dockerイメージ作成時の
COPY . .という指示によって、クレデンシャルを含む.gitディレクトリや.envファイルが意図せずコンテナ内に取り込まれてしまうケースがこれに該当します。 - プロバンス（由来）情報の消失 Javaの「shaded/uber-JAR」のように、複数の依存ライブラリをひとつのJARファイルに再パッケージ化するプロセスにおいて、元のクラス名やパッケージ構造が変更され、元の依存関係マニフェスト（POM）の追跡情報が消えてしまう現象です。
- メタデータの乖離 成果物に実際に同梱されているソフトウェアのバージョンが、宣言されているメタデータ（SBOMに記載されるべき情報）と一致しない、あるいはメタデータ自体が欠落している状態です。
- ポストビルド・ドリフト ビルドプロセスの後半や、デプロイ後の実行時初期化スクリプトの実行によって、メタデータの管理対象外となる新しいファイルが作成される現象です。
4つのエコシステムにおけるSDMの実態調査
調査概要：本研究では、Debian/UbuntuベースのDockerHub人気イメージ上位5,000件、Maven Centralのパッケージ4,889件、Jenkinsプラグイン2,066件、VS Code拡張機能3,000件、および約9,000人のエンジニアを擁する企業のエンタープライズLinux環境を対象に、2021年から2026年にかけて分析を行いました。
研究グループは、未追跡のファイルを検出して到達可能性を分析するツール「DARKFILES」を開発し、4種類のエコシステムを対象に実態調査を行いました。
| エコシステム | 普及率 | セキュリティ影響 | 主な発生源 | 時間的変化/ラグ |
|---|---|---|---|---|
| コンテナ（DockerHub） | 多くのコンテナにおいてSDMは依然として普遍的 | 重大なCVSSスコアを持つ脆弱性やゼロデイの存在を確認 | ADDやCOPYなどのファイルシステムレイヤー操作による導入 | メタデータに反映されるまで複数バージョン遅れる（パッケージング・ラグ） |
| パッケージ（Maven Central） | 依存関係を隠蔽しないものと、大半を隠蔽するものの二峰性の分布を示す | SCAツールで検出できない多数の脆弱性を検知 | クラスのネストやシェーディングによる導入 | 時間経過による変化は少なく、構造的・意図的に埋め込まれている |
| プラグイン（Jenkins/VS Code） | 難読化やパッケージングにより解析が困難なケースが存在 | 約1,000件のSBOMに現れない脆弱性を検知、クレデンシャルの漏洩 | 依存関係のバンドルやベンダー同梱による導入 | 代表的な傾向は見られず |
| エンタープライズ（実環境） | 社内環境でもSDMの存在を確認 | 未使用だが実行可能な一時スクリプトなどが検知される | IT自動化や構成管理ツールの運用プロセスから導入 | 社内環境のため比較対象外 |
表1：エコシステムごとの調査結果の概要
1. コンテナ環境（DockerHub）での分析
DockerHubの人気イメージを分析した結果、全体の平均として未追跡ファイルの割合は30%（中央値21%）に上ることが判明しました。これらの未追跡ファイルの中には、暗号鍵やパスワード、秘密設定ファイルなど、実行時に直接参照されるものの、SBOMスキャナーからは完全に隠れてしまっているファイルが多く含まれています。
2. 言語パッケージ環境（Maven Central）での分析
Javaのライブラリ配信プラットフォームであるMaven Centralにおいても、調査対象となったパッケージ（依存関係のバンドルが疑われる4,889件）の中でSDMの存在が確認されました。パッケージあたり平均して11.91個の依存関係が含まれており、そのうち約5.67個がメタデータに記載されていない「隠された依存関係」でした。
3. 拡張機能・プラグイン環境での分析
JenkinsのプラグインやVS Codeの拡張機能（Marketplace経由で配布されるもの）は、ホストのシステム特権を伴って実行されることが多く、SDMが存在する場合のリスクが非常に高い領域です。
- Jenkinsプラグイン： 解析対象のうち318個のプラグインから計1,737個の未追跡JARファイルが発見されました。さらに、57個のプラグインでは、マニフェストファイル（POM）が示すバージョンと、実際に同梱されているJARファイルのバージョンが異なっており、SBOMの記述が「不完全」なだけでなく「誤っている」状態でした。
- VS Code拡張機能： 調査された拡張機能の多くはJavaScriptのバンドラー（Webpackやesbuildなど）を使用して全依存関係をひとつのファイルに結合しているため、パッケージごとの構成情報が完全に消失していました。
4. 組織のエンタープライズ環境での分析
実際に運用されている企業のサーバー環境においても、Infrastructure as Code（IaC）や構成管理ツールによるプロビジョニングの過程で、パッケージマネージャーの管理外からバイナリやスクリプトをダウンロードして配置するケースが多発しており、これがSDMの温床となっていました。
SDMが引き起こすセキュリティリスクと「パッケージング・ラグ」
見過ごされる脆弱性と検出されたCVE
DARKFILESツールによる分析の結果、通常のSBOMベースのスキャナーでは検知できない、いくつかの深刻な脆弱性（ゼロデイ脆弱性を含む）が発見されました。
- Jenkins ssh-agentイメージにおける脆弱性（CVE-2025-32754、CVE-2025-32755）：
ビルド時にapt install openssh-serverを実行した際、コンテナイメージ内に動的に生成された一意ではない固定のSSHホスト鍵（例：/etc/ssh/ssh_host_rsa_key）がそのままイメージに埋め込まれていました。この結果、すべてのデプロイ先で同じSSH鍵が使い回される状態になっており、中間者攻撃（MitM）によるなりすましが可能な状態になっていました。 - acme.shイメージにおけるGitHubトークンの漏洩（CVE-2025-32111）：
コンテナ作成時の不要なファイルコピーによって、GitHubへのpush権限を持つ本番用トークンが含まれた.git/configファイルが、イメージのレイヤーに書き込まれていました。
| ファイルパス | 検出イメージ数 | 説明およびセキュリティ上の影響 |
|---|---|---|
/opt/bitnami/scripts/liblog.sh | 63 | Bitnamiのログヘルパー。改ざんによりログ監査をバイパスされたり、スタートアップコマンドを注入されたりする恐れがあります。 |
/usr/bin/with-contenv | 30 | s6-overlayの環境変数インジェクター。実行パス（PATH）の改変や、メインプロセス起動前の実行リダイレクトに悪用される可能性があります。 |
/etc/supervisord.conf | 28 | Supervisorの設定ファイル。不要なプロセスの追加起動やログ出力設定の変更に繋がります。 |
/etc/ssh/ssh_host_rsa_key | 7 | SSHのホスト秘密鍵。固定鍵の再利用により、暗号通信の傍受やデプロイ先へのなりすまし（MitM）が可能になります。 |
/usr/sbin/enable_insecure_key | 13 | 信頼性や認証のレベルを強制的に引き下げるスイッチスクリプト。 |
表2：DockerHubイメージで頻繁に検出されたセキュリティ上の注意を要するSDMの例
追いつかないメタデータ「パッケージング・ラグ」現象
コンテナなどの開発においては、実際のファイル内容の変更と、パッケージマニフェスト（メタデータ）の更新との間にタイムラグが生じる「パッケージング・ラグ」が発生します。
ひとつのプロジェクトのバージョンアップを時系列で追跡した調査によると、新しいリリースごとに未追跡のファイルが追加され、それが正式なメタデータ（パッケージ情報）としてSBOMに反映されるまでに、数バージョン遅れるサイクルが常態化していることが確認されました。
ソフトウェア・ダークマターを解消するための対策
ビルドプロセスにおける対策の統合
SDMの根本原因は、「ビルドパイプラインが生成するもの」と「マニフェストデータがキャプチャするもの」との間に情報的な隔たりがあることです。これを解消するためには、以下の対策が有効です。
- 「Darkfiles-before-SBOM」ステップの導入
ビルドプロセスの最後に、作成された成果物の中身（ファイルシステム全体）を実際にスキャンし、生成されたSBOMがファイルの実態を網羅しているか自動的に突合（検証）する工程を追加します。これにより、SBOMに記載漏れがある場合はビルドエラーにする、あるいは未解決の警告としてダッシュボードに表示させ、開発者に修正を促すフィードバックループを構築できます。 - 高忠実度（High-Fidelity）なビルド構成管理の推進
単なるマニフェストのスキャンに頼るのではなく、ビルド中にどのファイルが生成され、どこからダウンロードされたかをその場で正確に記録する「ビルド証明（Build Attestation）」や「再現可能なビルド（Reproducible Builds）」の仕組み（例：in-totoやDebianのbuildinfoなど）を活用し、ビルドプロセスそのものとSBOMの生成を密結合させることが推奨されます。
まとめ
SBOMはソフトウェアサプライチェーンの透明性を高める有効な手段として定着しつつありますが、マニフェストの解析に依存する現在のSCAツールや監査ワークフローには、大きな死角があります。
実際のファイルシステムとマニフェストとの乖離である「ソフトウェア・ダークマター」は、単なるレアケースではなく、多くの主要なエコシステムで構造的に発生している問題です。SBOMを正しく機能させるためには、単に「書かれた通りにスキャンする」だけでなく、デプロイされる成果物の実体に基づいた検証（ファイルシステムグラウンデッドな検証）をビルドプロセスに組み込み、継続的なセキュリティ監査を実施していく姿勢が求められます。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: