公開2026.08.06更新2026.10.12 セキュリティ

ソフトウェアサプライチェーンセキュリティとは？開発工程に組み込む防御と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配布に該当するなら、CRAの報告義務と2027年12月11日の全面適用から逆算して来歴の生成と検証を組み込みます。

ツールは工程ごとにOSSで一通り揃います。商用ベンダーに費用を払う価値が出るのは、検知結果の集約・優先度付け・監査証跡の保管といった「検知した後の運用」を人手で回せなくなった段階からです。

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

攻撃側の話と防御側の話が混ざると、対策の予算配分を誤ります。まず守る範囲と責任の持ち方を定めます。

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

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

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

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

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

脅威モデルと防御手段は一対一で対応させると設計が楽になります。

脅威	止める工程	本記事の該当章
悪意あるパッケージ公開	取得元の制限と待機期間	依存関係の固定
メンテナの乗っ取り	発行経路のOIDC化	npmの認証変更
ビルド環境の侵害	ランナー隔離と来歴	ビルド来歴と署名
成果物の差し替え	署名と検証	Sigstore

脅威を1つ挙げたら、それを止める工程を1つ指させる状態にします。指させない脅威が残っていれば、そこが次の投資先です。

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

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

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

オープンソースソフトウェアのサプライチェーンセキュリティを担う社内体制

OSSの部品管理は、ツールを入れただけでは誰の仕事にもなりません。依存の追加を誰が承認するのか、脆弱性の通知を誰が受けるのか、メンテナンスが止まったOSSを誰が置き換えるのか。この3つの役割を名前で割り当てる作業が、オープンソースソフトウェアのサプライチェーンセキュリティの出発点です。

開発組織が数十人を超える企業では、OSPO（Open Source Program Office）という横断組織を置き、採用基準とライセンス確認と脆弱性対応をまとめて持たせる形が広がっています。専任組織を置けない規模なら、各プロダクトのテックリードに依存追加の承認権を持たせ、四半期ごとに依存一覧を棚卸しするだけでも効果を得られる仕組みです。開発工程にセキュリティ検査を組み込む考え方の全体像は、DevSecOpsの考え方とライフサイクル・導入判断で扱っています。サプライチェーンの防御は、その中で「他人が書いた部品」を受け持つ層にあたります。

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

ここが投資対効果の最も高いレイヤーです。設定ファイル数行で塞げる穴が多く残っています。

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

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

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

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

開発端末とCIから公開レジストリへ直接取りに行く構成は、取得元の統制ができません。ArtifactoryやNexus、Verdaccioといったプロキシを1本立て、上流を許可リストで限定し、取得したパッケージをキャッシュします。上流が停止しても社内のビルドは継続でき、どのバージョンがいつ社内に入ったかの記録も残る構成です。社内へ取り込んだアーカイブのハッシュを外部の判定サービスへ照会する手順は、VirusTotal APIで検体判定を自動化する実装手順でコマンド付きで整理しています。

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

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

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

リポジトリ直下に置く設定例です。月曜朝にまとめてプルリクエストを作らせ、公開から3日たっていない版は候補から外します。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "schedule": ["before 9am on monday"],
  "minimumReleaseAge": "3 days"
}

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

# .npmrc
ignore-scripts=true

# 必要なパッケージだけ、スクリプトを許可して個別に再ビルドする
npm ci
npm rebuild esbuild --ignore-scripts=false

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

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

移行先はOIDCによるTrusted Publishingです。npmのTrusted Publishers解説では、2026年9月時点でGitHub Actions、GitLab CI/CD（GitLab.comの共有ランナー）、CircleCI Cloudの3つが対応先に挙がり、npm CLI 11.5.1以上とNode 22.14.0以上が条件です。セルフホストランナーは対象外なので、社内ランナーで公開している組織は公開ジョブだけをクラウドのランナーへ移す設計になります。

GitHub Actionsでの公開ワークフローは次の形です。npmjs.com側のパッケージ設定で、このリポジトリとワークフローのファイル名を信頼済み発行元として登録しておきます。本番では各アクションをタグでなくコミットSHAで固定してください。

# .github/workflows/publish.yml
name: publish
on:
  release:
    types: [published]
permissions:
  id-token: write
  contents: read
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: "22"
          registry-url: "https://registry.npmjs.org"
      - run: npm install -g npm@latest
      - run: npm ci
      - run: npm publish

実行ごとに短命の資格情報が発行されるため、リポジトリのシークレットに公開用トークンを持たずに済みます。トークンを保持しない状態が最も漏洩に強い、という原則が実装に落ちた例です。

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

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

費用をかけずに始めるなら、Googleが公開しているOSV-Scannerが手軽です。ロックファイルを読み、OSVデータベースと照合します。脆弱性が見つかると0以外の終了コードを返すため、CIのジョブをそのまま失敗させる使い方ができます。

# インストール（Go環境がある場合）
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest

# カレントディレクトリ配下のロックファイルを再帰的に走査する
osv-scanner scan source -r .

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

OpenSSF Scorecardで採用前のOSSを点検するコマンドと判定の目安

既知脆弱性の有無は、採用したOSSの過去しか教えてくれません。これから採用するOSSが今後も保守されるかは、リポジトリの運営状況で見ます。OpenSSFが公開しているScorecardは、ブランチ保護・コードレビュー・依存の固定・ワークフロー権限などをチェック項目ごとに0〜10点で採点するツールです。

# GitHubのトークンを渡してDocker版を実行する
export GITHUB_AUTH_TOKEN=ghp_xxxxxxxx
docker run -e GITHUB_AUTH_TOKEN ghcr.io/ossf/scorecard:latest \
  --repo=github.com/expressjs/express \
  --checks=Maintained,Code-Review,Pinned-Dependencies,Token-Permissions

点数の閾値を全社一律で決める必要はありません。Maintainedが極端に低い、つまり直近のコミットや課題対応がほとんど無いOSSを新規採用の候補から外す、という1点だけでも、保守が止まった部品を抱え込む事故は減ります。既存の依存に適用するなら、点数の低いものから置き換え計画を作る材料に使います。

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

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

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

SLSAはビルドの完全性を段階で示すフレームワークです。2025年11月24日の発表でv1.2が承認され、2026年9月時点ではこれが現行版です。v1.2ではBuildトラックに加えて、ソースコードの作成・レビュー・管理を扱うSourceトラックが正式に入りました。v1.1との後方互換は保たれているため、v1.0やv1.1でL3を満たしていた成果物の構成を作り直す必要はありません。

レベル	要求される内容	実装の目安
Build L1	来歴を自動生成する	CIでの生成を有効化
Build L2	署名済みの来歴を出す	認証済みビルド基盤
Build L3	偽造できない来歴	署名工程をビルドと分離

L2とL3の差は、署名の鍵をビルドジョブから触れる位置に置くかどうかです。同じジョブ内で署名まで済ませると、ジョブを奪われた時点で来歴も偽造されます。Sourceトラックはブランチ保護やレビュー必須化の証跡を求める内容で、Buildトラックより先に手を付ける必要はありません。

GitHub Artifact AttestationsでのL3到達手順

GitHub Actionsを使っているなら、Artifact Attestationsが最短経路です。成果物のダイジェストとSLSAの来歴述語をin-toto形式で結びつけ、Sigstoreが発行する短命の署名証明書で署名します。GitHubの手順書は2026年9月時点でactions/attest@v4を使う例に切り替わっており、従来のattest-build-provenanceはそのラッパとして残っています。

# ビルドジョブに追加する権限と手順
permissions:
  id-token: write
  contents: read
  attestations: write
steps:
  - uses: actions/checkout@v5
  - run: npm ci && npm pack
  - uses: actions/attest@v4
    with:
      subject-path: "*.tgz"

# 受け取った側での検証
gh attestation verify ./my-lib-1.0.0.tgz -R my-org/my-lib

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に残っていた資格情報を収集して次のパッケージへ広がりました。経緯と影響確認の方法はShai-Huludによるnpmサプライチェーン攻撃の全体像にまとめています。権限の分離は、侵害の有無ではなく侵害後の広がりを決める設定だと考えてください。

ソフトウェアサプライチェーンセキュリティのツールとベンダーを工程別に選ぶ基準

「サプライチェーンセキュリティツール」で探すと、SCA・SBOM管理・コンテナスキャン・署名基盤が区別なく並びます。先に工程で分けてから製品を見ると、重複購入を避けられます。

サプライチェーンの工程ごとにOSSで揃う範囲と代表的なツールの対応表

2026年9月時点で、主要な工程はOSSだけで一通り組めます。

工程	OSSの例	商用で補う領域
依存の自動更新	Renovate・Dependabot	多数リポジトリの集約
脆弱性の検知	OSV-Scanner・Trivy	到達可能性の判定
SBOMの生成	Syft・cdxgen	SBOMの保管と検索
OSSの健全性	OpenSSF Scorecard	悪性パッケージ検知
署名と来歴	Sigstore・attest	監査証跡の保管

SBOMの生成ならSyftのように、コンテナイメージやディレクトリを指定するだけでSPDXとCycloneDXの両形式を出力できるツールがあります。SBOM管理製品の比較軸はSBOMツールの比較と選び方、コンテナイメージの検査をパイプラインへ組み込む手順はDockerの脆弱性診断をCI/CDに組み込む手順とツール選定で個別に扱っています。

検知後の運用負荷から判断する商用ベンダーに費用を払う価値が出る3つの条件

サプライチェーンセキュリティのベンダーや専業カンパニーの製品が効いてくるのは、次のいずれかに当てはまったときです。

管理対象のリポジトリが数十を超え、検知結果を横断で集約しないとトリアージが回らない
検知件数が多すぎて、到達可能性（実際に呼ばれるコードか）で絞り込まないと担当者が追えない
取引先や監査対応で、いつ何を検知しどう処置したかの証跡を年単位で保管する必要がある

いずれにも当てはまらない段階で商用製品を先に買うと、ダッシュボードの設定に工数を取られ、肝心の依存固定とトリアージの取り決めが後回しになります。公開直後の悪性パッケージ検知のように、OSSでは代替しにくい機能だけを単体で足すのも選択肢です。その例はsocket.devが不正パッケージを防ぐ仕組みと料金で扱っています。

ツール導入企業が見落としやすい検知後の運用コストの見積もり方

ツールの年額より重いのは、検知1件あたりの判断工数です。導入前に既存のリポジトリへOSV-Scannerを1回かけ、出てきた件数に「1件あたり15〜30分の一次判断」を掛けてみてください。初回の棚卸しで数百件が出ることは珍しくなく、その処理を誰が何週間で終えるかが決まらないまま製品を入れると、通知が無視される運用に落ちます。

見積もりの結果、社内で抱えきれないと分かった段階で初めて、到達可能性の判定を持つ商用製品や外部の診断サービスが比較対象に入ります。ベンダーを比べるときは、機能一覧よりも「誤検知を抑えて何件に減るか」を自社のリポジトリで試させてもらうほうが、判断を誤りません。

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」ではなく実際に悪用が観測された脆弱性である点は、運用設計で効いてきます。

経産省のSCS評価制度が示す企業の対策状況の星区分と申請受付までの準備日程

国内では、経産省が主導する「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」の準備が進んでいます。2026年3月27日に制度構築方針が公表され、政府が定めた共通基準で企業の対策状況を星の数として可視化する枠組みが固まりました。初期は★3と★4の区分から始まり、IPAの制度詳細ページでは要求事項が★3で26件・★4で43件、有効期間は★3が1年・★4が3年と示されています。

運用開始は2026年度下期の予定ですが、2026年9月時点のIPAの案内では申請受付の開始は2027年3月頃とされています。評価基準の項目数や登録料はセキュリティ対策評価制度（SCS評価制度）の解説で整理しました。

この制度が実務に効くのは、取引先ごとに届くセキュリティチェックシートの負荷を評価結果の提示で置き換えられる点です。受付開始を待たず、自社がどの区分を狙うのかを2026年度中に決めておく作業が宿題になります。基幹インフラ16分野の指定事業者へ納入する立場なら、経済安全保障推進法が求めるリスク管理措置と届出情報の提示も別建てで発生します。

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

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

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

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

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

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

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

依存関係の固定と取得元の一本化（何が入っているかを確定させる）
SCAでの検知とトリアージ担当の割り当て（見つけた後の処理を決める）
発行経路の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は調査を速くするデータであって、報告義務を代替する成果物ではありません。

サプライチェーンセキュリティのツールは無料のOSSだけで足りますか？

管理するリポジトリが少ないうちは足ります。Renovateで更新を回し、OSV-Scannerで脆弱性を検知し、Syftで部品表を作り、Scorecardで採用前のOSSを点検すれば、主要な工程は一通り揃います。商用製品を検討するのは、リポジトリが数十を超えて検知結果を集約できなくなったとき、または監査向けに処置の証跡を長期保管する必要が出たときです。

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

直接の義務は生じません。ただしEU市場に製品を出す企業のサプライヤーであれば、取引先から同等の対応を求められる形で影響が及びます。国内でもSCS評価制度が★3・★4の区分から始まり、2027年3月頃に申請受付が始まる見込みで、取引条件として提示を求められる可能性が残ります。輸出の有無を問わず、2026年度中に自社の対策状況を棚卸ししておく価値は小さくありません。

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

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