From Prompt to Patch: Turning LLMs Into a Red Team Partner That Finds Flaws Before Your Users Do

Security reviews are the task everyone agrees matters and nobody has time for. A sprint ends, a release is cut, and the audit gets pushed to "next quarter" — which is exactly the window attackers count on. Meanwhile, the LLM already sitting in your editor is a surprisingly capable first-pass reviewer: it will not replace a human pentester, but it can catch the boring, expensive mistakes (IDOR, missing auth checks, hardcoded secrets, permissive IAM) before code review even starts.

The trick is that generic prompts return generic advice. "Check this code for vulnerabilities" produces a lecture on SQL injection instead of a finding in your file. The prompts below are structured for a specific task, a specific input, and a specific output format — threat model, payload, diff, or policy. Use them as a triage layer, then verify every claim yourself against OWASP, MITRE, and the vendor docs.

The Ground Rules Before You Paste Anything

A few non-negotiables, because these prompts handle sensitive material:

• Scope and legality first. Only test systems you own or have written authorization for. Unauthorized scanning is a criminal offense in most jurisdictions, including under the U.S. Computer Fraud and Abuse Act and the UK Computer Misuse Act.
• Never paste production secrets. Redact keys, tokens, connection strings, and customer data before sending code to a third-party model. Better: run a local model for anything touching real infrastructure.
• Treat every output as a hypothesis. LLMs hallucinate CVE numbers and invent API parameters. Cross-check against nvd.nist.gov, the OWASP Top 10, and vendor advisories.
• Loop it into CI. A prompt is useful once; a prompt in a pre-commit hook or PR check is useful every day.

1. OWASP Top 10 Audit of a Single File

Task: turn a diff or file into a structured findings list mapped to the OWASP Top 10 (2021).

You are a senior application security engineer. Review the code below against the OWASP Top 10 (2021).
For each finding return: category (A01–A10), severity (Critical/High/Medium/Low), exact line reference,
why it is exploitable, and a minimal patch as a unified diff. If a category has no findings, say so explicitly.
Do not invent vulnerabilities that are not in the code. If you need more context, list the questions first.

CODE:
<paste>

Example output: A01 Broken Access Control — High — line 42: /invoices/{id} fetches by id without checking owner_id == current_user.id. Patch: add ownership check before serialization. This is the class of bug that a scanner often misses because the endpoint looks authenticated.

2. Threat Model Before the First Line of Code

Task: generate a STRIDE threat model from an architecture description.

Act as a threat modeling facilitator. Given this architecture description, produce a STRIDE table:
Threat type

| Component | Attack scenario | Likelihood | Impact | Mitigation | Owner.
Then list the top 3 assumptions that, if wrong, break the model.

ARCHITECTURE:
<paste diagram description or README>

STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is a Microsoft-originated framework — use it because it forces coverage of categories engineers forget, especially repudiation and elevation.

3. Payload Generation for Your Own Lab

Task: produce test inputs for a staging environment you control.

Generate a test-case matrix for the input field described below, targeting a staging environment I own.
Cover: boundary values, encoding tricks, and injection probes for the listed sink (SQL, shell, template, or path).
Output as a table: input

| expected safe behavior | what a failure would indicate.
Do not provide working exploit chains against third-party systems.

FIELD: <description> SINK: <sql query / subprocess / template engine>

The value is the "what a failure would indicate" column — it turns random fuzzing into a diagnostic.

4. CVE Triage Without Panic

Task: decide whether a new CVE actually affects you.

Explain CVE-<id> in plain terms: affected component and versions, attack vector, prerequisites,
and whether it is exploitable remotely without authentication. Then give a decision checklist:
1) am I affected? 2) is it reachable in my architecture? 3) patch or mitigate?
Cite the official advisory URL. If you are unsure of a detail, say so instead of guessing.

Why it matters: most CVEs drown teams in noise. The reachability question ("is the vulnerable parser actually exposed?") is where LLMs save hours.

5. Dependency Audit

Given this dependency list (name + version), flag packages with known advisories, group by severity,
and propose the smallest safe upgrade path. Output a table: package

| current | advisory | fix version | breaking-change risk.
Verify advisory IDs against the official registry; do not fabricate CVE numbers.

6. Secret Scanning and Rotation Plan

Scan the code below for hardcoded credentials, tokens, and private keys. For each hit: what it is, where it is used,
and a rotation + replacement plan (env var, secret manager, vault). Also give a regex I can add to pre-commit.

A practical follow-up: ask for a gitleaks or detect-secrets config snippet — both are real, maintained tools.

7. Docker Hardening

Rewrite this Dockerfile as a hardened multi-stage build: non-root user, pinned base image digest,
no secrets in layers, minimal final image, HEALTHCHECK. Explain each change in one line.
Then list the residual risks you cannot fix at the Dockerfile level.

Residual risks usually include kernel-level escapes and image supply-chain trust — worth knowing.

8. Kubernetes and IaC Policy Review

Review this Kubernetes manifest against the CIS Kubernetes Benchmark and Pod Security Standards (restricted profile).
Flag: privileged containers, hostPath mounts, missing resource limits, runAsRoot, wildcard RBAC.
Output a table and a corrected manifest. Note which rules belong in a policy engine (OPA/Gatekeeper, Kyverno).

9. Writing the Security Policy Nobody Reads

Draft a one-page secure-coding policy for a 10-person engineering team. Cover: secrets handling, dependency updates,
code review requirements, incident reporting. Use imperative language, no filler, max 400 words.
Include a short "what to do if you find a vulnerability" section.

10. Secure Review Inside the PR

Act as a code reviewer. Review this diff only for security regressions introduced by the change.
Comment line by line, maximum 5 comments, ordered by severity. If the diff is clean, say "no security findings".
Be concise — this goes into a pull request.

DIFF:
<paste>

The "say no findings" instruction is what stops the model from manufacturing issues to seem useful.

11. Auth and Session Logic

Trace the authentication and session flow in this code. Identify: token lifetime, revocation path,
privilege checks on each endpoint, and any path where an unauthenticated user reaches sensitive data.
Draw the attack path in text if one exists.

What This Actually Buys You

The realistic outcome is not "AI replaces the pentester." It is that the cheap, repeatable checks — secrets in code, missing ownership checks, root containers, unpinned images — get caught in minutes instead of at the next audit. The expensive human work (business-logic flaws, chained exploits, social engineering) stays where it belongs. Run these prompts as a first pass, verify every finding, and turn the ones that recur into automated checks. Your future release notes will be a lot duller, and that is the point.