DevOps & CI
AuraScore 79/100

Container Artifact Supply Chain Vulnerability Evaluation

Evaluate software supply chain security, image dependencies, and vulnerability gate enforcement across CI pipelines.

Use this prompt when auditing container image scanning policies, base image lineage, and pipeline admission gating. It delivers an actionable artifact security evaluation and remediation framework.

Template

Role: Lead DevSecOps Architect with deep expertise in container supply chain security, SLSA frameworks, and continuous artifact validation.

Context

  • Artifact container registry: {{artifact_registry}}
  • Upstream base image ecosystem: {{base_image_source}}
  • Static and dynamic scanning tooling: {{scan_tooling}}
  • Enforced blocking severity threshold: {{cve_severity_threshold}}
  • Current release gate deployment policy: {{release_gate_policy}}
  • Engineering organization scale: {{developer_team_size}}

Task

Produce a Comprehensive Container Supply Chain Security Analysis evaluating container artifact risk across {{artifact_registry}}, assessing vulnerability posture under {{scan_tooling}}, and designing an optimized enforcement model for {{cve_severity_threshold}} without impeding the velocity of {{developer_team_size}} engineers.

Method

  1. Analyze the integrity and provenance of base images pulled from {{base_image_source}} through the supply chain into {{artifact_registry}}.
  2. Evaluate how effectively {{scan_tooling}} identifies operating system packages, language-level runtime dependencies, and configuration vulnerabilities.
  3. Audit the current {{release_gate_policy}} to uncover bypass patterns, false-positive handling friction, and exception management gaps.
  4. Assess developer feedback loop latency caused by blocking builds at the {{cve_severity_threshold}} threshold.
  5. Review Software Bill of Materials (SBOM) generation, signing (e.g., Cosign), and verification processes throughout the build pipeline.
  6. Formulate a multi-stage triage model to manage zero-day CVEs, unfixable upstream issues, and patch inheritance.
  7. Provide organizational rollout guidance calibrated to maintain developer productivity across {{developer_team_size}} engineers.

Constraints

  • The evaluation MUST NOT recommend ignoring unpatched vulnerabilities without documented risk acceptance and automated TTL expiration.
  • Policies MUST maintain strict cryptographic verification of image signatures prior to registry admission.
  • Recommendations must be compatible with {{artifact_registry}} and {{scan_tooling}} native capabilities.
  • Avoid generic security advice; ground every finding in container dependency lifecycles.

Output format

  • Supply Chain Security Posture Summary (200 words evaluating current security vs. velocity balance)
  • Vulnerability Exposure Vector Breakdown (categorized analysis: OS layers, language packages, base images)
  • Pipeline Policy Gate Evaluation (strengths and weaknesses of {{release_gate_policy}} against {{cve_severity_threshold}})
  • SBOM & Provenance Architecture Blueprint (step-by-step pipeline signing and verification architecture)
  • Developer Workflow Mitigation Plan (concrete guidelines to prevent pipeline friction for {{developer_team_size}} engineers)

Self-review

  • Ensure all variables ({{artifact_registry}}, {{base_image_source}}, {{scan_tooling}}, {{cve_severity_threshold}}, {{release_gate_policy}}, {{developer_team_size}}) are contextualized.
  • Validate that proposed gate thresholds distinguish between exploitable vulnerabilities and low-risk informational CVEs.
  • Verify that SBOM generation and image signing recommendations align with enterprise supply chain standards.
AuraScore breakdown
79/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-devops
technology-software
devsecops
container-security
sbom