セキュリティ
新しい脅威はほとんど無い。増えるのは、既知の脅威に触れる口の数。 秘密情報も依存関係も、既存のページに対策が書いてある。 変わるのはその対策を仕掛ける場所で、コードとリポジトリだけでなく、 エージェントの入出力にも同じ口ができる。
元の規範
何が崩れるか
秘密情報に、口が3つ増える
元の規範は 検出とスキャンの仕掛け先を3つ 挙げている。pre-commit フック、CI/CD パイプライン、定期スキャン。
AI 駆動では、その手前に3つ増える。
| 口 | 何が起きるか | 元の規範 |
|---|---|---|
| 読ませる | .env・鍵ファイル・認証情報を含む設定を、文脈として読み込む | 最小権限を徹底する |
| 出力させる | 読んだ値が説明・ログ・コミットメッセージに出る | パイプラインの出力から秘密が漏れないようにする |
| 貼る | 人間がプロンプトに秘密を貼る | 秘密を平文で送信しない |
**3つとも、既存の規範の適用先が増えただけ。**新しい原則は要らない。
とくに「読ませる」は仕掛けやすい。そもそも読めなくしておけば、 後ろの2つは起きない。最小権限を ファイル単位で機械的に効かせられる、珍しく素直な場面。
それでも漏れたときの手順は変わらない。 失効 → ローテーション → 削除。 「AI に読ませただけだから」は失効を省略する理由にならない。 むしろどこまで出たかを追いにくいので、前提を侵害側に寄せる方が安い。
実在しないパッケージが提案される
依存関係はこう書いている。
ほとんどの場合推移的依存先の信頼性の検証をしていない
信頼に当たらないものを使用していることが多々ある
その依存先は信頼に値するか
AI 駆動では、その手前に「そもそも存在するか」が挟まる。 自然な名前・自然な API の、実在しないパッケージが提案されうる。
実害は「動かない」ことではない。
動かないだけなら気づく。危ないのは、
サプライチェーンが挙げる
post-install スクリプトの経路と組み合わさったとき。
post-install スクリプトが攻撃面になるのは、依存を入れる行為自体が コード実行になっているため。「入れただけ」で安全ということはない。
つまり**「提案された名前をそのまま install する」が、そのまま実行になる。**
名前が実在するかどうかを、install の前に確かめる必要がある。
確かめ方は元の規範のまま。
GitHubやnpmのものか、公式のものか
利用方法が明確かどうか
後方互換性がどれくらい担保されているかどうか
(出典: 依存関係)
生成コードが、レビューを通らずに増える
脆弱な状態のサインの うち、AI 駆動で悪化しやすいのは2つ。
使っているコンポーネントのバージョンが把握できていない(直接依存も推移的依存も)
更新時の互換性テストをしていない
依存を足す費用が下がるので、足す回数が増える。 自作と利用の 「自作する場合にはどれくらい複雑でどれくらい手間がかかるか」という天秤も、 自作の側の費用が下がったことで釣り合いが変わっている。 小さな依存なら、入れずに書いた方が安いことが増える。
破壊的な操作が、確認なしで走りうる
これは既存のどのページにも無い、この階層に固有の項目。
ファイルの削除、git の履歴の書き換え、本番への接続、外部への送信は、
取り消せないか、取り消しが高い。
決定を覆せることが
効かない領域なので、事前に止めるしかない。
どう仕掛けるか
**文章で頼まない。**このページの内容は、
ハーネスに書く側の permissions と hooks にほぼ全部移せる。
| やること | 置き場所 |
|---|---|
| 秘密ファイルを読ませない | permissions.deny（コピペ） |
| 秘密のパターンをコミット前に止める | pre-commit フック + PreToolUse hook |
| 破壊的なコマンドを止める | permissions.deny と PreToolUse hook |
| 依存の実在確認 | CLAUDE.md の指示 + install を ask に落とす |
| 脆弱性スキャン | CI（元の規範のまま。変更なし） |
「AI に読ませない」と「リポジトリに入れない」は別の対策で、両方要る。 前者だけだと、人間が貼ったものは止まらない。 後者だけだと、読み込んだ値が出力に混ざるのは止まらない。
そのまま貼る
CLAUDE.md に足す。機械で止められるものは settings.json 側に置くので、
ここに書くのは「機械では判定しにくいが、守ってほしいこと」だけ。
## 秘密情報と依存
- **秘密情報を読まない・書かない・出力しない。**
`.env`、鍵ファイル、認証情報を含む設定を開かない。必要なら、
値ではなく「その値を参照している変数名」を使って進める
- **秘密の値を、説明・ログ・コミットメッセージ・テストの固定値に書かない。**
例が必要なら、明らかにダミーと分かる値を使う
- **依存を足す前に、実在と素性を確認する。**
公式のリポジトリか、更新されているか、利用方法が明確か。
確認できないものは提案するだけにして、install しない
- **依存を足す前に、足さずに書けないか考える。**
小さな機能のために依存を1つ増やすのは、たいてい割に合わない
- **取り消せない操作は、実行前に確認を取る。**
ファイルやブランチの削除、履歴の書き換え、外部への送信、本番環境への接続。
「確認を取る」は、何をどうするかを具体的に述べてから訊くこと