npm provenance
日本語記事
採用しているサンプルとしては sigstore が良さそう
pnpm も 8.4.0 で対応した
yarn は対応が進んでいそう
changesets や lerna などのサードパーティのツールで使いたい場合は、環境変数か package.json か .npmrc をいじると良い
changesets に issue があったので回答しておいた
GitHub の npmjs.com の間に https://www.sigstore.dev/ というサービスがあって、build から publish までの流れ(=サプライチェーン) の証明を行えるようになる
sigstore は npmjs.com や GitHub に依存したサービスではなくて、Docker コンテナなどのソフトウェアの成果物に対して電子署名を行えるサービス
署名は https://github.blog/2023-04-19-introducing-npm-package-provenance/ にある画像のデータに対して行われる
GITHUB_
系の環境変数がたくさんある
_type
フィールドの https://in-toto.io/Statement/v0.1
にアクセスすると https://github.com/in-toto/attestation/tree/v0.1.0/spec#statement にリダイレクトされる
in-toto
は A framework to protect software supply chain integrity
らしく、サプライチェーン用のフレームワークを提供しているみたい
predicate
のフォーマットは predicateType
にある URL で定義する形らしい
While this sort of attack is relatively rare in comparison to the occurrence of unintentional vulnerabilities, we are seeing a growing number of these, and the impact is often magnified given that it’s a deliberate and targeted attack. Over the past few years there have been a number of notable attacks against popular npm packages, including UAParser.js, Command-Option-Argument, and rc.
https://github.blog/2023-04-19-introducing-npm-package-provenance/
サプライチェーン攻撃はここ最近よくあるらしい
Supply-chain Levels for Software Artifacts
という仕様があるらしい
Supply-chain Levels for Software Artifacts, or SLSA ("salsa").
It’s a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. It’s how you get from "safe enough" to being as resilient as possible, at any link in the chain.
パッケージの出どころを証明するには?
→メンテナが管理する鍵で署名
→けど鍵が漏洩すると問題
→メンテナに依存するのではなくて、ソースコードとビルドプロセスを直接信頼したい
→信頼できる CI/CD サービスを使う
CI の OIDC を使うことでパッケージの利用者がいつでも検証可能な状態にする
→ sigstore に OIDC トークンを投げると短命な X.509 署名証明書を発行する
CI 上でキーペアを発行して、それで署名を行うらしい
Sigstore の Rekor に来歴証明書がアップロードされる
npmjs.com のレジストリはあるソフトウェアのあるバージョンを公開する前に、Rekor の証明書を確認して改ざんされていないことを確認する
npm cli の実装
GitHub にべったりな実装がされている
他の CI/CD サービスにも対応するならここの抽象化は必須になりそう
PGP署名からの開放
keyless signing
鍵の管理が自動化され、署名もtransparency logとして公の場所に保存されるため誰でも監査することが出来ます。簡単に無料で署名できるという点で、ソフトウェア署名におけるLet’s EncryptのようなものとGoogleは述べています。
Sigstore プロジェクトの各種ツールを利用すると、上述のように自分で鍵管理を行わずにコンテナイメージへの署名を行うこともできます。具体的には 「OpenID Connect を活用して得られる署名者の認証情報に紐づけて短命の署名用鍵を発行し、それで署名する」 というようなことができるのです。これが本稿のテーマである Keyless Signing と呼ばれる手法です。
https://blog.flatt.tech/entry/sigstore_keyless_signing
ID Token からキーペアを生成する流れがよくわかっていない
ID Token は誰でも閲覧できるから、他にどういう情報を混ぜているんだろう
いや ID Token は認証情報なので誰にも見せられないものだった
短命のキーペア生成はここで行っている
GitHub Actions の ID Token の取得はここ
短命のキーペアは ID Token の subject と payload に対して署名を行っている
この辺も npm cli は GitHub Actions にべったり
CI の OIDC を使うことでパッケージの利用者がいつでも検証可能な状態にする
→ sigstore に OIDC トークンを投げると短命な X.509 署名証明書を発行する
これが↑の
短命のキーペアは ID Token の subject と payload に対して署名を行っている
の部分かな
ここで npmjs.com にデータを渡していそう
PUT 時に body として渡されている
-
npm publish
実行 - sigstore.js で署名を作成
- 署名を npmjs.com に PUT
という流れは確認できた
PUT されたあとは npmjs.com 側で署名などなどを検証して、大丈夫ならパッケージを公開という流れかな
Rekor で確認できる
SLSAプロベナンス仕様のバージョン1.0を採用
他のクラウドCI/CDプロバイダーと協力して、プロベナンス署名のサポートを追加
想定されるソースリポジトリとコミットが存在することを検証
CI/CD環境とnpmレジストリ間のアクセスを管理する新しいツールを開発
↑が今後の展望なんだけど
想定されるソースリポジトリとコミットが存在することを検証
これやってないのかwってなるな