セキュリティのプロンプト15選

脆弱性レビュー・脅威モデリング・設定監査・インシデント対応など、守る仕事で使える指示文。ChatGPT・Claude にそのまま貼り付けて使えます。全文公開・登録不要で、 コピーボタンから1クリックで持ち出せます。

[組織規模・取り扱いデータの感度]に応じた脆弱性開示プログラム（VDP / Bug Bounty）：
・公開ポリシー（Safe Harbor / 対象範囲 / 報奨）
・報告チャネル（security.txt / Email / プラットフォーム）
・トリアージ SLA
・社内のエスカレーションパス
・公開タイミングの判断
・誤報・恫喝への対応

最初の 90 日のロードマップ。

[サービス特性・ユーザー数]に対するログイン異常検知：
・新規デバイス／場所からのログイン通知
・短時間多発ログインのレートリミット
・地理的不可能性（地理ジャンプ）
・パスワードリスト攻撃の検知
・ユーザー向け通知文（過剰通知の回避）
・運用側ダッシュボード

誤検知でユーザーを苛立たせない閾値設計。

[使用言語スタック・配布形態]に応じた SBOM（Software Bill of Materials）運用：
・生成（CycloneDX / SPDX）
・保管と提示（顧客監査要求）
・脆弱性照合（OSV / NVD）
・License compliance（GPL / AGPL の伝播）
・トランジティブ依存の可視化
・廃止依存・メンテナ不在の検知
・SLSA / Sigstore による署名

『大量の依存をどう減らすか』の議論にもつなげる。

[対象スコープ・想定脅威]に対するペンテスト依頼仕様：
・Black / Grey / White Box の選択
・対象環境（本番 vs ステージング）
・テスト不可行為（DoS / 顧客データ）
・成果物（報告書様式・CVSS / 是正期限）
・ベンダー選定基準（経験／資格／参考）
・社内体制とコミュニケーション
・是正後の再テスト

過去の指摘事項の再発を防ぐ仕組みも。

<context>
[システム概要・データフロー図（DFD）／信頼境界／取り扱いデータの感度]
</context>

<task>
STRIDE フレームワークで脅威モデリングを行い、運用込みの是正計画まで出す。開発チームに丸投げしない。
</task>

<output_format>
各カテゴリ（Spoofing / Tampering / Repudiation / Information Disclosure / DoS / Elevation）について：
- 具体的シナリオ 1 つ以上（"○○の場合、攻撃者は××できる"）
- 既存対策の有無と十分性
- 残存リスク（影響 × 発生可能性、High/Med/Low）

最後に：
- 優先対応 5 件（影響大 × 発生可能性高）
- OWASP ASVS の目標レベル（L1 / L2 / L3）
- 各対応の owner と期限の置き方
</output_format>

<example>
<input>
SaaS 顧客管理。Web フロント → API Gateway → Lambda → RDS。認証は Cognito、データは PII 含む。
</input>
<output>
S(Spoofing): Cognito トークンの再利用攻撃 / 既存対策: 短寿命トークン+リフレッシュ / 残存: Med（端末紛失時の Refresh 失効が手動）
T(Tampering): Lambda 環境変数の改ざん / 既存対策: KMS 暗号化 / 残存: Low
R(Repudiation): 顧客データ削除の証跡不足 / 既存対策: なし / 残存: **High**
I(Info Disclosure): RDS スナップショット公開誤設定 / 既存対策: SCP で deny / 残存: Low
D(DoS): API Gateway レートリミット未設定 / 既存対策: なし / 残存: **High**
E(Elevation): IAM Role の "*:*" ポリシー残存 / 既存対策: 一部最小化 / 残存: Med

優先対応 5:
1. R: CloudTrail Data Events + 削除イベントの WORM 保管（owner: SRE / 2 週間）
2. D: API Gateway 使用プラン + 異常時 alarm（owner: Backend / 1 週間）
3. E: IAM ポリシー棚卸し（owner: Sec / 1 ヶ月）
4. S: 端末紛失自動失効フロー（owner: IdP担当 / 1 ヶ月）
5. T: Lambda env を Secrets Manager 経由に統一（owner: Backend / 2 週間）

ASVS L2 を目標。R/D/E が満たされれば到達可。
</output>
</example>

<context>
[現状の認証フロー図 / 利用者種別（一般 / 管理者 / API クライアント）/ セッション仕様 / 既存 IdP]
</context>

<task>
認証と認可のそれぞれを OWASP ASVS L1〜L2 に照らして監査し、是正項目を優先度付きで出す。
</task>

<output_format>
1. トークン仕様の監査（種別・寿命・保管場所・回転）
2. リフレッシュ／失効動線（端末紛失時 / アクセスキー漏えい時）
3. スコープと最小権限の達成度（実権限 vs 必要権限）
4. 水平権限昇格（IDOR）の余地
5. セッション固定攻撃・CSRF 対策
6. MFA / パスキーの導入状況と必須化判定
7. 監査ログの十分性（誰が誰の権限で何を変更したか）
8. ASVS 項目別ギャップ表 + 是正計画（短期 / 中期 / 長期）
</output_format>

<example>
<input>
B2B SaaS、Email + Password、JWT(2h) + Refresh(30d) を localStorage 保存。RBAC は admin/member/viewer の 3 種。
</input>
<output>
1. トークン: localStorage は XSS 直撃。HttpOnly Cookie + SameSite=Lax に変更すべき（短期）
2. 失効: 即時失効 API なし。Refresh の denylist + JWT に jti 必須（中期）
3. スコープ: viewer が一部 write API を呼べる。RBAC 中央化 + ロール表のリアル監査（中期）
4. IDOR: /api/teams/:id 系で actor != team の Owner チェックが一部欠落。一覧テスト追加（短期）
5. CSRF: Cookie 化に伴い CSRF token 必須
6. MFA: 任意のみ。Admin は強制必須化（短期、UX 設計込み）
7. 監査: 権限変更ログがアプリログ依存。WORM な audit_logs テーブル分離（長期）
8. ASVS L1 → 6 項目ギャップ。短期（2 ヶ月）3、中期（半年）2、長期 1
</output>
</example>

<context>
[現状の管理方法（.env / CI シークレット / Vault 等）/ 言語スタック / クラウド / 人数規模]
</context>

<task>
「.env をコミットしない」を超えた、運用込みのシークレット管理戦略を設計する。
</task>

<output_format>
1. 分類（Static / Dynamic / 鍵付き / 個人 vs サービス）
2. 保管先の選定（KMS / Secrets Manager / HashiCorp Vault / SOPS）
3. 配布方法（OIDC / Workload Identity / GitHub Actions の secrets）
4. ローテーション周期と自動化（rotate hooks）
5. 漏洩検知（コミットログ / GitHub Secret Scanning / pre-commit gitleaks）
6. 廃止プロセス（不要シークレットの定期棚卸し）
7. 人 vs サービスアカウントの分離（人は SSO、サービスは短寿命トークン）
8. 監査ログとアクセス権の最小化
</output_format>

<example>
<input>
B2B SaaS、AWS + GitHub Actions + Vercel。Stripe / SendGrid / OpenAI を呼ぶ。10 名のエンジニア、Vault 未使用。
</input>
<output>
1. 分類: Static（OpenAI/SendGrid 鍵）、Dynamic（DB 認証は Aurora IAM 経由）、鍵付き（KMS Customer Master Key）
2. 保管先: AWS Secrets Manager に統一（Stripe/OpenAI/SendGrid）。GitHub Actions は OIDC で AssumeRole
3. 配布: Vercel は OIDC で AWS から取得。ローカル開発は aws-vault + 個人 IAM
4. ローテーション: 90 日。Stripe は手動、SendGrid/OpenAI は API でローテ → Lambda で自動化
5. 漏洩検知: pre-commit に gitleaks、GitHub Secret Scanning + push protection 有効
6. 廃止: 月次で「90 日アクセスゼロ」のシークレットをアラート
7. 人/サービス分離: 個人キーは禁止、SSO 経由のロールに統一
8. 監査: CloudTrail + Secrets Manager の読み取りログを SIEM 連携
</output>
</example>

<context>
[サービス概要 / 規制要件（個情法 / GDPR / SOC2）/ 既存ログ基盤 / 利用者数 / 想定インシデント種別]
</context>

<task>
監査ログを SIEM 観点で設計する。「全部 Datadog に入れる」で終わらせず、保存期間・タンパー耐性・取り扱い権限まで降ろす。
</task>

<output_format>
1. 記録対象イベント（認証 / 権限変更 / データアクセス / 設定変更 / 削除）
2. ログスキーマ（誰が / いつ / どこから / 何を / 結果）
3. タンパー耐性（WORM / Hash Chain / 別アカウント転送）
4. 保存期間と階層化（Hot 90日 → Warm 1年 → Cold 7年）
5. 典型クエリ（不正検知 / コンプラ報告）
6. SIEM 連携（Datadog / Splunk / Wazuh / Sumo Logic）
7. アラートと通知の階層（INFO / WARN / CRITICAL）
8. 年次監査でのエクスポート形式
9. ログ自体の取り扱い権限（最小特権）と PII の扱い
10. ノイズ抑制（健全な失敗を CRITICAL にしない）
</output_format>

<example>
<input>
SOC2 Type2 取得を目指す B2B SaaS、AWS、利用者 5,000、コンプラ要員なし。
</input>
<output>
1. 対象: ログイン成功/失敗、権限変更、顧客データ READ（PII含む列のみ）、Admin API、デプロイ
2. スキーマ: actor_id, source_ip, ts, action, target, result, request_id
3. WORM: S3 + Object Lock + 別アカウントへ送信、Hash Chain で連鎖検証
4. 保存: Hot 90 日 CloudWatch、Warm S3 1 年、Cold S3 Glacier 7 年
5. クエリ: 失敗ログイン上位 IP、特権 API の昼夜比、PII 大量 READ
6. SIEM: Datadog（既存契約）、Audit Trails 機能で WORM
7. アラート: 同一 IP から 1 分 100 失敗で CRITICAL
8. エクスポート: 監査人向けに JSON + 概要 CSV
9. 権限: 監査ログ閲覧は Sec チーム + 監査人のみ、書き込み不可
10. ノイズ: 既知健全な失敗（パスワードリセット直後）を別タグ化
</output>
</example>

<context>
コンテナイメージ脆弱性スキャン結果（Trivy / Grype / Snyk いずれかの JSON または抜粋テキスト）：
[スキャン結果を貼付]

サービスの利用構造：
[該当言語スタック・想定攻撃面（外部入力 / DB / 認可境界 等）]
</context>

<task>
一般的な運用解説ではなく、貼り付けたスキャン結果に対する **具体的なトリアージ** を行う。スキャン結果が空なら『スキャン結果を貼付してください』とだけ返す。
</task>

<output_format>
1. **悪用可能性（Reachability）の絞り込み**
   - VEX（Vulnerability Exploitability eXchange）の観点で、自社コードから到達可能な Critical/High のみ抽出
   - 到達不能と判断する根拠（依存パスがテストのみ／ランタイムでロードされない 等）
2. **3 分類の対応方針**
   - 🔴 即時パッチ：理由と作業見積り
   - 🟡 次期リリースで対応：理由と期限
   - ⚪️ Risk Acceptance：許容根拠と再評価日
3. **根本対策**
   - ベースイメージ差し替え（distroless / chiseled / alpine の選択）
   - マルチステージ化や依存削減の Dockerfile 書き換え具体案
4. **影響評価**：脆弱ライブラリに依存する自社モジュール
5. **記録**：監査ログに残す項目、Allowlist の期限管理
</output_format>

<example>
<input>
Trivy 抜粋: CVE-2024-XXXX High lodash@4.17.20（フロント開発依存のみ）／ CVE-2024-YYYY Critical openssl 1.1.1（ベースイメージ）
</input>
<output>
Reachability:
- lodash@4.17.20 → 到達不能（devDependencies のテストランナー由来、本番バンドルから除外を webpack-bundle-analyzer で確認可）
- openssl 1.1.1 → 到達可（HTTPS 通信で常時使用）

対応:
- 🔴 openssl: ベースイメージを debian:bookworm-slim → distroless/base-debian12 に差替（OpenSSL 3.x）。作業 1 PR / 半日 / カナリアリリース必須
- ⚪️ lodash: Risk Acceptance（再評価日：次回 npm audit 時）

根本対策:
- Dockerfile 書き換え: マルチステージで FROM node:20-bookworm AS build → FROM gcr.io/distroless/nodejs20-debian12 AS runtime
- 副次効果: イメージサイズ 850MB → 180MB

影響評価: TLS ハンドシェイク全パス、payments-service と auth-gateway が要再テスト
</output>
</example>

<context>
- サービスの機微度（金融／医療／一般 SaaS）
- 既存認証手段とユーザー数
- 過去のインシデント（クレデンシャルスタッフィング等）
</context>

<task>
UI/UX の『ログイン画面のフロー』とは別観点で、**脅威モデルとポリシー判断** に集中する。フローや画面文言ではなく、認証要素の選定根拠と運用設計を返す。
</task>

<output_format>
1. 脅威モデル（個人攻撃／クレデンシャルスタッフィング／フィッシング／内部不正）と優先度
2. 認証要素の選定（パスワード／TOTP／プッシュ通知 MFA／WebAuthn パスキー／SMS の脅威別有効性、推奨組み合わせ、フォールバック）
3. NIST SP 800-63B 準拠の判定（最低長、複雑性ルール撤廃、Have-I-Been-Pwned 連携、強制変更の廃止）
4. リカバリ経路の脆弱性（メール／SMS／バックアップコード／ソーシャル認証）
5. アカウントロックと DoS のバランス
6. 計測・レポート指標（パスキー登録率／MFA 突破率／フィッシング検知）
</output_format>

<constraints>
UI フローや画面文言は扱わない。運用上の脅威に応じた『どの要素を要求するか』の意思決定に集中。
</constraints>

<example>
<input>
B2B HR SaaS、機微度中、ユーザー 50,000、過去 1 年でクレデンシャルスタッフィング 2 件、フィッシング 1 件。
</input>
<output>
1. 脅威優先度: クレデンシャルスタッフィング(高) / フィッシング(高) / 内部不正(中)
2. 推奨: パスキー必須 + 移行期は TOTP 併用、SMS は廃止（SIM スワップ脅威）
3. NIST: 12 文字以上、複雑性撤廃、HIBP API 連携、定期変更廃止
4. リカバリ: バックアップコード（オフライン保管）+ 認証済み端末からの再ログインのみ。メール再設定は管理者承認
5. ロック: 10 失敗で 5 分ロック、IP 単位レート、ユーザー単位は緩め（DoS 防止）
6. 指標: パスキー登録率目標 70% / MFA 突破率（不審ログイン後の MFA 失敗）/ Phishing alert
</output>
</example>

<context>
[想定インシデント種別（漏洩／改ざん／DoS／内部不正）／組織体制（人数・地域）／取扱データの規制（個情法 / GDPR / HIPAA）]
</context>

<task>
パニック時に開いて使えるプレイブックを作成する。曖昧な指示はそのまま機能しないので、最初の 30 分・2 時間・24 時間で何を誰がやるかまで降ろす。
</task>

<output_format>
1. 初動 30 分: 役割分担（Incident Commander / Comms / Tech / Legal）と最初の連絡経路
2. 2 時間以内: エビデンス保全（ログ・メモリダンプ・スナップショット）と封じ込めの第一歩
3. 24 時間以内: 影響範囲の確定、外部通知の必要性判断、暫定回避策
4. 短期封じ込め vs 恒久対策の分離
5. 社内コミュニケーション原稿（経営／全社／関連部署）
6. 社外コミュニケーション原稿（顧客／規制当局／メディア）
7. 規制報告のチェックリスト（個情法 72h ルール / GDPR）
8. ポストモーテムへの引き継ぎ項目
9. 訓練（Tabletop）の頻度と進め方
</output_format>

<example>
<input>
B2B SaaS、顧客データ漏洩シナリオ。日本＋EU で運営、個情法 + GDPR 適用。エンジニア 30 名。
</input>
<output>
30 分:
- IC: SRE オンコール。Comms: PR マネージャー。Tech: 該当サービスチームリード。Legal: 顧問弁護士
- Slack #incident-room を開設、ステークホルダー召集
2 時間:
- アクセスログを WORM ストレージへ即コピー、本番 RDS スナップショット取得
- 被害アカウントの権限剥奪・該当キーローテ
24 時間:
- 影響顧客リスト確定 → CS 通知準備、規制報告必要性判定
原稿（顧客）: 「事実 / 影響 / 当面の対策 / 質問先 / 続報日時」を明記
規制: 日本個情法は知った時から速やか、GDPR は 72h
PM 引き継ぎ: タイムライン、根本原因（5 Whys）、再発防止
訓練: 半年に 1 回 Tabletop、内容を毎回更新
</output>
</example>

<context>
[サービス概要 / 依存サードパーティ（広告 / 分析 / CDN / 認証）/ 既存 CSP の有無 / SPA か MPA か]
</context>

<task>
XSS の被害をゼロに近づける CSP を運用込みで設計する。一気に厳格化せず、Report-Only から段階導入する。
</task>

<output_format>
1. Strict CSP（nonce / hash）の導入可否と方針
2. Report-Only での段階導入プラン
3. サードパーティ問題の解消順序（広告系・分析系の置換）
4. unsafe-inline / unsafe-eval の最終撤去計画
5. Reporting API でのモニタリング設定
6. 関連ヘッダ（COOP / COEP / Permissions-Policy / X-Frame-Options）
7. 段階リリースの観測指標と中止条件
8. 既存コード側のリファクタ箇所（インラインスタイル等）
</output_format>

<example>
<input>
B2B SaaS、Next.js App Router、Google Analytics + Sentry + Stripe Checkout。CSP 未設定。
</input>
<output>
1. Strict CSP（nonce ベース）。Next.js 14+ は middleware で nonce 注入可
2. Report-Only を 2 週間 → 違反 0 を確認 → enforce
3. サードパーティ順序:
   - GA4: gtag.js を nonce 化、img-src / connect-src を許可
   - Sentry: connect-src ingest.sentry.io、script-src で SDK
   - Stripe: frame-src js.stripe.com / connect-src api.stripe.com
4. unsafe-eval: 既存依存を audit、tailwind/JS の eval 使用箇所を排除
5. Reporting API: report-uri /csp-report 経由で Datadog Logs
6. 併用: COOP same-origin / COEP credentialless / Permissions-Policy 最小許可
7. 観測: 違反レポート数、ユーザー影響なし → 段階拡張
8. リファクタ: インライン onclick を addEventListener 化、CSS-in-JS の inline style を CSS モジュール化
</output>
</example>

<context>
[現状のセキュリティ運用 / 取得したい認証（SOC2 Type1/Type2 / ISO27001）/ 取得期限 / 組織規模 / 既存ツール（IdP / MDM / SIEM）]
</context>

<task>
ギャップを洗い出し、「タダ／少額／要投資」の 3 分類で工程表を作る。「監査人に丸投げ」ではなく自走できる粒度で。
</task>

<output_format>
1. アクセス管理（プロビジョニング／オフボーディング）
2. 変更管理（PR / IaC レビュー）
3. インシデント対応
4. ベンダー管理（リスク評価・SOC2 確認）
5. BCP / DR（RTO / RPO 定義 / 訓練）
6. 監視と監査（SIEM / ログ保管）
7. 教育と意識向上（年次研修 / フィッシング訓練）
8. 物理セキュリティ（クラウド前提でも 0 にしない）
9. ポリシー文書（情報セキュリティ・受け入れ可能利用・データ分類）
10. ギャップ分類表（タダ / 少額 / 要投資 × 期限）
</output_format>

<example>
<input>
30 名のスタートアップ、AWS、IdP は Google Workspace、SIEM 未導入、ポリシー文書なし。SOC2 Type1 を 6 ヶ月後に取りたい。
</input>
<output>
1. SCIM 連携（Google → AWS / SaaS）→ 少額（¥0〜10万）3 ヶ月
2. PR 必須レビュー + IaC で本番アクセス→ タダ 1 ヶ月
3. インシデント対応プレイブック作成 → タダ 1 ヶ月
4. ベンダー一覧と SOC2 確認 → タダ 2 ヶ月
5. BCP/DR 設計（RTO 4h / RPO 1h）+ 半年訓練 → 少額 3 ヶ月
6. SIEM: Datadog Audit Trails 既存契約活用 → 少額 1 ヶ月
7. 年次セキュリティ研修動画 → タダ 1 ヶ月
8. オフィス入退室記録 → タダ 1 ヶ月
9. ポリシー雛形 + 法務レビュー → 少額 2 ヶ月
10. 工程表:
   - タダ: 4-6 項目、3 ヶ月以内
   - 少額: SCIM / SIEM / 法務、3-5 ヶ月
   - 要投資: なし（Type1 は現体制で可、Type2 で MDM 検討）
   - 監査人選定: 3 ヶ月目 / 監査開始: 5 ヶ月目
</output>
</example>

<context>
[組織規模 / 職務分掌 / 取扱情報の機微度 / 既存のログ・アクセス管理]
</context>

<task>
内部不正検知を、社員の信頼を損なわず冤罪も生まない形で運用設計する。
</task>

<output_format>
1. 検知対象（特権操作 / データエクスポート量 / 営業・CS の過剰アクセス / 退職前の異常行動）
2. ログ収集と相関分析（SIEM / UEBA）
3. 分掌の徹底（最小権限・二重承認・職務分離）
4. 通報窓口（社内匿名 / 外部第三者）
5. 冤罪を生まないプロセス（複数指標一致 → 人手レビュー → 本人聴取）
6. 監視の透明性をユーザー（社員）に説明する文面
7. 検知から対応までのタイムライン
8. 法務・人事との連携プロトコル
</output_format>

<context>
- AI が生成した差分（PR）：[コード貼付]
- 静的解析の警告（Semgrep / CodeQL / ESLint Security / Bandit など）：[出力貼付]
- 依存追加があれば SCA 結果（npm audit / Snyk / OSV）：[出力貼付]
- 想定される攻撃面（外部入力 / DB / 認可境界）：[テキスト]
</context>

<task>
LLM 単独で『安全です』と偽陰性を返すリスクを避けるため、添付された静的解析・SCA 結果をアンカーに具体的な脆弱性レビューを行う。アンカーが添付されていない場合は『最低限 Semgrep か該当言語の SAST 出力を添付してください』と返す。
</task>

<output_format>
1. **静的解析の各警告に対する判定**
   - True Positive / False Positive / 要追加調査
   - False と判断する場合は具体的な根拠（到達不能・サニタイズ済み 等）
2. **静的解析が拾えていない可能性のある脆弱性**
   - 認可漏れ（IDOR）／SSRF／TOCTOU／暗号誤用／Prototype Pollution など
   - 検出には実行時挙動が必要なものを明示
3. **AI 生成特有の落とし穴**
   - 古いライブラリAPIの幻覚的呼び出し
   - 存在しない関数・パッケージの import
   - サンプルコードからの逐語コピー（ライセンス警戒）
4. **テストの不足箇所**（特に認可境界テスト）
5. **修正後の再検証手順**
</output_format>

<example>
<input>
PR: Express ルートに /api/users/:id を追加、req.user.id チェックなし。
Semgrep 警告: javascript.lang.security.audit.express-cookie-session-no-secret.express-cookie-session-no-secret
</input>
<output>
1. 静的解析判定:
   - express-cookie-session-no-secret: True Positive。本番ENV側で secret が空のままマージされる
2. 静的解析が拾えていない:
   - **IDOR（Critical）**: /api/users/:id で req.user.id と :id の一致チェックがない。任意のユーザーIDで他人情報を取得可能
   - SSRF: 該当なし
3. AI生成落とし穴:
   - express-validator のメソッド param().isUUID() を使っているが該当バージョンに存在しない（v6 の API、本リポは v7）
4. テスト不足: 認可境界テスト（他ユーザーのID渡したら 403）が無い
5. 再検証:
   - IDOR: middleware に requireOwnership を追加 → e2e で 403 を確認
   - secret: vault 連携で必須化、CI で空時に fail
</output>
</example>