What should a vulnerability triage note say? A six line template

A good vulnerability triage note has six lines: what the finding is, the facts you checked, the evidence, your decision, the owner and date, and the trigger to look again. A stranger should be able to read it six months later and agree or disagree with it. If the note just says "not an issue," it is not enough.

TL;DR

• A triage note is the written reason behind a decision on a vulnerability alert.
• Six lines are enough: finding, facts, evidence, decision, owner and date, recheck trigger.
• Four decision types cover nearly every case: fixed, affected, not affected, under investigation.
• Good notes save time later with auditors, customers and new teammates.

Definition: triage note. A short written record of why an alert was handled the way it was. It states the facts checked, the decision, and who made it. Think of the note a nurse writes on a chart: brief, dated, signed, and clear enough for the next person to act on.

Why does a triage note matter?

Imagine a doctor reads a chart that says "patient fine." No numbers, no date, no name. Would you trust it? Would you want to be the next doctor?

That is how many vulnerability decisions are recorded. A developer closes an alert and clicks "dismissed" or writes "false positive." Months later nobody remembers why. A customer asks. An auditor asks. A new engineer sees the same alert and starts over. The decision was fine, but the record was missing, so the work is done twice and the answer is weaker the second time.

A good note pays off in four places.

1. For you. You will not redo the work when the alert returns.
2. For your team. Someone else can act on the note when you are out.
3. For your customers and auditors. You can show the reason and the date.
4. For your future decisions. When the facts change, the note says which fact to recheck.

The OpenVEX format shows how seriously the industry takes this. Its specification says that a statement saying a product is not affected must include either a status justification, which is a fixed label, or an impact statement, which is free text explaining why the flaw cannot be exploited. It treats the reason as a required part of the record, not a nice extra.

What are the six lines?

Here is the template. Each line can be one sentence.

1. Finding. The package, the version you run, the flaw ID, and the fixed version if one exists. Example: "ParseKit 2.3.1, CVE shown in scan, fixed in 2.3.4."

2. Facts. The things you checked, in plain words. Is the function called? Can outside input reach it? Is the feature on? Is the flaw on the CISA KEV list? What is the EPSS score? What does the advisory say about conditions?

3. Evidence. Where a reader can verify the facts. A link to the advisory, a reachability result, a config file name, a code search, a screenshot, or a build ID. Say what you looked at and when.

4. Decision. One of a few fixed choices (see below), with a deadline if it is a fix.

5. Owner and date. The person who made the call and the date. Add who reviewed it if the system is sensitive.

6. Recheck trigger. The event that should reopen this note: a new public route, a new feature, a new dependency version, a KEV listing, or a date.

What are the decision types?

Most decisions fit four types. They match the four statuses used in the OpenVEX specification, which is handy if you later share your decisions with customers.

For "not affected," OpenVEX defines a short list of reasons, called justification labels. They include: the component is not present, the vulnerable code is not present, the vulnerable code cannot be executed as the product uses it, the vulnerable code cannot be controlled by an attacker, and inline mitigations already exist. The specification warns that the last two can be hard to prove conclusively. That is a good rule for your own notes too: the harder a claim is to prove, the more evidence the note should carry.

Notice that "under investigation" is a legitimate decision. It is honest and it keeps the alert alive. It must have an owner and a date, or it becomes a place where alerts go to be forgotten.

What do good and bad notes look like?

Here are three examples. The product names and numbers are invented for illustration.

A bad note. "False positive. Closed."

This tells the reader nothing. Which part is false? Who checked? How? When?

A better note, not affected.

1. Finding: ImageLib 4.1.0, resize crash flaw, fixed in 4.1.3.
2. Facts: Our code never calls the resize function. The library is in our build tools and does not ship in the product. Not on KEV. EPSS low.
3. Evidence: Code search result saved as build 5521 notes. Packaging list for release 8.2 shows no ImageLib.
4. Decision: Not affected, vulnerable code not in the execute path. No fix scheduled. Upgrade at the next normal update.
5. Owner and date: A. Rivera, 19 October 2026.
6. Recheck: If any shipped component starts using ImageLib, or if the flaw is added to KEV.

A note for a fix.

1. Finding: HeaderKit 9.0.2, header parsing flaw, fixed in 9.0.5.
2. Facts: Called on every public request. On KEV. Impact: attacker can run commands. Upgrade is a patch release.
3. Evidence: Reachability result for the main branch, KEV catalog entry, release notes for 9.0.5.
4. Decision: Affected. Upgrade to 9.0.5 today. Review web logs for the past 30 days.
5. Owner and date: B. Chen, 19 October 2026. Reviewed by security lead.
6. Recheck: Confirm fixed version in production after deploy and rescan.

A note for an unknown.

1. Finding: QueueTool 1.7.0, parsing flaw, no fixed version yet.
2. Facts: We use the parser in one worker. We do not yet know if outside data reaches it.
3. Evidence: Advisory link. Open question on data flow in ticket.
4. Decision: Under investigation. Owner to trace the data flow by 26 October 2026. If outside data reaches it, treat as affected and add a stopgap.
5. Owner and date: C. Okafor, 19 October 2026.
6. Recheck: 26 October 2026, or when a fixed version is published.

These three notes take about five minutes each. They are short, but a stranger can follow every one.

How do you make notes a habit?

1. Make a template. Put the six lines in your ticket system or a shared file so no one starts from a blank page.
2. Require a reason to close. Configure your process so an alert cannot be closed without at least the decision, the reason, and the owner.
3. Keep evidence close. Store links to results in the note, not on a laptop.
4. Review a sample monthly. Pick five closed notes and test whether a stranger could verify them. Fix the template if they could not.
5. Mark stale notes. Add a review date to each. When it passes, the alert returns to the queue.
6. Share what you can. If customers ask about specific flaws, your notes are the raw material for a clear answer.

What can Safeguard do for triage notes?

Safeguard keeps findings for each product in one queue with a status for each and the signals that set priority. Reachability analysis traces your call paths into a vulnerable function and gives you evidence for the facts line. Policies and gates let you decide what blocks a release, and compliance and evidence automation helps you keep records organized for reviews. SBOM and dependency scanning supply the finding line itself.

Autonomous remediation with fix pull requests exists, but it is off by default and every category starts on Manual. A person turns it on. Try a free scan at gold.safeguard.sh/scan.

For related reading, see a guide to VEX and what VEX is and when to use it.

Try it yourself

Click through it at your own pace, or open it full screen. Follow a critical finding from the scanned repo to the check on whether your code reaches it, and notice the facts you would copy into the facts and evidence lines of a note.

Quick check

Sources

• OpenVEX specification repository
• OpenVEX specification text
• CISA Known Exploited Vulnerabilities Catalog
• FIRST: EPSS overview

Last reviewed: 19 October 2026.