Container Image Vulnerability Triage Prompt

This prompt is designed for platform security engineers and DevSecOps teams who receive a high volume of container image vulnerability scan results and need to separate signal from noise. The core job-to-be-done is to move beyond raw CVSS scores by assessing whether a vulnerable package is actually reachable in the running container's execution path. Use this prompt when you have a container image scan output (from tools like Trivy, Grype, or Snyk) and need a structured, runtime-informed prioritization list that accounts for entrypoint processes, network exposure, and loaded libraries. The ideal user has access to both the scan JSON and runtime context—such as a running process list, open port mapping, or filesystem mount details—to feed into the analysis.

Do not use this prompt when you lack runtime context and are working solely from a static image scan. Without process lists, network bindings, or filesystem usage data, the model cannot reliably assess reachability and will default to raw CVSS ranking, which defeats the purpose. Similarly, avoid this prompt for images that are not yet deployed or for which you cannot obtain a docker inspect or equivalent runtime snapshot. This prompt is also inappropriate for compliance-only workflows where every CVE must be patched regardless of exploitability; it is a prioritization tool, not a compliance checklist generator. For regulated environments, always route the final triage output through a human reviewer before closing findings.

Before using this prompt, gather the following inputs: (1) the raw vulnerability scan report in JSON format, (2) the output of ps aux or equivalent from a running container instance, (3) a list of listening ports and their associated processes, and (4) any known constraints such as network policies or seccomp profiles that limit exploitability. The prompt template expects these as structured inputs and will produce a ranked table with exploitability assessments. Next step: copy the prompt template from the following section, populate the placeholders with your scan and runtime data, and run it against a model that supports structured JSON output. Validate the results against a small set of manually triaged findings before scaling to your full image fleet.

This template is designed to be wired directly into a CI/CD or security pipeline. It takes the raw output from a container image scanner (like Trivy, Grype, or Snyk) and combines it with a runtime reachability analysis to move beyond raw CVSS scores. The goal is to reduce alert fatigue by focusing remediation efforts on vulnerabilities in packages that are actually loaded and executed, not just present in the image manifest. The prompt instructs the model to act as a security analyst, cross-referencing a vulnerability list with a runtime profile to produce a prioritized, evidence-backed triage report.

markdownCopy
You are a senior platform security engineer triaging container image vulnerabilities. Your task is to analyze a list of vulnerabilities found in a container image and determine which ones pose a genuine runtime risk.

You will be provided with two pieces of data:
1.  **VULNERABILITY_LIST:** A JSON array of objects from a container scanner. Each object contains `VulnerabilityID`, `PkgName`, `InstalledVersion`, `FixedVersion`, `Severity` (from the scanner, e.g., CRITICAL, HIGH), `CVSS` score, and a `Description`.
2.  **RUNTIME_PROFILE:** A JSON object detailing the packages and binaries that are actually loaded or executed in a running instance of this container. It includes a list of `LoadedPackages` and `ExecutedBinaries`.

**Your Task:**
For each vulnerability in the VULNERABILITY_LIST, determine if the vulnerable package is reachable based on the RUNTIME_PROFILE. A package is reachable if it appears in `LoadedPackages` or if any of its binaries are in `ExecutedBinaries`.

**Output Instructions:**
Produce a JSON object with the following structure. Do not include any text outside the JSON object.

[OUTPUT_SCHEMA]
{
  "triage_report": [
    {
      "vulnerability_id": "string",
      "package_name": "string",
      "cvss_score": number,
      "scanner_severity": "string",
      "runtime_reachable": boolean,
      "reachability_evidence": "string", // Explain why it is or is not reachable, referencing the RUNTIME_PROFILE.
      "effective_severity": "string", // One of: CRITICAL, HIGH, MEDIUM, LOW, INFO. Downgrade non-reachable CRITICAL/HIGH vulns to LOW.
      "remediation_priority": number // 1 (highest) to 5 (lowest). Priority 1 is for reachable CRITICAL vulns. Priority 5 is for non-reachable INFO vulns.
    }
  ],
  "summary": {
    "total_vulnerabilities": number,
    "reachable_critical_count": number,
    "reachable_high_count": number,
    "requires_immediate_action": boolean // True if any reachable CRITICAL vulnerability exists.
  }
}

[CONSTRAINTS]
- Base your analysis strictly on the provided VULNERABILITY_LIST and RUNTIME_PROFILE. Do not infer or assume other information.
- If the RUNTIME_PROFILE is empty or missing, set `runtime_reachable` to false for all vulnerabilities and add a warning to the `summary`.
- If a vulnerability is not reachable, its `effective_severity` must be downgraded to LOW, regardless of the CVSS score.
- Sort the `triage_report` array by `remediation_priority` in ascending order (most critical first).

---

[VULNERABILITY_LIST]
{{VULNERABILITY_LIST_JSON}}

[RUNTIME_PROFILE]
{{RUNTIME_PROFILE_JSON}}

To adapt this template, replace the {{VULNERABILITY_LIST_JSON}} and {{RUNTIME_PROFILE_JSON}} placeholders with your actual data. The VULNERABILITY_LIST should be the direct JSON output from your scanning tool, and the RUNTIME_PROFILE can be generated by tools like syft packages, a custom eBPF-based agent, or a dynamic analysis step in your CI pipeline. If you lack a runtime profile, you must modify the prompt's logic to avoid downgrading all findings; instead, you might instruct the model to prioritize based on known exploitability or network exposure. Always validate the model's JSON output against the provided schema before allowing it to pass to the next stage of your workflow, as a malformed JSON response could break automated ticket creation.

This prompt is designed to be integrated into a DevSecOps pipeline, not used as a one-off chat. The core workflow ingests a container image scan report (typically from tools like Trivy, Grype, or Snyk) and a runtime reachability analysis (from tools like Slim, Syft/Grype's cataloger, or a custom eBPF agent). The application layer must orchestrate these two data fetches, assemble the prompt, and parse the structured JSON output to update a vulnerability management system (e.g., DefectDojo, Jira, or a custom security dashboard). The model's primary job is to correlate static findings with runtime evidence and downgrade or escalate severity based on actual exposure, not just theoretical CVSS scores.

The implementation harness must enforce a strict contract. Before calling the LLM, validate that the [SCAN_REPORT] contains the required fields (VulnerabilityID, PkgName, InstalledVersion, FixedVersion, Severity) and that the [RUNTIME_EVIDENCE] provides a boolean or probabilistic assessment of package reachability. After the LLM call, validate the output JSON against a defined schema. If the model fails to produce valid JSON or omits required fields like effective_severity or rationale, implement a retry loop (maximum 2 retries) with a repair prompt that includes the validation error. If retries are exhausted, log the raw output and flag the image for manual triage. For high-risk deployments, route all CRITICAL effective severities to a human approval queue before allowing the pipeline to proceed.

Model choice matters here. This task requires strong instruction-following and structured output capabilities. A capable model like Claude 3.5 Sonnet or GPT-4o is recommended. Set the temperature low (0.0-0.1) to maximize deterministic, fact-based reasoning. Do not enable web browsing or other tools; the model must reason strictly from the provided [SCAN_REPORT] and [RUNTIME_EVIDENCE]. Log every prompt and response pair, including the model version, for auditability. This log becomes critical evidence for compliance reviews (e.g., SOC 2, FedRAMP) to demonstrate that vulnerability triage follows a consistent, documented process. Finally, avoid the anti-pattern of sending raw, unredacted scan reports that may contain internal image names or registry URLs to an external model endpoint without a data loss prevention (DLP) review.