OSS開発者は今何をするべきか？ソフトウェアサプライチェーン侵害対策を考える
https://gyazo.com/62cba01886ad8dc47dff433f1b2799f3
脆弱なライブラリ・ソフトウェアは速やかに対処
いつの間にか中身が毒入りにならないようにする
GitHub Actionsで自動update & push
依存関係はpinしている
Cooldownも導入
今後目指すこと
仮に毒入りバージョンが入ってもすぐ検知
ネットワークレベルで遮断
少ない技術の組み合わせで多くのことを実現したい
Security fix やアップデートに関わる作業の最小化
コーディングエージェントの出力を安定しやすく
スコープを狭めることで人間の理解をより深く
セッション①：PRを取り込むのが怖くなった理由と今後
PRを取り込むのが怖くなった理由
牧歌的に楽しかった（過去）
朝起きたらリバプールのOSS共同者が対応してくれて 自分のOSSによって加害者にならないか？
サプライチェーンの攻撃経路が多い
開発者アカウントの乗っ取り
OSS作者が狙われている印象
GitHubはPRでコミュニケーション
マージで取り組むがこれは実質publishボタン
レビューしているのはコード差分だけではない
コントリビューターがどこのものなのか
botが大量にPR作ってくることもある
配布経路が狙われている
PR→cache→merge→OIDC→publish release経路につながると、PRはpublishまで届く
OSSではなく商業ソフトウェア
Issueで透明性のある運営を行う
フォーク歓迎していく
失敗も、運用も、判断基準も公開できる
依存関係 4,393
アカウント乗っ取り
偽のオンライン会議を提案
pull_request_targetによるトリガー
OIDCトークンを取得、そこからnpm publish
外部コントリビューターのアカウントをハッキング
@mastra/*の書き込み権限を持っている
easy-day-jsという偽パッケージを作成
依存関係を利用して広範囲で伝わる
セッション③：Hardening npm Publishing
なぜ公開フローを守るのか
npmは依存が深い
トークンを盗むところからCI/CDに移る
侵害されてもレジストリに公開されないようにする
攻撃者は一番弱いところを狙う
どこか１つだけ守っても他で抜かれるかもしれない
1. ローカルのToken管理
大前提としてローカルには置くな
GitHubはclassic PAT（Personal Access Token）を常用しない orgを跨ぐ場合はめんどくさい
fine-grained PATは用途ごとに分ける
1つの強いトークンを使い回さず、用途ごとに発行する
Checks APIがfine-grained未対応
2. npm
アクセストークンを0個にする
code:yml
permissions:
contents: write
id-token: write # OIDC
steps:
- uses: actions/setup-node@v5
with:
- run: npm publish --access public
build中に何が起きたかまでは保証しない
3. GitHub Actions の構成
https://gyazo.com/e12c0da823c098ed1c5e1ea90b73e655
environment: npmを参照させて、jobの実行を待機させる
https://gyazo.com/6c9d03d562bc429b2addb7c81fbfd8de
4. npm staged publishing
Approve待ちにする
課題
Approveが1パッケージずつしかできない
CLIからapproveするにはnpmトークンが要る
攻撃が成功するには、GitHubとnpmのアカウントを同時に侵害する必要がある