Postman：依存パッケージ経由でCIの公開用トークンを悪用

原因・対策の仮説

以下は編集者の仮説です。事故の確定原因や、公表された対応とは分けています。支持・反証の観測は、これから調べる項目であり、取得済みの証拠ではありません。

1. 対策仮説 1 未検証

   レビュー済みのlockfileと固定インストールで、CIが意図せず新しい感染版を取得する機会を減らせる可能性があります。

   一次資料から確認した出発点

   同社は、適切なlockfileを欠くビルドが感染版を取り込んだと説明しています。

   [s1]How did it happen?

   成立条件・検証の観測・限界を読む

   成立に必要な条件

   • 承認済みの依存版が感染しておらず、lockfileの変更もレビューされる場合。

   仮説を支持する観測

   • CI設定と自分の隔離環境のビルド記録で固定インストールを確認し、manifestとの不一致が黙って解決されず失敗する。

   仮説を見直す観測

   • lockfileが無視・再生成される、または承認されたlockfile自体に感染版が含まれる。

   判断の限界

   • lockfileはコードの安全性を証明しません。依存更新の検証や公開権限の制限も必要です。

   関連する点検

   • SEC-001
   • SEC-007

2. 対策仮説 2 未検証

   依存コードを実行するCIから常設の公開用トークンを外し、公開ジョブの権限を限定すると、感染後の再配布を抑えられる可能性があります。

   一次資料から確認した出発点

   感染したビルドが公開用トークンを悪用しました。同社はトークン失効とOIDCへの移行を公表しています。

   [s1]How did it happen? / What we have already done

   成立条件・検証の観測・限界を読む

   成立に必要な条件

   • ビルドと公開を分離でき、OIDCの発行条件を特定の承認済みワークフローに限定できる場合。

   仮説を支持する観測

   • workflowの権限と公開元の設定で常設トークンがなく、承認されたジョブ以外に公開権限が発行されないと確認できる。

   仮説を見直す観測

   • 依存コードを実行する同じジョブで公開権限を使える、または旧トークン・別workflowでも公開できる。

   判断の限界

   • OIDCへの置換だけでは不十分です。許可された公開ジョブやその成果物が改ざんされれば再配布のリスクが残ります。

   関連する点検

   • SEC-004
   • SEC-005
   • SEC-007

この事例のAI向け資料を読む ↗