CI/CD Pipeline Security Architecture Review Prompt

This prompt is built for DevSecOps engineers, platform security architects, and release engineering leads who need a structured supply-chain risk assessment of a CI/CD pipeline design before it reaches production. It takes a pipeline architecture description, configuration snippets, or a design document and produces a prioritized risk report covering authentication, secret handling, artifact integrity, deployment gates, and credential exposure. The ideal moment to use it is during a security architecture review gate, when onboarding a new service into an existing build-and-release system, or when a pipeline design is stable enough to review but not yet locked in.

This is a design-time review prompt, not a runtime log scanner or a replacement for SAST/DAST tooling. It will not analyze live pipeline execution logs, detect active intrusions, or scan running containers for vulnerabilities. Instead, it reasons about the architecture itself: where secrets are injected, how artifacts are signed, whether deployment gates can be bypassed, and which identities have write access to critical stages. The prompt expects a description of the pipeline topology, tooling choices, and configuration approach. It works best when you provide concrete details—naming the CI platform, artifact registry, deployment target, and secret store—rather than abstract descriptions.

Before using this prompt, gather the pipeline design artifacts: architecture diagrams, configuration snippets for pipeline stages, identity and access control lists, artifact signing and verification steps, and any existing security review notes. The prompt is most effective when you include these as structured context. After receiving the output, treat it as a starting point for deeper review, not a final audit. Validate findings against your actual configuration, test the identified risks with manual inspection or automated checks, and use the prioritized list to drive remediation before the pipeline goes live. Avoid using this prompt on pipelines already in production without pairing it with runtime evidence and human review.

This prompt template is designed to be pasted directly into your AI harness. It instructs the model to act as a DevSecOps architect and perform a structured security review of a CI/CD pipeline. The review covers authentication, secret handling, artifact integrity, and deployment gates. Before execution, replace every square-bracket placeholder (e.g., [PIPELINE_DESIGN_DOC]) with the actual content from your system. The prompt is self-contained and can be used independently of the rest of this playbook.

textCopy
You are a principal DevSecOps architect conducting a supply-chain security review of a CI/CD pipeline.

Review the provided pipeline design document against industry best practices for software supply chain security, including SLSA framework guidance and OWASP CI/CD Security Cheat Sheet recommendations.

# INPUT
[PIPELINE_DESIGN_DOC]

# REVIEW SCOPE
Analyze the pipeline from initial code commit through artifact deployment to production. For each stage, evaluate:
- Authentication and authorization mechanisms for users and services.
- Handling, storage, and rotation of secrets (API keys, tokens, certificates).
- Artifact generation, signing, and integrity verification.
- Deployment gate controls, including required approvals and automated checks.
- Logging and audit trail completeness for all security-relevant events.

# CONSTRAINTS
- Base all findings strictly on the provided design document. Do not invent missing details.
- Flag any missing information as a "Gap" that requires clarification.
- Prioritize findings by risk severity: Critical, High, Medium, Low.

# OUTPUT_SCHEMA
Return a valid JSON object with the following structure:
{
  "executive_summary": "A 2-3 sentence summary of the overall security posture.",
  "risk_assessment": {
    "critical_risks": [
      {
        "id": "RISK-001",
        "finding": "Description of the vulnerability or misconfiguration.",
        "location": "Specific stage or component in the pipeline.",
        "impact": "Potential consequence if exploited.",
        "recommendation": "Specific, actionable mitigation step."
      }
    ],
    "high_risks": [],
    "medium_risks": [],
    "low_risks": []
  },
  "gaps_in_documentation": [
    "List of critical pieces of information missing from the design doc needed for a complete review."
  ],
  "positive_findings": [
    "List of security controls that are correctly implemented."
  ]
}

# RISK_LEVEL
This is a high-stakes security review. If the design document is incomplete or ambiguous, state this clearly in the gaps section and do not guess. Flag unsigned artifacts and potential credential exposure in logs as Critical risks.

To adapt this template, replace [PIPELINE_DESIGN_DOC] with the full text of your architecture document, runbook, or configuration description. The output schema is designed for direct ingestion by a downstream security dashboard or ticketing system. Because this is a high-risk workflow, always route the generated JSON to a human security engineer for validation before accepting it as a final audit record. Do not use this prompt to make automated blocking decisions in a live pipeline without human-in-the-loop approval.

This prompt is designed to be integrated into a CI/CD pipeline security gate, not run as a one-off chat. The implementation harness must treat the model output as a structured risk assessment that feeds downstream decision logic—not as a final report. Wire the prompt into a pipeline stage that executes after the pipeline configuration is parsed but before any deployment artifact is promoted. The harness should extract the pipeline definition (e.g., .github/workflows/*.yml, Jenkinsfile, tekton/pipeline.yaml), serialize it as structured input, and pass it to the prompt along with the organization's security policy, artifact signing requirements, and deployment environment context.

Input assembly: Collect the pipeline definition, the target environment's trust level (e.g., production, staging, development), the artifact registry URL, and any existing supply-chain policy documents. Inject these into the [PIPELINE_DEFINITION], [ENVIRONMENT_CONTEXT], and [SECURITY_POLICY] placeholders. For [OUTPUT_SCHEMA], provide a strict JSON schema that the model must follow—include fields for risk_id, category (e.g., unsigned_artifact, credential_exposure, unrestricted_deployment_gate), severity, finding, evidence_location, and remediation. This schema-first approach enables downstream validation. Model choice: Use a model with strong structured-output capabilities and a context window large enough to hold the full pipeline definition plus policy documents. For high-security environments, prefer a model deployed within your VPC or private cloud to avoid sending pipeline configurations to external APIs.

Validation and retries: After the model returns, validate the JSON output against the schema. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. If the second attempt also fails, log the failure, flag the pipeline stage as blocked, and route the raw output to a human reviewer. Human approval gate: For any finding with severity: critical or severity: high, the harness must require human approval before the pipeline can proceed. Post the finding to a security review queue (e.g., Jira, ServiceNow, or a Slack channel) with the evidence location and suggested remediation. Do not auto-remediate based on model output—the model can identify risks but cannot authorize pipeline changes. Logging and audit: Log every invocation, including the prompt version, model identifier, input hash, output hash, validation result, and reviewer decision. This audit trail is essential for compliance reviews and for debugging prompt drift over time. What to avoid: Do not pass secrets or credentials as part of the pipeline definition input. Redact environment variables and secret references before sending to the model. If the pipeline definition contains inline secrets, the harness must fail early and alert the team—this is itself a critical finding that should block the pipeline.