A vulnerability report tracker needs fourteen fields at most: case ID, received date, source, reporter contact and credit preference, affected product and versions, summary, state, owner, severity vector, next update date, promised dates, linked fix, advisory or CVE, and outcome. Keep it private, with access limited to the response team.
Why a tracker at all
Reports arrive by email, forms and chat. Without a single list, a case slips between people. A tracker gives you the dates you need for a timeline, the owner for each case, and the evidence that you followed your own policy.
The fields
| Field | Why |
|---|---|
| Case ID | Stable reference that does not reveal details |
| Received date | Starts the clock |
| Source | Email, form, platform, public post |
| Reporter and credit preference | Contact and how to name them |
| Affected product and versions | Scope |
| Summary | One or two neutral sentences |
| State | See below |
| Owner | One named person |
| Severity and vector | The vector string, not only a number |
| Next update date | The date you promised the reporter |
| Target dates | Fix and publish, with the reason if they move |
| Linked fix | Commit, branch or pull request |
| Advisory or CVE | Identifier once assigned |
| Outcome | Fixed, duplicate, not reproducible, by design, out of scope |
States
Keep them few:
- Received
- Acknowledged
- Validating
- Confirmed
- Fixing
- Released
- Published
- Closed
Add a side state, Waiting on reporter, with a date after which you chase. The six phases in the CERT Guide to CVD, from discovery to deployment, map neatly to these states if you want a reference.
Where to keep it
Somewhere private. A private repository, a restricted project in your issue tracker, or an access controlled spreadsheet will work. Avoid putting details in a public issue tracker or a team wide chat channel. Limit access to the response team, because a leak from your tracker is a leak of unfixed vulnerabilities.
Habits that make it useful
- Update the state when you act, not at the end of the week.
- Never delete a case. Close it with an outcome.
- Review open cases weekly in a ten minute meeting.
- Look for cases with a past next update date. Those are the ones to fix first.
- Keep a template for the first reply and the advisory.
Measure from it
With dates in place you can compute the gaps between steps: acknowledgement time, validation time, fix time. See measuring a small team's vulnerability response.
Try it yourself
The continuous monitoring demo shows items moving through states while the overall picture stays visible. Look for how open items remain on screen until resolved.
Click through it at your own pace, or open it full screen.
Quick check
Can we use our normal ticket system?
Yes, if you can restrict access to the security team. Otherwise use a separate private project.
Should the tracker include the exploit details?
Link to them in a private, access controlled location rather than pasting them into many places.
Safeguard's compliance and evidence automation can help keep dated records you may later need to show a customer. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
