Study session / AI coding security

AI開発の
公開前セキュリティ監査入門

Codex × Cloudflare公式「security-audit」スキルで、
“動くけど危ない”を公開前に見つける。

← → キーで操作
Today’s goal

今日、持ち帰るもの

1

なぜ必要?

AI開発で生まれやすい公開前リスクを理解する。

2

何ができる?

スキルが調べる範囲と成果物を把握する。

3

どう使う?

導入・監査・結果確認・修正の流れを知る。

4

どう判断?

AIの報告を鵜呑みにせず、優先順位を決める。

Why now?
AIコーディングで増えたのは、
「作れる人」だけではない。
「確認せず公開できる人」も増えた。
The blind spot

「動く」と「安全」は別

動作確認で分かること

  • 画面が開く
  • ログインできる
  • データを保存できる
  • AIの回答が返る
🛡️

監査で見ること

  • 他人のデータも見えないか
  • 権限を回避できないか
  • 秘密情報が漏れないか
  • APIを使い放題にできないか
正常な操作が成功するだけでは、攻撃的な操作を防げる証明にはならない。
Typical risks

AI開発で見落としやすい5領域

① 認証・認可

ログイン確認だけで、操作権限を確認していない。

② 他人のデータ

URLやIDを変えると別ユーザーの情報に届く。

③ 秘密情報

APIキーや強いDB権限がブラウザ側やGitに露出。

④ 入力・ファイル

入力値、アップロード、表示内容の検証不足。

⑤ APIの乱用

回数制限がなく、AI料金や処理資源を消費される。

+ 配置設定

WAF、環境変数、DBポリシーなどコード外の設定。

Three roles

Codex・スキル・プロンプトの違い

🤖

Codex

作業する人

コードを読み、道具を使い、結果をまとめる。

📘

security-audit

監査手順書

調査、検証、分類、報告のやり方を定義する。

📝

監査プロンプト

今回の依頼書

対象、範囲、禁止事項、出力条件を指定する。

プロンプトを貼るだけではスキルはインストールされない。事前導入が必要。
What is a skill?

スキル=再利用できる専門ワークフロー

SKILL.md
判断基準・手順
参照資料
攻撃分類・検証法
スクリプト
成果物の検証
再現性のある監査
毎回長い指示をゼロから考えるのではなく、同じ基準・同じ形式で繰り返せる。
Where to install

導入場所は「使う範囲」で決める

使い方配置向いている状況
自分の複数プロジェクトで使う$HOME/.agents/skillsこたさんのMacで共通利用
特定プロジェクトだけで使う.agents/skillsチームでGit管理したい
共有環境の標準として使う/etc/codex/skills管理者が共通設定する
MacのローカルCodexとクラウド側の実行環境は別。Macに入れただけで、すべての環境に入るわけではない。
Install

公式リポジトリから導入

# プロジェクト単位で導入 npx skills add https://github.com/cloudflare/security-audit-skill \ --skill security-audit # 自分の複数プロジェクトで使う(ユーザー共通) npx skills add https://github.com/cloudflare/security-audit-skill \ --skill security-audit \ --global
GitHubのForkや、自分のリポジトリへの丸ごとコピーは通常不要。
Six phases

監査は6段階で進む

1

構造把握

境界・入力・構成を地図化

2

脆弱性探索

担当を分けて候補を探す

3

候補検証

別の担当が反証を試みる

4

構造化

3つの判定に分類

5

独立再確認

最終主張を再検証

6

報告

人が読めるレポートへ

Reconnaissance

最初に「攻撃される入口」を地図化

アプリ構成

Next.js、DB、OAuth、決済、AI API、ストレージ、外部サービス

信頼境界

未ログイン/一般ユーザー/管理者/サーバー/外部サービス

入力面

URL、フォーム、ファイル、Webhook、API、AIへのプロンプト

コード外の制御

DBポリシー、WAF、環境変数、デプロイ設定、IAM

Example

「ログイン済み」だけでは足りない

// 危険な例:ログインだけ確認 if (!session.user) return unauthorized() return db.profile.find({ id: params.userId }) // 必要な考え方:対象データの所有者も確認 const profile = await db.profile.find({ id: params.userId }) if (profile.userId !== session.user.id) return forbidden() return profile
URLのIDを書き換えるだけで他人の情報に届く問題は、Broken Access Control/IDORの典型。
Verdicts

「怪しい」と「確認済み」を分ける

confirmed

問題を確認

根拠となるコード経路と、境界を越えた結果が揃っている。

needs_validation

追加確認が必要

具体的な疑いはあるが、設定や安全な検証環境など決定情報が足りない。

rejected

候補を棄却

調べた結果、境界違反ではない、または別の制御で防がれている。

重大度が付くのは原則としてconfirmedだけ。needs_validationは「低い危険度」ではなく「未確定」。
Profiles

quick・standard・deepの違い

プロファイル向いている場面特徴注意
quick小規模、再監査、最初の確認探索1波+最終批評1回部分的なカバレッジ
standard通常の公開前監査標準の6段階を実施quickより時間・計算量が増える
deep高リスク・大規模システム領域を細分化し、独立検証を強化最も重い
quick=安全証明ではない。範囲と反復を絞るだけで、問題をconfirmedにする証拠基準は下げない。
Safe execution

なぜ「本番を攻撃しない」のか

禁止するもの

  • 本番URLへの攻撃的アクセス
  • 顧客の実データ利用
  • 本物の秘密鍵・APIキーの使用
  • 有料APIを消費する検証
  • 共有環境を止める試験

安全な代替

  • ソースコード中心の調査
  • ダミーユーザーと偽データ
  • 外部通信を遮断した隔離環境
  • 最小限のローカル再現
  • 検証不能なら未確定として残す
隔離条件を満たせないなら実行しない。無理に確定させず、needs_validationにする。
What you receive

監査後に作られる成果物

REPORT.md

結論、件数、優先順位、監査範囲を読む入口。

FINDINGS-DETAIL.md

確認された問題の詳細、根拠、修正方針。

NEEDS-VALIDATION.md

追加確認が必要な事実と、安全な確認方法。

findings.json

3分類を機械処理できる形で保存。

architecture.md

構成、信頼境界、入力面の整理。

coverage-ledger.json

どこを調べ、どこが未確認かの台帳。

How to read

レポートはこの順で読む

1

実行状態

完了か、不完全終了か。

2

Confirmed

Critical/Highから確認。

3

未確認範囲

設定・外部環境・保留理由。

4

修正方針

最小変更と再発防止テスト。

「0件=安全」ではない。監査範囲・未確認・実行制約を必ず一緒に読む。
Workshop demo

勉強会で見せる実行フロー

① 対象を開く
重要データなし
② quick監査
修正禁止
③ レポート確認
3分類を読む
④ 修正計画
別タスク
デモでは、監査対象・読み込んだSKILL.md・出力先の3点を最初に表示させる。
Practice prompt 1/2

実践用プロンプト:開始条件

導入したCloudflare公式の「security-audit」スキルを使って、 現在開いているプロジェクトをquickプロファイルで監査してください。 開始時に、監査対象のプロジェクトのパスと、 実際に読み込んだSKILL.mdのパスを示してください。 スキルを読み込めない場合は、そのことを報告し、 通常のコードレビューをスキルによる監査と偽らないでください。 【今回の作業範囲】 診断とレポート作成のみです。 アプリのコード変更、依存関係の更新、コミット、 プッシュ、デプロイは行わないでください。 【重点確認】 このアプリに存在する機能について、以下を確認してください。 ・ログインと権限管理の不備 ・他人のデータを閲覧・変更できる問題 ・APIキーなどの秘密情報が公開される問題 ・入力値やファイルの扱いに関する問題 ・APIの不正利用や過剰な利用につながる問題 【実行条件】 スキルの正式な手順と検証基準に従ってください。 必要なサブエージェントや検証環境が使えない場合は、 その制約と未確認の範囲を明記してください。
Practice prompt 2/2

実践用プロンプト:安全と報告

本番環境や外部サービスへの攻撃的なアクセスは禁止です。 本番用の.env、秘密鍵、顧客の実データは読み込まないでください。 秘密情報を見つけても、その値を回答やレポートに転記しないでください。 対象コードを実行する検証は、スキルが要求する隔離条件を 満たす場合だけ行ってください。 満たせない場合は実行せず、検証できなかった理由を残してください。 【報告】 監査成果物は、スキル標準のプロジェクト外の保存先に作成してください。 レポート本文とチャットでの説明は日本語にしてください。 confirmed、needs_validation、rejectedを区別し、 未監査・検証不能の範囲も明記してください。 最後にチャット上で、 「確認された問題」「追加確認が必要な点」「修正の優先順位」 を、専門用語を補足しながら説明してください。 確認された問題には、該当ファイル・行番号・根拠・修正方針を示してください。 今回は修正せず、レポートの保存先を案内して終了してください。
Operational rule

安全な運用は「3タスク分離」

1. 調べる
コード変更なし
2. 修正計画
影響範囲を確認
3. 修正する
テスト+差分レビュー
「全部見つけて全部直して」と一度に丸投げすると、問題の根拠と変更理由を追いにくい。
Kota’s use cases

こたさんの開発では、ここで使える

コミュニティツール

ロール・管理者権限・他会員データ・招待URL

Discord/Slack連携

Botトークン、Webhook、コマンド権限、なりすまし

Google Workspace連携

OAuth権限、共有範囲、GAS Webアプリの実行者

予約システム

他人の予約、Meet URL、個人情報、キャンセル権限

AIアプリ

API料金乱用、プロンプト注入、出力の安全な表示

ポイント・投票

二重付与、本人確認、権限昇格、集計改ざん

Limits

このスキルだけでは足りない

保証できないこと

  • 脆弱性がゼロである保証
  • 本番設定の自動確認
  • 法令・契約・個人情報保護の完全判断
  • 設計上の事業リスクの最終判断

人間が担うこと

  • 対象範囲と重要データの定義
  • 未確認項目の担当者確認
  • 修正優先順位と公開判断
  • 重大案件での専門家レビュー
AI監査は「公開判断を助ける材料」。最終責任をAIへ移す仕組みではない。
Takeaway
作る → 動かす → 監査する → 直す → 再監査 → 公開

security-auditの価値は「AIが全部守ってくれる」ことではない。
公開前に、安全性を確認する工程を再現可能にすること。

最初の一歩:重要データのない小さなアプリで、quick監査を一度最後まで通す。
1 / 24