1.0.0 サイクルのセキュリティレビューで Major として挙がり、未対処のまま残っているもの。
現状(実測 2026-08-26)
.github/workflows/deploy.yml:9-10
permissions:
contents: write
なぜ問題か
GitHub Pages への配備であれば、必要な権限は pages: write + id-token: write であり、contents は read で足りる。contents: write はリポジトリの中身を書き換えられる権限であり、workflow 内で実行される任意のコード(依存パッケージの postinstall を含む)がそれを使える。
やること
permissions:
contents: read
pages: write
id-token: write
配備方式が peaceiris/actions-gh-pages 系(gh-pages ブランチへ push)である場合は contents: write が必要なので、その場合は公式の actions/deploy-pages へ寄せるかどうかから判断する。まず現行の配備方式を確認すること。
関連
Harumi にも同一の設定がある(.github/workflows/deploy.yml:9-10 が contents: write)。→ code4history/Harumi#8
出どころ
1.0.0 サイクルのセキュリティレビュー docs/superpowers/reviews/2026-08-25-cycle1-maplat-1-0-release-security-review-v1.md。「次のトレインで」として申し送られた。
1.0.0 サイクルのセキュリティレビューで Major として挙がり、未対処のまま残っているもの。
現状(実測 2026-08-26)
.github/workflows/deploy.yml:9-10なぜ問題か
GitHub Pages への配備であれば、必要な権限は
pages: write+id-token: writeであり、contentsは read で足りる。contents: writeはリポジトリの中身を書き換えられる権限であり、workflow 内で実行される任意のコード(依存パッケージの postinstall を含む)がそれを使える。やること
配備方式が
peaceiris/actions-gh-pages系(gh-pages ブランチへ push)である場合はcontents: writeが必要なので、その場合は公式のactions/deploy-pagesへ寄せるかどうかから判断する。まず現行の配備方式を確認すること。関連
Harumi にも同一の設定がある(
.github/workflows/deploy.yml:9-10がcontents: write)。→ code4history/Harumi#8出どころ
1.0.0 サイクルのセキュリティレビュー
docs/superpowers/reviews/2026-08-25-cycle1-maplat-1-0-release-security-review-v1.md。「次のトレインで」として申し送られた。