※本稿は、2026年8月30日時点で公表されているRustプロジェクト、経済産業省、CISA等の資料に基づいています。事案の内容や対象パッケージについて追加情報が公表される可能性があるため、公開前に最新情報を再確認してください。
※事案の経緯、SBOMの最小要素、各ツールの仕様は公表資料に基づく事実です。一方、納品物一覧、検収項目、契約条項の例は、中小企業が開発を外注する場合を想定した実務上の提案です。契約書の最終的な内容については、必要に応じて弁護士へ確認してください。
「システムは開発会社に作ってもらったので、詳しい中身は分かりません」
外注したシステムについて、脆弱性が公表されたときに、このような状態になっていないでしょうか。
現代のソフトウェアは、開発会社が全てを一から作るとは限りません。多くの場合、オープンソースソフトウェアや市販のライブラリ、フレームワーク、クラウドサービスなどを組み合わせて作られています。
それ自体は問題ではありません。
実績のあるライブラリを利用することで、開発期間を短縮し、既に検証された機能を活用できます。問題になるのは、何を、どのバージョンで、どのように組み込んだのかを、発注者も開発会社も説明できない状態です。
2026年8月20日、Rustプロジェクトは、Rustのパッケージ公開基盤であるcrates.ioにおいて、悪意あるパッケージが確認されたと公表しました。
悪意あるproc-macro1というパッケージには、外部から不正なプログラムをダウンロードするビルドスクリプトが含まれていました。さらに、正規の開発者が管理していた人気パッケージにも、悪意あるパッケージへの依存関係を追加したバージョンが公開されていました。Rust Security Response Teamは、正規の開発者本人が悪意を持って行ったとは考えておらず、その端末または認証情報が侵害された可能性が高いと説明しています。
この事案は、開発を委託する企業にとっても無関係ではありません。
発注者が直接選んでいないライブラリであっても、別のライブラリを経由して間接的に取り込まれることがあります。また、今回のようにビルド時に不正な処理が実行される場合、完成したシステムだけでなく、開発者のパソコンや開発会社のCI/CD環境まで確認が必要になる可能性があります。
今回は、SBOMの一般的な説明を繰り返すのではなく、外注開発の発注者が、契約時と納品時に何を求めればよいのかに絞って解説します。
2026年8月に発生したRustのサプライチェーン攻撃
Rustプロジェクトによると、2026年8月20日7時15分（UTC）、proc-macro1というパッケージが悪意あるものであるとの報告を受けました。
調査の結果、このパッケージには、ビルド時に外部から不正なプログラムをダウンロードするスクリプトが含まれていることが確認されました。
さらに、次の正規パッケージについて、悪意あるproc-macro1へ依存するバージョンが公開されていました。
| パッケージ | 悪意あるバージョン | 公開されていた時間 |
|---|---|---|
| arrayref | 0.3.10 | 約86分 |
| internment | 0.8.7 | 約90分 |
| append-only-vec | 0.1.9 | 約107分 |
このほか、proc-macro-en、aovine、arone、aronenao、tinymemberといった関連パッケージも削除されました。Rustプロジェクトは、ローカル環境の依存関係やキャッシュを確認し、これらのパッケージが取り込まれていないかを調べるよう案内しています。
ここで注目したいのは、悪意あるバージョンが公開されていた時間の長さだけではありません。
わずか1時間半前後で削除されたとしても、その時間帯に開発者のパソコンや自動ビルド環境が新しい依存関係を取得していれば、影響を受ける可能性があります。
パッケージ公開サイトから削除されたからといって、既に開発者の端末、ビルドサーバー、コンテナイメージ、キャッシュなどへ保存されたデータまで自動的に削除されるわけではありません。
発注者が直接選んでいない部品も含まれる
ソフトウェアの依存関係には、いくつかの種類があります。
| 種類 | 内容 | 例 |
|---|---|---|
| 直接依存 | 開発者が自ら利用すると指定した部品 | 画面表示用のフレームワーク |
| 間接依存 | 直接利用する部品が、さらに利用している部品 | フレームワーク内部の通信ライブラリ |
| ビルド依存 | ソフトウェアを作成・変換するときに利用する部品 | コンパイラ拡張、コード生成ツール |
| 実行時依存 | 完成したソフトウェアを動かすために必要な部品 | データベースドライバー |
| 開発・テスト依存 | 開発やテストのときだけ利用する部品 | テスト自動化ツール |
発注者が「このライブラリを使ってください」と指定していなくても、開発会社が選んだフレームワークの先に、多数の間接依存が存在する場合があります。
Rustの公式ドキュメントも、一般的なプログラムは外部ライブラリを利用し、さらにそのライブラリの依存先へ間接的に依存することを説明しています。
今回の事案では、悪意ある処理がライブラリの通常機能ではなく、ビルドスクリプトに含まれていました。
そのため、次の二つは別々に確認する必要があります。
- 悪意あるパッケージが完成した製品に含まれているか
- 悪意あるパッケージが開発・ビルド時に取得または実行されたか
最終的な実行ファイルだけを調べても、ビルド時に何が起きたかを完全には確認できない場合があります。
問題は「無料」であることではない
オープンソースソフトウェアや無料のライブラリを利用すること自体が、危険なのではありません。
有償の製品にも、オープンソースの部品が含まれていることがあります。また、有償か無償かにかかわらず、脆弱性が発見されたり、開発者のアカウントが侵害されたりする可能性はあります。
問題は、次の状態です。
- 何を利用しているか分からない
- バージョンが分からない
- 誰が更新するか決まっていない
- 開発終了後の保守責任者がいない
- 脆弱性が公表されても影響を判断できない
- ライセンス条件を確認していない
- 開発会社が変わるとビルドできない
「無料のライブラリだから費用は発生していない」という説明と、「管理しなくてよい」という説明は同じではありません。
ライブラリの導入費用が無料でも、調査、更新、テスト、ライセンス確認、脆弱性対応には作業が必要です。
ソフトウェア納品時に起きやすい問題
中小企業がシステム開発を外注した場合、納品物が次のようになっていることがあります。
- 利用できるWebサイトだけが納品される
- 実行ファイルだけを受け取る
- ソースコードは受け取るが、作成方法が分からない
- プログラム一式はあるが、外部ライブラリのバージョンが分からない
- 開発会社のパソコンでしかビルドできない
- 開発時のアカウントやクラウド環境が残っている
- ライセンス一覧がない
- 脆弱性が公表された後の連絡先が決まっていない
この状態では、数年後に脆弱性が公表されても、自社が影響を受けるか判断できません。
元の開発会社へ問い合わせても、担当者が退職していたり、開発環境が廃棄されていたりする可能性があります。
開発が完了した時点では問題なく動いていても、将来の更新や調査に必要な情報が残っていなければ、会社として管理できるシステムとはいえません。
「依存関係一覧」と「SBOM」は同じではない
外部ライブラリを管理する資料には、いくつかの種類があります。
それぞれ役割が異なるため、どれか一つだけ受け取れば十分とは限りません。
| 資料 | 主な内容 | 主な用途 |
|---|---|---|
| 依存関係一覧 | ライブラリ名、バージョン、用途など | 人が内容を確認する |
| マニフェスト | 開発者が指定した依存条件 | 開発環境を再現する |
| ロックファイル | 実際に解決された正確なバージョン | 同じ依存関係で再ビルドする |
| SBOM | 部品、バージョン、識別子、依存関係など | 自動照合、脆弱性・ライセンス管理 |
| ソースコード | 自社開発したプログラム | 修正、調査、再開発 |
| ビルド手順 | ソースコードから成果物を作る方法 | 保守会社変更、障害復旧 |
| ビルド記録 | 作成日時、環境、実行結果など | 事後調査、成果物の再現 |
| ハッシュ値 | 成果物を識別する値 | 改変確認、納品物との対応確認 |
| ライセンス一覧 | OSS等の利用条件 | 著作権・契約上の確認 |
| 脆弱性確認結果 | 納品時点で確認した既知の脆弱性 | 検収、残存リスクの把握 |
小規模な開発では、Excel形式の依存関係一覧から始めることもできます。
ただし、部品数が増えると、人が一覧表を作成・更新するだけでは漏れが生じやすくなります。脆弱性情報との自動照合も困難です。
そのため、機械的に読み取り、分析できるSBOMが利用されます。
マニフェストとロックファイルの違い
今回のRust事案を理解するうえでは、マニフェストとロックファイルの違いが重要です。
Rustでは、主に次の二つのファイルが利用されます。
| ファイル | 内容 |
|---|---|
| Cargo.toml | 利用するパッケージや許容するバージョン範囲などを記載する |
| Cargo.lock | 実際に解決されたパッケージと正確なバージョンを記録する |
Rust公式ドキュメントは、Cargo.tomlが依存関係を比較的広い条件で記述するのに対し、Cargo.lockには依存関係の正確な情報が含まれると説明しています。
例えば、マニフェスト上で「0.3系列を利用する」と指定されている場合、実際に取得されるバージョンは、取得した時期やロックファイルの内容によって変わる可能性があります。
そのため、「arrayrefを利用しています」という回答だけでは不十分です。
確認すべきなのは、次の情報です。
- 正確なバージョン
- 直接依存か間接依存か
- どのリポジトリから取得したか
- いつ取得したか
- どのビルドで利用したか
- どの成果物へ対応するか
ロックファイルは有用ですが、ロックファイルだけでライセンスや成果物のハッシュ、SBOMの作成者、作成時点などを全て確認できるとは限りません。
そのため、ロックファイルとSBOMは競合するものではなく、互いを補う資料として扱います。
SBOMとは何か
SBOMは、Software Bill of Materialsの略で、ソフトウェアを構成する部品と、その関係を記録した情報です。
製造業における部品表のソフトウェア版と考えると分かりやすいでしょう。
SBOMにより、あるライブラリに脆弱性が発見されたときに、自社のシステムへ含まれているかを調べやすくなります。
ただし、SBOMがあるだけで安全になるわけではありません。
CISA等による2026年版のSBOM最小要素も、SBOMだけで全てのソフトウェアセキュリティ問題を解決できるわけではない一方、リスクに基づく判断を行うために必要な基盤であると説明しています。
過去のライトハウスコンサルタントの記事でもSBOMの概要や脆弱性管理への活用を取り上げていますが、本稿では、外注開発における納品物と検収方法へ重点を置いています。
2026年にSBOMの最小要素が更新された
2026年7月、CISAと国際パートナーは、「2026 Minimum Elements for a Software Bill of Materials」を公表しました。
これは、2021年に米国NTIAが公表したSBOMの最小要素を更新・置き換えるものです。経済産業省も、この国際ガイダンスへ共同署名しています。
2026年版では、従来の部品名、バージョン、依存関係などに加え、次の要素が新たに示されました。
- SBOM作成者の電子署名
- SBOMのデータ形式名
- データ形式のバージョン
- SBOMを作成した工程・状況
- SBOM作成ツール名
- SBOM作成ツールのバージョン
- SBOM自体のバージョン
- ソフトウェア部品のハッシュ値
- ハッシュアルゴリズム
- ソフトウェア部品のライセンス
これらが追加された理由の一つは、単に「部品名が並んでいる一覧」ではなく、いつ、どのような方法で作られたSBOMかを確認し、機械的な分析や信頼性の確認に利用しやすくするためです。
ただし、この国際ガイダンス自体が、日本国内の全ての民間開発契約へ新たな法的義務を課すものではありません。
同ガイダンスも、SBOMの生成や要求方法を整理するものであり、それ自体が新しい法的要件を作るものではないと説明しています。
発注者としては、「法律で義務だから求める」というより、将来の脆弱性対応と保守のために、契約上の納品物として定めることが重要です。
「いつ作られたSBOMか」を確認する
2026年版で追加された項目の中で、外注開発の発注者が特に確認したいのが、SBOMの生成時点を示す情報です。
同じソフトウェアでも、SBOMを作成する時点によって、記録される部品が異なる場合があります。
| 作成時点 | 確認できる内容の例 |
|---|---|
| ビルド前 | ソースコードやマニフェスト上の依存関係 |
| ビルド中 | 実際に取得・利用したビルド用部品 |
| ビルド後 | 完成した実行ファイル等に含まれる部品 |
| 配備後 | サーバーやコンテナ上で稼働している部品 |
CISA等の2026年版ガイダンスでは、この違いを明確にするため、「SBOM Generation Context」が追加されました。ソースコードから作成したSBOMは「ビルド前」、バイナリ解析から作成したSBOMは「ビルド後」といった形で、生成した工程を示すことが想定されています。
今回のRust事案のように、悪意ある処理がビルド時に実行される場合、完成した実行ファイルの解析だけでは、開発環境で何が実行されたかを把握できない可能性があります。
そのため、重要なシステムでは、次の二つを分けて受け取る方法が考えられます。
- ソースコードやロックファイルを基にした依存関係情報
- 完成した成果物を解析したSBOM
両方の結果を比較することで、ビルド時だけ使われた部品や、成果物へ追加された部品を確認しやすくなります。
SBOMはPDFだけで受け取らない
人が読むためのPDFやExcel形式の一覧には価値があります。
しかし、部品数が数百、数千に増えると、脆弱性情報との照合作業を人手だけで行うことは困難です。
2026年版ガイダンスは、SBOMを機械処理可能な形式で提供することを重視しています。現在広く利用されている形式として、SPDXとCycloneDXを挙げています。
納品条件としては、例えば次のように定めます。
- 人が確認するための概要表
- SPDXまたはCycloneDX形式のSBOM
- 元となったマニフェストとロックファイル
- SBOMを作成したツール名とバージョン
- SBOMの作成日時
- 対象となる成果物の名称とバージョン
- 成果物のハッシュ値
PDFしか受け取っていない場合、将来、脆弱性情報と自動照合する際に、改めて入力し直す必要があります。
一方、機械処理用ファイルだけでは、経営者や発注担当者が内容を理解しにくい場合があります。
両方を受け取る方法が現実的です。
小規模な開発で最低限受け取りたいもの
全ての小規模開発で、大企業向けの複雑なSBOM管理システムを導入する必要はありません。
ただし、最低限、次の資料は受け取ることを推奨します。
| 納品物 | 最低限記載する内容 |
|---|---|
| ソースコード一式 | 納品対象となる全ソースコード |
| 依存関係一覧 | 部品名、正確なバージョン、用途 |
| ロックファイル | 実際に解決された依存バージョン |
| ライセンス一覧 | ライセンス名、表示・提供条件 |
| ビルド手順書 | 必要なツール、手順、設定 |
| 環境情報 | OS、ランタイム、データベース等のバージョン |
| 成果物一覧 | 実行ファイル、コンテナ、設定ファイル等 |
| ハッシュ値 | 納品成果物を識別する値 |
| 既知脆弱性確認結果 | 確認日、使用ツール、未対応事項 |
| 保守連絡先 | 脆弱性発生時の問い合わせ先 |
| 更新責任表 | 誰が何を更新するか |
| アカウント一覧 | 開発者、委託先、クラウド等の権限 |
Webシステムであっても、「URLを納品して終わり」にせず、これらを会社の資産として保管します。
ソースコードを受け取れない契約の場合は、少なくとも依存関係、SBOM、保守条件、事業者変更時の移行方法を確認してください。
システムの重要度で要求水準を変える
全ての開発案件に同じ量の資料を要求すると、費用と作業負担が増えます。
実務上は、システムの重要度に応じて要求水準を分ける方法があります。
| 水準 | 対象例 | 要求する内容の例 |
|---|---|---|
| 基本 | 小規模な社内ツール、短期利用 | 依存関係一覧、正確なバージョン、ライセンス、保守連絡先 |
| 標準 | 顧客情報や業務データを扱うシステム | 基本項目に加え、SBOM、ロックファイル、ビルド手順、脆弱性確認結果 |
| 重要 | 基幹業務、停止影響が大きいシステム | 標準項目に加え、ビルド記録、署名、ハッシュ、ログ、独立した確認、復旧試験 |
| 特別 | 安全性や社会的影響が大きいシステム | 個別の規制・業界要件、第三者評価、継続的監視等 |
これは公的に定められた分類ではありません。
個人情報の量、停止時の影響、インターネット公開の有無、決済機能、制御機能などを基に、自社で基準を決めてください。
契約前に決めなければ、納品時に追加費用となる
SBOMや依存関係一覧を納品直前に求めると、開発会社から追加費用を提示されることがあります。
これは、必ずしも開発会社の対応が不当ということではありません。
当初の契約に含まれていなければ、次の作業が追加で必要になるためです。
- SBOM作成ツールの導入
- 依存関係の確認
- 誤検出や重複の整理
- ライセンスの確認
- 機密情報の除外
- 納品物との対応付け
- 社内レビュー
- 顧客向け説明資料の作成
したがって、見積りを依頼する段階で、納品物として明示することが重要です。
経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引 Ver2.0」でも、委託先との契約等において、SBOMに関する要求事項、責任分担、費用負担、権利関係などを規定する考え方が示されています。
契約で決めたい項目
契約書、仕様書、見積条件書などでは、次の項目を明確にします。
| 項目 | 決める内容 |
|---|---|
| 対象 | どのソフトウェア、環境、成果物が対象か |
| 対象部品 | 直接・間接・ビルド依存をどこまで含めるか |
| 形式 | SPDX、CycloneDX、CSV、PDF等 |
| 作成時点 | ビルド前、ビルド時、ビルド後のどこか |
| 提出時期 | 中間納品、検収、更新時など |
| 更新頻度 | リリースごと、定期、重大変更時など |
| 正確性 | 誰が内容を確認するか |
| 不明項目 | 不明、非開示をどのように記載するか |
| ライセンス | 利用条件や表示義務を誰が確認するか |
| 脆弱性 | 納品時の確認方法と未対応項目の扱い |
| 通知 | 納品後に脆弱性が判明した場合の連絡期限 |
| 修正 | 無償・有償の範囲、対応期限 |
| 再委託 | 下請事業者にも同等の要求を行うか |
| 権利 | 発注者がSBOMを保管、解析、第三者提供できるか |
| 秘密保持 | SBOMに含まれる機密情報の取扱い |
| 契約終了 | ソースコード、SBOM、鍵、アカウント等の引継ぎ |
「SBOMを提出する」とだけ記載すると、対象範囲や形式を巡って認識が分かれる可能性があります。
何を含み、何を含まないのかまで具体化してください。
契約条項の記載例
次は、実務上のたたき台です。
受託者は、本システムの開発、ビルドおよび実行に使用する自社開発部品、第三者製ソフトウェア、オープンソースソフトウェア、ライブラリその他の構成要素について、名称、提供者、バージョン、識別子、ライセンスおよび依存関係を記載した一覧を作成する。
受託者は、検収時に、対象成果物に対応するSBOMを、双方が合意した機械処理可能な形式および人が確認可能な形式で委託者へ提出する。
SBOMには、作成者、作成日時、作成ツールおよびそのバージョン、SBOMの生成時点、対象成果物の名称・バージョン・ハッシュ値を含める。
情報が不明である場合、または契約上の理由により開示しない場合は、その区分を明示する。
受託者が成果物の更新または再ビルドを行った場合は、更新後の成果物に対応するSBOMを再提出する。
納品後、構成要素に重大な脆弱性または悪意あるコードが確認された場合、受託者は、影響の有無、対象となる成果物、暫定対策および修正方針を、別途定める期限内に委託者へ報告する。
この例は、法的な完成形ではありません。
通知期限、費用負担、保証、損害賠償、知的財産権、再委託、契約終了後の支援などは、案件ごとに検討してください。
納品時の検収で確認すること
SBOMをファイルとして受け取るだけではなく、納品物と対応しているかを確認します。
次の項目を検収表へ追加します。
| 確認項目 | 確認内容 |
|---|---|
| 対象成果物 | SBOMがどのシステム・バージョンに対応するか |
| 作成日時 | 納品した成果物より前の古いSBOMではないか |
| 部品名 | 名称だけでなく正確なバージョンがあるか |
| 依存関係 | 直接依存だけでなく間接依存を含むか |
| ビルド依存 | ビルド用部品が対象に含まれるか |
| 識別子 | PURL等の識別子があるか |
| ハッシュ | 納品したファイルと一致するか |
| ライセンス | 不明なライセンスが残っていないか |
| 不明項目 | 不明と非開示が区別されているか |
| 脆弱性 | 重大な既知脆弱性が残っていないか |
| 例外 | 未対応項目の理由、期限、責任者があるか |
| 再現性 | ビルド手順に従って再作成できるか |
| 保守 | 納品後の更新責任者が明確か |
CISA等の2026年版ガイダンスは、必要な情報が提供されない場合、作成者が知らない情報なのか、意図的に提供していない情報なのかを明示するよう求めています。また、重要な構成情報が意図的に除外されている場合、受領側はSBOMを不完全と判断することがあります。
「空欄だから該当なし」と判断せず、空欄の意味を確認してください。
新しいバージョンには新しいSBOMが必要
システムを更新すれば、利用するライブラリやバージョンも変わる可能性があります。
初回納品時のSBOMを、何年も使い続けることはできません。
2026年版ガイダンスでは、ソフトウェアの各バージョンや更新に対応するSBOMを用意し、新しいビルドやリリースで部品や依存関係が変わった場合は、新しいSBOMを生成する考え方が示されています。
次のタイミングで更新します。
- 新しいバージョンを公開した
- ライブラリを更新した
- 緊急の脆弱性対応を行った
- ビルド環境を変更した
- OSやランタイムを変更した
- 新しい外部サービスを追加した
- SBOMの誤りを訂正した
保守契約には、「修正プログラムを納品する際は、更新後のSBOMも提出する」と記載しておくと管理しやすくなります。
Rustの事案が起きた場合に開発会社へ確認すること
今回のRust事案について、自社の委託システムがRustで開発されている場合は、開発会社へ次のように確認できます。
当社向けシステムの開発またはビルドにおいて、次のパッケージが使用された事実はありますか。
・arrayref 0.3.10
・internment 0.8.7
・append-only-vec 0.1.9
・proc-macro1
・proc-macro-en
・aovine
・arone
・aronenao
・tinymember使用の有無は、マニフェストだけでなく、ロックファイル、開発端末、CI/CD環境、パッケージキャッシュおよびビルド記録を確認して回答してください。
影響が確認された場合は、さらに次の事項を確認します。
- どの開発端末またはビルド環境で実行されたか
- いつビルドを行ったか
- その環境からアクセスできた情報は何か
- ソースコード管理やクラウドの認証情報が保存されていたか
- 不審な通信やファイル作成がなかったか
- 影響を受けた可能性がある認証情報を変更したか
- 安全な環境で再ビルドしたか
- 再ビルド後の成果物を再納品したか
- 更新後のSBOMとハッシュ値を提出したか
後半の項目は、Rustプロジェクトが公表した統一的なチェックリストではなく、委託先へ影響範囲を確認するための実務上の質問例です。
SBOMがあれば調査は終わるのか
SBOMがあっても、それだけで調査が終わるとは限りません。
主な理由は次のとおりです。
SBOMが不完全な可能性がある
使用したツールや作成方法によって、ビルド時の依存関係や手作業で追加したファイルが含まれない場合があります。
部品名だけでは一致しない場合がある
同じ名前の別製品や、名称の表記違いがあるため、PURLなどの識別子も重要です。
脆弱性があっても、実際に影響するとは限らない
部品が含まれていても、脆弱な機能を利用していない場合があります。反対に、SBOMに記録されていない部品が影響を受けている可能性もあります。
悪意ある処理はビルド時に実行されることがある
完成品に残っていなくても、開発環境の認証情報が影響を受ける可能性があります。
SBOMは更新されなければ古くなる
納品後にライブラリを更新しても、SBOMが更新されていなければ、実際の環境と一致しません。
SBOMは「安全証明書」ではありません。
影響調査を始めるための、部品台帳です。
CISA等のガイダンスも、SBOMを脆弱性情報やVEX、CSAFなどのセキュリティ情報と関連付けることで、脆弱性管理を効率化できると説明しています。
開発会社だけに責任を押し付けない
発注者が「開発会社が全部管理すべきだ」と考えるだけでは、運用は安定しません。
役割分担を明確にする必要があります。
| 作業 | 発注者 | 開発・保守会社 |
|---|---|---|
| システムの重要度決定 | 主担当 | 技術情報を提供 |
| SBOM要求水準の決定 | 主担当 | 実現方法と費用を提示 |
| 使用部品の選定 | 承認または方針決定 | 主担当 |
| SBOMの生成 | 確認 | 主担当 |
| 納品物との対応確認 | 業務面を確認 | 技術面を確認 |
| 脆弱性情報の監視 | 契約範囲を確認 | 主担当候補 |
| 影響調査 | 経営・業務影響を判断 | 技術調査 |
| 更新判断 | 最終判断 | 更新案を提示 |
| 修正・再ビルド | 承認 | 主担当 |
| SBOM更新 | 受領・保管 | 主担当 |
| 契約終了時の引継ぎ | 受領・確認 | 資料と権限を引き渡す |
開発会社がSBOMを作成しても、発注者が保管場所や確認担当者を決めていなければ、数年後には所在が分からなくなります。
発注者側にも、受け取った資料を管理する責任があります。
経営者が確認したい五つの質問
経営者がSBOMの技術仕様を全て理解する必要はありません。
まず、開発担当者や委託先へ次の五つを確認してください。
- 外注したシステムに含まれるライブラリと正確なバージョンを一覧にできるか
- 直接依存だけでなく、間接依存とビルド時の依存関係を確認できるか
- 納品した成果物に対応するSBOM、ロックファイル、ビルド手順があるか
- ライブラリに重大な脆弱性が見つかった場合、誰が影響を調べ、何日以内に報告するか
- 開発会社を変更しても、別の会社が再ビルドと保守を行えるか
この五つに答えられなければ、システムは動いていても、会社として中身を管理できていない可能性があります。
まとめ
2026年8月に公表されたRustのサプライチェーン攻撃では、悪意あるパッケージのビルドスクリプトが外部から不正なプログラムをダウンロードすることが確認されました。
さらに、正規の人気パッケージについても、悪意あるパッケージへ依存するバージョンが短時間ながら公開されていました。
今回の事案から分かるのは、次の点です。
- 発注者が直接選んでいない部品も取り込まれる
- 部品名だけでなく正確なバージョンが必要である
- 間接依存とビルド依存も確認する必要がある
- 完成した成果物だけでなく、ビルド環境も影響を受けることがある
- パッケージ公開サイトから削除されても、端末やキャッシュに残ることがある
- 納品時の依存関係一覧とSBOMが、将来の影響調査に役立つ
問題は、無料のライブラリを利用することではありません。
利用していることを把握せず、更新責任者を決めず、後から調査できる資料を受け取っていないことです。
まずは、過去3年以内に外注したシステムを一つ選び、開発会社へ次の質問をしてください。
このシステムに含まれる外部ライブラリの名称、正確なバージョン、依存関係、ライセンスを確認できる資料はありますか。
資料がなければ、今後の更新時に作成を依頼します。
これから発注する案件では、見積りを取る段階から、依存関係一覧、ロックファイル、SBOM、ビルド手順、脆弱性対応を納品条件へ含めてください。
ライトハウスコンサルタントでは、専任の情報システム担当者がいない中小企業を対象に、開発委託時のセキュリティ要求事項、納品物一覧、検収チェックリスト、SBOMの要求内容、脆弱性発生時の連絡・対応手順などの整理を支援しています。
開発会社を一方的に厳しく監査することが目的ではありません。
発注者と開発会社が、納品後に誰が何を管理するのかを共有し、数年後に脆弱性が見つかっても回答できる状態を作ることが重要です。
