SBOM Generation and Review Prompt Template

This prompt is for platform and security engineering teams that need to generate or review a software bill of materials (SBOM) from a dependency update. Use it when a pull request modifies a package manifest or lock file and you need a structured inventory of every component, version, supplier, and license before merge. The prompt produces an SBOM in a machine-readable format and runs completeness checks against the dependency graph to flag missing or phantom entries.

The ideal user is a developer or DevSecOps engineer reviewing a dependency update PR, or an automated CI/CD pipeline that gates merges on SBOM completeness. Required context includes the full diff of the package manifest and lock file, the project's dependency graph, and any existing SBOM for comparison. The prompt expects structured input: the changed files, the resolved dependency tree, and a target output schema such as SPDX or CycloneDX. Without this context, the model cannot verify that every transitive dependency is accounted for.

Do not use this prompt for runtime dependency analysis, vulnerability scoring, or license compliance decisions. It is a generation and structural review tool, not a policy engine. For vulnerability reachability analysis, use the Transitive Dependency Vulnerability Reachability Prompt. For license compliance, use the Dependency License Compliance Review Prompt. This prompt stops at producing a verified inventory; downstream decisions require separate, purpose-built workflows with human review for high-risk findings.

The following prompt template is designed to be copied directly into your AI orchestration layer, test suite, or evaluation harness. It accepts a dependency update context—such as a lock file diff, a package manifest change, or a changelog—and produces a structured SBOM with component inventory, version, supplier, license, and completeness checks. Every placeholder is enclosed in square brackets and must be replaced with real data before execution. The prompt is self-contained and does not depend on the rest of this playbook to function.

textCopy
You are an SBOM generation assistant for platform and security engineering teams. Your task is to produce a Software Bill of Materials (SBOM) from the provided dependency update information. The output must be a structured JSON object that can be ingested by compliance, vulnerability management, and inventory systems.

## INPUT
[DEPENDENCY_UPDATE_CONTEXT]

## OUTPUT SCHEMA
Return a single JSON object with the following structure. Do not include any text outside the JSON object.

{
  "sbom": {
    "format": "CycloneDX",
    "specVersion": "1.5",
    "serialNumber": "urn:uuid:[GENERATE_A_UNIQUE_UUID]",
    "version": 1,
    "metadata": {
      "timestamp": "[ISO_8601_TIMESTAMP]",
      "tools": [
        {
          "vendor": "Inference Systems",
          "name": "SBOM Generation Prompt",
          "version": "1.0"
        }
      ],
      "component": {
        "type": "application",
        "name": "[APPLICATION_NAME]",
        "version": "[APPLICATION_VERSION]"
      }
    },
    "components": [
      {
        "type": "library",
        "name": "[COMPONENT_NAME]",
        "version": "[COMPONENT_VERSION]",
        "purl": "[PACKAGE_URL]",
        "supplier": {
          "name": "[SUPPLIER_NAME]"
        },
        "licenses": [
          {
            "license": {
              "id": "[SPDX_LICENSE_ID]"
            }
          }
        ],
        "hashes": [
          {
            "alg": "SHA-256",
            "content": "[INTEGRITY_HASH]"
          }
        ],
        "scope": "required",
        "evidence": {
          "identity": {
            "field": "purl",
            "confidence": 1.0,
            "methods": [
              {
                "technique": "manifest-analysis",
                "confidence": 1.0,
                "value": "[MANIFEST_FILE_PATH]"
              }
            ]
          }
        }
      }
    ],
    "dependencies": [
      {
        "ref": "[COMPONENT_REF]",
        "dependsOn": ["[DEPENDENCY_REF]"]
      }
    ]
  },
  "completeness_checks": {
    "total_declared_dependencies": [INTEGER],
    "total_enumerated_in_sbom": [INTEGER],
    "missing_from_sbom": ["[MISSING_COMPONENT_NAME]"],
    "unexpected_in_sbom": ["[UNEXPECTED_COMPONENT_NAME]"],
    "completeness_score": [FLOAT_BETWEEN_0_AND_1],
    "warnings": ["[WARNING_MESSAGE]"]
  }
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## TOOLS
[TOOLS]

## RISK LEVEL
[RISK_LEVEL]

## INSTRUCTIONS
1. Parse [DEPENDENCY_UPDATE_CONTEXT] to identify every direct and transitive dependency being added, removed, or updated.
2. For each dependency, extract or infer the component name, version, package URL (purl), supplier, SPDX license identifier, and SHA-256 integrity hash.
3. Populate the `components` array with one object per dependency.
4. Populate the `dependencies` array to reflect the dependency graph, using the component's purl as the `ref`.
5. Run completeness checks by comparing the total number of dependencies declared in the input against the number you enumerated in the SBOM. Flag any discrepancies in `completeness_checks`.
6. If [RISK_LEVEL] is "high", include a `confidence` field in each component object indicating your certainty in the extracted data (0.0 to 1.0).
7. If [TOOLS] includes a package registry lookup function, call it to verify supplier and license data when confidence is below 0.8.
8. Do not fabricate data. If a field cannot be determined, set its value to `null` and add a warning to `completeness_checks.warnings`.
9. Return only the JSON object. No markdown fences, no explanatory text.

To adapt this template for your environment, replace each square-bracket placeholder with real data or a reference to your application's variable store. The [DEPENDENCY_UPDATE_CONTEXT] placeholder should receive the raw diff, manifest change, or changelog text. The [CONSTRAINTS] placeholder can inject additional rules, such as "only include production dependencies" or "exclude devDependencies with scope: optional." The [EXAMPLES] placeholder is optional but recommended for complex ecosystems; provide one or two few-shot examples of correct SBOM components for your language or package manager. The [TOOLS] placeholder should list any functions the model can call, such as a package registry API or a license database lookup. The [RISK_LEVEL] placeholder accepts "low," "medium," or "high" and controls whether confidence scoring is required. After adapting the template, run it against a known-good dependency set and validate the output JSON against your SBOM schema before integrating it into a CI pipeline or compliance workflow.

This prompt is designed to be called programmatically as part of a dependency update review pipeline, not as a one-off chat interaction. The typical integration point is a CI/CD job that triggers when a package-lock.json, yarn.lock, Cargo.lock, or equivalent manifest file changes in a pull request. The application layer is responsible for extracting the dependency graph from the lock file, formatting it as structured input, and injecting it into the [DEPENDENCY_GRAPH] placeholder. The model should never receive raw lock file text; pre-parsing ensures the model focuses on analysis rather than format interpretation.

Validation and retry logic is critical because the output must be machine-readable. After the model returns a response, the application layer must parse the JSON output and validate it against the expected SBOM schema: check that all required fields (component, version, supplier, license, relationship) are present for each entry, that version strings match the input graph, and that no components are missing. If validation fails, implement a single retry with the validation error message appended to the prompt as additional [CONSTRAINTS] context. After two failed attempts, escalate to a human reviewer queue rather than looping indefinitely. For high-risk repositories (e.g., production infrastructure, regulated systems), always require human approval on the final SBOM before it is committed to the attestation store.

Model choice and tool use should favor models with strong structured output support. Use constrained decoding or JSON mode when available to reduce malformed output. This prompt does not require tool calling or RAG in its base form, but if your pipeline includes a vulnerability database lookup, consider splitting the workflow: first generate the SBOM with this prompt, then pass the structured component list to a separate advisory matching tool or prompt. Log every SBOM generation with the prompt version, model, input hash, and validation result for auditability. Avoid running this prompt on every commit; trigger it only on dependency manifest changes to control cost and latency.