サプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断

サプライチェーンセキュリティは、自社が書いていないコードとビルド環境をどこまで信用するかを決める作業です。2025年12月9日にnpmが長期有効なクラシックトークンを一斉失効させ、2026年9月11日にはEUサイバーレジリエンス法（CRA）の報告義務が始まります。コード・ビルド・配布の3レイヤーで何を実装するのか、SLSAのどのレベルで止めてよいのか、経産省の評価制度と受託開発の契約条項をどう結ぶのかを、着手順と見送り条件つきで整理します。

まとめ：着手順は依存関係の固定・脆弱性検知・発行経路のOIDC化

サプライチェーンセキュリティとは、部品の調達からビルド、配布までの各工程で、意図しないコードの混入と改ざんを防ぐ一連の防御策です。守る対象は「コード（自作＋OSS依存）」「ビルド（CI環境とツールチェーン）」「配布（レジストリ・署名・更新経路）」の3レイヤーに分かれ、実装手段もレイヤーごとに違います。

最初の3カ月で手を付けるのは3つで十分です。ロックファイルによる依存関係の固定と取得元の一本化、SCAによる脆弱性検知とトリアージ担当の明確化、公開パッケージの発行経路のOIDC化。順番を崩すと、SBOMだけ生成されて誰も見ないという失敗に落ちます。

SLSA Build L3は全社一律の目標にしません。社外へ配布物を出さず規制対象製品も扱わない社内向けWebシステムなら、L1からL2で止める判断が妥当です。EU市場向け製品・OSS公開・顧客へのSDK配布に該当するなら、2026年9月11日の報告義務から逆算して来歴の生成と検証を組み込みます。

サプライチェーンセキュリティの定義と防御対象になる3つのレイヤー

攻撃側の話と防御側の話が混ざると、対策の予算配分を誤ります。

部品の調達から配布までを対象にする防御策としての定義と適用範囲

サプライチェーンセキュリティは、製品に組み込まれる部品の調達経路と、それを加工・配布する工程の全体を保護対象にします。ソフトウェアの文脈では、npmやPyPIから取得するOSS、ビルドを実行するCIランナー、成果物を置くレジストリ、更新を配信する経路までが射程です。自社の従業員が書いたコードが行数ベースで全体の1割に満たない案件も珍しくありません。

適用範囲には委託先、OSSのメンテナ、CIサービスやレジストリの運営者も入ります。いずれかが侵害されると、自社のコードレビューをすり抜けて成果物に到達します。境界防御やWAFでは検知できない経路だという点が、他のセキュリティ施策との違いです。

サプライチェーン攻撃との違いと脅威モデルごとの防御手段の対応関係

サプライチェーン攻撃は脅威の側を指す言葉で、サプライチェーンセキュリティは対策の側を指します。攻撃の類型と国内外の事例はサプライチェーン攻撃の起点別3類型と対策の優先順位で整理しているため、本記事は防御手段の実装に絞ります。

脅威モデルと防御手段は一対一で対応させると設計が楽です。悪意あるパッケージの公開には取得元の制限と待機期間、メンテナアカウントの乗っ取りには発行経路のOIDC化、ビルド環境の侵害にはランナーの隔離と来歴の生成、成果物の差し替えには署名と検証。脅威を1つ挙げたら、それを止める工程を1つ指させる状態にします。

物流のサプライチェーンとソフトウェア領域で守る対象の明確な境界線

調達・製造・物流を対象にした従来のサプライチェーンリスク管理と、ソフトウェアサプライチェーンの防御は、扱う資産が違います。前者の主題は部品の供給停止や偽造部品の混入、災害時の代替調達です。後者で問われるのは、バイナリとソースコードの同一性、そして「このアーティファクトは本当にこのソースからこのビルド環境で作られたか」の証明になります。

経産省が2024年8月29日に公開した「ソフトウェア管理に向けたSBOMの導入に関する手引ver2.0」は、この後者を対象にした文書です。企業間取引で部品表をどう受け渡すかまで踏み込んだ構成になっています。

依存関係の固定とレジストリ認証で防ぐ部品混入リスクの具体的な実装手順

ここが投資対効果の最も高いレイヤーです。

lockfile固定と自動更新の頻度で決まる依存関係管理の初期設定

ロックファイルをリポジトリにコミットし、CIでは必ずロックファイル準拠のインストールコマンドを使います。npmならnpm ci、Pythonのpoetryならpoetry.lock、Goならgo.sumが基準です。バージョン範囲の指定だけを頼りにすると、同じコミットからビルドしても取得される依存が変わり、事故の再現も切り分けもできません。

自動更新はDependabotやRenovateで週次のプルリクエストに寄せ、CIがグリーンでなければマージしない運用にします。更新を止めれば別のリスクが育ちます。EU CRAの下では、サポート期間中の製品に含まれる脆弱なコンポーネントの放置を説明できません。更新を溜めない設計そのものが、規制対応の一部になりました。

社内レジストリのプロキシ設定とパッケージ取得元を絞る制限方法

開発端末とCIから公開レジストリへ直接取りに行く構成は、取得元の統制ができません。ArtifactoryやNexus、Verdaccioといったプロキシを1本立て、上流を許可リストで限定し、取得したパッケージをキャッシュします。上流が停止しても社内のビルドは継続でき、どのバージョンがいつ社内に入ったかの記録も残ります。

自社スコープのパッケージ名を公開レジストリ側で先に押さえておかないと、同名パッケージを外部に公開されて解決順序を奪われる依存関係混同（dependency confusion）の余地が残ります。

公開直後のバージョンを避ける待機期間とtyposquatの検知設定

悪意あるパッケージの多くは、公開から数時間から数日でレジストリ側に削除されます。この時間差を利用するのが待機期間の設定です。RenovateのminimumReleaseAgeで3〜7日の猶予を置くだけでも、公開直後の混入バージョンを踏む確率は下がります。緊急の修正だけは例外扱いにしておきます。

打ち間違いを狙うtyposquatには、パッケージ名の許可リストとインストール時スクリプトの遮断を組み合わせます。npmのignore-scriptsは、依存の追加だけで任意コードが走る経路を塞ぐ設定です。ビルドに必要なネイティブモジュールだけを明示的に許可すれば、遮断による副作用も限定できます。

npmの認証変更で必須になったOIDC発行と90日上限の運用体制

npmは2025年12月9日に有効期限のないクラシックトークンをすべて失効させました。書き込み権限を持つ粒度トークンの寿命は最長90日に制限され、npm loginで得られるセッションも2時間で切れます。CIに長期トークンを貼り付けていたパイプラインは、この変更で軒並み停止しました。

移行先はOIDCによるTrusted Publishingで、2026年8月時点ではGitHub ActionsとGitLab CI/CDが対応しています。実行ごとに短命の資格情報が発行されるため、リポジトリのシークレットに公開用トークンを持たずに済みます。トークンを保持しない状態が最も漏洩に強い、という原則が実装に落ちた例です。

SCAによる脆弱性検知とトリアージ担当を決めるまでの運用設計

依存の一覧が固定できたら、既知脆弱性との突き合わせを自動化します。仕組みと導入判断はSCA（ソフトウェア構成分析）の仕組みとSAST・SBOMとの違いで詳述しているため、ここでは運用側の要件だけ挙げます。

実務で機能する最小構成は、CVSS 9.0以上は当日中に一次判断、7.0以上は5営業日以内に対応方針を確定、それ未満は次回の定期更新に含める、という3段階です。担当が決まっていない検知は必ず放置されます。人を割り当てられないなら、対象を本番稼働中のプロダクトだけに絞って始めるほうが続きます。

ビルド来歴と署名検証でSLSAレベルを引き上げる構成と運用コスト

コードが正しくても、ビルド環境が乗っ取られれば成果物は汚染されます。ここから先は配布物を外に出す組織向けの話です。

SLSA Buildトラックのレベル定義と到達に必要な構成条件

SLSAはビルドの完全性を段階で示すフレームワークで、2025年4月に承認されたv1.1が現行の承認済み仕様、2025年6月にv1.2のリリース候補が公開されています（2026年8月時点）。安定版として扱えるのはBuildトラックのみで、Source・Dependencies・Verificationの各トラックはドラフト段階です。v1.0でL3を満たす成果物は、ほぼそのままv1.1のL3としても通ります。

L2とL3の差は、署名の鍵をビルドジョブから触れる位置に置くかどうかです。同じジョブ内で署名まで済ませると、ジョブを奪われた時点で来歴も偽造されます。

GitHub Artifact AttestationsでのL3到達手順

GitHub Actionsを使っているなら、attest-build-provenanceアクションが最短経路です。成果物のダイジェストとSLSAの来歴述語をin-toto形式で結びつけ、Sigstoreが発行する短命の署名証明書で署名します。v4以降はattestアクションのラッパとして提供されています。

SLSA v1.0のBuild L3に届かせるには、来歴の生成を再利用可能ワークフローに切り出す構成が必要です。提供条件には注意してください。Free・Pro・Teamの各プランではパブリックリポジトリのみが対象で、プライベートおよび内部リポジトリで使うにはGitHub Enterprise Cloudが要ります。

Sigstoreの短命証明書による署名検証と検証側の運用負荷の実際

Sigstoreは、長期保管する秘密鍵を持たずに署名する仕組みです。OIDCで認証したアイデンティティに有効期間の短い証明書を発行し、署名の記録を公開透明性ログに残します。従来の署名運用で最も事故が多かった鍵の保管と失効管理が、丸ごと消えました。

負荷が移るのは検証側です。生成した来歴を誰も検証しなければ、署名は装飾で終わります。gh attestation verifyのようなCLIをデプロイ前のジョブに組み込むか、KubernetesならKyvernoやpolicy-controllerで未検証イメージの起動を拒否する設定まで入れて、初めて防御として成立します。失敗時に何を止めるかを決めずに導入すると、警告だけが増えて素通りする状態から抜け出せません。

CI/CDの権限設計とビルド環境の隔離で塞ぐ攻撃者の横展開経路

CIランナーは、本番の資格情報と全リポジトリへの書き込み権限が集まる場所です。横展開を止める設定は4つあります。ジョブ単位で権限を最小化する、外部フォークからのプルリクエストにシークレットを渡さない、サードパーティ製アクションをタグではなくコミットSHAで固定する、ビルドごとにランナーを使い捨てる。

2025年から2026年にかけてnpmエコシステムで連鎖したワーム型の攻撃は、CIに残っていた資格情報を収集して次のパッケージへ広がりました。権限の分離は、侵害の有無ではなく侵害後の広がりを決める設定だと考えてください。

EU CRAと経産省評価制度が2026年に課す報告義務と対応期限

期限は日付まで確定済みです。

EU CRAで2026年9月に始まる報告義務と24時間以内の初期通知

EUサイバーレジリエンス法は規則（EU）2024/2847として2024年12月10日に発効し、デジタル要素を持つ製品全般に統一のセキュリティ要件を課します。2026年9月11日からは、悪用が確認された脆弱性と重大なインシデントの報告義務が先行して適用されます。全面適用は2027年12月11日です。

報告の時間軸は3段階です。認知から24時間以内に早期警告、72時間以内に本通知、是正措置の提供後14日以内（重大インシデントは1カ月以内）に最終報告。提出先は単一報告プラットフォームで、主たる拠点のCSIRTとENISAへ同時に共有されます。対象が「すべてのCVE」ではなく実際に悪用が観測された脆弱性である点は、運用設計で効いてきます。

経産省の対策評価制度が2026年度下期に始める星区分と申請準備

国内では、経産省が主導する「サプライチェーン強化に向けたセキュリティ対策評価制度」が2026年度下期（2026年10月から2027年3月）に運用開始を予定しています。政府が定めた共通基準で企業の対策状況を星の数として可視化する枠組みで、初期は★3と★4の区分から始まります。

この制度が実務に効くのは、取引先ごとに届くセキュリティチェックシートの負荷を評価結果の提示で置き換えられる点です。提示を求められる前に自社がどの区分を狙うのかを決めておく作業が、2026年度前半の宿題になります。

SBOM手引ver2.0とSSDFが求める脆弱性管理の運用工程

SBOMは規制対応の基礎データとして位置づけが固まりました。CRAでは製造者にSBOMの作成と維持が求められ、経産省の手引ver2.0は作成後の脆弱性管理プロセスまでを扱います。フォーマットの選定基準や生成ツールの比較はSBOMの目的・フォーマットと作成運用の判断に譲ります。

米国NISTのセキュアソフトウェア開発フレームワーク（SP 800-218）は、開発組織の準備、ソフトウェアの保護、セキュアな実装、脆弱性への対応という4群で構成されます。CRAの要求も経産省の評価制度も、参照する実務項目はこの枠組みと大きくは離れません。3つの制度に個別対応せず、SSDFの項目へ自社の工程を1回だけ対応づけるほうが手戻りが減ります。

先に着手すべき対策と過剰投資になる対策を切り分ける判断基準の実務整理

全部やるという方針は、実質的に何もやらないのと同じ結果に着地します。

最初の3カ月で着手する依存関係の固定と脆弱性検知の実務的な導入順序

着手順は固定です。1カ月目にロックファイルの徹底とレジストリプロキシの設置、2カ月目にSCAの導入とトリアージ基準の合意、3カ月目に公開用トークンのOIDC移行とCI権限の最小化。前の工程が次の工程の前提データを作るため、この順序を守ります。

1. 依存関係の固定と取得元の一本化（何が入っているかを確定させる）
2. SCAでの検知とトリアージ担当の割り当て（見つけた後の処理を決める）
3. 発行経路のOIDC化とCI権限の分離（資格情報を残さない）

署名や来歴から始めた組織は、依存の一覧すら固定できていない状態で証明だけを積み上げます。証明対象が動いていては、来歴の価値も出ません。

SLSA Build L3を見送ってよい組織規模と条件の線引き

次の3条件をすべて満たすなら、SLSA Build L3への投資は見送って構いません。成果物を社外へ配布しておらず自社運用のWebシステムに閉じている。ビルドがマネージドCIの標準ワークフローだけで完結する。EU市場向けのデジタル要素製品や医療機器などの規制対象に該当しない。

この場合はBuild L1からL2で止め、浮いた工数を依存関係の更新頻度とトリアージ体制に回すほうが、防げる事故の数は増えます。逆に、顧客へインストーラやSDKを配る、OSSを公開している、EU市場に製品を出しているのいずれかに該当する組織では、L3を2027年12月11日の全面適用に向けた必須項目として扱ってください。判断の分かれ目は組織の人数ではなく、成果物が自社の管理外で実行されるかどうかです。

SBOMを生成しただけで運用が止まる失敗パターンと回避の分岐点

最も多い失敗は、CIでSBOMを生成してアーティファクトに保存したところで止まる状態です。生成物は増えるのに、脆弱性が出たときに誰がどのSBOMを開くのかが決まっていません。影響調査の依頼が来てから手作業でgrepすることになり、SBOMの有無で所要時間が変わらない結果に終わります。

回避の分岐点は生成の前にあります。SBOMを作る前に、「新しい脆弱性が公表されてから、影響有無の一次回答を何時間以内に出すか」を決めてください。この時間が決まれば、必要な保管場所も検索性も自動的に定まります。影響しない脆弱性を「影響なし」と説明するVEXの運用も同時に設計すれば、問い合わせ対応をテンプレート化できます。第三者の検査を組み合わせるなら、脆弱性診断・セキュリティ診断で実環境の穴を洗い出してから検知と対応の工程を設計すると、手戻りが減りました。

受託開発と外注で交わすSBOM要求事項と契約条項への落とし込み

外注先の工程が抜けていれば、全体の水準はそこで決まります。

発注側がRFPに書くべきSBOM提出と脆弱性対応の具体的な条件

RFPに入れる条件は4つに絞ると受注側も見積もれます。納品物にSPDXまたはCycloneDX形式のSBOMを含める、CVSSスコア別の対応期限を明記する、サポート終了済みコンポーネントを新規採用しない、ビルドの来歴を提出する。抽象的な「セキュリティに配慮すること」という文言は、見積もりにも検収にも使えません。

提出形式まで指定してください。形式を決めずに依頼すると、PDFの一覧表が納品されて機械処理できません。SBOMの受け渡し方は経産省の手引ver2.0がSBOM取引モデルとして整理しているため、条項の下敷きに使えます。

納品物として受け取る来歴データと検証手順を契約書に残す具体策

来歴データは、受け取るだけでなく検証手順まで取り決めます。どのアイデンティティで署名されるのか、検証に失敗した納品物をどう扱うのか、検収の合格条件に検証成功を含めるのか。この3点がない契約では、来歴の不一致が発覚した際の責任分界が決まりません。

保守フェーズの条項も同時に決めます。納品後に依存OSSへ重大な脆弱性が公表された場合の一次調査の主体、対応工数の費用負担、報告の窓口と期限。CRAがサポート期間中の脆弱性対応を製造者の義務とした以上、ここを曖昧にしたまま長期保守を請けるのは受注側にもリスクです。

よくある質問

導入検討でよく寄せられる質問を、判断に直結する範囲でまとめます。

サプライチェーンセキュリティとサプライチェーン攻撃対策は同じ意味ですか？

ほぼ同じ領域を指しますが、視点が違います。サプライチェーン攻撃は脅威そのものを指す言葉で、攻撃の起点や手口を説明するときに使います。サプライチェーンセキュリティは、その脅威に対して調達から配布までの各工程に施す防御策の総称です。実務では攻撃類型を洗い出して工程ごとの対策に落とすため、両者を行き来します。

SBOMを作れば規制対応としては足りますか？

足りません。EU CRAでは製造者にSBOMの作成と維持が求められますが、2026年9月11日から始まるのは悪用が確認された脆弱性と重大インシデントの報告義務です。24時間以内の早期警告と72時間以内の本通知に対応するには、部品表に加えて脆弱性情報を受け取る体制と社内の判断フローが要ります。SBOMは調査を速くするデータであって、報告義務を代替する成果物ではありません。

小規模な受託開発の現場でもSLSAへの対応は必要ですか？

成果物が自社の管理下だけで動くなら、Build L1からL2で十分です。社内向けWebシステムに閉じており規制対象製品を扱わないなら、来歴の自動生成までで止めて依存関係の更新体制に工数を回すほうが効果が出ます。判断基準は人数ではなく配布形態です。顧客の環境で動くインストーラやSDKを納品しているなら、規模を問わずL3への到達を計画してください。

EU向けに製品を出していない日本企業も2026年9月の期限に関係しますか？

直接の義務は生じません。ただしEU市場に製品を出す企業のサプライヤーであれば、取引先から同等の対応を求められる形で影響が及びます。国内でも経産省の「サプライチェーン強化に向けたセキュリティ対策評価制度」が2026年度下期に★3・★4の区分から始まる予定で、取引条件として提示を求められる可能性が残ります。輸出の有無を問わず、2026年度中に自社の対策状況を棚卸ししておく価値は小さくありません。

OSSを使わなければサプライチェーンリスクは避けられますか？

避けられません。OSS依存はリスクの一部にすぎず、ビルドを実行するCI環境、コンテナのベースイメージ、開発端末の拡張機能、外注先が納品するコードのすべてが同じ経路です。商用ライブラリでも、内部にOSSが含まれていれば脆弱性は継承されます。OSSの採用を絞る判断より、何が入っているかを機械可読な形で把握する仕組みを作るほうが、リスク低減につながります。

関連記事

• サプライチェーン攻撃の起点別3類型と対策の優先順位：脅威側の類型と国内外の事例を整理しています。
• SBOMの目的・フォーマットと作成運用の判断：SPDXとCycloneDXの選定基準や生成ツールを詳述しています。
• SCAの仕組みとSAST・SBOMとの違い：脆弱性検知を担うSCAの導入判断をまとめています。
• socket.devが不正パッケージを防ぐ仕組みと料金：公開直後の悪意あるパッケージを検知するサービスの実例です。
• Shai-Huludによるnpmサプライチェーン攻撃の全体像と対策：CI資格情報を起点に連鎖したワーム型攻撃の実例です。