Security Copilot: 12 AI Prompts for Code Audit, Threat Hunting, and Incident Response

Security Copilot: 12 AI Prompts for Code Audit, Threat Hunting, and Incident Response

Security teams are drowning in alerts, code changes, and compliance requests. AI assistants can help — but only if you ask the right questions. A generic "find bugs in this code" prompt returns noise. A well-structured prompt that specifies the threat model, the framework, and the expected output format returns something you can actually act on.

This collection is built from real DevSecOps workflows: static analysis triage, dependency scanning, threat modeling, pentest planning, log analysis, and post-mortem drafting. Each prompt is copy-paste ready and references real tools and standards — OWASP, NIST, CWE, MITRE ATT&CK, CVSS, and RFCs where relevant. No invented formats, no fake statistics.

Use these as starting points. The best results come when you paste actual code, logs, or scan output into the prompt context.

1. Secure Code Review with Threat Context

When to use: During pull-request review when you need a second pair of eyes on authentication, authorization, or input handling logic. This prompt forces the model to reason about the threat model before listing issues.

Prompt:

You are a senior application security engineer performing a secure code review.

Context:
- Language/framework: {e.g., Python 3.12 + FastAPI}
- Component: {e.g., user authentication endpoint}
- Trust boundary: {e.g., internet-facing, handles PII}
- Relevant standard: OWASP Top 10 2021, CWE

Task:
1. Identify security issues in the code below.
2. For each issue, output a table row with: CWE ID, severity (Critical/High/Medium/Low), location (file:line), and a one-line fix.
3. Flag any issue that maps to OWASP Top 10 2021 categories.
4. Do NOT suggest fixes that change public API contracts unless you explicitly mark them as breaking.

Code:

{paste code}

Example output snippet:

Tip: Paste only the relevant function, not the whole repo. The model's attention degrades with large inputs.

2. Dependency Vulnerability Triage

When to use: After npm audit, pip-audit, govulncheck, or Dependabot produces a wall of CVEs. This prompt helps prioritize by exploitability, not just CVSS score.

Prompt:

You are a vulnerability management analyst.

I have the following dependency scan output:

{paste output from pip-audit / npm audit --json / govulncheck}

My environment: {e.g., internet-facing web app, no user-supplied packages, Node 20}

Task:
1. Rank each finding by realistic exploitability in MY environment, not by raw CVSS.
2. For each, state: is it reachable? Is there a public exploit? Is a fix available?
3. Group findings into: Patch Now, Patch This Sprint, Accept Risk (with justification), False Positive.
4. Output as a Markdown table.

Why it works: CVSS base scores ignore context. A CVSS 9.8 in a dev-only tool is less urgent than a CVSS 6.5 in an auth path. The prompt forces context-aware triage.

3. Threat Modeling with STRIDE

When to use: Before building a new service or feature. STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a proven framework from Microsoft's threat modeling methodology.

Prompt:

Act as a threat modeling facilitator using the STRIDE framework.

System description:
{describe the system: components, data flows, trust boundaries, external actors}

Task:
1. Enumerate assets and trust boundaries.
2. For each STRIDE category, list concrete threats with: threat description, affected component, likelihood (Low/Med/High), impact (Low/Med/High).
3. Propose one mitigation per threat.
4. Highlight the top 3 threats that need immediate design changes.

Output as a Markdown table plus a short prioritized list.

Example: For a file-upload service, Spoofing → attacker uploads file with forged MIME type; mitigation → validate magic bytes server-side, not just Content-Type.

4. SAST Finding Triage

When to use: When Semgrep, CodeQL, or SonarQube returns hundreds of findings and you need to separate real bugs from noise.

Prompt:

You are triaging static analysis findings from {Semgrep/CodeQL/SonarQube}.

Rule that fired: {rule ID and description}
Code snippet:

{paste snippet}

Task:
1. Is this a true positive or false positive? Explain your reasoning step by step.
2. If true positive, describe a concrete exploit scenario.
3. If false positive, explain which sanitizer, framework feature, or control makes it safe.
4. Suggest a code change that removes the finding without weakening security.

Tip: For Semgrep, include the rule's pattern and message fields — the model uses them to reason about intent.

5. Pentest Plan Generator

When to use: Scoping an authorized penetration test. Always ensure you have written authorization before testing.

Prompt:

You are a penetration tester preparing a scoped engagement.

Target: {web app / API / network range}
Scope: {in-scope assets}
Out of scope: {exclusions}
Rules of engagement: {time windows, rate limits, forbidden techniques}

Task:
1. Map the target to MITRE ATT&CK tactics relevant to this scope.
2. Produce a test plan with phases: Recon, Enumeration, Exploitation, Post-Exploitation, Reporting.
3. For each phase, list 3-5 concrete techniques and the tools typically used (e.g., nmap, Burp Suite, ffuf, sqlmap).
4. Define stop conditions — what triggers an immediate halt and report.

Output as a structured Markdown checklist.

Important: This is planning support only. Never run a pentest without signed authorization and defined scope.

6. Incident Response Playbook Draft

When to use: When a real incident is unfolding and you need a structured response, aligned with NIST SP 800-61 (Computer Security Incident Handling Guide).

Prompt:

You are an incident responder following NIST SP 800-61 phases: Preparation, Detection & Analysis, Containment, Eradication & Recovery, Post-Incident Activity.

Incident summary:
{what we know so far: alerts, affected hosts, timeline}

Task:
1. Draft an immediate containment plan (short-term and long-term).
2. List evidence to preserve (volatile first: memory, network connections, running processes).
3. List 5-7 investigative questions to answer next.
4. Draft a stakeholder update (3-4 sentences, no jargon).

Tip: Preserve volatile evidence first — memory and network state disappear on reboot. Reference NIST SP 800-61r2 for formal handling procedures.

7. Log Analysis and Anomaly Hunting

When to use: When you have raw logs (auth logs, web server logs, cloud audit logs) and need to spot suspicious patterns quickly.

Prompt:

You are a SOC analyst reviewing logs for signs of compromise.

Log source: {e.g., nginx access logs, AWS CloudTrail, Linux auth.log}
Time window: {start-end}

Logs:

{paste logs}

Task:
1. Identify anomalies: unusual IPs, user agents, request patterns, error spikes.
2. Map suspicious behavior to MITRE ATT&CK techniques where possible.
3. For each anomaly, rate confidence (Low/Med/High) and suggest a next investigative step.
4. Output as a table: timestamp, indicator, ATT&CK technique, confidence, next step.

Example indicator: Many 401 responses from a single IP against /login in a short window → possible credential stuffing → ATT&CK T1110 (Brute Force).

8. Secure SDLC Checklist Generation

When to use: When setting up or auditing a Secure SDLC process for a team or project.

Prompt:

Act as a DevSecOps lead designing a Secure SDLC.

Context:
- Team size: {e.g., 8 engineers}
- Stack: {languages, CI/CD platform}
- Compliance needs: {e.g., SOC 2, ISO 27001, PCI DSS}

Task:
1. Map security activities to SDLC phases: Requirements, Design, Implementation, Testing, Deployment, Operations.
2. For each phase, list concrete gates: what must be true before moving on.
3. Recommend tooling per gate (e.g., SAST: Semgrep; SCA: Dependabot; secrets: gitleaks).
4. Flag which gates are mandatory vs. recommended for our compliance target.

Output as a Markdown table: Phase

| Activity | Gate | Tooling | Mandatory?

9. IaC Security Review (Terraform / Kubernetes)

When to use: Reviewing infrastructure-as-code before applying it. Common tools: Checkov, tfsec, kube-linter.

Prompt:

You are reviewing infrastructure-as-code for security misconfigurations.

Platform: {Terraform / Kubernetes / CloudFormation}
Compliance target: {e.g., CIS Benchmarks, PCI DSS}

Code:

{paste IaC}

Task:
1. List misconfigurations with: resource, issue, CIS control reference (if applicable), severity.
2. For each, provide a corrected snippet.
3. Flag any resource that exposes data publicly by default.
4. Note which issues would be caught by Checkov/tfsec and which require manual review.

Example: A Terraform S3 bucket without server_side_encryption_configuration and with acl = "public-read" → two findings: missing encryption, public exposure.

10. Cryptographic Review

When to use: When reviewing code that handles keys, hashing, encryption, or token generation.

Prompt:

You are a cryptography reviewer.

Code:

{paste code}

Context: {language, library versions, use case}

Task:
1. Identify cryptographic weaknesses: weak algorithms, bad modes, insecure randomness, key reuse, missing authentication.
2. Reference the relevant standard: NIST SP 800-57 (key management), NIST SP 800-38 (modes), RFC 8018 (PKCS #5) where applicable.
3. For each issue, provide a safe alternative with a code example.
4. Flag any use of deprecated algorithms (MD5, SHA-1 for signatures, DES, ECB mode).

Why it matters: ECB mode leaks patterns; MD5 and SHA-1 are broken for collision resistance. Always prefer AEAD modes (AES-GCM, ChaCha20-Poly1305) for encryption with integrity.

11. Phishing Email Analysis

When to use: When a user reports a suspicious email and you need a fast triage.

Prompt:

You are a security analyst triaging a reported phishing email.

Email headers:

{paste raw headers}

Body (text only):

{paste body}

Task:
1. Check SPF, DKIM, and DMARC alignment results from the headers (Authentication-Results).
2. Identify spoofing indicators: display-name mismatch, reply-to mismatch, lookalike domains.
3. Extract all URLs and describe where they lead (do NOT visit them).
4. Verdict: Phishing / Suspicious / Legitimate, with reasoning.

Note: SPF, DKIM, and DMARC are defined in RFC 7208, RFC 6376, and RFC 7489 respectively. Always verify alignment, not just pass/fail.

12. Post-Incident Report Draft

When to use: After an incident is resolved, to produce a structured write-up for stakeholders and future reference.

Prompt:

You are drafting a post-incident report following NIST SP 800-61 structure.

Incident facts:
{timeline, affected systems, root cause, actions taken, current status}

Task:
1. Write sections: Summary, Impact, Timeline, Root Cause, Detection, Response, Lessons Learned, Action Items.
2. For Action Items, assign owner roles (not names) and priority.
3. Keep the Summary under 150 words and free of jargon.
4. Flag any gap in the timeline that needs more investigation.

Output in Markdown.

Tip: Blameless post-mortems produce better action items. Focus on system and process gaps, not individuals.

Making These Prompts Actually Work

Three rules separate useful AI output from noise in security work:

1. Give context, not just code. The model needs the trust boundary, framework, and threat model to reason correctly. Without them, it defaults to generic advice.

2. Constrain the output format. Tables with fixed columns (CWE, severity, location, fix) are actionable. Free-form paragraphs are not.

3. Verify everything. AI can hallucinate CVE numbers, misattribute CVSS scores, or invent CWE IDs. Cross-check every finding against the official source: cve.org, nvd.nist.gov, cwe.mitre.org, and the vendor advisory.

AI is a force multiplier for security teams, not a replacement for judgment. It accelerates triage, drafting, and pattern-spotting — but the final decision on risk acceptance, scope, and disclosure stays with humans. Start with one prompt from this list, adapt it to your stack, and measure whether it saves time or just adds review overhead. The teams that win with AI in security are the ones that treat prompts like code: versioned, tested, and continuously improved.