Package Provenance and Attestation Verification Prompt

This prompt is designed for security engineers and DevSecOps teams who need to verify that a package update meets organizational supply chain security policies before it is merged or deployed. The core job-to-be-done is automated, consistent policy enforcement: you have collected raw provenance data and attestation bundles from a package registry or build system, and you need a structured verification report that compares expected versus actual provenance, flags missing attestations or unsigned artifacts, and checks compliance against your defined SLSA-based policies. The ideal user is a platform security engineer integrating this check into a CI/CD pipeline or a manual review workflow where every dependency change must pass a provenance gate before acceptance.

Use this prompt when you already have the input artifacts—a target package identity, its provenance file (such as an in-toto attestation), any available signature bundles, and a machine-readable policy definition specifying required levels, trusted builders, and expected source repositories. The prompt is designed to consume these structured inputs and produce a deterministic verification report with clear pass/fail criteria per policy rule. It works best as a step in a larger supply chain security pipeline, positioned after artifact collection and before merge or deployment approval. Do not use this prompt for initial package selection, vulnerability scanning, or license compliance; those are separate workflows covered by sibling playbooks in this content group. This prompt also does not perform dynamic analysis, reachability assessment, or exploitability scoring—it strictly verifies the integrity and policy compliance of the provenance trail.

Before wiring this prompt into production, ensure you have a reliable mechanism for collecting provenance data from your registries and build systems. The prompt assumes inputs are complete and well-formed; garbage provenance in will produce garbage verification out. You should also define your policy schema clearly—ambiguous policy rules lead to inconsistent verification results. For high-risk deployments, always pair this automated check with a human review step for any policy failures or edge cases the prompt flags with low confidence. The next section provides the copy-ready prompt template you can adapt to your specific policy structure and output format requirements.

The following prompt template is designed to be wired into a package ingestion or CI/CD pipeline. It expects structured input from your package registry, build system, and policy store. Replace each square-bracket placeholder with real data before sending the prompt to the model. The prompt instructs the model to act as a supply chain security analyst, comparing expected provenance metadata against actual attestation data and flagging discrepancies, missing signatures, or policy violations. The output is a structured verification report suitable for automated gating decisions or human review queues.

textCopy
You are a supply chain security analyst verifying package provenance and attestation integrity.

## TASK
Verify the provenance and attestation data for a package update against the organization's supply chain security policy. Produce a structured verification report.

## PACKAGE CONTEXT
- Package Name: [PACKAGE_NAME]
- Version: [PACKAGE_VERSION]
- Registry: [REGISTRY_URL]
- Digest (SHA256): [PACKAGE_DIGEST]

## EXPECTED PROVENANCE (from policy or trusted source)
- Expected Builder ID: [EXPECTED_BUILDER_ID]
- Expected Source Repository: [EXPECTED_SOURCE_REPO]
- Expected Build Invocation: [EXPECTED_BUILD_INVOCATION]
- Required Attestation Types: [REQUIRED_ATTESTATION_TYPES]
- Minimum SLSA Level: [MINIMUM_SLSA_LEVEL]

## ACTUAL PROVENANCE (from attestation bundle)
```json
[ACTUAL_ATTESTATION_PAYLOAD]

POLICY CONSTRAINTS

• Allowed Builder IDs: [ALLOWED_BUILDER_IDS]
• Required Signature Types: [REQUIRED_SIGNATURE_TYPES]
• Blocked Source Repositories: [BLOCKED_SOURCE_REPOS]
• Maximum Provenance Age (hours): [MAX_PROVENANCE_AGE_HOURS]
• Require Non-Falsifiable Subject: [REQUIRE_NON_FALSIFIABLE_SUBJECT]

OUTPUT SCHEMA

Return a JSON object with the following structure: { "verification_status": "PASSED" | "FAILED" | "INCONCLUSIVE", "provenance_match": { "builder_id": { "expected": string, "actual": string, "match": boolean }, "source_repository": { "expected": string, "actual": string, "match": boolean }, "build_invocation": { "expected": string, "actual": string, "match": boolean }, "slsa_level": { "expected": string, "actual": string, "meets_minimum": boolean } }, "attestation_checks": [ { "attestation_type": string, "present": boolean, "signature_valid": boolean | null, "signer_identity": string | null, "policy_compliant": boolean, "finding": string } ], "policy_violations": [ { "rule": string, "severity": "BLOCKER" | "WARNING" | "INFO", "detail": string, "evidence": string } ], "missing_attestations": [string], "unsigned_artifacts": [string], "provenance_age_hours": number | null, "recommendation": "APPROVE" | "REJECT" | "MANUAL_REVIEW", "confidence": "HIGH" | "MEDIUM" | "LOW", "summary": string }

CONSTRAINTS

• If any required attestation type is missing, set verification_status to "FAILED" and recommendation to "REJECT".
• If the actual builder ID does not match the expected builder ID, flag as a BLOCKER policy violation.
• If provenance age exceeds the maximum, flag as a WARNING and set recommendation to "MANUAL_REVIEW".
• If signature validation cannot be performed due to missing public key material, set signature_valid to null and note the limitation in the finding.
• Do not assume attestation content is trustworthy; cross-reference subject digest with the provided package digest.
• If the attestation bundle is empty or unparseable, set verification_status to "INCONCLUSIVE" and confidence to "LOW".
• Cite specific fields from the attestation payload as evidence for each finding.

EXAMPLES

[FEW_SHOT_EXAMPLES]

RISK LEVEL

[RISK_LEVEL]

To adapt this template for your environment, replace the [FEW_SHOT_EXAMPLES] placeholder with 2–3 annotated examples showing correct verification reports for known-good and known-bad attestation bundles. Set [RISK_LEVEL] to HIGH if the package has network access or runs in a production path, or STANDARD otherwise—this controls the strictness of the model's recommendation logic. The [ACTUAL_ATTESTATION_PAYLOAD] should be the raw attestation bundle from your registry (e.g., Sigstore bundle, in-toto attestation, or custom format), inserted as a JSON block. If your attestation format differs from SLSA/in-toto conventions, add a [ATTESTATION_FORMAT_NOTES] section describing field mappings before the output schema. Always validate the model's JSON output against the schema before acting on the recommendation, and route any MANUAL_REVIEW or INCONCLUSIVE result to a human security reviewer.

This prompt is designed to operate as a gating step in a CI/CD pipeline or as an asynchronous security review task. It should never be the sole decision-maker for blocking a production deployment. The harness must treat the model's output as a structured recommendation that requires deterministic policy enforcement and, for high-risk findings, human review. The primary integration points are: a pre-receive hook on package registries, a pull request check for manifest or lock file changes, or a scheduled audit job that re-verifies attestations for already-deployed packages.

Wiring the prompt into an application requires a multi-stage pipeline. First, a data collection stage must gather the package's provenance attestation (e.g., from Sigstore, a DSSE envelope, or a vendor's transparency log), the package's checksum, and the organization's verification policy (allowed signers, source repositories, and builder IDs). This stage should fail closed if the attestation cannot be retrieved. Second, the prompt execution stage sends the collected data to the model with the prompt template, requesting a structured JSON output that conforms to the [OUTPUT_SCHEMA]. Use a model with strong JSON mode and low latency for this task, such as gpt-4o or claude-3.5-sonnet. Third, a deterministic validation stage must parse the model's JSON output and enforce hard policy rules: if the model flags a missing attestation or a signer mismatch, the pipeline must independently verify this against the raw attestation data before acting. This stage should also check that the model's output schema is valid and that all required fields are present. If validation fails, retry the prompt once with a more explicit [CONSTRAINTS] block that includes the validation error. If it fails again, escalate to a human.

Logging and observability are critical. Every prompt execution should log: the package name and version, the attestation source URL, the full prompt and model response, the validation result, and the final pass/fail decision. This audit trail is essential for debugging false positives and for proving compliance during external audits. For high-risk or regulated environments, the harness must include a human approval gate for any finding categorized as HIGH severity or for any case where the model's confidence score (if included in the output schema) falls below a defined threshold. The approval queue should present the human reviewer with a diff view: the expected provenance attributes versus the actual ones, along with the model's analysis. The reviewer's decision (approve, reject, or override) should be logged and fed back into the system to improve future policy tuning. Do not use this prompt for real-time blocking of critical systems without a manual override and a fast rollback path.