ソフトウェアサプライチェーンセキュリティ 2026 完全ガイド - Sigstore · SLSA · SBOM (CycloneDX/SPDX) · Chainguard Images · Socket.dev · JFrog Xray · Snyk Open Source · GUAC · in-toto · GitHub Actions OIDC 詳細解説

プロローグ — サプライチェーンは新しい攻撃面である

ソフトウェアセキュリティの重心が変わった。10年前は「自分のコードのバグを防ぐ」だけで十分だった。2026年の答えは違う。「自分のコード + importする5,000個のパッケージ + そのパッケージのビルド環境 + そのビルド環境のコンテナイメージ + そのコンテナイメージのベースOS」まですべて検証する必要がある。

この変化を作ったのは一連の事件だ。

SolarWinds Orion（2020年） — Sunburstバックドア。米国連邦機関とフォーチュン500企業18,000社に侵入。ビルドシステム侵害。
Codecov bash uploader（2021年） — CIで使われるbashスクリプトが改ざんされ、環境変数のトークンが流出。
Log4Shell（2021年12月） — Log4j 2.x JNDI脆弱性CVE-2021-44228。ほぼすべてのJavaサービスに影響。
3CXデスクトップアプリ（2023年3月） — Mandiantが確認。北朝鮮系グループ。ビルドパイプライン侵害事例。
XZ Utilsバックドア（2024年3月） — Jia Tan（仮名）が2年かけてメンテナーの信頼を獲得しバックドアを挿入。Andres Freund（MS PostgreSQLエンジニア）が偶然発見。CVE-2024-3094。
npmタイポスクワッティング — 2023-2025年の間、毎週報告。lodash → lodahs、requests → requetsなど。

これらの事件が導く結論はシンプルだ。ビルド時に起きたことを事後に証明できなければならない。 そして importするすべての依存関係の振る舞いを把握しなければならない。

本稿は、その2つの命題に対する2026年の答えだ。Sigstoreがキーなしで署名を作り、SLSAがビルド完全性のレベルを定義し、SBOMが「このバイナリの中に何が入っているか」を標準フォーマットで記録する。60以上のツール・標準・事件を一つの流れで整理する。

1章 · なぜサプライチェーンセキュリティが必要か

2026年のサプライチェーン脅威の5つの軸。

依存ツリーの爆発 — 平凡なnpmプロジェクトが直接・間接に引き込むパッケージ数は1,500-3,000個。それぞれが個別のメンテナー信頼モデルを持つ。
ビルド環境の不透明性 — gitリポジトリのコードとnpmにアップされたtarballが一致する保証はない。event-stream（2018）、ua-parser-js（2021）、node-ipc（2022）はすべて同じパターン。
ベースイメージのCVE蓄積 — Docker Hubにアップされたalpine、ubuntu、debianイメージは時間が経つほどCVEが積もる。最後のビルドが6ヶ月前なら平均30-60個の未適用セキュリティパッチ。
CI/CD秘密情報の漏洩リスク — GitHub Actions、GitLab CI、CircleCI、Buildkiteに保存されたトークンがワークフローログ・キャッシュ・アーティファクトから漏れる事例。
法的義務の登場 — 米国EO 14028、CISA Attestation Form、EU CRA、韓国ISMS-P、日本IPAガイドラインがSBOM・attestationを要求し始めた。

それぞれの軸ごとに別個のツール・標準が登場した。本稿の構成はその5つの軸をたどる。

[サプライチェーンセキュリティの6段階 — 2026モデル]
  1. ソース管理            — Git、SCMポリシー、コード署名
  2. 依存関係キュレーション — Socket、Snyk、Phylum、Endor
  3. ビルド完全性          — SLSA、in-toto、GitHub OIDC、Tekton Chains
  4. SBOM生成              — Syft、CycloneDX、SPDX、CSAF
  5. アーティファクト署名  — cosign、Sigstore、Notary v2
  6. ランタイム検証        — Kyverno、Sigstore policy-controller、OPA

各段階で異なるツール・異なる責任者がいる。本稿は段階別にツール・標準・実際の事件を整理する。

2章 · 決定的事件 — XZ Utilsバックドア（CVE-2024-3094）

2024年3月28日、MSのPostgreSQLエンジニアAndres Freundがセキュリティメーリングリストoss-securityに投稿した。その投稿が2020年代サプライチェーンセキュリティの分水嶺となった。

事件の輪郭 — XZ Utils 5.6.0と5.6.1にバックドアコード挿入。liblzmaを介してOpenSSHのsshdに影響。特定のRSAキーを持つユーザーに認証なしでRCE権限を付与。
メンテナー信頼の侵入 — Jia Tan（あるいはJia Cheong Tan）という仮名が2021年から活動。2-3年かけてpatch、review、release権限を着実に獲得。
社会工学的圧力 — Jigar Kumarなどの仮名アカウントが原メンテナーLasse Collinに「リリースが遅い」という圧力メールを送る。結局Jia Tanをco-maintainerに追加。
発見の偶然性 — Freundがsshdログイン遅延（0.5秒）を不審に思いperfで追跡して発見。事実上偶然。

この事件の教訓は明確だ。

メンテナーの信頼は永続しない — 一人の人間が単一障害点になってはならない。
バイナリビルドとソースの差検証は必須 — XZのバックドアはtarballにはあるがgitリポジトリにはなかったコードだった。
再現可能ビルドの重要性 — Debianとtorが推進しているreproducible buildなら差を即座に検知できた。
自動検出の限界 — 静的解析では捕まえられなかった。行動解析が必要だ。

XZ Utils事件以後、OpenSSFのAlpha-OmegaプロジェクトがコアOSSメンテナーへの支援を拡大し、Sigstore・SLSA・Socketなどのツールの導入が本格化した。

3章 · Sigstore — キーなし署名の標準

Sigstore（sigstore.dev）は2021年にLinux Foundation・Red Hat・Googleが共同で発足。OpenSSF傘下のプロジェクト。

中核コンポーネント。

cosign — コンテナイメージ・SBOM・バイナリに署名するCLIツール。
fulcio — 短期認証局。OIDCトークンを受け取り、5-10分有効な署名用X.509証明書を発行。
rekor — 変更不可な透明性ログ。Merkle Tree基盤。すべての署名が公開記録に。
gitsign — Gitコミット署名用のcosignバリアント。SSHキーの代わりにOIDC使用。

仕組みは「キーなし署名（keyless signing）」だ。

OIDCログイン — GitHub Actions、Google、Microsoft、GitLab OIDCで認証。
fulcioにCSR提出 — fulcioがOIDC claimを証明書に埋め込み、短期署名証明書を発行。
cosignで署名 — その証明書でアーティファクトに署名。直後に証明書・署名をrekorに記録。
検証 — 誰でもrekorの透明性ログとfulcioの証明書チェーンに沿って検証可能。

既存PGP署名の問題 — キー管理、キー失効、キー紛失 — を正面から回避する。キーがないので失うキーもない。すべての署名が公開ログに記録され、事後否認が不可能。

2026年5月時点でKubernetes、npmの一部パッケージ、PyPIの一部パッケージがSigstore署名を採用。GitHub Actions Artifact Attestations（2024年5月GA）も内部的にSigstoreを使用。

4章 · SLSA v1.1 — サプライチェーン完全性レベル

SLSA（slsa.dev、「サルサ」と読む）はSupply-chain Levels for Software Artifactsの略。Googleが社内のBinary Authorization for Borg（BAB）をOSSに一般化したフレームワーク。OpenSSFで管理。

v1.0 — 2023年4月発表。Build、Source、Dependencyトラックを分離。
v1.1 — 2024年後半に更新。Buildトラックに集中、SourceとDependencyは別作業に。

Buildトラックのレベル。

Build Level 1 — provenance（誰が、どこで、どうやってビルドしたか）を提供。改ざん防止はまだない。
Build Level 2 — provenanceが署名されており、ビルドサービスがホスティングされている。ビルダー信頼が必要。
Build Level 3 — ビルダーが隔離され他のビルドの影響を受けない。GitHub Actions Reusable Workflows + OIDCが代表例。

SLSA Level 3を達成すれば、SolarWinds・Codecov型の攻撃 — ビルド環境改ざん — に強力な防御線ができる。ビルドサービス自体が侵害されない限り、attackerが任意コードをビルド成果物に挟み込めない。

実務適用例。

GitHub Actions — slsa-framework/slsa-github-generatorアクションでLevel 3ビルド可能。
GitLab CI — Premium以上でprovenance attestationを自動生成。
Google Cloud Build — Container Analysis APIでprovenance提供。
AWS CodeBuild — Public BuildsでBuild Level 3支援（2024 GA）。

5章 · in-toto — Attestationの一般フレームワーク

in-toto（in-toto.io）はNYU・Cornellで始まった学術プロジェクトがCNCFに定着したケース。2022年CNCF Incubating入り、2024年Graduated。

中核アイデア。サプライチェーンの各段階で「私が何をした」というattestation（証言）を発行し、次の段階がそれを検証する。

Layout — パイプライン定義。「この順序で、この人々が、この作業をする」。
Step — 各段階の入出力ハッシュ。
Sublayout — 大きいパイプラインの一部の段階をさらに別のlayoutに委任。

SLSAのprovenanceはin-toto attestationの一種。つまりSLSAはin-toto形式を借りてビルド完全性に集中した仕様。

in-totoの一般性は次を意味する。

SBOMもattestation — 「このアーティファクトのSBOMはこれです」という証言。
脆弱性スキャン結果もattestation — 「この時点でTrivyでスキャンしたら結果はこれです」。
テスト結果もattestation — 「この時点でこういうテストが通りました」。

すべての証言がSigstoreで署名されrekorに記録されると、運用チームはデプロイ直前に「このイメージが十分なattestationを集めたか」をポリシーエンジン（Kyverno、OPA）で強制できる。

6章 · GUAC — Attestationのグラフデータベース

GUAC（guac.sh、Graph for Understanding Artifact Composition）はKusari・Google・Purdueが始めたOpenSSFプロジェクト。2023年初発足。

問題意識。SBOM・attestation・脆弱性データが各所に散らばっている。一箇所にまとめてグラフでクエリできるべきだ。

GUACは次を統合する。

SBOM — Syft、Trivyが作ったCycloneDX/SPDXファイル。
Attestation — SLSA provenance、in-toto。
脆弱性 — OSV、GHSA、NVDから収集。
コンテナメタデータ — registryからpullした情報。

クエリ例。

Q: 運用中のすべてのイメージで Log4j 2.14 を使っているものは？
GUAC: registry/payments-api:v3.2.1, registry/inventory:v1.0.5 ...

Q: このイメージが依存するすべての npm パッケージのうち、
   Jia Tan のようなメンテナーパターンを見せるものは？
GUAC: (graph traversalでメンテナー・リリースパターンを解析)

2026年5月時点でGUACはAlpha段階だがOpenSSFが積極的に推している。KusariがSaaS形態でホスティングサービスを提供。

7章 · OpenSSF Scorecard — OSSプロジェクトの健全性スコア

OpenSSF Scorecard（github.com/ossf/scorecard）はOSSプロジェクトのセキュリティ慣行を自動スコア化するツール。2020年発足。

スコア項目（チェック16個）。

Code-Review — すべての変更がコードレビューを経るか。
Branch-Protection — mainブランチ保護設定。
Token-Permissions — GitHub Actionsトークンの権限最小化。
Vulnerabilities — 既知の脆弱性依存使用の有無。
Pinned-Dependencies — 依存をSHAでピン留めしたか。
Maintained — 直近90日の活動の有無。
License — ライセンスファイルの存在。

各項目0-10点、平均がプロジェクトスコア。10点が満点。

活用。

deps.dev（Google） — すべてのOSSパッケージのScorecardスコアを自動表示。
Securityscorecards.dev — スコア可視化ダッシュボード。
GitHub Action — 自プロジェクトにScorecardワークフローを追加。

Scorecardは「このパッケージをimportしてよいか」の自動評価基準として徐々に使われている。Endor Labs、Snykなど商用ツールもScorecardスコアを依存リスク評価に統合。

8章 · Frizbee · AllStar — 補助OpenSSFツール

Frizbee（github.com/stacklok/frizbee）はStacklokが作った小さなツール。GitHub Actionsとコンテナイメージを SHAでピン留めする。

# Before
- uses: actions/checkout@v4

# After (Frizbee適用)
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1

タグ（v4）はメンテナーが新しいSHAに移せる。tj-actions/changed-files事件（2025年3月、GitHub Action自体の改ざん）がその危険を示した。SHAピンは一時改ざんに影響されない。

AllStar（github.com/ossf/allstar）はOpenSSFが作ったポリシーボット。GitHub組織で次を自動強制。

Branch Protection — mainに直接push禁止、PRレビュー義務など。
Binary Artifacts — リポジトリに.exe・.dll・.soなどのバイナリ禁止。
Outside Collaborators — 外部協力者の権限制限。
SECURITY.md — セキュリティポリシーファイル存在の有無。

AllStarは発見時にissueを自動生成し、一定期間未解決ならPull Requestで修正案を提案。OpenSSF・Sigstore・CNCF本人らのGitHub組織がAllStarを運用中。

9章 · OSV-Scanner · OSV.dev — Open Source Vulnerabilities

OSV（osv.dev、Open Source Vulnerabilities）はGoogleが2021年初に発足させた脆弱性データベース。NVDの代替。

NVDの問題。

遅い登録 — CVE発行後NVDに登録されるまで数ヶ月遅延。
2024年NVDスローダウン — NIST人員不足で2024年2月からNVDの解析が事実上停止。米国政府OSSセキュリティ全体に大きな衝撃。
バージョン範囲表現の不一致 — vulnerable_software_listのようなCPEマッチングが精密でない。

OSVの強み。

JSONスキーマ標準 — 誰でも新しいDBをOSV形式で発行可能。
自動import — GHSA（GitHub）、RustSec、PyPA Advisory、npm Advisoryを自動統合。
言語・エコシステム別分離 — npm、PyPI、Go、Maven、NuGetなどそれぞれのデータセット。
バージョン範囲精密マッチング — パッケージマネージャの意味論（semver、PEP 440）に合わせてマッチング。

OSV-Scanner（github.com/google/osv-scanner）はOSVデータを使うローカルスキャナ。lockfile（package-lock.json、Cargo.lockなど）を読んで脆弱性を報告。無料・オープンソース。

2024年NVDスローダウン以後、OSVは事実上NVD依存を断った初の大規模DBとなった。CISAもOSVをKEV（Known Exploited Vulnerabilities）データと連携。

10章 · SBOMフォーマット — CycloneDX 1.6 vs SPDX 3.0

SBOM（Software Bill of Materials）を表現する2つの標準が並行発展中。

CycloneDX（cyclonedx.org）。

運営主体 — OWASP。
バージョン — 1.6（2024年4月）。
フォーマット — JSON、XML、ProtoBuf。
強み — VEX（Vulnerability Exploitability eXchange）統合、MLモデル・サービス・ハードウェアBOM支援。セキュリティツール中心に速い採用。

SPDX（spdx.dev）。

運営主体 — Linux Foundation。
バージョン — 3.0（2024年4月）。
フォーマット — JSON-LD、RDF/XML、Tag-Value。
強み — ISO/IEC 5962:2021国際標準。ライセンス情報表現が強力。法務・コンプライアンス中心に採用。

選択基準。

セキュリティ中心ならCycloneDX — VEX統合に強み、JSONが軽量。
コンプライアンス・ライセンス中心ならSPDX — ISO標準、ライセンスメタデータ強い。
両方出力する — Syft・Trivy両方とも両フォーマット同時出力支援。デュアル発行が無難。

米国EO 14028、CISA Attestationは両フォーマットを許容。EU CRAもSBOMフォーマットを強制しない。

11章 · SWID Tags · CSAF — 補助SBOM/脆弱性標準

SWID Tags（ISO/IEC 19770-2）はソフトウェア識別タグ。NISTが米国政府システムに推奨。パッケージインストール時に共に配布されるXMLファイルで、誰が・いつ・何をインストールしたかを記録。

SWIDはSBOMより精密な単一パッケージ識別に強い。ただしCycloneDX・SPDXほど普遍的ではない。

CSAF（Common Security Advisory Framework）はOASISが標準化。脆弱性公示のJSONフォーマット。

2.0 — 2022年発表。
VEX統合 — CSAF VEXプロファイルで「この脆弱性が当社製品に影響なし」のような陳述を標準化。
使用事例 — Red Hat、SUSE、Cisco、Siemensがセキュリティ公示をCSAFで発行。

CSAFはSBOMと対になる。SBOMが「この中に何があるか」、CSAFが「それにどの脆弱性が影響するか」を機械可読な形で答える。

12章 · Syft · Grype — AnchoreのSBOMツール

Syft（github.com/anchore/syft）はAnchoreが作ったマルチフォーマットSBOM生成器。無料・オープンソース。

入力 — コンテナイメージ、ファイルシステムディレクトリ、OCIアーカイブ。
出力フォーマット — CycloneDX、SPDX、Syft JSON、GitHub Dependency Snapshot、text。
検出パッケージ — npm、PyPI、Maven、Goモジュール、Rustクレート、RubyGems、Debian/RPMパッケージ、Java JAR、Python wheel。

syft alpine:3.20 -o cyclonedx-json=sbom.cdx.json
syft alpine:3.20 -o spdx-json=sbom.spdx.json

Grype（github.com/anchore/grype）は同じAnchoreの脆弱性スキャナ。Syftが作ったSBOMを入力として受け取る。

DB — NVD + OSV + GitHub Advisory + Anchoreのキュレーション。
出力 — table、JSON、SARIF。
VEX支援 — --vexオプションで偽陽性を除去。

Anchore EnterpriseはSyft・GrypeをSaaS・オンプレプラットフォームでまとめてポリシーエンジン（Anchore Policy）を追加する。

13章 · Trivy · Microsoft SBOM Tool

Trivy（github.com/aquasecurity/trivy）はAqua Securityが作った総合セキュリティスキャナ。iter79で別途扱ったが、サプライチェーンセキュリティで中心的ツール。

コンテナイメージスキャン — OSパッケージ + 言語依存 + IaC + シークレット。
SBOM生成 — CycloneDX、SPDX出力。
SBOMスキャン — 既存SBOMを入力として受け取り脆弱性スキャン。

trivy image --format cyclonedx --output sbom.json alpine:3.20
trivy sbom sbom.json

Trivyは無料・オープンソース。Aqua Enterprise（商用）はクラスタ全体スキャン・ポリシー・CI統合を追加。

Microsoft SBOM Tool（github.com/microsoft/sbom-tool）はMS社内用に開始し2022年OSS化。Windows・.NETエコシステムに強み。SPDX 2.2出力。

sbom-tool generate -b ./build -bc ./src -nsb https://example.com/sbom

MSは社内すべてのビルドにSBOM Toolを義務化。Visual Studio・Azure DevOpsと統合。

14章 · GitHub Dependency Graph · Dependabot · Snyk SBOM

GitHub Dependency GraphはGitHubが自動生成する依存ツリー。ほぼすべてのパッケージマネージャlockfileをパース。

Dependabot Alerts — 依存脆弱性発見時に自動アラート。
Dependabot Security Updates — 自動PR生成でパッチ適用。
Dependency Review — PRで新依存追加時にライセンス・脆弱性差分を表示。
SBOM Export — Settings → Dependency graph → Export SBOM（SPDX 2.3）。

GitHub Advanced Security（GHAS）を購入するとCodeQL（SAST） + Secret Scanning + Push Protectionなど追加。

Snyk SBOM（snyk.io）は商用製品のSBOMモジュール。Snyk Open Source（依存スキャン）、Snyk Code（SAST）、Snyk Container（イメージスキャン）と統合。CycloneDX・SPDX出力。

Mend（旧WhiteSource、mend.io）も同カテゴリ。ライセンスコンプライアンスに強み。SBOMモジュールでCycloneDX出力。

15章 · イメージ署名 — cosign · Notary v2 · TUF

イメージ署名の標準がいくつか共存する。

cosign / Sigstore — 3章参照。キーなし署名。事実上の標準（de facto）。

Notary v2（notaryproject.dev）はCNCF Incubatingプロジェクト。Docker Notary v1の後続。

OCI Image標準採択 — 署名をOCI artifactとしてregistryに保存。
多様な署名アルゴリズム — RSA、ECDSA、EdDSA。
Azure Key Vault、AWS KMS統合 — エンタープライズKMS親和。
notation CLI — cosignと類似だがキーベース。

Notary v2とcosignは同一OCI registryに共存可能。AWS・AzureはKMS基盤のキーを好みNotary v2を推し、Google・OpenSSFはcosignを推す。

**Docker Content Trust（DCT）**はNotary v1時代のlegacy。2026年にはほぼ使われない。

TUF（theupdateframework.io、The Update Framework）はCNCF Graduated。更新メカニズムの一般フレームワーク。cosign・notation両方ともTUFの原理を一部借用。PyPIのPEP 458 secure package signingがTUF基盤。

16章 · Chainguard Images · Wolfi OS — Distrolessの進化

Chainguard（chainguard.dev）は2021年Dan Lorenc、Kim LewandowskiなどGoogle出身者が創業。Sigstore共同創立者らが作った会社。

中核製品 — Chainguard Images。

イメージ種類 — nginx、python、go、node、php、openjdk、postgresなど350余種。
ベース — 自社OSのWolfi。
特徴 — distroless（シェルなし）、Sigstore署名、SBOM同梱、目標CVE 0個。

Wolfiの差別点。

undistro — 既存distroと異なって始まったOS。glibc基盤（Alpineはmusl）。
rolling release — パッケージ最新バージョン即座に反映。
ビルドツール — apko（イメージビルダー）、melange（パッケージビルダー）両方ともOSS。

価格（2026年5月）。

Chainguard Free — 公開イメージ使用無料（community）。
Chainguard Production — SLA、長期支援、社内mirror、FIPS認証イメージ。価格非公開（エンタープライズ）。
Chainguard Custom — ユーザー定義ベースイメージビルドサービス。

戦略的にRed Hat UBI、Google Distrolessの市場を直接狙う。2024-2025年Chainguardはシリーズ D 1億4千万USDなどを集めて評価額約30億USDを記録。

17章 · Google Distroless · Red Hat UBI Minimal · BuildPacks

Google Distroless（github.com/GoogleContainerTools/distroless）はGoogleが2017年に発足させたOSS。シェル・パッケージマネージャなしの最小イメージ。

base-nossl — 単純cgo未使用Goバイナリ用。
cc — glibc含む、C/C++/Go。
nodejs / java / python — 言語ランタイム含む、パッケージマネージャなし。

Distrolessは無料・オープンソース。ただしChainguardと違いSBOM・署名・CVEモニタリングなどの付加サービスはない。

Red Hat UBI Minimal（catalog.redhat.com）はRed HatのUniversal Base Image。RHEL互換。microdnfパッケージマネージャ含む（完全distrolessではない）。エンタープライズRHEL顧客親和。

BuildPacks（buildpacks.io）はCNCF Incubating。コンテナビルドをDockerfileなしで自動化。

Paketo Buildpacks（VMware） — Java、Node、Python、Go、Rubyなど。
Heroku Buildpacks — Heroku PaaSのビルドシステムに由来。
Google Cloud Buildpacks — Cloud Run、App Engineで使用。

BuildPacksの長所 — Dockerfile表面積縮小でmisconfiguration・脆弱性減少。自動ベースイメージ更新。

Apko、Melange（github.com/chainguard-dev/apko、github.com/chainguard-dev/melange）はChainguardが作ったビルドツール。apkoはYAML宣言でイメージ生成、melangeはパッケージビルド。Wolfiビルドの基盤。

18章 · Socket.dev — npm/PyPI行動解析

Socket（socket.dev）は2022年Feross Aboukhadijehが創業。Node.jsエコシステムのベテラン（Standard JS、WebTorrentなど）。

問題意識。npm・PyPIの新パッケージ・新バージョンが毎日数万件アップされるが、人間が一つ一つ検討できない。

Socketのアプローチ。

AST解析 — すべての新パッケージを静的解析。怪しいパターン（eval、child_process、fs.readFileSyncなど）を自動スコア化。
install script解析 — npm preinstall・postinstall、PyPI setup.pyコードを実行前に検査。
ネットワーク通信検出 — 怪しいドメイン・IP・テレメトリ検出。
タイポスクワッティング検出 — 人気パッケージ名との編集距離測定。
メンテナー変更追跡 — 新メンテナー追加時にアラート。

PRにSocket Botがコメントでリスクを表示。GitHub Marketplaceで無料インストール可能。有料プランはSAST・SBOM・ポリシーエンジンを追加。

価格（2026年5月）。

Free — オープンソースプロジェクト、個人。
Team — 月ユーザーあたり8 USD。
Enterprise — 価格協議。

XZ Utils事件直後、Socketは自社解析でJia Tanの特異パターン（リリース権限追加後即座に大きな変更）を事後に捕まえられたと発表。似たパターン検出を本格導入。

19章 · JFrog Xray · Black Duck — エンタープライズ依存スキャン

JFrog Xray（jfrog.com/xray）はJFrog Artifactoryのセキュリティモジュール。Artifactoryを使うすべての会社に自然な追加オプション。

ターゲット — JFrog Artifactoryリポジトリのすべてのアーティファクト。
スキャン — CVE、ライセンス、運用リスク（deprecatedパッケージなど）。
遮断ポリシー — Artifactoryで危険パッケージのダウンロード遮断。
SBOM — CycloneDX・SPDX出力。
Curation（2024追加） — 安全なパッケージだけ選んで社内レポにmirroring。

JFrog統合が強みだが、それが短所でもある。Artifactoryを使わないとXray導入理由が弱くなる。

Black Duck（blackduck.com）はSynopsysのSCA事業を2024年9月に分社化した会社。正式名称はBlack Duck Software Composition Analysis。

歴史 — 2002年創業。SCA（Software Composition Analysis）カテゴリを事実上定義。
KnowledgeBase — 500万個以上のオープンソースコンポーネント・ライセンスDB。
強み — ライセンスコンプライアンス、デューデリジェンス報告書（M&A時に使用）。
SBOM — CycloneDX・SPDX。

Black Duckはライセンスリスクに強く、価格が高い。自動車・医療・金融など厳格な産業で標準。価格非公開（エンタープライズ）。

20章 · Snyk Open Source · Snyk Container

Snyk（snyk.io）は2015年英国で創業。2022年評価額80億USDまで上がってから2023-2024ダウンラウンド。

製品群。

Snyk Open Source — npm・PyPI・Maven・NuGetなど依存スキャン + ライセンス。
Snyk Code — SAST（独自エンジン、DeepCode買収基盤）。
Snyk Container — コンテナイメージスキャン。
Snyk IaC — Terraform・Kubernetes・CloudFormationスキャン。

価格（2026年5月）。

Free — 月200回テスト。
Team — 月ユーザーあたり25 USD。
Enterprise — 価格協議。

Snykの強み — 開発者親和UX、IDEプラグイン（VS Code、JetBrains）、GitHub/GitLab統合。弱み — 価格が速く高くなる。

2024年SnykはSBOM機能を強化し、AppRisk ProというASPM（Application Security Posture Management）製品で拡張中。Endor Labs・Apiiro・OX Security・CycodeなどASPM新興企業と競合。

21章 · Phylum · Stacklok · Endor Labs — 次世代サプライチェーンセキュリティ

Phylum（phylum.io）は2020年創業。ML基盤パッケージリスクスコア化。

解析モデル — メンテナー、コードパターン、ライブラリ履歴など280+ heuristic。
対象パッケージマネージャ — npm、PyPI、RubyGems、Maven、NuGet、Cargo、Go。
ゼロデイ遮断 — 新パッケージが登録される即座に解析。

Stacklok（stacklok.com）は2023年Craig McLuckie（Kubernetes共同創立者）、Luke Hinds（Sigstore共同創立者）が創業。

製品 — Minder — サプライチェーンセキュリティポリシーエンジン。Sigstore・OPA・GUAC統合。
製品 — Trusty — パッケージリスクスコア無料サービス。
製品 — Frizbee — SHAピンツール（8章）。

Stacklokは本質的にSigstore創立者らが会社化したもの。OSS優先戦略。

Endor Labs（endorlabs.com）は2022年Varun Badhwar（前Palo Alto/RedLock創立者）が創業。

Reachability Analysis — 「このパッケージの脆弱性が実際に自分のコードで呼ばれるか」精密追跡。CVEノイズを大幅削減。
Phantom Dependencies — package.jsonにないのに実際にimportされるパッケージを検出。
License Risk — デュアルライセンス、コピーレフトリスク。
SBOM + VEX — 自動VEX生成で「影響なし」表示。

Endor Labsはシリーズ B 7千万USD（2023）、2024年1.6億USD追加。ASPMカテゴリリーダーの一つ。

22章 · GitHub Actions OIDC + Artifact Attestations

GitHub Actions OIDCはGitHub Actionsワークフローが OIDCトークンを受け取り外部クラウド（AWS、GCP、Azure）にIAMロールで認証するメカニズム。2022年GA。静的secret（AWS_ACCESS_KEY）の削除。

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123:role/github-actions
          aws-region: us-east-1

GitHub Artifact Attestations（2024年5月GA）はOIDC + Sigstore + in-totoの統合。ワークフロー成果物に自動でprovenanceを添付。

- uses: actions/attest-build-provenance@v1
  with:
    subject-path: dist/myapp

この一行でSLSA Build Level 3水準のprovenanceが自動生成され、Sigstoreで署名され、rekorに記録される。検証はgh attestation verify。

2026年5月現在GitHub ActionsはOSSサプライチェーンセキュリティの事実上の標準。GitLab CI、CircleCIも類似OIDCを提供するが採用率はGitHubが圧倒的。

23章 · GitLab CI · Buildkite · Tekton Chains

GitLab CIはGitLabの組み込みCI/CD。2023年からSLSA provenance生成をPremium以上で支援。

OIDC — id_tokensキーワードでAWS・GCP・HashiCorp Vault認証。
Container Scanning — Trivy統合。
Dependency Scanning — Gemnasium（GitLab独自） + 外部DB。
SBOM Export — UltimateでCycloneDX出力。

Buildkite（buildkite.com）はオーストラリアで始まったCI。Hybridモデル（SaaSコントロールプレーン + 自社ホスティングエージェント）。2024年からSigned Pipelines機能。パイプライン定義自体を署名して改ざん防止。

CircleCIは2023年1月自社セキュリティ事故（顧客secret流出）後OIDCを強調。2024年SLSA Level 3自動化。

Tekton Chains（tekton.dev/docs/chains）はCNCF Tektonのセキュリティモジュール。Tektonパイプラインのすべてのtask runにattestationを自動生成。Sigstore署名。Red Hat OpenShift Pipelinesに標準装備。

24章 · パッケージマネージャの OIDC 署名 — PyPI · npm · RubyGems

パッケージマネージャがOIDCで発行者検証を導入した。メンテナーのパスワード・APIトークン流出が即悪性リリースにつながるリスクを減らす。

PyPI Trusted Publishers（docs.pypi.org/trusted-publishers）は2023年4月GA。GitHub Actions・GitLab CI・Google Cloud BuildのOIDCトークンを直接信頼。別途PyPI APIトークン不要。

- uses: pypa/gh-action-pypi-publish@release/v1
  with:
    # No api-token! OIDCのみ使用
    repository-url: https://upload.pypi.org/legacy/

PyPIは2024年11月、セキュリティパッケージへの外部点検を強化し2FA義務化を完了。

npm provenance（docs.npmjs.com/generating-provenance-statements）は2023年4月GA。npm publish --provenanceオプション。GitHub Actions OIDC基盤。provenanceがnpmパッケージページに「Provenance」バッジで表示。

RubyGems trusted publishingも2024年後半に導入。似たOIDC基盤。

Crates.io（Rust）は2024年新しいセキュリティモデルを発表（RFC 2706など）。aud検証・OIDC基盤。

Maven Centralは2024年PGP署名を強化し、signing portalを新しく作った。OIDC直接導入は2026年進行中。

25章 · 脆弱性データベース比較 — NVD · OSV · GHSA · KEV

NVD（nvd.nist.gov）はNISTのNational Vulnerability Database。CVEにCVSSスコア・CPEマッチングを追加。2024年2月から解析が遅延することが広範に知られ、NISTが外部委託など代案発表。

OSV（osv.dev）は9章参照。2024年NVDスローダウン以後、事実上OSS標準。

GHSA（GitHub Security Advisories、github.com/advisories）はGitHubが発行するadvisory。CVE発行も自動処理。Dependabotのデータソース。

KEV（CISA Known Exploited Vulnerabilities、cisa.gov/known-exploited-vulnerabilities-catalog）は米国CISAが運営。実際に攻撃に使われたCVEだけ記載。米国連邦システムはKEV登載CVEを短期間内にパッチ義務。

選択基準。

包括性 — NVDが最も広範だったが2024年スローダウンでOSV・GHSAに優位喪失。
速度 — GHSA・OSVが最速。
実リスク — KEVが最も正確。量より質。
商用データ — Snyk DB、Rapid7、Tenable DBが独自キュレーション追加。

26章 · 規制環境 — US EO 14028 · CISA · EU CRA · NIST SSDF

Executive Order 14028（2021年5月、バイデン）は米国連邦機関サイバーセキュリティ強化。SBOM・zero trust・incident reporting義務。

NIST SSDF（Secure Software Development Framework、NIST SP 800-218）はEO 14028の後続。安全なSDLC実践ガイド。4グループ・19実践項目。

CISA Secure Software Development Attestation Form（2024年3月発表）はEO 14028履行の核心。米国連邦機関にソフトウェアを販売するベンダーがCEO・役員署名でNIST SSDF順守を宣言。虚偽陳述時に刑事処罰可能。

**EU Cyber Resilience Act（CRA）**は2024年10月EU議会採択。2027年12月本格施行予定。デジタル製品にサイバーセキュリティ義務。

CEマーク — ハッキング可能性のある製品（IoT、ソフトウェア）にCEマーク義務。
SBOM — 市場に出すすべての製品にSBOM同梱。
脆弱性報告 — 24時間内にENISA・国家CSIRTに報告。
罰金 — 売上の2.5 %または15M EURのうち大きい金額。

OSSメンテナーは当初懸念が大きかった（OSS免除明示）が、最終案で「商業的に提供されるすべてのデジタル製品」に限定され、非商業的OSSは免除。

PCI DSS 4.0（2024年3月義務化）は決済カード産業標準。SBOM・SAST/DAST・secret管理強化。

27章 · 韓国・日本のサプライチェーンセキュリティガイドライン

韓国。

ISMS-P（情報保護および個人情報保護管理体系認証） — KISAが運営。サプライチェーンセキュリティ項目が2024年改定で強化。
金融保安院（FSI）SBOMガイド（2024年9月発表） — 金融機関のSBOM導入勧告案。CycloneDX・SPDX勧告。
Samsung SDS、LG CNS、NCSOFT — 社内SBOMシステム運用。独自依存キュレーションレジストリ。
Naver Whale、Kakaoセキュリティセンター — 外部パッケージ使用ポリシー強化。2024年KakaoTalkセキュリティ事故後、サプライチェーン点検を強化。
ソフトウェア振興法 — 2024年改定で公共SW事業にSBOMを要求。

日本。

IPA Software Supply Chain Security Guidelines（2023年12月1.0版） — 情報処理推進機構が発表。CycloneDX勧告。
NISC（内閣官房サイバーセキュリティセンター） — 政府システムサプライチェーンセキュリティ標準。
METI（経済産業省） — サイバーセキュリティ経営ガイドライン3.0にサプライチェーン項目追加。
NTT Communications（Group-CSIRT） — SBOM・SCA独自運用。社内安全パッケージレジストリ。
GMO Cybersecurity by IERAE — SBOM・SCAコンサル + JVN統合ソリューション。
自動車産業 — UN R155サイバーセキュリティ義務化でトヨタ・ホンダ・日産が1次協力会社までSBOMを要求。

28章 · 産業別特殊要求 — 医療 · 自動車 · 金融

医療（米国）。FDAが2023年10月から医療機器に対するサイバーセキュリティ義務化。Section 524B医療機器サイバーセキュリティ。

SBOM義務 — すべての新規医療機器510(k)提出時にSBOMを同伴。
脆弱性モニタリング — 出荷後生涯モニタリング。
ソフトウェア更新 — セキュリティパッチ配布計画提出。

GE Healthcare、Medtronic、Philips、Siemens Healthineersが独自SBOMワークフローを強化。

自動車。UN R155（2022年から新車形式認証義務）とISO/SAE 21434。

CSMS（Cyber Security Management System） — 自動車OEM・1次協力会社義務。
SBOM・VEX — 車両ソフトウェアコンポーネント追跡。
OTA更新 — 無線セキュリティパッチ配布標準。

トヨタ・BMW・GM・フォード・テスラがすべて影響。韓国現代自動車・起亜もグローバル販売でR155影響圏。

金融。PCI DSS 4.0（2024年3月）、韓国電子金融監督規定、日本FISC安全対策基準。

決済カード環境 — SBOM・SAST/DAST義務。
システムリスク — 決済断絶がシステムリスク。3rd party SWリスク評価必須。

韓国金融保安院の2024年SBOMガイドもこの流れ。

29章 · 実戦導入ロードマップ — 0ヶ月から12ヶ月まで

導入は漸進的でなければならない。一度にすべてのツールを投げると開発チームが無力化する。12ヶ月ロードマップ例。

[0-1ヶ月] 可視性確保
  - GitHub Dependency Graph + Dependabot 有効化（無料）
  - Trivy ですべてのコンテナイメージスキャン開始
  - Syft で SBOM 生成試行（CycloneDX 出力）

[1-3ヶ月] 自動化導入
  - Socket Bot GitHub Marketplace インストール
  - Snyk または Endor Labs PoC 実施
  - CI/CD に OIDC 導入（GitHub Actions → AWS IAM Role）

[3-6ヶ月] ビルド完全性
  - SLSA Build Level 2 達成（provenance 自動生成）
  - GitHub Actions Artifact Attestations 導入
  - Sigstore cosign でコンテナイメージ署名

[6-9ヶ月] ベースイメージ強化
  - Chainguard Images または Google Distroless へ移行
  - Frizbee ですべての GitHub Action を SHA ピン

[9-12ヶ月] ポリシー強制
  - Kyverno または Sigstore policy-controller で
    署名されていないイメージのデプロイ遮断
  - SLSA Build Level 3 達成
  - SBOM・VEX を顧客・監査人に定期発行

各段階に測定可能な成果物が必要だ。「SBOMがある」は満足ではなく、「脆弱性平均パッチ時間が30日から7日に減った」が本当の目標。

30章 · 意思決定 — どのツールをいつ使うか

[OSS・個人プロジェクト]
  → GitHub Dependabot + Trivy + Sigstore（すべて無料）
  → OpenSSF Scorecard スコアモニタリング
  → 依存関係を少なく維持

[スタートアップ・中小 SaaS]
  → Snyk Free または Socket Free
  → GitHub Actions Artifact Attestations
  → Chainguard Images（community）
  → Syft で SBOM 自動生成

[エンタープライズ — 金融・医療・自動車]
  → JFrog Xray（Artifactory 使用時）
  → Black Duck（ライセンスコンプライアンス）
  → Chainguard Production
  → Endor Labs または Snyk Enterprise
  → SLSA Level 3 + cosign + Kyverno

[政府・国防]
  → CISA Attestation Form 作成
  → NIST SSDF 全面履行
  → SBOM + VEX 定期発行
  → KEV 登載 CVE 短期間内パッチ

選択の核心は「必要なだけ」だ。依存関係50個のプロジェクトにEndor Labs Enterpriseは過剰。依存関係5,000個の決済システムにTrivyだけ使うのは不足。

31章 · 自己点検チェックリスト

サプライチェーンセキュリティツールを導入する時の8つの質問。

1. 依存 lockfile があり、CI が lockfile を検証するか？
   → package-lock.json、poetry.lock 欠如時に即時導入。

2. コンテナイメージが毎ビルドごとにスキャンされるか？
   → Trivy・Grype・Snyk Container のうち一つは必須。

3. CI トークンが静的 secret か、OIDC か？
   → AWS_ACCESS_KEY のような静的キーは即時 OIDC に交換。

4. 新依存追加時に誰が検討するか？
   → Socket・Phylum のような自動解析を導入。

5. ベースイメージ出所を追跡可能か？
   → Chainguard・Distroless・UBI のうち一つで統一。

6. ビルド成果物に provenance があるか？
   → SLSA Build Level 2 以上推奨。

7. 脆弱性発見時の平均パッチ時間は？
   → KEV は 24-72 時間、その他は 30-90 日 SLA。

8. SBOM を顧客・監査人に発行するか？
   → CISA Attestation・EU CRA 対応。

この8つのうち5つ以上を充足しないとサプライチェーン攻撃に露出している。SolarWinds・Log4Shell・XZのような事件が起こると会社が回復できない。

エピローグ — 信頼は作るものであって仮定するものではない

本稿が描いた地図は60余のツール・標準・事件で満ちている。Sigstore・SLSA・SBOM・Chainguard・Socket・JFrog・Snyk・Endor Labs・Phylum・GUAC・in-toto・OpenSSF Scorecard・CycloneDX・SPDX。それぞれが自分の場所で意味を持つ。

しかし2026年サプライチェーンセキュリティの核心真実はこうだ。信頼はデフォルトではない。信頼は作るものだ。 メンテナーのメールアドレス、GitHubのスター数、npmダウンロード数は信頼の根拠ではない。署名、attestation、再現可能ビルド、行動解析が信頼の根拠だ。

XZ Utils事件が示した教訓は冷たい。2年にわたる社会工学的侵入を人の直観だけで防げない。Andres Freundの発見は偶然であり、次の侵入は発見されないかもしれない。その事実がツール・標準・自動化の導入を先延ばしできない理由。

本稿を読み終えたら今日一つだけ決めよう。自分のプロジェクトの依存ツリーを一度出力してみる。 npm ls --all、pip list、mvn dependency:tree、go mod graph。その出力に1,500個以上のパッケージがあれば、それが自社の本当のサプライチェーンだ。その1,500個の信頼がどう形成されているか問うのが出発点。

良いツール、良い標準、良いメンテナー。SigstoreとSLSAはその三つをつなぐ橋に過ぎない。

付録 · クイックコマンド参照

# SBOM 生成
syft alpine:3.20 -o cyclonedx-json=sbom.cdx.json
trivy image --format spdx-json -o sbom.spdx.json alpine:3.20

# イメージ署名 (cosign + GitHub OIDC)
cosign sign --yes registry.example.com/myapp:v1.0.0

# イメージ検証
cosign verify --certificate-identity-regexp 'https://github.com/myorg/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  registry.example.com/myapp:v1.0.0

# Attestation 検証 (GitHub CLI)
gh attestation verify oci://registry.example.com/myapp:v1.0.0 \
  --repo myorg/myapp

# OSV スキャン
osv-scanner --lockfile=package-lock.json
osv-scanner --docker alpine:3.20

# Scorecard スコア確認
scorecard --repo=github.com/myorg/myproject

プロローグ — サプライチェーンは新しい攻撃面である

1章 · なぜサプライチェーンセキュリティが必要か

2章 · 決定的事件 — XZ Utilsバックドア（CVE-2024-3094）

3章 · Sigstore — キーなし署名の標準

4章 · SLSA v1.1 — サプライチェーン完全性レベル

5章 · in-toto — Attestationの一般フレームワーク

6章 · GUAC — Attestationのグラフデータベース

7章 · OpenSSF Scorecard — OSSプロジェクトの健全性スコア

8章 · Frizbee · AllStar — 補助OpenSSFツール

9章 · OSV-Scanner · OSV.dev — Open Source Vulnerabilities

10章 · SBOMフォーマット — CycloneDX 1.6 vs SPDX 3.0

11章 · SWID Tags · CSAF — 補助SBOM/脆弱性標準

12章 · Syft · Grype — AnchoreのSBOMツール

13章 · Trivy · Microsoft SBOM Tool

14章 · GitHub Dependency Graph · Dependabot · Snyk SBOM

15章 · イメージ署名 — cosign · Notary v2 · TUF

16章 · Chainguard Images · Wolfi OS — Distrolessの進化

17章 · Google Distroless · Red Hat UBI Minimal · BuildPacks

18章 · Socket.dev — npm/PyPI行動解析

19章 · JFrog Xray · Black Duck — エンタープライズ依存スキャン

20章 · Snyk Open Source · Snyk Container

21章 · Phylum · Stacklok · Endor Labs — 次世代サプライチェーンセキュリティ

22章 · GitHub Actions OIDC + Artifact Attestations

23章 · GitLab CI · Buildkite · Tekton Chains

24章 · パッケージマネージャの OIDC 署名 — PyPI · npm · RubyGems

25章 · 脆弱性データベース比較 — NVD · OSV · GHSA · KEV

26章 · 規制環境 — US EO 14028 · CISA · EU CRA · NIST SSDF

27章 · 韓国・日本のサプライチェーンセキュリティガイドライン

28章 · 産業別特殊要求 — 医療 · 自動車 · 金融

29章 · 実戦導入ロードマップ — 0ヶ月から12ヶ月まで

30章 · 意思決定 — どのツールをいつ使うか

31章 · 自己点検チェックリスト

エピローグ — 信頼は作るものであって仮定するものではない

付録 · クイックコマンド参照

参考資料