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

ソフトウェアセキュリティの重心が変わった。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

参考資料

- [OpenSSF](https://openssf.org/)

- [Sigstore](https://www.sigstore.dev/)

- [SLSA Framework](https://slsa.dev/)

- [in-toto](https://in-toto.io/)

- [GUAC](https://guac.sh/)

- [OpenSSF Scorecard](https://scorecard.dev/)

- [OSV.dev](https://osv.dev/)

- [CycloneDX](https://cyclonedx.org/)

- [SPDX](https://spdx.dev/)

- [CSAF (OASIS)](https://oasis-open.github.io/csaf-documentation/)

- [Syft (Anchore)](https://github.com/anchore/syft)

- [Grype (Anchore)](https://github.com/anchore/grype)

- [Trivy (Aqua)](https://trivy.dev/)

- [Microsoft SBOM Tool](https://github.com/microsoft/sbom-tool)

- [GitHub Artifact Attestations](https://docs.github.com/en/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)

- [GitHub Advisory Database](https://github.com/advisories)

- [CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)

- [CISA Secure Software Development Attestation](https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form)

- [Executive Order 14028](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)

- [NIST SSDF (SP 800-218)](https://csrc.nist.gov/publications/detail/sp/800-218/final)

- [EU Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)

- [Chainguard](https://www.chainguard.dev/) · [Wolfi](https://wolfi.dev/)

- [Google Distroless](https://github.com/GoogleContainerTools/distroless)

- [Red Hat UBI](https://catalog.redhat.com/software/base-images)

- [Socket](https://socket.dev/)

- [JFrog Xray](https://jfrog.com/xray/)

- [Black Duck](https://www.blackduck.com/)

- [Snyk](https://snyk.io/)

- [Phylum](https://www.phylum.io/) · [Stacklok](https://stacklok.com/) · [Endor Labs](https://www.endorlabs.com/)

- [PyPI Trusted Publishers](https://docs.pypi.org/trusted-publishers/)

- [npm Provenance](https://docs.npmjs.com/generating-provenance-statements)

- [Andres Freund XZ Backdoor Disclosure (oss-security)](https://www.openwall.com/lists/oss-security/2024/03/29/4)

- [Tekton Chains](https://tekton.dev/docs/chains/)

- [Frizbee (Stacklok)](https://github.com/stacklok/frizbee)

- [AllStar (OpenSSF)](https://github.com/ossf/allstar)

- [IPA Software Supply Chain Security Guidelines (Japan)](https://www.ipa.go.jp/security/reports/oversea/supplychain/index.html)

- [Korea FSI (金融保安院)](https://www.fsec.or.kr/)

- [KISA ISMS-P](https://isms.kisa.or.kr/)