How to Use the Syft and Grype SBOM Triage Prompt to Fix the Vulnerabilities That Matter First
Triage container image vulnerabilities from a Syft SBOM and Grype scan: exact commands, findings grouped into fixable now, not fixed upstream, and will not fix, notes on whether the vulnerable code is actually used at runtime, documented .grype.yaml ignore rules, a CI fail gate, and a grouped fix PR plan.
Running a vulnerability scanner is easy. Deciding what to do with the results is the hard part. A typical container image scan returns a mix of findings: some with a fix available, some the upstream distribution will not fix, some in packages that only run at build time, and duplicates from vendored copies. Without triage, teams either ignore everything or block every build. The Syft and Grype SBOM Vulnerability Triage Reviewer: CycloneDX SBOM Scan, Fixable vs Not Fixed Findings, Runtime Exposure Notes, Grype Ignore Rules With Reasons, and a Fix PR Plan prompt turns a Syft SBOM and Grype results into a sorted list, documented ignore rules, and a fix plan.
What the prompt produces
- Exact commands to generate a CycloneDX SBOM with Syft and scan it with Grype, with flags that match your fail policy.
- A deduplicated findings table grouped into fixable now, not fixed upstream, and will not fix.
- Runtime exposure notes stating whether each vulnerable package runs at runtime, at build time only, or not at all, as judgments to verify.
- Grype ignore rules for .grype.yaml, each naming one vulnerability and package with a reason and review date.
- A fix PR plan that separates dependency pins from base image refreshes.
- A CI gate snippet that fails the build per your policy and uploads the SBOM.
- A team summary of what is fixed, what is accepted, and why.
How to fill the inputs
ImageOrRepo names the image, base image, and runtime.
SyftVersionAndSBOM gives the Syft version and SBOM format, such as CycloneDX JSON.
GrypeFindings is pasted from the Grype output: package, installed version, fixed in version, type, vulnerability ID, severity, and fix state. The prompt uses only these IDs and versions.
RuntimeContext explains which packages actually load at runtime, network exposure, and the user the process runs as. This is what makes the triage useful.
ExistingIgnoreConfig is your current .grype.yaml, if you have one.
FailPolicy is the rule your team agreed on, such as failing on High or Critical findings that have a fix.
Reading the example output
The example scans a Python API image built on a slim Debian base. Three findings have fixes: a High in setuptools and two Mediums in requests and idna. A Critical in zlib is marked will not fix by the distribution, and the vulnerable part of the library is not used by the app.
The output dedupes setuptools, which appeared twice from two install paths, and notes that setuptools runs only at build time but still blocks the build under the policy because it is High with a fix. The requests and idna fixes ship together because idna comes in through requests.
The zlib finding gets a single ignore rule with the vulnerability ID, package name, version, and type, plus a comment with the reason, owner, and review date. There is no blanket ignore by severity. The fix plan splits the work into a dependency pin PR and a base image refresh, each with the test to run.
Tips for better results
- Keep the SBOM as a build artifact so you can rescan old releases when new vulnerabilities are published.
- Review every ignore rule on its date. Reasons go stale.
- Remove build tools from the final image stage where you can.
- Paste RuntimeContext from someone who knows the service, not a guess.
Mistakes to avoid
- Do not ignore findings by severity level. Name each one.
- Do not treat runtime exposure notes as proof. Verify them.
- Do not let the model invent CVE IDs or fixed versions.
Who it is for
Application security engineers, platform teams that own CI pipelines, and developers who maintain containerized services.
A practical routine
Run the scan on every pull request, run the prompt weekly on the main branch results, and review ignore rules at the start of each quarter.
Related PromptDig links
Triage your next scan with the Syft and Grype SBOM Vulnerability Triage Reviewer: CycloneDX SBOM Scan, Fixable vs Not Fixed Findings, Runtime Exposure Notes, Grype Ignore Rules With Reasons, and a Fix PR Plan prompt. For more developer and DevOps prompts, Browse more prompts. If you have a security workflow that saves your team time, Share a prompt.