10 Prompts for Security and DevSecOps: Audit, Scanning, and Access Policies
Security teams are drowning in alerts. DevSecOps promises to bake security into the development lifecycle, but the day-to-day reality often involves repetitive tasks: writing YAML rules, triaging vulnerabilities, and reviewing access policies. Large language models (LLMs) can absorb a lot of that toil—if you know how to ask.
This article collects 10 proven prompts that cover the DevSecOps spectrum: static and dynamic analysis, infrastructure as code, threat modeling, and policy auditing. Each prompt comes with a realistic example and an explanation of why it works. Use them as a starting point for your own security automation.
1. Generate a threat model with STRIDE
Task: Create a structured threat model for a web application using the STRIDE methodology.
Prompt:
Act as a senior security architect. Analyze the following application and produce a threat model using STRIDE.
Application: React frontend, Node.js API, PostgreSQL database, AWS S3 for file uploads.
For each threat, list the affected component, the attack scenario, the impact, and a mitigation.
Output the result as a Markdown table.
Example output:
| Threat | Component | Scenario | Impact | Mitigation |
|--------|-----------|----------|--------|------------|
| Spoofing | API | Attacker steals a JWT from local storage | Unauthorized access | Use httpOnly cookies and short-lived tokens |
| Tampering | S3 | Malicious file uploaded as an image | Stored XSS | Validate file type and content on the server |
| Repudiation | API | Admin performs destructive action without a log | Non-repudiation loss | Enable audit logging and enforce signed requests |
| Information disclosure | Database | SQL injection via unsanitized search input | Data breach | Use parameterized queries and an ORM |
| Denial of service | API | Flood of requests from unauthenticated users | Service downtime | Implement rate limiting and WAF rules |
| Elevation of privilege | API | JWT with role "admin" is forged | Full system compromise | Verify JWT signature and check user roles on each request |
Why it works: STRIDE gives the model a clear structure to follow, and the output is useful for generating a security backlog. This approach aligns with the OWASP Threat Modeling guidance and NIST SP 800-154. You can extend the prompt by adding trust boundaries or a data flow diagram, and ask for risk-ordered recommendations.
2. Craft a SAST rule for SQL injection
Task: Write a Semgrep rule that detects unsafe string concatenation in Python SQL queries.
Prompt:
As a static analysis expert, write a Semgrep rule that flags unsafe concatenation of user input into SQL queries.
Include a pattern and a positive/negative test case.
Example output:
# semgrep-rule.yaml
rules:
- id: sql-injection-concat
pattern-either:
- pattern: |
cursor.execute("SELECT ..." + $USER_INPUT)
- pattern: |
cursor.execute(f"SELECT ... {user_input}")
message: Potential SQL injection from string concatenation.
languages: [python]
severity: ERROR
metadata:
cwe: CWE-89
owasp: A03:2021
# test.py
query = "SELECT * FROM users WHERE id = " + request.args["id"] # fails
query = "SELECT * FROM users WHERE id = %s" # passes
Why it works: LLMs are surprisingly good at generating pattern-matching rules. You can iterate by pasting the rule into Semgrep Playground or your CI pipeline. This fits into a broader SAST strategy recommended by OWASP's Source Code Analysis Tools page. The generated rule uses OWASP ASVS A03 identifiers, making it easy to integrate into existing workflows.
3. Build a DAST test scenario for XSS
Task: Generate HTTP requests for a DAST tool to test reflective XSS in a search endpoint.
Prompt:
Act as a penetration tester. Generate a set of HTTP requests to test for reflective XSS in the /search?q= parameter.
Include five different payloads and expected response indicators. Use the format:
- Request: GET /search?q=PAYLOAD
- Expected sign: the payload is echoed unescaped in the HTML.
Example output:
- Request: GET /search?q=<script>alert(1)</script>
Expected sign: the string <script>alert(1)</script> appears in the response.
- Request: GET /search?q="><img src=x onerror=alert(1)>
Expected sign: an img tag is rendered and the onerror fires.
- Request: GET /search?q=javascript:alert(1)>
Expected sign: the URL contains javascript:alert(1) in a href attribute.
- Request: GET /search?q=</script><script>alert(1)</script>
Expected sign: the closing script tag breaks out of an existing script block.
- Request: GET /search?q=%3Csvg%20onload=alert(1)%3E
Expected sign: URL-decoded payload is reflected and executes.
Why it works: Dynamic analysis tools like OWASP ZAP use exactly these kinds of payloads. This prompt saves time when you need a quick smoke test or want to extend your DAST regression suite. It follows the OWASP Testing Guide (WSTG-INPV). You can also ask the model to generate ZAP automation framework scripts for repeatable scans.
4. Write a CI/CD security policy
Task: Draft a GitLab CI configuration that includes SAST, DAST, and dependency scanning.
Prompt:
Act as a DevSecOps engineer. Write a GitLab CI configuration for a Node.js project that runs Semgrep, OWASP ZAP, and npm audit.
Fail the pipeline on critical vulnerabilities. Use the standard GitLab CI syntax.
Example output:
stages: [test, security]
semgrep:
stage: security
image: returntocorp/semgrep
script: semgrep scan --config=auto
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
zap:
stage: security
image: owasp/zap2docker-stable
script: zap-baseline.py -t https://staging.example.com
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
npm-audit:
stage: security
script: |
npm audit --audit-level=high
if [ $? -eq 1 ]; then exit 1; fi
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
Why it works: The prompt creates policy as code, which is the core of DevSecOps. You can adapt it to your own CI platform, for example GitHub Actions or Jenkins. The configuration is based on the GitLab CI/CD security scanning documentation, a reliable reference. It also demonstrates how to fail the pipeline only on high severity issues, avoiding unnecessary noise.
5. Analyze an SBOM for known vulnerabilities
Task: Identify critical vulnerabilities from a CycloneDX SBOM.
Prompt:
You are a security analyst. Given the following CycloneDX SBOM, identify the most critical vulnerabilities and suggest remediation.
Prioritize by CVSS score. Only use vulnerabilities from public advisories.
Example output:
The SBOM contains these high-risk components:
- lodash@4.17.20 — CVE-2020-8203, CVSS 7.4, ReDoS. Upgrade to 4.17.21.
- django@3.0.5 — CVE-2020-13596, CVSS 9.8, SQLi. Upgrade to 3.0.7.
- org.apache.logging.log4j:log4j-core:2.14.1 — CVE-2021-44228, CVSS 10.0, RCE. Upgrade to 2.17.1.
Recommended action: upgrade all components within the next 48 hours, then rescan.
Why it works: SBOM analysis is a key part of software supply chain security. The prompt guides the model to check for real CVEs and produce actionable output. This is consistent with Executive Order 14028 and NIST SP 800-218. You can extend the prompt to include a SBOM generation command (e.g., syft or cdxgen) before analysis, making the whole process one-shot.
6. Harden a Dockerfile with CIS benchmarks
Task: Review a Dockerfile for security issues and suggest fixes.
Prompt:
Act as a container security specialist. Review the following Dockerfile and list violations of the CIS Docker Benchmarks.
For each violation, provide the specific benchmark ID and a corrected line.
Example output:
Dockerfile: FROM ubuntu:20.04 (violates 4.1: Use a specific base image tag)
Fix: FROM ubuntu:20.04@sha256:32edd6ba5f28...
Dockerfile: RUN apt-get update && apt-get install -y curl (violates 4.7: Ensure apt-get update is always combined with upgrade)
Fix: RUN apt-get update && apt-get upgrade -y && apt-get install -y curl
Dockerfile: USER root (violates 4.11: Ensure the container runs as a non-root user)
Fix: add `RUN useradd -m app` and `USER app`
Why it works: The CIS Docker Benchmark is a well-documented standard. By referencing it explicitly, you get precise and auditable results. You can use the output to fix your Dockerfile and pass security scans like Trivy or Docker Bench. This prompt also helps you learn the benchmark requirements before you memorize them.
7. Audit Terraform code for misconfigurations
Task: Find security misconfigurations in a Terraform snippet.
Prompt:
As an IaC security expert, examine this Terraform snippet for misconfigurations. Focus on S3 bucket policies, IAM roles, and encryption.
Example output:
The Terraform code has these issues:
- aws_s3_bucket.data: public-read ACL is set. Set `acl = "private"` and block public access with `aws_s3_bucket_public_access_block`.
- aws_db_instance.db: `storage_encrypted = false`. Set to true to enable encryption at rest.
- aws_iam_role.ec2_role: policy grants `s3:*` on `arn:aws:s3:::my-bucket/*` instead of a minimal set of actions. Use `s3:GetObject` and `s3:PutObject` only.
- aws_security_group.web: port 22 is open to 0.0.0.0/0. Restrict ingress to a VPC CIDR or specific IP.
Why it works: LLMs can be surprisingly good at spotting common IaC mistakes. This prompt is a quick way to check your code before running a full scanner like Checkov or tfsec. The examples correspond to the AWS Well-Architected Framework security pillar. You can also ask the model to output a corrected Terraform file, which is handy for fast fixes.
8. Generate an incident response playbook for ransomware
Task: Write a step-by-step playbook for a compromised Windows server.
Prompt:
Create a step-by-step incident response playbook for a Windows server compromised by ransomware. Include phases: containment, eradication, and recovery. Assume the server is on the production network.
Example output:
1. **Containment:**
- Disconnect the server from the network (but keep power on for forensics).
- Block the server's IP in the firewall.
- Take a forensic snapshot of the memory and disk.
2. **Eradication:**
- Identify the ransomware variant via IOC analysis (e.g., file extensions, ransom note).
- Search for lateral movement: check RDP logs, scheduled tasks, and new user accounts.
- Reset credentials of the compromised account and all service accounts.
3. **Recovery:**
- Restore from a known-good backup, after verifying the backup is not encrypted.
- Rebuild the server from a hardened image, then apply patches and security policies.
- Monitor for reinfection for at least 30 days.
Why it works: This prompt is based on the NIST SP 800-61 incident handling guide. It gives you a starting point, but you should always adapt it to your organization's specific assets and SLAs. You can make the playbook even more useful by asking for a communication plan or a list of stakeholders to notify.
9. Audit IAM policies for least privilege
Task: Review an AWS IAM policy for excessive permissions.
Prompt:
As an AWS security expert, analyze the following IAM policy. Identify permissions that violate least privilege and provide a hardened version.
Example output:
Original policy:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": "*"
}]
}
Issues:
- Wildcard action `s3:*` grants all S3 permissions, including deletion.
- Resource `*` allows access to every bucket.
Hardened policy:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"]
}]
}
Why it works: IAM policy audits are tedious. Using an LLM to generate a least-privilege version saves time and reduces the chance of human error. This aligns with the IAM best practices in the AWS documentation. You can also feed the output into automated policy validation tools like AWS Config or Policy Sentry.
10. Create a secure code review checklist based on OWASP ASVS
Task: Build a checklist for a security-focused code review.
Prompt:
Generate a checklist for a security-focused code review of a web API. Map each item to the relevant OWASP ASVS 4.0 category. Keep it concise.
Example output:
- Verify all endpoints require authentication (V2 Authentication).
- Check that session tokens are invalidated on logout (V3 Session Management).
- Ensure that access control checks are enforced on every request (V4 Access Control).
- Confirm that input validation is centralized and uses allowlists (V5 Validation, Sanitization, Encoding).
- Ensure that error messages don't leak stack traces or SQL queries (V7 Error Handling).
- Verify that cryptographic keys are stored securely and rotated (V6 Cryptography).
- Check that security headers are set (e.g., CSP, X-Content-Type-Options) (V14 Security Configuration).
Why it works: ASVS is a comprehensive standard, and mapping review items to its categories makes the checklist actionable. This prompt is perfect for security champions who want to include security in the pull request process. You can even turn the checklist into a Markdown template and use it as a PR description helper.
These ten prompts are just the beginning. The key is to treat LLMs as an extension of your security team: give them clear context, ask for structured output, and always verify results against authoritative sources like OWASP, NIST, and vendor documentation. Start with two or three prompts, integrate them into your pipeline, and measure the time saved. Security automation is not a one-time project—it's a continuous improvement loop.
Comments