Safeguard
Security Guides•

What fields belong in a vulnerability report tracking record?

A simple case record for inbound vulnerability reports: the fields that keep response times honest and make advisories and audits easy later.

Safeguard Security Team
4 min read

A tracking record for inbound reports needs about a dozen fields: who reported it, what and where it affects, when each step happened, who owns it, the severity and status, and where the fix and advisory live. Keep it small enough that people fill it in.

Why a record at all

Email threads lose state. A case record makes you answer simple questions: how many reports did we get, how long until we replied, which are still open. CISA's directive lists metrics agencies report, including the number of reports, the number determined valid, the median age of open valid reports, the number older than 90 days, median time to validate, median time to remediate, and median time to initially respond. Those need dates captured at every step, so the record has to hold them.

A practical field list

GroupFieldNotes
IdentityCase IDOne per vulnerability, not per email
IdentityReporter name or handleAnd how they want to be credited
IdentityContact methodEmail, form or platform
ReportReceived dateStart of every clock
ReportAffected product and versionAs reported, then as confirmed
ReportSummaryOne or two sentences, no sensitive payloads
ReportWeakness typeFor example access control or injection
TriageStatusNew, acknowledged, confirmed, fixing, fixed, closed
TriageOutcomeValid, duplicate, out of scope, informational, not reproduced
TriageSeverity and vectorWith the assumptions you made
ResponseFirst reply dateYour response metric
ResponseOwnerOne named person
ResponseNext update duePrevents silent stalls
FixFix referencePull request or release
FixFixed in versionsFeeds the advisory
DisclosureCVE IDIf assigned
DisclosureAdvisory link and publish dateCloses the loop
DisclosureCredit and agreed publish termsAvoids surprises

You can drop fields that you will never read. Do not drop the received date, the first reply date and the owner.

Where to store the evidence

Keep the reproduction log and the original report in a restricted folder linked from the record, not pasted into the ticket body. If you use a general issue tracker, mark the project private and limit membership, because access control is part of handling reports safely.

Status definitions to agree on

  • Acknowledged: a human replied.
  • Confirmed: you reproduced the effect.
  • Fixing: a change is in progress with an owner.
  • Fixed: the fix is released, not just merged.
  • Closed: the reporter was told the outcome.

The BOD 20-01 targets treat acknowledgment, initial assessment and resolution as the three milestones, each with a recommended time limit. Build those three into your record and you will have the timeline data you need.

Review rhythm

Once a week, the case reviewer sorts open cases by next update due and sends any overdue updates. Once a quarter, compute the medians above and ask whether they match what your disclosure policy promises. The post on response times you can keep helps with that.

Quick check

Should the record include the exploit details?

Link to them in a restricted location instead. The record is read by more people than the proof of concept should be.

Do I need a special tool?

No. A private spreadsheet or a private tracker project works if the fields are filled in and access is limited.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.