Supply Chain Security Architecture Review Prompt

This prompt is for security architects and platform engineers who need to evaluate the software supply chain security posture of a system design before code reaches production. It is designed to be used during architecture review gates, security design sprints, or when onboarding a new critical vendor dependency. The core job-to-be-done is to produce a structured threat analysis that covers dependency confusion, compromised packages, artifact tampering, and insider build risks—threats that are architectural in nature and often invisible to runtime scanners. The ideal user is someone who already has a system design document, a dependency manifest, or a build pipeline description and needs to pressure-test the design itself, not just the running artifacts.

The prompt assumes you have a concrete input to analyze, such as a software bill of materials (SBOM), a pom.xml, package-lock.json, Cargo.lock, or a textual description of your CI/CD pipeline stages. It works by guiding the model to reason about trust boundaries between registries, build servers, signing infrastructure, and deployment targets. For example, it will flag if your design pulls unsigned artifacts from a public registry without a local proxy or if a single compromised developer workstation could push a release without a second-party code review gate. The output is a structured threat list with architectural mitigations, not a list of CVEs. Use it when you are making decisions about build isolation, provenance verification, or vendor access policies.

Do not use this prompt as a replacement for a runtime SBOM generator, a container vulnerability scanner, or a dependency update bot. It will not tell you that libssl version 1.1.1t has a known buffer overflow; a vulnerability scanner does that. Instead, it will tell you that your design lacks a mechanism to enforce that libssl is pulled from a controlled, integrity-checked mirror. It complements operational tools by surfacing the architectural risks that allow a compromised dependency to reach production in the first place. If you need a CVE report, run a scanner. If you need to know why your scanner might never see the next SolarWinds-style attack, use this prompt. For high-risk or regulated environments, always follow the prompt's output with a human expert review and ground findings in your specific build attestations.

The following prompt instructs the model to act as a supply chain security architect. It is designed to consume a system design document, dependency manifest, or build pipeline description and produce a structured threat analysis. The output focuses on dependency confusion, compromised packages, artifact integrity, and insider build risks. Before using this prompt, ensure you have gathered the relevant architecture context—this is not a general-purpose security scanner and will produce unreliable results if fed incomplete or unrelated documents.

textCopy
You are a supply chain security architect. Your task is to review the provided system design, dependency manifest, and build pipeline description for supply chain security risks.

## INPUT
[ARCHITECTURE_DOCUMENT]
[DEPENDENCY_MANIFEST]
[BUILD_PIPELINE_DESCRIPTION]

## OUTPUT_SCHEMA
Return a valid JSON object with the following structure:
{
  "threats": [
    {
      "id": "string (e.g., SC-001)",
      "category": "dependency_confusion | compromised_package | artifact_integrity | insider_build_risk | provenance_gap | vendor_access_risk",
      "description": "string (clear, specific threat description)",
      "affected_component": "string (the specific package, artifact, or pipeline stage)",
      "likelihood": "low | medium | high | critical",
      "impact": "low | medium | high | critical",
      "existing_controls": ["string (list any controls already mentioned in the design)"],
      "missing_controls": ["string (list controls that should be present but are not)"],
      "evidence": "string (quote or reference the specific part of the input that supports this finding)"
    }
  ],
  "sbom_completeness_assessment": {
    "score": "incomplete | partial | complete",
    "missing_artifact_types": ["string (e.g., 'transitive npm dependencies', 'base container images')"],
    "recommendation": "string"
  },
  "build_integrity_assessment": {
    "score": "weak | moderate | strong",
    "findings": ["string (specific gaps in build integrity)"],
    "recommendation": "string"
  },
  "vendor_access_risk_summary": {
    "risk_level": "low | medium | high | critical",
    "vendors_with_elevated_access": ["string"],
    "recommendation": "string"
  },
  "executive_summary": "string (3-5 sentence summary for leadership)"
}

## CONSTRAINTS
- Only report threats supported by evidence in the provided input. Do not invent threats.
- If a section of the input is missing or insufficient to assess a category, set the score to 'incomplete' or 'weak' and explain what information is needed.
- For each threat, cite the specific evidence from the input that supports the finding.
- Do not recommend specific vendor products. Focus on architectural controls and patterns.
- If no supply chain threats are found, return an empty threats array and explain why in the executive_summary.

## RISK_LEVEL
[HIGH] This analysis may inform security decisions. All findings must be evidence-backed. Flag any assumptions clearly.

To adapt this prompt, replace the square-bracket placeholders with your actual inputs. The [ARCHITECTURE_DOCUMENT] should contain system diagrams, component descriptions, and data flow documentation. The [DEPENDENCY_MANIFEST] should include package manifests (e.g., package-lock.json, requirements.txt, pom.xml, or SBOM exports). The [BUILD_PIPELINE_DESCRIPTION] should describe CI/CD stages, artifact signing, and deployment gates. If any of these inputs are unavailable, the model will flag the assessment as incomplete rather than fabricating findings—this is intentional behavior designed to prevent false confidence.

Before integrating this prompt into a production workflow, test it against known-good and known-bad architecture documents. A design with signed artifacts, pinned dependencies, and verified SBOMs should produce a low-risk assessment. A design referencing unpinned public registries without integrity checks should trigger high-severity dependency confusion and artifact integrity findings. Run these test cases and compare the output against your expected threat model. If the model misses a known threat class, add a [CONSTRAINTS] entry or a few-shot example to tighten coverage. For high-risk production use, always route the output through a human security reviewer before acting on findings.

This prompt is designed to operate inside a structured review pipeline, not as a standalone chat interaction. The typical integration point is a CI/CD security gate, an architecture review board submission tool, or an internal developer portal where design documents are submitted before build approval. The prompt expects a design document, dependency manifest, or architecture description as [DESIGN_DOCUMENT], plus optional [SBOM] and [BUILD_CONFIG] inputs. The application layer is responsible for assembling these inputs, enforcing required fields, and validating the model's output against the expected threat analysis schema before the review is considered complete.

The implementation harness should enforce a strict output contract. Define a JSON schema for the expected threat analysis: a top-level object with threats (array of threat objects, each containing threat_id, category, description, affected_component, likelihood, impact, existing_controls, missing_controls, and evidence_references), a summary string, and a sbom_completeness_score (0-100). After the model returns its response, run a structural validator that checks for required fields, enum values for category (e.g., dependency_confusion, compromised_package, build_integrity, vendor_access, artifact_tampering), and non-empty evidence_references arrays. If validation fails, retry once with the error message injected into [CONSTRAINTS]. If the retry also fails, escalate to a human reviewer queue with the raw output and validation errors attached. Log every attempt, including the prompt version, model used, input hashes, and validation results, for auditability.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window, as design documents plus SBOM data can be lengthy. For high-assurance reviews, consider routing the same input to two different models and comparing the threat coverage overlap before accepting the result. Never treat the model's output as a final security sign-off. The harness should always attach a human-review flag when likelihood is high and impact is high for any threat, or when sbom_completeness_score falls below 70. Wire the output into your existing ticketing or risk register system so that each identified threat becomes a trackable item with the model's analysis as the initial evidence, not the final verdict.