Open the CVE record and read the tags on each reference. A link tagged patch contains an update that fixes the flaw. A link tagged vendor-advisory comes from the product's maker or maintainer. A link tagged mitigation describes a workaround when no patch is possible. Start with those three, then check the rest.
The tags and what they mean
The CVE Record Format defines a list of reference tags. The ones that matter most to someone fixing a finding:
| Tag | Meaning in the schema | What you do with it |
|---|---|---|
| patch | Contains an update that fixes the vulnerability | Find the fixed version |
| vendor-advisory | From the vendor, publisher or maintainer (or parent organization) | Treat as the authority on affected versions |
| third-party-advisory | From an organization other than the vendor | Useful cross-check |
| mitigation | Steps to reduce risk when a patch cannot be applied or the product is end of life | Interim control |
| release-notes | Vendor or project release notes or change log | Confirm the fix version |
| issue-tracking | Post from a bug tracker | Context and discussion |
| exploit | Detailed exploitation steps, or legitimate proof of concept code | Raises urgency; handle with care |
| signature | A method to detect or prevent exploitation | Detection content |
| vdb-entry | A public vulnerability database entry with identifiers | Cross-reference |
| broken-link | The link returns a 404 or the site is gone | Skip it |
| permissions-required | Behind a login | Ask your vendor account contact |
A one-minute routine
- Open the record for the CVE in question.
- Look for a patch tag. If present, open it and note the fixed version.
- If not, look for vendor-advisory and release-notes. These usually state the fixed version.
- If you still have no fix, look for mitigation.
- Check whether an exploit tag exists. That does not prove active exploitation, but it tells you the technique is public.
- Write down the link you relied on in the ticket.
This pairs well with how to read a vendor security advisory and decide whether it applies to you.
Cautions
Tags are applied by people and tools, and the schema defines them as descriptions, not guarantees. A few habits keep you safe:
- A patch link can be a commit, not a release. Confirm that a tagged release contains it.
- A record can carry references from the CNA and from the CVE Program container, so the same link may appear twice.
- A missing patch tag does not mean no fix exists. It can mean nobody tagged it. Check the vendor's own page.
- An exploit tag points at third-party content. Do not run proof of concept code on production systems.
For gates, avoid building policy on tags alone. Use them to find evidence, then rely on the version data and your own scan.
Where Safeguard fits
Safeguard offers autonomous remediation with fix PRs, which is off by default with every category on Manual, plus SBOM and dependency scanning. The demo below shows what a fix looks like when a fixed version exists.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a finding links to a fixed version.
Quick check
Which tag tells me a fix exists?
The patch tag, which the schema defines as a reference containing an update that fixes the vulnerability.
Is a vendor-advisory better than a third-party-advisory?
For affected versions, usually yes, because it comes from the maker or maintainer. Use the third-party one as a cross-check.
Does an exploit tag mean attacks are happening?
No. It means the link has exploit steps or proof of concept code. Check KEV for evidence of exploitation.
Sources
- CVE Record Format, reference tags, fetched 19 October 2026.
- CVE Program, cvelistV5 repository README, fetched 19 October 2026.
Last reviewed: 19 October 2026.
