Transitive Dependency Vulnerability Reachability Prompt

Security scanners flag CVEs in transitive dependencies constantly. Most are not exploitable in your specific application because the vulnerable function is never called, the vulnerable code path is unreachable, or compensating controls neutralize the risk. This prompt takes a CVE advisory, your application's dependency graph, and relevant source code to produce a structured reachability assessment. Use it when you need to prioritize hundreds of dependency alerts and cannot manually trace each call path. The ideal user is a security engineer or platform engineer who understands the application's architecture and can provide accurate dependency graphs and source snippets. Without this context, the model cannot produce a reliable assessment.

The prompt requires three concrete inputs to function: a CVE advisory with the vulnerable package, version range, and vulnerable function signatures; a dependency graph showing how the vulnerable package is pulled into your application, including all intermediate packages in the transitive chain; and source code snippets from your application that import or use the affected dependency, even indirectly. The model traces call paths from your code through the dependency graph to determine if the vulnerable function is ever invoked. It produces a confidence-scored assessment with specific evidence citations for each call path analyzed. This is not a replacement for static analysis tools or runtime profiling—it is a triage accelerator that helps you focus manual review effort on the dependencies that actually matter.

Do not use this prompt as the sole decision-maker for production-blocking remediation. A 'not reachable' finding from this prompt should never be the only evidence used to close a critical or high-severity vulnerability ticket. Always require human review for high-severity findings and validate call path evidence against actual code before dismissing a vulnerability. The model can miss indirect call paths through reflection, dynamic dispatch, dependency injection frameworks, or runtime configuration. It also cannot assess vulnerabilities triggered by data flow rather than control flow, such as deserialization gadgets or prototype pollution chains. For those cases, supplement this prompt with dynamic analysis or manual code review. Use this prompt to reduce the triage queue from hundreds of alerts to the handful that warrant deep investigation.

This prompt template is designed to be pasted directly into your AI workflow. It instructs the model to act as a security engineer, tracing call paths from your application code through the dependency graph to determine if a specific CVE is reachable. The template uses square-bracket placeholders for all dynamic inputs—replace these with real data from your codebase, package manifests, and vulnerability scanners before execution. The output is a structured reachability analysis with a confidence score and evidence citations, making it suitable for integration into a security review pipeline or ticketing system.

textCopy
You are a senior application security engineer. Your task is to perform a reachability analysis for a reported CVE in a transitive dependency.

## INPUT DATA
- **Application Code (relevant excerpts):**
  [APPLICATION_CODE]
- **Dependency Graph (from lock file or SBOM):**
  [DEPENDENCY_GRAPH]
- **CVE Details:**
  [CVE_DETAILS]
- **Known Safe Patterns (functions/versions not affected):**
  [SAFE_PATTERNS]

## CONSTRAINTS
- Only analyze call paths that originate from [APPLICATION_CODE].
- Do not assume exploitability without a concrete, traceable call path.
- If the vulnerable function is imported but never called, classify it as "Unreachable."
- If the vulnerable code path requires a specific configuration that is not present, note this as a mitigating factor.
- Cite specific file paths, function names, and line numbers as evidence.

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "cve_id": "string",
  "package_name": "string",
  "vulnerable_version": "string",
  "installed_version": "string",
  "reachability_assessment": "Reachable | Potentially Reachable | Unreachable | Insufficient Evidence",
  "confidence_score": 0.0-1.0,
  "call_paths": [
    {
      "path": ["file.function()", "...", "vulnerable_function()"],
      "evidence": "string describing how this path was determined",
      "requires_user_input": true/false,
      "requires_specific_config": true/false
    }
  ],
  "mitigating_factors": ["string"],
  "remediation_priority": "Critical | High | Medium | Low | Informational",
  "summary": "string"
}

## RISK LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

To adapt this template, start by replacing [APPLICATION_CODE] with the specific files or functions that import or use the affected dependency. The [DEPENDENCY_GRAPH] should be a machine-readable representation of your full dependency tree, such as the output of npm ls --all or a CycloneDX SBOM. For [CVE_DETAILS], paste the full CVE record including the vulnerable function names, version ranges, and attack vector. The [RISK_LEVEL] placeholder should be set to the context's risk tolerance, which influences the model's remediation priority. The [EXAMPLES] placeholder can be populated with one or two few-shot examples of correct analyses to improve consistency. After generating the output, always validate the JSON structure and verify that each cited call path exists in your actual codebase—this is a high-risk workflow where hallucinated paths can lead to wasted remediation effort or a false sense of security.

This prompt is designed to operate as a gated analysis step within a CI/CD pipeline or a periodic security scanning workflow, not as a one-off chat interaction. The harness must receive a structured input payload containing the CVE identifier, the affected package name and version, the project's full dependency graph (from a lock file or SBOM), and a set of call path snippets extracted from the application codebase. The prompt's output—a reachability assessment with a confidence score and evidence citations—should be treated as a machine-readable signal that feeds into a vulnerability management system, not as a final human-readable report. The implementation must enforce strict input validation before the prompt is ever called, ensuring that the dependency graph is complete and that the call path extraction has been performed by a deterministic static analysis tool, not by the model itself.

Wire the prompt into your workflow by first building a pre-processing step that uses a tool like grep, semgrep, or a language-specific call graph analyzer to find all import statements and function invocations that touch the vulnerable package or its dependents. This evidence must be packaged into the [CALL_PATH_EVIDENCE] placeholder as a structured list of file paths, line numbers, and function signatures. The prompt should be called with a model that supports structured output (JSON mode) and a low temperature setting (0.0–0.1) to maximize deterministic behavior. Implement a post-processing validator that checks the output schema for required fields (reachability_assessment, confidence_score, evidence_citations, analysis_summary), rejects any response with a confidence score below a configurable threshold (e.g., 0.7) for manual review, and logs the full prompt and response payload for auditability. For high-risk findings, route the result to a human security engineer via a ticketing system or approval queue before any automated suppression or closure occurs.

Avoid wiring this prompt directly to raw lock files without pre-processing. The model cannot reliably perform static analysis on large dependency graphs; it will hallucinate call paths if asked to invent them. Instead, treat the prompt as a reasoning engine over pre-computed evidence. Implement retries with exponential backoff for transient API failures, but do not retry on validation failures—those should escalate immediately. For production deployments, consider caching results per unique (CVE, package, version, call-path-hash) tuple to avoid redundant API calls. The next step after implementation is to build a regression test suite using known-vulnerable and known-safe dependency configurations to measure the prompt's false-positive and false-negative rates before enabling it as a blocking gate in your merge or release pipeline.