Turn an LLM into Your DevSecOps Engineer: 12 Battle-Tested Prompts for SAST, DAST, CVE Triage and Threat Modeling
Most teams don't skip security audits because they don't care — they skip them because a dedicated pentester is expensive, and a full SAST/DAST pipeline feels like a project of its own. Meanwhile a large language model, wired to the right prompt, can read a diff, spot a missing authorization check, explain a CVE in plain language, and draft a STRIDE threat model in the time it takes to drink a coffee.
This roundup is not about magic. LLMs hallucinate, miss context and cannot replace a real exploit run against a live target. But as a first-pass reviewer, triage assistant and documentation engine they are genuinely useful — especially if you keep them on a short leash: give them the code, the version numbers and the exact standard to check against, and always verify findings yourself.
Below are 12 prompts I use for DevSecOps work: code audits, CVE triage, security test generation, SAST/DAST in CI/CD, and threat modeling. Each comes with the task it solves and a copy-paste example.
1. The "Explain the diff" reviewer
Task: catch security regressions in a pull request before merge. This is your cheapest SAST layer — a human-readable review of what actually changed.
You are a senior application security engineer.
Review this git diff for security regressions only.
Check: authentication/authorization checks, input validation,
secrets in code, unsafe deserialization, SQL/command injection,
path traversal, logging of sensitive data.
For each finding give: file:line, severity (Critical/High/Medium/Low),
CWE ID, why it is exploitable, and a minimal fix as a code snippet.
If you see no issue, say so explicitly. Do not invent problems.
DIFF:
<diff>
Example: paste a diff that adds db.query("SELECT * FROM users WHERE id=" + req.params.id) and the model returns a High finding mapped to CWE-89 (SQL Injection) with a parameterized-query fix. It is not a substitute for Semgrep, but it catches the obvious things on a Friday afternoon.
2. Language-specific SAST pass on a single file
Task: deep review of one file where generic scanners drown in noise.
Audit this <language> file as if you were doing a manual pentest.
Focus on: injection sinks, insecure crypto (MD5/SHA1, ECB mode),
insecure randomness for tokens, SSRF via user-controlled URLs,
XXE in XML parsers, insecure deserialization, weak TLS config.
For every finding: quote the vulnerable line, assign CWE,
rate exploitability, and show a patched version of the function.
FILE:
<code>
Example: a Python file using random.randint() to build a password-reset token gets flagged as CWE-338 (Use of Cryptographically Weak PRNG) with a secrets.token_urlsafe(32) replacement. That is a real class of bug that ships to production more often than anyone admits.
3. CVE triage in 60 seconds
Task: decide whether a fresh CVE actually matters to your stack, instead of panicking at every advisory.
Act as a vulnerability analyst. Here is a CVE: <CVE-ID>.
Here is my context: <library + exact version>, deployed as <service>,
exposed to <internet/internal>, uses <feature X>.
1. Explain the vulnerability in 3 sentences for a developer.
2. State the CVSS vector and what it means practically.
3. Is my version affected? Answer yes/no/unclear with reasoning.
4. What is the minimal mitigation if I cannot upgrade today?
5. What is the fixed version?
Cite the NVD entry and vendor advisory if you know them;
if unsure, say 'verify against nvd.nist.gov'.
Example: for a Log4Shell-style report the model explains JNDI lookup abuse, names the fixed version, and suggests removing the JndiLookup class as a stopgap. Always cross-check against the official NVD page (nvd.nist.gov) and the vendor advisory — the model is a fast first reader, not the source of truth.
4. Dependency audit from a lockfile
Task: turn a wall of npm audit / pip-audit output into a prioritized plan.
Here is my dependency list with versions: <paste package.json / requirements.txt>.
Identify packages with known CVEs, prioritize by exploitability in a
web-facing service, and group results into: fix now, fix this sprint,
monitor. For each: package, CVE, fixed version, breaking-change risk.
Example: the model sorts a transitive lodash prototype-pollution issue into "fix now" and a dev-only linter CVE into "monitor", which is exactly the judgment call a busy team needs.
5. Generate security tests (not just unit tests)
Task: turn findings into regression tests so the bug never returns.
Write security regression tests for this function in <pytest/Jest>.
Cover: SQL injection payloads, XSS payloads, path traversal (../../etc/passwd),
IDOR (accessing another user's resource), and oversized input.
Each test must assert the safe behavior, not just that it doesn't crash.
Example: for an upload endpoint the model writes a test posting ../../../../etc/passwd as the filename and asserting a 400 response. These tests are cheap and catch regressions that unit tests ignore.
6. DAST plan for a running service
Task: plan a dynamic test run without a full pentest engagement.
I have a REST API at <endpoint> with these endpoints: <list>.
Draft a DAST test plan: authentication bypass, IDOR, rate limiting,
input fuzzing, HTTP verb tampering, and error-message leakage.
For each test give the exact request (method, path, headers, body)
and the expected safe response. Format as a checklist I can run in Postman.
Example: the model produces a request that swaps the userId in a JWT-protected path — the classic IDOR check — and states that a 200 with another user's data is a failure. Run it against staging, never production.
7. SAST/DAST in CI/CD: wiring the pipeline
Task: get real scanners into the pipeline with sane config.
Write a GitHub Actions workflow that runs Semgrep (SAST),
Trivy (container image scan) and OWASP ZAP baseline scan (DAST)
on pull requests. Fail the job on High/Critical findings.
Include caching and a step that uploads SARIF to GitHub code scanning.
Explain each block in comments.
Example: the output is a working .github/workflows/security.yml using returntocorp/semgrep-action, aquasecurity/trivy-action and zaproxy/action-baseline — all real, maintained actions. Review the pinned versions before merging.
8. Secrets-scanning policy prompt
Task: stop credentials from reaching git history.
Review this repo structure and propose a secrets-management policy:
where secrets should live (env vars, vault), pre-commit hooks
(gitleaks/detect-secrets), and rotation rules. Then scan this snippet
for hardcoded secrets and explain how to rotate each one.
Example: the model flags an AWS access key in a config file and walks through disabling it in IAM and moving it to GitHub Actions secrets. Treat any key it finds as already leaked.
9. STRIDE threat model from an architecture description
Task: produce a threat model before writing code, not after an incident.
Here is my architecture: <describe services, data flows, trust boundaries>.
Build a STRIDE threat model. For each category (Spoofing, Tampering,
Repudiation, Information disclosure, Denial of service, Elevation of
privilege) list concrete threats, affected components, and mitigations.
Output as a table: Threat
| STRIDE category | Component | Mitigation.
Example: for a web app + queue + worker setup the model surfaces a Tampering threat on unsigned queue messages and recommends HMAC signing — a real gap teams miss.
10. Attack-surface review of an API spec
Task: audit an OpenAPI spec for exposed risk.
Analyze this OpenAPI 3 spec. List endpoints lacking authentication,
endpoints returning sensitive fields in responses, missing rate limits,
and overly permissive CORS. Output a prioritized table with fixes.
Example: the model spots a /admin/users endpoint with no security block and a response schema that leaks password_hash — both real, common mistakes.
11. Incident triage assistant
Task: structure a response when something is already on fire.
We suspect a breach. Here are logs: <paste>. Walk me through
triage: what to preserve, likely attack vector, containment steps,
and what to check next. Do not guess — list evidence for each claim.
Example: given nginx logs with a burst of 404s followed by a 200 on /admin, the model suggests checking for path brute-forcing and preserving logs before rotation. It structures thinking; the decisions stay with you.
12. Security report for stakeholders
Task: translate findings into language management understands.
Turn these findings into an executive summary: business impact,
likelihood, effort to fix, and recommended priority order.
Avoid jargon; one paragraph per finding. Then a one-line risk score.
Example: a SQL-injection finding becomes "customer data can be read by an outsider; fix this week; low effort" — which is what actually gets a fix scheduled.
Where the model stops and you start
LLMs are excellent at the boring, repetitive parts of security work: reading diffs, explaining CVEs, drafting tests and writing pipeline config. They are bad at proving exploitability, understanding your business context, and knowing when they are wrong. Treat every output as a lead to verify — cross-check CVEs against nvd.nist.gov, run scanners for real, and test on staging.
Start with prompt #1 on your next pull request and #3 on your next advisory email. Two prompts, ten minutes, and your team already has a first-line security reviewer that never sleeps through a diff.
Comments