A good vulnerability ticket tells the person fixing it what is affected, why it matters, exactly what to change, who owns it, when it is due, and how to prove it is done. If any of those is missing, the ticket sits idle or bounces back with questions.
TL;DR
- A ticket is a work request, not an alarm.
- Include seven things: what, where, why it matters, the fix, the owner, the due date, and proof of done.
- Write for someone who has never seen the scanner report.
- One ticket per fix, not one per finding, when many findings share a fix.
Why do vulnerability tickets stall?
Picture a note on a fridge that says "plumbing problem, please fix." The person who reads it has to ask which tap, how bad, by when, and who pays. Most scanner tickets are like that note. They paste a long report and a severity label and hope someone figures out the rest.
The result is a queue of tickets nobody wants to open. Fixers lose time hunting for context. Security teams chase updates. Nothing closes.
A few terms. A vulnerability is a flaw in software that someone could misuse. A ticket is a tracked request in a tool such as an issue tracker. The fixer is whoever has to change the code or system, often a developer. For the vocabulary, see vulnerability, exploit and threat, and for the bigger picture read what vulnerability management is.
What are the seven parts of a good ticket?
1. What is affected?
Name the package and the exact version found. Add the CVE ID, which is the shared name for one known flaw, so the fixer can look it up. Example: package name, version 4.1.2, flaw ID.
2. Where does it live?
List the repository, the application or service, and the environment (production, test). If the package appears in several places, list them all or link to the list. This prevents the problem where a fix lands in one place and the flaw returns elsewhere. See why fixed vulnerabilities keep showing up.
3. Why does it matter?
Give two or three plain sentences. Is it on the CISA Known Exploited Vulnerabilities list, meaning there is reliable evidence of exploitation in the wild? Is the system open to the internet? Is the vulnerable code used by your program? This is the part that earns the priority label. Without it, severity is just a color.
FIRST, the non-profit that maintains CVSS, says a base score measures severity and should not be used alone to assess risk. So do not rely on the score alone in the ticket. Add the context that the score leaves out. Our post on what a CVSS 9.8 tells you explains why.
4. What exactly should the fixer do?
Be specific. "Upgrade package X from 4.1.2 to 4.1.5, the lowest version that removes the flaw." If the fix is a bigger jump, say so and note anything known to change. If there is no fix, write the interim step instead: restrict access, disable a feature, or add a filter, and name the follow up date.
5. Who owns it?
Give one named person or one named team. Not "engineering." A ticket with no single owner has no owner.
6. When is it due?
Set a date based on danger. A flaw on the exploited list that is reachable from the internet gets a short date. A low risk item gets a longer one. Write the reason for the date so the owner can push back with facts if needed.
7. How do we know it is done?
State the proof: "A new scan of the production image shows no finding for this flaw." Add where to find the scan. This avoids a ticket closed on faith.
What does the template look like?
| Field | Example text |
|---|---|
| Title | Upgrade example-parser to 4.1.5 in billing-api |
| What | example-parser 4.1.2, flaw ID attached |
| Where | billing-api repository, production and staging |
| Why it matters | On the known exploited list. Service faces the internet. Parser is called on every upload. |
| Fix | Upgrade to 4.1.5, the lowest fixed version. Run upload tests. |
| Owner | Named developer on the billing team |
| Due | Five days from today |
| Done when | Rescan of the production image shows no finding |
A worked example with invented numbers
These details are invented to show the idea. They are not from a real company.
A scan reports 14 findings that all trace to one outdated package, called example-parser, spread across 3 services. A weak setup creates 14 tickets with the same text pasted in. Two sit untouched for a month because each looks like a duplicate.
A better setup creates 3 tickets, one per service, each using the template. Each lists the single upgrade that clears all findings in that service. The owners differ, so each ticket has its own name. The due dates differ: the internet facing service gets 5 days, the internal tools get 30.
The result: the 14 findings close with 3 pieces of work, each with an owner who understood the task on first read.
Should you group findings or split them?
Group when many findings share one fix and one owner. Split when owners differ, when the fix sizes differ, or when one part is urgent and the rest is not. A good test: could one person close this ticket in one sitting or one pull request? If yes, it is a sensible size.
What about tickets for flaws you will not fix?
Some items will be accepted, not fixed, for a limited time. Write that as a decision record: the reason, the owner, the end date, and what will trigger a review. Read accepting an unfixable vulnerability for the details.
Try it yourself
Click through it at your own pace, or open it full screen. Follow one finding from detection to fix and notice which facts you would put in a ticket at each step.
How can Safeguard help?
Safeguard scans your dependencies and shows each finding with the affected package, the version and the fixed version when one is known, so the ticket facts are already assembled. Reachability analysis supplies the "why it matters" evidence. For many fixes, autonomous remediation can open a fix pull request instead of a ticket, but it is off by default and every category starts on Manual. The Safeguard CLI can also write code when a fix needs more than a version change. Start with the free scan at gold.safeguard.sh/scan.
Quick check
How long should a vulnerability ticket be?
Short enough to read in a minute. Use the seven parts and keep each to a sentence or two. Link to the full scanner report for detail.
Should the ticket include the full scan report?
No. Link to it. Paste only the facts the fixer needs: package, version, fix, and reason it matters.
What if nobody owns the affected system?
Assign an interim owner, such as the team lead of the nearest related service, and note it. An unowned ticket is the most common reason items go stale.
Sources
Last reviewed: 19 October 2026.
