7 Prompts for Security and DevSecOps: Audits, Scanning, and Policy Enforcement

Introduction

In the rapidly evolving landscape of software development, security can no longer be an afterthought. With the rise of DevSecOps, security is embedded into every stage of the CI/CD pipeline, from code commit to deployment. Yet, many teams struggle to translate high-level security requirements into actionable, automated checks. This is where structured prompts come in—not for generative AI, but for configuring security tools, writing effective SAST/DAST rules, and defining access policies that are both strict and maintainable.

This article presents a curated collection of 7 prompts designed to help security engineers, DevOps practitioners, and developers audit their systems, scan for vulnerabilities, and enforce policies. Each prompt is categorized by complexity (basic, advanced, expert) and includes a clear task, the prompt itself, and an example result. These prompts are tool-agnostic but can be adapted to popular platforms like GitHub Actions, GitLab CI, Snyk, SonarQube, and OPA (Open Policy Agent).

Why Prompts Matter in DevSecOps

A well-crafted prompt is essentially a configuration template or a natural-language instruction that drives a security tool or process. In DevSecOps, prompts help:

• Standardize security checks across repositories.
• Reduce false positives by narrowing scan scopes.
• Enforce compliance policies without manual overhead.
• Accelerate incident response by pre-defining queries.

According to the 2025 DevSecOps Community Survey by GitLab, organizations that automate security scanning in CI/CD pipelines reduce mean time to remediation (MTTR) by 60% compared to those relying on manual audits. However, automation is only as good as the rules it follows. Without precise prompts, teams risk alert fatigue or, worse, missed vulnerabilities.

Basic Prompts

These prompts are suitable for teams new to DevSecOps or for routine checks that don’t require deep customization.

1. Secret Scanning in Repositories

Task: Scan a Git repository for accidentally committed secrets (API keys, passwords, tokens) and generate a report.

Prompt:

Search the repository at [repo_url] for any hardcoded secrets. Use regex patterns for common secret formats:
- AWS Access Key ID (AKIA...)
- GitHub personal access tokens (ghp_...)
- Generic password strings (password=, secret=, token=)
Ignore files in .gitignore. Output a JSON list of findings with file path, line number, and secret type.

Example Result:

[
  {
    "file": "src/config.js",
    "line": 45,
    "type": "AWS Access Key ID",
    "value": "AKIAIOSFODNN7EXAMPLE"
  },
  {
    "file": "scripts/deploy.sh",
    "line": 12,
    "type": "GitHub Token",
    "value": "ghp_abc123def456"
  }
]

Why it works: This prompt is generic enough to run on any repository with tools like GitLeaks or TruffleHog. It focuses on the most common secret patterns and excludes irrelevant files, reducing noise.

2. Basic SAST Scan Configuration

Task: Configure a Static Application Security Testing (SAST) tool to scan Python code for injection vulnerabilities.

Prompt:

Create a SAST configuration for a Python web application (Flask/Django). Enable rules for:
- SQL injection (e.g., raw queries without parameterization)
- Cross-Site Scripting (XSS) in template rendering
- Command injection (e.g., os.system, subprocess with user input)
Set severity threshold to 'high' for blocking the pipeline. Exclude test files and migrations.

Example Result:

Using SonarQube, this prompt translates to a quality profile with activated rules like python:S3649 (SQL injection) and python:S5135 (XSS). The pipeline is configured to fail if any high-severity issue is found in non-test files.

Outcome: Developers receive immediate feedback on dangerous patterns before code is merged.

Advanced Prompts

These prompts require a deeper understanding of security frameworks and tool customization.

3. DAST Scan for an API Endpoint

Task: Run a Dynamic Application Security Testing (DAST) scan against a staging API to identify authentication and authorization flaws.

Prompt:

Perform a DAST scan on https://staging-api.example.com/v2/. Focus on:
- Broken Object Level Authorization (BOLA): Test by replacing user IDs in endpoints like /users/{id}/profile with another valid user's ID.
- JWT token validation: Send requests with expired, malformed, and unsigned tokens.
- Rate limiting: Send 1000 requests in 10 seconds to /login and check for 429 status.
Generate a report with severity, endpoint, and evidence (request/response pairs).

Example Result:

A scan using OWASP ZAP or Burp Suite reveals that the /users/{id}/profile endpoint does not verify that the authenticated user owns the resource. The report flags this as a high-severity BOLA vulnerability with a sample request showing user ID 1002 accessing data for user 1003.

Why it matters: DAST scans simulate real attacks. This prompt specifically targets OWASP API Security Top 10 risks, which account for many data breaches in modern microservices architectures.

4. Infrastructure-as-Code Security Policy

Task: Write an Open Policy Agent (OPA) policy to enforce that all Terraform AWS resources have encryption enabled.

Prompt:

Define an OPA/Rego policy that checks Terraform plan JSON for:
- aws_s3_bucket must have server_side_encryption_configuration with AES256 or aws:kms.
- aws_rds_cluster must have storage_encrypted = true.
- aws_ebs_volume must have encrypted = true.
Deny any resource that violates these rules. Provide a clear error message with the resource name and type.

Example Result:

package terraform.encryption

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"
  not resource.change.after.server_side_encryption_configuration
  msg := sprintf("S3 bucket %v must have encryption enabled", [resource.change.after.bucket])
}

When applied in CI, this policy blocks any Terraform plan that creates unencrypted resources. According to the 2024 Cloud Security Report by Check Point, misconfigured storage accounts are the leading cause of cloud data leaks, making such policies critical.

Expert Prompts

These prompts are for seasoned security engineers who need to handle complex, multi-layered threats.

5. Supply Chain Attack Detection

Task: Identify potential supply chain attacks in a Node.js project by analyzing dependency behavior.

Prompt:

Analyze the package-lock.json and node_modules of project [path]. Look for:
- Packages with names similar to popular packages (typosquatting): e.g., 'lodash' vs 'lodashs'.
- Packages with very recent creation dates and high download counts (potential malicious injection).
- Packages that execute postinstall scripts that write to /tmp or /etc.
Flag any package that has fewer than 10 GitHub stars but more than 100,000 weekly downloads.

Example Result:

A tool like Socket.dev or npm audit reports that eslint-scope (a real-world compromised package in 2018) has a postinstall script that exfiltrates environment variables. The prompt catches this by combining heuristic checks (star-to-download ratio) and behavioral analysis (postinstall scripts).

Context: The 2021 SolarWinds attack highlighted how a single compromised dependency can cascade. This prompt operationalizes lessons from that incident.

6. Real-Time Threat Intelligence Integration

Task: Create a custom rule to block IP addresses that are associated with known C2 (Command and Control) servers in real-time during DAST scans.

Prompt:

Integrate threat intelligence feeds (AlienVault OTX, AbuseIPDB) into the DAST scanner. For each incoming request to the staging environment:
1. Extract the source IP.
2. Query the threat feed API (e.g., GET https://otx.alienvault.com/api/v1/indicators/IPv4/{ip}/general).
3. If the IP has a pulse count > 5 or is tagged as 'malware', immediately block the request and log the incident.
Use a local cache to avoid rate limits (TTL = 300 seconds).

Example Result:

During a penetration test, the scanner encounters requests from an IP listed in AlienVault's pulse for Emotet. The prompt causes the scanner to drop the connection and log: Blocked IP 185.220.101.x — associated with malware (Emotet). This prevents the test from interacting with a known malicious host.

Note: This prompt requires API keys and careful tuning to avoid false positives from shared hosting IPs.

7. Automated Compliance Audit for SOC 2

Task: Generate a compliance report for SOC 2 criteria (security, availability, processing integrity) by auditing cloud infrastructure and application logs.

Prompt:

Run a compliance audit against AWS/GCP infrastructure using the following checks:
- All S3 buckets must have block public access enabled (CC6.1).
- CloudTrail must be enabled in all regions with log file validation (CC7.2).
- RDS instances must have automated backups with retention >= 7 days (A1.2).
- IAM users must have MFA enabled (CC6.3).
Output a markdown report with PASS/FAIL status for each control and remediation steps for failures.

Example Result:

## SOC 2 Audit Report — 2026-07-05

| Control | Status | Details |
|---------|--------|---------|
| CC6.1 — S3 Block Public Access | FAIL | Bucket 'logs-prod' has public read access. Remediation: Enable block public access via AWS Console or Terraform. |
| CC7.2 — CloudTrail Enabled | PASS | CloudTrail is enabled in us-east-1, eu-west-1. |
| A1.2 — RDS Backup Retention | FAIL | Instance 'prod-db' has backup retention of 1 day. Remediation: Set backup_retention_period to 7. |
| CC6.3 — IAM MFA | FAIL | User 'deploy-bot' does not have MFA. Remediation: Attach MFA device or use IAM roles with temporary credentials. |

Why it’s expert-level: This prompt combines multiple cloud services and compliance frameworks. It requires understanding of SOC 2 trust services criteria and how they map to specific infrastructure configurations. Tools like Prowler or CloudSploit can execute such audits automatically.

Comparison of Prompt Types

Best Practices for Writing Security Prompts

1. Be specific about scope. Avoid scanning entire codebases when you only care about production code. Use exclude patterns for tests, examples, and generated files.
2. Set severity thresholds. Not all findings are equal. Define what blocks a build (critical/high) vs. what generates a warning (medium/low).
3. Test prompts in a sandbox first. Before deploying a rule to production CI, run it on a sample repository to verify it catches real issues without excessive false positives.
4. Version control your prompts. Store them in a dedicated security-policies/ directory in your repository, just like code. This enables peer review and rollback.
5. Leverage community knowledge. OWASP maintains a list of top vulnerabilities; use those as the foundation for your prompts.

Conclusion

Security in DevSecOps is not about buying the most expensive tool—it’s about defining precise, actionable rules that automate enforcement without slowing down development. The 7 prompts in this article cover the spectrum from basic secret scanning to advanced compliance audits. By adopting a structured prompt approach, teams can reduce manual effort, catch vulnerabilities earlier, and build a culture of security-first development.

Remember: a prompt is only as good as the context it’s given. Tailor these examples to your specific tech stack, threat model, and compliance requirements. Start with one or two basic prompts, iterate based on results, and gradually introduce advanced ones as your team matures in its DevSecOps journey.

ASI Biont supports integration with a variety of security tools and cloud providers via API. For example, you can automate SAST scans and policy enforcement across your entire infrastructure—learn more at asibiont.com/courses.