Nullstead

AI

2026年版 個人開発のサプライチェーン防衛術：npm ProvenanceとArtifact Attestationsを“読む側”まで実装する

2026年の個人開発向けに、npm Provenance・GitHub Artifact Attestations・SLSAを組み合わせた実践的な供給網防衛フローを、検証側まで含めて解説します。

約9分

「公開は自動化できた。めでたしめでたし」……で終わるなら、セキュリティエンジニアという職業はもっと暇なはずです。

2026年の個人開発では、作る側の自動化だけでは足りません。大事なのは、受け取る側で検証できる状態まで揃えることです。この記事では、npm Provenance、GitHub Artifact Attestations、SLSAをつなげて、個人開発でも無理なく回る実装パターンをまとめます。

先に結論を言うと、以下の3点を押さえるだけで防御力はかなり上がります。

  • 発行: CIで来歴情報（Provenance）を生成・署名する
  • 配布: 成果物と来歴を公開場所にひも付ける
  • 検証: 利用側のCIで来歴を検証し、条件を満たさなければ落とす

「鍵は持ち歩かない、証明は持ち歩く」という発想です。※OIDC（OpenID Connect）= 外部ID基盤を使って短命トークンを発行する仕組み。長期シークレット削減の要。

なぜ今「公開」より「検証」が重要なのか

2024〜2026年にかけて、供給網対策の話題は「署名できるか」から「検証を強制できるか」にシフトしてきました。理由は単純で、署名は出発点でしかないからです。

たとえば、次のような状態は珍しくありません。

  • CIで署名したが、利用側は署名を見ていない
  • Provenanceは生成したが、どのリポジトリ・どのワークフロー由来か検査していない
  • 依存パッケージの検証結果をビルド失敗条件に入れていない

この状態は、ヘルメットを買って玄関に飾っているのと同じです。安全意識は高いが、頭は守られていません。

SLSA v1.0の文脈でも、Build Provenanceは「作った証跡」を構造化して残し、それを検証可能にすることが中心です。※SLSA = Supply-chain Levels for Software Artifacts。ソフトウェア成果物の供給網保護フレームワーク。

全体像：個人開発向けの最小アーキテクチャ

私がいま一番バランスが良いと考えているのは、次の構成です。

  1. GitHub Actionsでビルド
  2. OIDCで短命証明書を使ってAttestation生成
  3. npm公開時にProvenanceを付与
  4. 利用側CIで npm audit signatures と gh attestation verify を実行
  5. 失敗時はデプロイ停止

「個人開発でここまで必要ですか？」という声もあります。はい、必要です。理由は、個人開発ほど人的レビューの層が薄く、自動検証が最後の砦になるためです。

実装ステップ1：GitHub ActionsでBuild Provenanceを発行する

Artifact Attestationsを有効にする最短ルートは、GitHub公式アクションを使う方法です。必要なのは権限設定と対象ファイル指定です。

name: build-and-attest
on:
  push:
    tags:
      - "v*"

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      attestations: write
      packages: write

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - run: npm ci
      - run: npm run build

      - name: Pack artifact
        run: tar -czf dist.tgz dist

      - name: Attest build provenance
        uses: actions/attest-build-provenance@v3
        with:
          subject-path: dist.tgz

ポイントは id-token: write と attestations: write です。ここが抜けると「署名しようとしたのに権限がない」という、地味に悲しい失敗をします。深夜にやるとメンタルに効きます。

実装ステップ2：npm Provenanceを公開フローに組み込む

npm側はTrusted PublishingとProvenance生成を組み合わせると、長期トークン運用をかなり減らせます。公開時に来歴情報が付くので、利用側が検証可能になります。

name: publish
on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          registry-url: https://registry.npmjs.org

      - run: npm ci
      - run: npm test
      - run: npm publish --provenance --access public

補足として、npmのTrusted Publisher設定は「保存時に完全検証されない」ため、初回公開で設定ミスが発覚することがあります。これは仕様です。つまり、設定画面で成功した顔をしていても、実運用では失敗する可能性がある、ということです。UIの笑顔を信用しすぎてはいけません。

実装ステップ3：利用側CIで検証を“必須化”する

ここが本丸です。発行した証跡を、消費側で必ずチェックします。

3-1. npm依存の署名・来歴を検証

npm audit signatures

このコマンドで、インストール済み依存の署名・attestation検証結果を確認できます。CIで実行し、失敗時にジョブを落とすだけでも効果は高いです。

3-2. GitHub Artifact Attestationを検証

gh attestation verify dist.tgz \
  --repo your-org/your-repo \
  --format json

さらに厳密にするなら、期待するワークフローパスや発行元を絞ります。

gh attestation verify dist.tgz \
  --repo your-org/your-repo \
  --signer-workflow .github/workflows/build.yml

この「誰が、どの定義で、何を作ったか」を機械判定する設計が、後から効いてきます。事故のときに原因追跡が速くなり、復旧時間が短くなるからです。

SLSAをどう読むか：個人開発向けの現実解

SLSAという単語を見ると、急に会議室の空気が重くなることがあります。ですが、個人開発では「全部満点を狙う」より、次の順で進めるほうが現実的です。

  1. まず来歴を必ず発行する（Build Provenance）
  2. 発行元をOIDCベースにして長期秘密を減らす
  3. 検証をCIの必須ステップ化する
  4. 余力があればポリシー強化（許可ワークフロー限定など）

要は、SLSAを資格試験にしないことです。点数を取るための活動にすると疲れます。運用の再現性を上げるための道具として使うと、継続できます。

ハマりどころ5選（私が実際に踏んだやつ）

  1. 権限不足
    • id-token: write がなくて署名失敗。
  2. 対象ファイルの不一致
    • Attestation対象と配布物がズレる。
  3. 検証条件が緩すぎる
    • --owner だけで通してしまい、意図しない成果物も通過。
  4. 検証を任意ステップにしている
    • 失敗してもデプロイされる。これは検証した気分選手権です。
  5. “発行しただけ”で満足する
    • 発行は開始、検証が本番。

この5つを潰すだけでも、供給網リスクは体感でかなり減ります。

まとめ：2026年の個人開発は「自動公開」から「自動検証」へ

これからの個人開発は、速く作ることに加えて、由来を証明し、受け手で検査することが前提になります。

今日から始めるなら、次の順番をおすすめします。

  • ステップA: npm publishに --provenance を付ける
  • ステップB: GitHub Actionsで actions/attest-build-provenance を導入
  • ステップC: 利用側CIに npm audit signatures と gh attestation verify を追加

地味ですが、この3つで「なんとなく安全そう」から「失敗時に止まる安全」へ進めます。

防犯カメラを設置しても、録画を見ないなら意味がないのと同じです。開発も、証跡を作るだけでなく、ちゃんと見るところまで自動化していきましょう。

参考リンク

Tags #AI #セキュリティ #サプライチェーン #GitHub Actions #npm #自動化
← 記事一覧に戻る ページの先頭へ ↑