What this prompt does
This prompt designs a complete DevSecOps pipeline that bakes security scanning into every stage of your CI/CD workflow. You describe the [project_type], [ci_platform], [source_control], [container_registry], [deployment_target], and [tech_stack], and it builds out pre-commit hooks, SAST, SCA, container scanning, DAST, IaC scanning, pipeline orchestration, and a phased rollout plan — each with actual config file content.
The structure works because shift-left security only sticks if it runs automatically and doesn't make developers route around it. The prompt sequences scans the way they actually belong — secrets and SAST early, DAST against staging later — and parallelizes them for speed. It uses your [sast_tool] and [tech_stack] to produce real .pre-commit-config.yaml and CI job definitions, and the rollout plan starts non-blocking, then gates on Critical findings only, which is how teams adopt this without revolting. Findings land inline in pull requests with fix suggestions.
When to use it
- You're standing up CI/CD security and want scanning on every commit, not a quarterly audit.
- You need actual config files (
.pre-commit-config.yaml, CI job YAML) for your[ci_platform], not just descriptions. - You want SAST, SCA, secrets, and container scanning wired in with gate policies.
- You're rolling out security tooling to a team and need a phased plan that won't trigger pushback.
- You need an SBOM and license-compliance checks for
[compliance_standard]like SOC 2. - You want IaC scanning (Terraform, Kubernetes) with policy-as-code added to the pipeline.
Example output
You get a stage-by-stage pipeline with real config: a .pre-commit-config.yaml with secrets scanning, a SAST job using your [sast_tool] with severity gates and incremental scanning, an SCA stage with dependency scanning, reachability analysis, and SBOM generation, container security (image scanning, Dockerfile linting, distroless recommendations), DAST against staging, IaC scanning with OPA/Rego, a full [ci_platform] pipeline definition with parallel stages and gate policies, and a phased rollout — non-blocking first, then gating on Critical, then full enforcement.
Pro tips
- Name your exact
[ci_platform]so the orchestration file is directly usable, not pseudo-config. - List every language in
[tech_stack]; SCA and SAST coverage depends on knowing all your package managers. - Set
[sast_tool]to your preferred scanner (Semgrep, etc.) to get custom-rule configuration for your stack. - Follow the phased rollout — non-blocking reporting first is what prevents developers from disabling the tooling.
- Use
[compliance_standard]to drive the license-compliance and policy-as-code rules toward real requirements. - Insist the findings surface inline in PRs with fix suggestions; that's what makes shift-left actually adopted.
