Your news triage is working if people get a first answer quickly, answers rest on evidence, open items get rechecked, you rarely hear about relevant news late, and the process does not eat the team's week. Five light measures cover those five goals, and you can track them in a spreadsheet.
Why measure at all
Without measures, news triage feels fine until it fails. A team can believe it is calm while answers take two days, rest on guesses and never get revisited. Measuring a few simple things turns a feeling into something you can improve.
Keep it small. A scorecard that takes an hour a week to maintain will be dropped. Aim for ten minutes.
What to log for each news item
Create one row per item in a sheet or ticket label. Capture these fields:
| Field | Example |
|---|---|
| Item and source link | Maintainer notice for package X |
| Time first seen (UTC) | 08:55 |
| Time of first answer (UTC) | 09:40 |
| Type | Vulnerability, malicious release, vendor breach, other |
| Verdict | Affected, not affected, unclear |
| Evidence attached | Yes or no |
| Recheck scheduled | Yes or no, with time |
| How you learned of it | Feed, colleague, customer, press |
| Effort | Rough minutes spent |
If you already use a ticket template, add the missing fields. See the post on a ticket template for security news.
The five measures
1. Time to first answer. From first seen to a written status note that says what you know, what you do not, and when you will check next. The three line note works well for this. Watch the median and the slowest cases. The aim is a steady, short first answer, not a fast final one.
2. Evidence rate. Of items with a verdict, what share has evidence attached, such as a search result, a build log or a compared version? A verdict without evidence is a guess that happened to be written down. A healthy trend is up.
3. Recheck rate. Of items still open, what share has a scheduled recheck? Records change after publication, and an item without a recheck time tends to be forgotten. Aim for all open items.
4. Late discovery count. How many times did you learn about relevant news from a customer, a colleague outside the team or the press, instead of your own sources? Each is a gap in your feeds. The target is low, and every instance deserves a short note on why.
5. Noise ratio. What share of items reviewed turned out not to be relevant to your stack? Some noise is normal. If most of what you read is irrelevant, your filters are too wide. If you never see anything irrelevant, they may be too narrow. The post on following advisories for only the packages you use helps tune this.
A worked example
A team of six logs 12 items over a month. Reading the sheet:
- Median time to first answer was 35 minutes, with one item at four hours because it arrived on a Saturday.
- Nine of the 12 had a verdict with evidence attached. Three were closed on a colleague's say so.
- Two items were still open, and only one had a recheck time.
- One item came from a customer email before the team saw it.
- Seven of the 12 were not relevant to the stack.
What does the team do with this? They set a rule that no verdict closes without evidence, add a recheck time to the open item, look into why the customer-reported item was missed and add that source to the feeds, and decide that seven of 12 irrelevant is acceptable but worth trimming. The Saturday case leads to a short weekend coverage note.
None of this required a dashboard. It required a sheet and fifteen minutes at month end.
Cautions
Be careful what you reward. If you praise speed alone, people will skip evidence. If you praise a low noise ratio alone, people will narrow filters until they miss things. Look at the five measures together.
Do not use the measures to compare individuals. They are about the process. People who feel measured will hide uncertainty, which is the opposite of what you want.
Resist adding more measures. Five is plenty. If a sixth question matters, replace one of the five.
A monthly review in 15 minutes
- Open the sheet and compute the five measures.
- Pick the one with the biggest gap.
- Decide one change, such as a new feed, a stricter close rule or a weekend note.
- Write the change and the owner at the top of next month's sheet.
- Check next month whether the measure moved.
One small change a month beats a large redesign that never ships.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped by package and version, and think about which fields you would want to log for each news item.
Safeguard's SBOM and dependency scanning and its policies and gates can supply some of the evidence behind these measures, such as which packages and versions you run.
Quick check
What is the most important of the five measures?
Evidence rate. A fast answer that rests on a guess is worse than a slightly slower answer that rests on a search result or a build log.
Do I need special tools to track these?
No. A spreadsheet or a few ticket fields are enough. The value comes from the monthly review, not from the tooling.
Should we compare team members on these numbers?
No. Use them to improve the process. Comparing individuals encourages people to hide uncertainty.
Last reviewed: 19 October 2026.
