Introduction
In the rapidly evolving landscape of software development, security is no longer an afterthought—it's a continuous, integrated practice. DevSecOps, the movement to embed security into every phase of the DevOps pipeline, has become essential for organizations aiming to ship fast without compromising safety. Yet, even with the best tools, security teams often struggle with repetitive tasks: configuring static analysis (SAST), running dynamic scans (DAST), and enforcing access policies. This is where well-crafted prompts for AI assistants and automation systems come into play.
Prompt engineering for security—sometimes called "security prompt crafting"—allows engineers to define precise, repeatable instructions for AI models, chatbots, or automation frameworks. These prompts can guide vulnerability scanning, generate policy templates, or audit configurations. According to a 2025 report by SANS Institute, organizations that standardize security prompts reduce false positives by up to 40% and cut remediation time by 25% (SANS 2025 DevSecOps Survey).
This article presents a structured collection of 10 prompts across three categories: Basic (for newcomers), Advanced (for practitioners), and Expert (for seasoned architects). Each prompt includes a clear task, the exact prompt text, and an example result. Whether you're a developer new to security or a DevSecOps lead, you'll find actionable templates to strengthen your pipeline.
Basic Prompts
These prompts are designed for teams starting their DevSecOps journey. They focus on foundational tasks like generating SAST configuration snippets, explaining DAST concepts, and drafting simple access policies.
1. Generate a Basic SAST Configuration for a Python Project
Task: Create a minimal Semgrep configuration file to detect common Python vulnerabilities like SQL injection and hardcoded secrets.
Prompt:
Act as a DevSecOps engineer. Generate a Semgrep configuration file (semgrep-rules.yml) for a Python web application. Include rules for:
- SQL injection detection
- Hardcoded API keys or passwords
- Use of eval() or exec()
Output only the YAML content.
Example Result:
rules:
- id: sql-injection
patterns:
- pattern: |
cursor.execute("..." + $VAR + "...")
message: "Potential SQL injection"
languages: [python]
severity: ERROR
- id: hardcoded-secret
patterns:
- pattern-regex: (?i)(password
|api_key|secret)\s*=\s*['"][^'"]{8,}['"]
message: "Hardcoded secret detected"
languages: [python]
severity: WARNING
- id: dangerous-eval
patterns:
- pattern: eval(...)
- pattern: exec(...)
message: "Use of eval/exec can lead to code injection"
languages: [python]
severity: ERROR
2. Explain DAST Scanning Concepts to a Developer
Task: Get a concise explanation of Dynamic Application Security Testing (DAST) suitable for a junior developer.
Prompt:
You are a security trainer. Explain DAST (Dynamic Application Security Testing) in 3-4 sentences. Include its purpose, how it differs from SAST, and one real-world example of a vulnerability it catches (e.g., XSS). Keep it simple for a junior developer.
Example Result:
"DAST is a black-box testing method that analyzes running applications by simulating attacks, unlike SAST which scans source code. It catches runtime vulnerabilities like Cross-Site Scripting (XSS) or SQL injection that only appear during execution. For example, DAST can detect if user input in a search box is reflected unsanitized in the response, leading to XSS. Use DAST in staging or pre-production environments for realistic results."
3. Draft an Access Control Policy for a Cloud Storage Bucket
Task: Generate a basic Identity and Access Management (IAM) policy for an AWS S3 bucket that enforces least privilege.
Prompt:
Write an AWS S3 bucket policy that allows only read access to a specific IAM role (arn:aws:iam::123456789012:role/DataAnalyst) and denies public access. Use JSON format. Add a condition to require SSL.
Example Result:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/DataAnalyst"
},
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::example-bucket",
"arn:aws:s3:::example-bucket/*"
],
"Condition": {
"Bool": {"aws:SecureTransport": "true"}
}
},
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::example-bucket",
"arn:aws:s3:::example-bucket/*"
],
"Condition": {
"Bool": {"aws:SecureTransport": "false"}
}
}
]
}
Advanced Prompts
Advanced prompts assume familiarity with CI/CD pipelines and security tools. They focus on automation, integration, and policy-as-code.
4. Automate Vulnerability Reporting from a SAST Tool
Task: Create a prompt that generates a script to parse Semgrep JSON output and format it as a Markdown report with severity counts.
Prompt:
Act as a Python developer. Write a script that reads a Semgrep results JSON file (results.json) and produces a Markdown summary with:
- Total issues count
- Breakdown by severity (ERROR, WARNING, INFO)
- Top 5 most common rule IDs with examples
Use argparse for input file path. Output the script only.
Example Result:
#!/usr/bin/env python3
import json
import argparse
from collections import Counter
def generate_report(input_file):
with open(input_file, 'r') as f:
data = json.load(f)
results = data.get('results', [])
total = len(results)
severity_counts = Counter(r['extra']['severity'] for r in results)
rule_counts = Counter(r['check_id'] for r in results)
top_rules = rule_counts.most_common(5)
report = f"# SAST Scan Report\n\n"
report += f"**Total Issues:** {total}\n\n"
report += "## Severity Breakdown\n"
report += "
| Severity | Count |\n|----------|-------|\n"
for sev, count in severity_counts.items():
report += f"
| {sev} | {count} |\n"
report += "\n## Top 5 Rule IDs\n"
for rule_id, count in top_rules:
report += f"- `{rule_id}`: {count} occurrences\n"
return report
if __name__ == '__main__':
parser = argparse.ArgumentParser(description='Generate SAST report')
parser.add_argument('input_file', help='Path to Semgrep JSON results')
args = parser.parse_args()
print(generate_report(args.input_file))
5. Write a DAST Scan Configuration for OWASP ZAP
Task: Generate a ZAP automation framework YAML config to scan a web app for Top 10 vulnerabilities with authentication.
Prompt:
Create an OWASP ZAP automation plan (YAML) for a web application at https://staging.example.com. Include:
- Authentication via form-based login (username: testuser, password: env var ZAP_PASSWORD)
- Active scan with policy for SQL injection, XSS, and CSRF
- Report generation in HTML format
Use the ZAP Automation Framework syntax.
Example Result:
env:
contexts:
- name: staging
urls:
- https://staging.example.com
authentication:
method: form
loginPageUrl: https://staging.example.com/login
loginRequestData: "username={%username%}&password={%password%}"
credentials:
username: testuser
password: ${ZAP_PASSWORD}
jobs:
- type: spider
parameters:
url: https://staging.example.com
- type: activeScan
parameters:
policy: "Default Policy"
scanAll: true
rules:
- id: 40018 # SQL Injection
threshold: LOW
- id: 40012 # XSS
threshold: LOW
- id: 40014 # CSRF
threshold: MEDIUM
- type: report
parameters:
template: traditional-html
reportDir: /reports
reportFile: zap-scan-{{date}}.html
6. Generate a Kubernetes Network Policy
Task: Create a Kubernetes NetworkPolicy that restricts traffic to a backend service only from a frontend namespace.
Prompt:
Write a Kubernetes NetworkPolicy YAML for a service named 'backend' in namespace 'api'. Allow ingress traffic only from pods with app=frontend in namespace 'web'. Deny all other traffic. Use networking.k8s.io/v1.
Example Result:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-allow-frontend
namespace: api
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: web
podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
Expert Prompts
Expert prompts target complex scenarios like multi-tool orchestration, custom policy engines, and compliance audits.
7. Orchestrate a Multi-Tool Security Pipeline
Task: Design a CI/CD pipeline stage that runs Semgrep, Trivy, and OWASP ZAP sequentially, with conditional failure.
Prompt:
Act as a DevSecOps architect. Write a GitLab CI YAML job named 'security-scan' that:
- Runs Semgrep on the source code
- Scans Docker image with Trivy for vulnerabilities
- If both pass, runs ZAP DAST scan against staging URL
- Fails the job if any tool finds CRITICAL severity issues
Use artifacts to pass reports.
Example Result:
security-scan:
stage: test
script:
- semgrep --config=auto --json -o semgrep-results.json .
- trivy image --severity CRITICAL --exit-code 1 myapp:${CI_COMMIT_SHA}
- if [ $? -eq 0 ]; then
echo "Running ZAP scan..."
zap-cli quick-scan --self-contained --start-options '-config api.disablekey=true' https://staging.example.com
fi
artifacts:
paths:
- semgrep-results.json
- zap-report.html
only:
- main
8. Enforce a Custom Policy with Open Policy Agent (OPA)
Task: Generate an OPA Rego policy that validates Kubernetes deployments must have resource limits and no privileged containers.
Prompt:
Write an OPA Rego policy for Kubernetes admission control. The policy should:
- Require every container to have CPU and memory limits
- Deny any container with securityContext.privileged=true
- Include a rule name 'deny_privileged_and_no_limits'
Output only the Rego code.
Example Result:
package kubernetes.admission
deny_privileged_and_no_limits[msg] {
input.request.kind.kind == "Pod"
container := input.request.object.spec.containers[_]
# Check for privileged container
container.securityContext.privileged == true
msg := sprintf("Container '%v' is privileged", [container.name])
}
deny_privileged_and_no_limits[msg] {
input.request.kind.kind == "Pod"
container := input.request.object.spec.containers[_]
# Check missing resource limits
not container.resources.limits.cpu
not container.resources.limits.memory
msg := sprintf("Container '%v' has no CPU and memory limits", [container.name])
}
9. Conduct a Compliance Audit Against CIS Benchmark
Task: Generate a script that checks a Linux server against CIS Level 1 benchmarks for password policies.
Prompt:
You are a security auditor. Write a Bash script that audits a Linux system for CIS Benchmark Level 1 password policies:
- max password days <= 90
- min password length >= 14
- password expiration warning >= 7
Output PASS/FAIL for each check.
Example Result:
#!/bin/bash
# CIS Level 1 Password Policy Audit
# Check max days
max_days=$(grep '^PASS_MAX_DAYS' /etc/login.defs | awk '{print $2}')
if [ "$max_days" -le 90 ]; then
echo "PASS: PASS_MAX_DAYS is $max_days (<=90)"
else
echo "FAIL: PASS_MAX_DAYS is $max_days (>90)"
fi
# Check min length
min_len=$(grep '^PASS_MIN_LEN' /etc/login.defs | awk '{print $2}')
if [ "$min_len" -ge 14 ]; then
echo "PASS: PASS_MIN_LEN is $min_len (>=14)"
else
echo "FAIL: PASS_MIN_LEN is $min_len (<14)"
fi
# Check warn age
warn_age=$(grep '^PASS_WARN_AGE' /etc/login.defs | awk '{print $2}')
if [ "$warn_age" -ge 7 ]; then
echo "PASS: PASS_WARN_AGE is $warn_age (>=7)"
else
echo "FAIL: PASS_WARN_AGE is $warn_age (<7)"
fi
10. Design a Secrets Detection Workflow for Pre-Commit
Task: Create a pre-commit hook configuration that uses detect-secrets to prevent committing secrets.
Prompt:
Write a .pre-commit-config.yaml file that adds a hook to run detect-secrets on all staged files. Exclude *.lock files. The hook should fail if any potential secret is found.
Example Result:
repos:
- repo: https://github.com/Yelp/detect-secrets
rev: v1.4.0
hooks:
- id: detect-secrets
args: ['--baseline', '.secrets.baseline']
exclude: '\.lock$'
Conclusion
Security prompts are more than just instructions for AI—they are a form of executable knowledge that standardizes best practices across teams. By adopting the prompts in this collection, you can automate SAST configuration, DAST scanning, policy enforcement, and compliance audits. Start with the basic prompts to build foundational skills, then move to advanced and expert prompts as your DevSecOps maturity grows.
Remember: the most effective prompts are those you adapt to your specific stack. Test each prompt in a sandbox environment before deploying to production. For deeper integration of these workflows with your CI/CD platform, consider exploring automation frameworks that support custom scripts and policy-as-code. A well-crafted prompt today can save hours of manual security review tomorrow.
Comments