チェックリストではなく“順番”が必要だ
Shai-Hulud以降、多くの開発者が
「依存パッケージを確認しよう」「CI/CDを見直そう」
そう言うようになった。
だが問題は、何を、どの順番で確認すべきかが曖昧なことだ。
セキュリティは「網羅」ではなく、優先順位で守る。
なぜなら、対策は無限に増やせるが、
攻撃者が刺す場所は限られているからだ。
本章の目的は、
“手順書ではなく判断基準” を渡すこと。
STEP 1 ─ npm（依存）を疑う：最初に触るべき領域
最も攻撃されやすい場所は、
開発者が「安全だと思い込みやすい場所」だ。
npm はその典型だ。
最初に見るべき指標
| 観点 | 例 | 理由 |
|---|---|---|
| 依存の深さ | direct vs transitive | 攻撃者は深い階層を狙う |
| maintainerのアクティビティ | last update / commit | 放置パッケージほど危険 |
| インストール時スクリプト有無 | postinstall, prepare | Shai-Hulud型の侵入口 |
実践：まずこれだけやる
npm ls --depth=3 | grep -E '(postinstall|prepare)'これは、「自分が何を信用しているかを可視化する作業」だ。
必要なのは“排除”ではなく、「意図した依存か？」の確認。
STEP 2 ─ CI/CDパイプライン：自動化の境界を引く
依存チェックは入口だが、
感染を広げるのは CI/CD（自動化）だ。
多くの攻撃者は、依存そのものより、
「その依存が持っている権限」に興味がある。
特に以下は優先して確認する：
| 項目 | 観点 | 質問すべきこと |
|---|---|---|
| GitHub Actions | token scope | 「必要以上に広くないか？」 |
| パッケージ配信権限 | npm publish rights | 「誰が本当に Publish できる？」 |
| キャッシュされた認証情報 | artifacts / runners | 「無期限に残っていないか？」 |
CI/CD は便利だ。
だがその本質は “人間を通らず権限が流れる仕組み” だ。
攻撃視点では、
CIは自動化された踏み台
ということになる。
STEP 3 ─ Secrets：最後に触るべき “最弱の鍵”
多くの組織は逆順で対策する。
秘密情報 → パッケージ → CI の順で触る。
しかし現実は、
漏洩した Secrets が危険なのではない。
自動化が Secrets を使って動くことが危険なのだ。
Secretsの棚卸しは最後でいい。
理由は明確：
- 依存が整理されていない状態で見直しても、
どの権限が“必要”なのか判断できないから。
結論：優先順位はこう固定する
① npm（依存） → ② CI/CD（権限と発火条件） → ③ Secrets（必要最小化）これは対策フローではなく、
“攻撃者の視点と一致する順番”だ。
- 入口
- 拡散経路
- 価値（トークン・権限）
守る順番は、攻撃される順番と一致しなければ意味がない。
最後に──今日やるべき最低ライン
✔ コマンドを1回
✔ CIのトークン権限を1つ見直す
✔ 意図していない依存があるか確認する
「全部」ではなく、“線を引く”ところから始める。
