Dependency Vulnerability Scan Prompt Template

This prompt is designed for DevSecOps teams and security engineers who need to move from raw CVE data to an actionable remediation plan. It takes a software bill of materials (SBOM), a parsed lockfile, or a dependency manifest as input and produces a prioritized vulnerability report. The core job-to-be-done is not just listing CVEs, but connecting them to affected dependency chains, assessing exploitability in the context of your application, and specifying concrete upgrade or mitigation paths that developers can execute immediately. Use this when your existing software composition analysis (SCA) tool provides a flood of findings and you need a structured reasoning layer to triage, deduplicate, and translate those findings into engineering tasks.

This prompt assumes you have already generated an SBOM (e.g., via Syft, CycloneDX, or a build plugin) or parsed a lockfile and have access to a CVE database or advisory feed such as GitHub Advisory Database, OSV, or a commercial SCA API. The prompt template expects placeholders for [SBOM_INPUT], [CVE_FEED], and [APPLICATION_CONTEXT]—the latter being critical for exploitability assessment. Without application context (e.g., deployment environment, exposed attack surface, runtime configuration), the model cannot distinguish between a critical CVE in a test-only transitive dependency and one in a production-facing library. Do not use this prompt as a replacement for a dedicated SCA tool; it does not perform the initial CVE-to-dependency matching. Instead, it provides a reasoning and prioritization layer on top of existing scan results.

Avoid using this prompt when you lack a complete or recent SBOM, when the CVE feed is stale, or when the dependency graph is too large to fit in a single context window without chunking. For repositories with thousands of dependencies, you should pre-filter the input to include only direct and high-impact transitive dependencies, or split the analysis across multiple invocations grouped by dependency subsystem. Additionally, this prompt is not a substitute for human security review when findings involve critical production services, regulatory compliance (e.g., PCI DSS, HIPAA), or vulnerabilities with active exploitation in the wild. In those cases, the output should feed into a human-in-the-loop review queue with evidence links and risk justifications intact.

This template is designed to be populated with structured data from your Software Bill of Materials (SBOM) generator or Software Composition Analysis (SCA) tool. Before sending this prompt to the model, replace each square-bracket placeholder with the corresponding output from your toolchain. The prompt instructs the model to act as a DevSecOps analyst, correlating package manifests and lockfile data against known vulnerability databases to produce a prioritized, actionable report.

textCopy
You are a DevSecOps analyst reviewing a dependency manifest and associated vulnerability data.

Your task is to produce a prioritized vulnerability report based on the provided inputs.

# INPUT DATA

## SBOM / Dependency Tree
[SBOM_DATA]

## CVE / Vulnerability Feed
[CVE_FEED]

## Environment Context
[ENVIRONMENT_CONTEXT]

# CONSTRAINTS
- Only report on vulnerabilities with a CVSS score of [MIN_CVSS_SCORE] or higher.
- Ignore vulnerabilities in devDependencies unless they are exploitable in the build pipeline.
- If a fix version is available, you must include it in the remediation path.
- If no fix is available, suggest a concrete mitigation or workaround.
- Do not fabricate CVE IDs or CVSS scores. If the data is insufficient to make a determination, state that explicitly.

# OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "report_summary": {
    "total_dependencies_scanned": "number",
    "vulnerable_dependencies_found": "number",
    "critical_vulnerabilities": "number",
    "high_vulnerabilities": "number",
    "scan_timestamp": "ISO 8601 string"
  },
  "findings": [
    {
      "cve_id": "string",
      "cvss_score": "number",
      "severity": "Critical | High | Medium | Low",
      "affected_package": "string",
      "current_version": "string",
      "fixed_version": "string or null",
      "dependency_chain": ["string"],
      "exploitability_notes": "string",
      "remediation": "string",
      "mitigation_if_no_fix": "string or null"
    }
  ],
  "unresolved_issues": ["string"]
}

# RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by ensuring your [SBOM_DATA] is a complete and machine-readable representation of your dependency graph, such as a CycloneDX or SPDX JSON object. The [CVE_FEED] should be a structured list of relevant CVEs, ideally from a recent database dump or API response. Use [ENVIRONMENT_CONTEXT] to specify runtime details like the deployment environment (e.g., 'AWS Lambda, Node.js 20.x') or build pipeline exposure, which helps the model assess exploitability. Set [MIN_CVSS_SCORE] to your organization's action threshold, typically 7.0 for high-severity issues. The [RISK_LEVEL] field should contain a brief statement about your risk tolerance, such as 'Internet-facing production service handling PII,' to guide the model's prioritization and language in the report. After receiving the output, always validate the JSON structure against the defined schema and verify that reported CVE IDs and scores match your source feed to prevent hallucination.

The Dependency Vulnerability Scan prompt is designed to be called from a CI/CD pipeline step, a scheduled security scanner, or an on-demand triage tool. The harness must supply the prompt with a complete software bill of materials (SBOM) or parsed lockfile content, a CVE database snapshot timestamp, and the target environment context. Because the output drives remediation tickets and risk decisions, the harness must validate the response structure before any finding reaches a developer or security engineer.

Wire the prompt into an application by first assembling the input context: parse package-lock.json, Cargo.lock, poetry.lock, or equivalent into a normalized dependency tree with resolved versions. Attach a CVE feed freshness timestamp so the model can qualify its confidence. After the model responds, validate the output against a strict JSON schema that requires cve_id, affected_package, current_version, fixed_version, cvss_score, exploitability, dependency_chain, and remediation fields. Reject any finding where cve_id is missing or cvss_score is outside 0.0–10.0. Log schema validation failures and retry once with the error message appended to the prompt as a correction hint. If the retry also fails, route the raw output to a human review queue rather than silently dropping it.

For high-risk repositories—those handling customer data, authentication, or financial transactions—add a mandatory human approval gate for any finding with cvss_score >= 7.0 or exploitability marked as 'active' or 'public PoC'. The harness should create a ticket with the finding, the affected dependency chain, and a link to the relevant CVE advisory, then block the pipeline until a security engineer acknowledges it. For lower-risk findings, the harness can auto-file issues with the remediation guidance already formatted. Avoid wiring this prompt directly into auto-merge or auto-deploy gates without human review; a stale CVE database or a model hallucination could block releases unnecessarily or, worse, let a real vulnerability through.