OSS・SBOM セキュリティ実践ガイド

開発・ビルド・配布・実行の全経路で改ざんと攻撃を防ぐ実践。ソースコード、サードパーティ部品、ビルドシステム、成果物リポジトリ、配信経路を対象とする。SolarWindsやLog4Shellで注目が急上昇した。

ソフトウェア部品表。含まれる全コンポーネント・バージョン・依存関係の一覧で、ソフトの「原材料表示」に相当。米大統領令 14028 は連邦調達での SBOM 普及を加速させ、各機関はソフトウェアの重要度に応じて調達要件として SBOM を求めることができ、EU CRA は EU 市場に投入されるデジタル製品に SBOM 等の透明性義務を課す——対象は異なるが方向は同じだ。 CleanSource SCA の SBOM 機能を見る → SBOM 導入ガイド →

直接依存は自ら明示的に宣言した部品、推移依存はその部品がさらに引き込む部品。推移依存は現代アプリの依存関係の大半を占めるのが通例で、最も見落とされやすく追跡困難なリスク源だ。

コードの記述から納品・稼働までの一連のプロセス:ソースコード、サードパーティ部品、ビルドシステム、成果物レジストリ、配布経路。どの工程が侵害されても最終製品へ伝播する——供給網セキュリティの本質はすべての工程を信頼管理下に置くことだ。

大きく寛容型(MIT、Apache-2.0、BSD:義務が少なく商用向き)とコピーレフト型(GPL系:派生物も同条件で公開)に分かれる。採用前に義務の強さを確認する。

GPL部品を含む派生物を配布する場合、全体をGPLで公開しソース全文を提供する義務——いわゆる「伝染性」。配布しない社内利用のみなら通常は義務が生じない。 実際の義務は、改変・リンク方法・配布形態などによって異なります。個別案件では法務確認が必要です。

LGPLは緩く、動的リンクなら自コードの公開は通常不要。AGPLは厳しく、ネットワーク経由のサービス提供も「配布」とみなされ、SaaSでも義務が発生する。 実際の義務は、改変・リンク方法・配布形態などによって異なります。個別案件では法務確認が必要です。

OSSコンプライアンス管理の国際標準(ISO/IEC 5230)。企業のコンプライアンスプロセスの要件を定め、認証により取引先に管理体制を示すことができる。

ライセンス種別と使い方次第:寛容型(MIT/Apache)は不要。コピーレフト(GPL)は「配布」時に派生物の公開を要求し、社内利用のみなら発動しない。LGPL は動的リンクなら概ね免除。境界判定は複雑で、だからこそライセンス分析のツール化・自動化が要る。 実際の義務は、改変・リンク方法・配布形態などによって異なります。個別案件では法務確認が必要です。

される。GPL 執行訴訟には多くの先例がある:欧州の gpl-violations.org 系勝訴、米国の SFC 対 Vizio 判決は消費者にも GPL 権利主張を認めた。帰結は販売差止・強制公開・賠償・信用毀損——「OSS は誰も取り締まらない」は過去の認識だ。 実際の義務は、改変・リンク方法・配布形態などによって異なります。個別案件では法務確認が必要です。

共通脆弱性識別子。既知脆弱性の世界共通番号体系で、CVE-2021-44228(Log4Shell)など。MITREが維持し、脆弱性情報の共通言語となっている。

脆弱性悪用可能性交換(Vulnerability Exploitability eXchange)。ベンダーが「この製品はこの脆弱性の影響を受けるか」を機械可読で表明する。SBOMを補完する文書——SBOMが「この部品を含む」と言い、VEXが「だが自社製品での利用形態では影響を受けない」と言う。誤検知処置コストを大幅に下げる。 VEX 対応を見る →

米CISAが維持する「悪用が確認された脆弱性」の目録。実攻撃の証拠があるものだけを収録する。優先順位付けの重要な判断材料:KEV掲載>CVSS高得点——実際に悪用されるMediumは、理論上は Critical と評価された脆弱性 より緊急だ。

CVSS は「理論上の深刻度」であって「現実のリスク」ではない:悪用コードがなく隔離環境にある 9.8 は、大規模悪用中の 6.5 より軽いことがある。優先順位付けには KEV(悪用の有無)と到達可能性分析(脆弱な関数を実際に呼んでいるか)を重ねるべきだ。

悪用予測スコアリングシステム:機械学習で今後 30 日以内に悪用される確率を 0-1 で予測する。CVSS と相補的——CVSS は「どれほど深刻か」、EPSS は「実際に狙われる確率」。両者の併用が現代の脆弱性優先順位付けの標準だ。

OpenSSF が主導するソフトウェア供給網完全性のフレームワーク。現行 1.2 版は単一の 1〜3 級ではなく、「トラック」で構成される:ビルドトラックはビルド工程の改竄耐性と来歴証明を、ソーストラックはリポジトリの変更管理を測り、各トラック内に保証レベルがある。実践の道筋:まずビルドの来歴証明(Build L1)から始めて段階的に上げる——SLSA レベルは大手顧客と財団が成果物の完全性を測る共通言語になりつつある。 SLSA 1.2 公式仕様 →

5 段階:資産棚卸し(コードベース全体のスキャンで部品一覧)→ライセンス識別(スニペット単位まで)→義務マッピング→衝突検出(ライセンス間・ビジネスモデルとの間)→是正と証跡保全(NOTICE、SBOM、監査報告)。上場・M&A・大手顧客のデューデリ前が定番シーンだ。

5 軸:検出力(スニペット単位か、マニフェスト読取のみか)、データ品質(脆弱性DBの網羅と鮮度)、誤検知の管理(到達可能性分析・ポリシー定義)、開発プロセスへの統合(CI/IDE 統合と速度)、コンプライアンス出力(SBOM 形式・監査報告)。自社の実コードでの POC 比較がスペック表より確実だ。 Community Edition で試す →

三点セット:内部レジストリミラー(外部から統制下で定期同期)、脆弱性 DB のオフライン更新パッケージ(SCA はオフライン配備と脆弱性情報の取り込み対応が必須)、導入許可リスト工程(新部品は DMZ で審査後に内部へ)。金融・防衛・エネルギーの標準形態——選定時「完全オフライン対応」は重要な選定条件となる。 オフライン導入のデモを予約 →

モデルとデータセット自体が部品となり(ポイズニングや改ざんの対象となり得る)、高速進化するAIフレームワークは脆弱性が密集、Agentのプラグイン/ツール機構がコード実行面を開く。2026年以降、AI部品はCritical脆弱性の最多領域。(出典:Sectrend CSSA 月次統計) CleanCode を見る →

訓練データの汚染や公開済みモデル重みの改ざんにより、特定条件でモデルに悪性挙動をさせる攻撃。モデルファイル(pickle形式等)自体が実行コードを運べる——モデルの取得も依存パッケージ同様に出所検証が要る。

Model Context Protocol——AI Agent が外部ツールとデータ源を呼び出すオープンプロトコル。リスク:MCP サーバー自体が新たな供給網部品(ポイズニングや改ざんの対象となり得る)、ツール記述への指示注入(プロンプトインジェクション)、Agent 権限の濫用。導入前に OSS 部品と同じ厳しさで MCP サーバーを監査すべきだ。 SkillSec を見る →

Agent は「読んだテキスト」を「実行する行動」に変換する:Web ページ・文書・メール内の隠し指示がタスクとして実行され得る(間接プロンプトインジェクション)。しかも Agent は実際の資格情報とシステム権限を持つ。防御線:ツール権限の最小化、機微な操作の人間承認、Agent が読む内容への注入検査。

経産省が公表した「ソフトウェア管理に向けた SBOM の導入に関する手引」は、日本企業の SBOM 実装の事実上の出発点:導入フェーズの整理、環境構築、運用管理、そして実務チェックリストを提供する。自社の成熟度をこの手引の段階に当てはめることが、SBOM プロジェクト立ち上げの近道となる。 経産省 SBOM 手引(公式)→

確認すべきは 4 点:要求形式(SPDX か CycloneDX か)、対象範囲(製品全体か納品モジュールか)、更新頻度(リリース毎か定期か)、脆弱性情報の扱い(VEX 併用の可否)。SCA ツールでビルド毎に自動生成する体制を組めば、提出要求は負担ではなく信頼の証明機会になる。CleanSource SCA の SBOM 出力を見る →

組込みはソース解析だけでは足りない:ファームウェア、静的リンクされたライブラリ、ベンダー提供のバイナリ SDK は、バイナリ成分分析で初めて可視化できる。ソース側のスニペット検出とバイナリ解析を組み合わせ、「ソースから成果物まで」の SBOM を完成させるのが製造業における実践的な方法です。CleanBinary のバイナリ解析を見る → バイナリ SBOM 生成ガイド →

OSS ライセンスコンプライアンスの国際規格で、日本は世界で最も採用が進む市場の一つ。トヨタ、ソニーをはじめ主要製造業が参画し、サプライチェーン上流への準拠要求も広がる。Sectrend はアジア太平洋のセキュリティツールベンダーとして初期から OpenChain コミュニティに参画し、規格に整合したコンプライアンス運用を支援している。 OpenChain 公式サイト → OpenChain 導入事例(Toyota・公式)→

5 点:①日本語サポートとローカル体制②オンプレミス/オフライン対応(製造業・金融の必須要件)③組込み・バイナリ解析の対応範囲④OpenChain 準拠運用との整合⑤既存 ALM/CI ツールチェーンとの統合性。スペック表より、自社の実コードでの POC 検証が確実だ。まずは Community Edition で試す →