npmのバージョン一覧に認証済みバッジを付けてみる
- 投稿した日
- 更新した日
- 書いたひと
- ひらたけ
私のウェブサイト Hiratake Web でも使用している Nuxt のパッケージを npmjs.com で見た際に バージョン一覧のところに認証済みバッジ的なものが付いている ことに気づきました。他のパッケージを見てみると、Vue.js や Next.js などでも同様のバッジが付いています。
私も公開しているパッケージがあるので「私もこの認証済みバッジみたいなの欲しい！」ということで、付けてみたときの内容を備忘録的な感じで書いていこうと思います。
この認証済みバッジのようなものはプロベナンスというものが付いていることを示すもののようで、パッケージがどこでどのようにビルドされて公開されたかなどを確認できるようになり、サプライチェーンセキュリティを向上させることができるとのこと。
先日も eslint-config-prettier や eslint-plugin-prettier などに悪意のあるコードが含まれたバージョンが公開されていた問題 が話題となっていましたし、パッケージを公開している身としてはこのようなサプライチェーン攻撃に対してできることはやっておきたいところ。
プロベナンスをつける
今回は、私がコードを書いたり管理をしたりしている こちらのパッケージ で認証済みバッジのようなもの改めプロベナンスを付けてみました。以下の記事を参考にさせていただいたのですが、私のリポジトリでは semantic-release や pnpm を利用しており、微妙に対応が違ったのでその辺りや詰まったところなどを書いていきます。
パッケージの公開には既に GitHub Actions を利用していたため、基本的にはワークフローをちょこっと書き換えるだけでプロベナンスを付けることができました。
シンプルに npm publish コマンドを用いてパッケージを公開している場合には、上記の記事のように id-token: write の権限を付与して、npm publish コマンドを npm publish --provenance に変更するだけで対応が可能。あとは npm や GitHub がいい感じにやってくれます。
semantic-release や pnpm を使用している場合でも対応は複雑ではなく、npm のドキュメントにある「Using third-party package publishing tools」の通り、id-token: write の権限を付与するのに加えて、環境変数 NPM_CONFIG_PROVENANCE に true を設定してあげるだけ。対応した際のプルリクエストは以下です。
最初、NPM_CONFIG_PROVENANCE: true を追加するだけではうまくいかなかったのですが、エラーを見てみると package.json の repository.url に GitHub のリポジトリの URL が指定されていないという内容が出力されていました。package.json の記述、ちょいちょい何かしら漏れがち。
ワークフローを書き換えたら、あとはその書き換えたパッケージ公開のワークフローを実行するだけ。試しに新しいバージョンをリリースしてみると、ちゃんと欲しかった認証済みバッジみたいなやつがバージョン横に付いており、README の下には新たに「Provenance」という項目が増えていました。
GitHub Actions でパッケージを公開しているパッケージはたくさんあると思うので、たった数行ワークフローに追加するだけで付けられるならやっておいたほうが良さそう。複雑な仕組みを理解して実装して…ということをしなくても導入できるのが素晴らしいですね。