A ticket for a security news item should hold seven things: the primary source link, the component and version named, whether you run it, the exposure answer, a decision, an owner and a due date. Keep it short. Its job is to turn "I saw this" into a recorded answer.
Why a template helps
Security news arrives through chat, email and feeds. Without a standard ticket, one person replies "looks fine" in a thread, and three weeks later nobody can show what was checked. A template makes the minimum check the same every time and leaves a record for the next reviewer.
The template
Copy this into your tracker as a form or a saved description.
- Source: link to the primary source, such as the vendor advisory or the project's security page. Add secondary links only as context.
- Named component: product or library, and the affected version range from the source.
- Do we run it? Yes, no or unknown. If unknown, the first task is to find out from your inventory.
- Where? Services, images, devices or SaaS accounts that include it.
- Exposure: is the vulnerable feature reachable or enabled in our setup? Say how you know.
- Decision: act now, schedule, watch, or not affected. Use one word.
- Owner and date: one named person and a due date, or a review date for watch items.
A worked example
| Field | Entry |
|---|---|
| Source | Link to the vendor advisory |
| Named component | A message broker library, versions before the fixed release |
| Do we run it? | Yes, in two services |
| Where? | Orders service, billing worker |
| Exposure | The affected feature is a management endpoint, which is only reachable on the internal network |
| Decision | Schedule |
| Owner and date | Named engineer, upgrade by the next sprint end |
Notice that the decision is not "ignore". An internal only endpoint lowers urgency, but the upgrade is still scheduled, and the reasoning is written down.
Rules that keep tickets honest
- Primary source first. If you cannot find one, set the decision to "watch" and say the claim is unconfirmed. See primary vs secondary sources in security news.
- One ticket per component, not per article. Five articles about one issue should link to one ticket.
- No "unknown" at close. A ticket cannot close with the inventory question unanswered.
- Name the check. "Checked" is not evidence. "Searched the lock files in these repositories on this date" is.
- Set an end. Watch items get a review date, so they do not sit forever.
Wiring it up
Add the template as an issue form in your tracker. Create a chat shortcut that opens it. Add labels for the four decisions so you can count how many items fell in each bucket each month. For a decision scale, see track, attend, act.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding carries an owner, a status and a due date.
Where Safeguard fits
Safeguard's SBOM and dependency scanning answers the "do we run it, and where" fields from data, and its compliance and evidence automation can keep the decision record. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Do I need a ticket for every article?
No. Only for items that name something you might run. Link several articles about one issue to a single ticket.
Can a ticket close as "not affected"?
Yes, if it records what you checked and when.
Last reviewed: 19 October 2026.
