Write the ticket so someone outside security can act on it without a meeting. Name the product and version, the component, why it matters in your environment, what you asked the supplier, who owns the follow-up, and the date you will look again. A finding with no owner and no date is a note, not work.
Why most SBOM tickets stall
A typical ticket reads "Component X in Supplier Y SBOM has CVE-ID, please fix." The assignee cannot fix it, because it is the supplier's code. They close it or let it sit.
The better framing is that the action is yours, even when the code is not: ask, mitigate, accept or replace. NTIA's minimum elements report describes SBOM data as input to processes. The ticket is where the process lives.
The fields that matter
| Field | What to write |
|---|---|
| Title | Supplier, product, component, short issue |
| Product and version | The exact version you run |
| Source of finding | Which SBOM, received on which date |
| Component and version | As listed, with package URL if present |
| Exposure | Where it runs, internet facing or internal, data touched |
| Supplier question | What you asked, when, and the reply due date |
| Interim step | Mitigation you apply while waiting |
| Owner | One named person |
| Review date | When you look again, even if nothing changed |
A worked example
Title: Acme Reports 4.2, logging library, known flaw. Product and version: Acme Reports 4.2.1, production. Source: SBOM received 12 October. Component: example-logger 1.3.0. Exposure: internal network only, processes customer exports. Supplier question: sent 14 October asking whether the flaw affects the shipped product, reply due 28 October. Interim step: restrict the reporting server to the finance subnet. Owner: the finance systems lead. Review date: 29 October.
That is under a hundred words and everything needed to continue is present.
Choosing the outcome
Every ticket should end in one of four outcomes. Make this explicit so closure has a meaning.
- Supplier confirms not affected. Record their justification. If they use VEX, the OpenVEX spec lists not_affected with justifications such as component_not_present.
- Supplier ships a fix. Verify you run the fixed version, then close.
- Accept the risk. A named person accepts it, with an end date.
- Replace the product. Open a separate project; this ticket links to it.
Keep it small
If one SBOM produces forty findings, do not open forty tickets. Group by supplier and severity, open one ticket for the top few, and put the rest in the body. Reviewers can handle five items; they cannot handle forty.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which details a finding carries that you would copy into a ticket.
Safeguard's SBOM and dependency scanning supply those details, and the free scan is at gold.safeguard.sh/scan.
Quick check
Who should own a ticket about a supplier's code?
The person who owns the relationship or the deployment, since the action is to ask, mitigate, accept or replace.
When can we close it?
When one of the four outcomes is recorded: not affected, fixed, risk accepted, or replacement planned.
Sources
Last reviewed: 19 October 2026.
