How to Cut the Hours Your Team Spends Researching Vulnerabilities

You cut vulnerability research time by asking the same five questions about every finding, in the same order, and answering each one from the primary source that settles it fastest: is it real here, is it exploited, is it reachable, is there a fix, and what breaks if we take it. Record each answer once per component and version so every other project with the same component reuses it. Then automate the lookups and keep people for the judgment calls.

This post gives you a routine that works with free public data and your own tools. Near the end we show how Safeguard does the same job, with the maturity label of every capability we mention.

A note on numbers. We found no primary, independent survey of hours spent per vulnerability finding that we could cite, so this post makes no claim about how long research "usually" takes or how much time any tool saves. Where we use minutes or hours, they are a labelled worked example, and the measurement section shows how to get your own.

Key takeaways

• Ask five questions in order (present, exploited, reachable, fix, what breaks), because each "no" ends the session early.
• Use one primary source per question: CISA's Known Exploited Vulnerabilities (KEV) catalog, FIRST's EPSS, OSV and the project's advisory, and CISA Vulnrichment's SSVC decision points in the CVE record.
• Do not rely on the NVD alone. Since 15 April 2026 NIST enriches only prioritised CVEs and marks the rest "Lowest Priority".
• When databases disagree, the project's advisory and fix commit win, then OSV format ecosystem records, then the CVE record.
• Research once per component and version range, then reuse the answer everywhere with a VEX style status.
• Automate lookups and matching. Keep risk acceptance and "not affected" calls on thin evidence with a person.
• Measure with timestamps on a sample, not estimates, and report the median.
• Safeguard capabilities covered, with labels: Gold Open Source lookups, "Am I affected?" and the CLI form of the Gold scan (GA, free, no login); vulnerability management with EPSS and KEV filters in the Vulnerabilities tab (GA); reachability analysis and prioritisation (GA); the browser extension (GA as a surface); Griffin natural language search inside the app (GA); the MCP server for Claude and other assistants (GA); AI Remediate and autonomous remediation (GA, ships switched off with every category set to Manual); mobile app; fork and patch (GA).

The problem: why one finding can eat an afternoon

Picture an AppSec engineer at a fintech, health tech or SaaS company. The scanner reports a critical CVE in a library used by forty services. Before anyone can decide anything, someone has to work out whether those forty services run an affected version, whether attackers use the bug, whether the vulnerable function is ever called, whether a fixed version exists and whether upgrading will break the build.

None of those questions is hard on its own. The time goes into three things.

Tab sprawl. Severity is in the CVE record, exploitation in the KEV catalog, exploitation probability in EPSS, affected ranges in the advisory and OSV, reachability in your own code and the fix in a changelog. Every tab is another chance to read a stale value.

Disagreement. Two databases often give the same vulnerability different affected ranges, scores or package names. If nobody writes down the reconciled answer, the next person does it again.

Repetition. The same CVE in the same component shows up in many repositories, so the same research gets done many times. This is the largest and most avoidable cost.

Why the public data got slower to use in 2026

On 15 April 2026 NIST announced a change to how the National Vulnerability Database handles new CVEs. NIST said CVE submissions increased 263% between 2020 and 2025, that it enriched nearly 42,000 CVEs in 2025, and that this still was not enough to keep up. From that date NIST prioritises three groups for enrichment: CVEs in CISA's KEV catalog (with a goal of enrichment within one business day), CVEs for software used within the federal government, and CVEs for critical software as defined by Executive Order 14028. Everything else is still listed but categorised as "Lowest Priority, not scheduled for immediate enrichment". NIST also said it will no longer routinely add its own severity score when the CVE Numbering Authority already supplied one, and it moved backlogged CVEs published before 1 March 2026 into a "Not Scheduled" category. Older CVEs published before 1 January 2018 that were awaiting enrichment had already been marked "Deferred" in 2025.

An NVD page with no product list, no NIST score or a "Lowest Priority" label is now normal, not a sign the vulnerability is minor. You need other primary sources, and to know which one answers which question.

What the standards and directives expect

NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, puts this work in its Respond to Vulnerabilities (RV) group: RV.1.1 asks producers to gather vulnerability information from public sources and other parties, RV.2.1 to analyse each vulnerability enough to plan its remediation, and RV.2.2 to plan and carry out a risk response. Analysis is required; the question is how to do it without spending a day per finding.

For US federal agencies, CISA's Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk", issued on 10 June 2026, makes the research questions explicit. It sets remediation urgency (Table 1, Remediation Timelines) from four variables: asset exposure (is the asset publicly exposed?), KEV status, exploit automation (can an adversary automate every step of exploitation?) and technical impact (partial or total control). CISA says it publishes answers to three of those four, KEV status, exploit automation and technical impact, for every CVE ID through services such as its Vulnrichment program. Agencies answer asset exposure themselves. BOD 26-04 supersedes BOD 22-01, which CISA has revoked; 22-01's fixed two week and six month deadlines are history now, not current guidance.

Even if you are not a federal agency, BOD 26-04 is a useful template. Three of its four questions are answered for you, in public, for free. Your research only has to supply the parts about your own environment.

What are the questions every vulnerability research session has to answer?

Write these down and ask them in order. Each one can end the session early, which is where the time savings come from.

1. Is it real here? Does a version inside the affected range actually ship in this project, in a build that reaches production? A test only dependency, a lockfile entry for a removed feature, or a version just outside the range all end the session.
2. Is it exploited? Is the CVE in CISA's KEV catalog? If yes, the remaining questions get answered today, not this sprint. If not, what is the EPSS probability, and what does CISA's Vulnrichment record say for Exploitation (none, proof of concept or active)?
3. Is it reachable? Does your code call the vulnerable function or trigger the vulnerable code path, and is that code wired in by configuration? An unreachable finding in a library you call heavily is still worth fixing, but it rarely needs to jump the queue.
4. Is there a fix? Is there a fixed version, a backported patch, a configuration change or a documented workaround? If there is no fix, the session ends with a compensating control or an exception, not an upgrade.
5. What breaks if we take it? Is the fixed version a patch release, a minor release or a major release? Does it change behaviour your code relies on? Do your tests pass with it?

There is a sixth question that often hides inside the others: who owns the fix? If the answer is "nobody knows", the finding will come back next week no matter how good the research was. Record the owning team with the answer.

The order runs from cheapest to most expensive: questions 1, 2 and 4 are lookups, question 3 needs analysis of your code, and question 5 needs a build and tests. Teams that open the upgrade pull request first pay the most expensive cost on findings a lookup would have closed.

Which primary sources answer each one fastest?

Use one primary source per question, and know what each field means. The table maps each question to the source that settles it and the trap to watch for.

The CVE record and the NVD

The CVE record is published by the CVE Numbering Authority (CNA) that assigned the ID, in the CVE JSON record format maintained in the public cve-schema repository. Authorized Data Publishers (ADPs) such as CISA can add their own data to the record. The NVD adds NIST's enrichment on top. Given NIST's 2026 changes, read the CNA's data first and treat NVD enrichment as a bonus when it exists.

CISA's KEV catalog

KEV answers question 2 directly. CISA lists three criteria for adding a vulnerability: it has an assigned CVE ID, there is reliable evidence that it has been actively exploited in the wild, and there is a clear remediation action such as a vendor update. That third criterion matters for researchers: a KEV entry usually tells you that a fix exists.

If a CVE is in KEV, exploitation is a fact rather than a forecast. If it is not, that only means CISA has not added it, so read EPSS and the Vulnrichment record too.

FIRST EPSS

The Exploit Prediction Scoring System is a data driven model run by FIRST. It estimates the probability that a published CVE will be exploited in the wild in the next 30 days, and publishes a score between 0 and 1 with a percentile, every day, for every published CVE. The data is free through a CSV download and an API.

Read the two numbers differently. FIRST's FAQ explains that the probability is absolute while the percentile is a ranking against all scored CVEs, and that because scores are heavily skewed toward zero, a probability of 0.10 currently sits around the 95th percentile. A CVE at the 95th percentile is not "95% likely to be exploited". Use the probability for thresholds and the percentile for comparisons.

CISA Vulnrichment and SSVC

CISA Vulnrichment is CISA's public enrichment of CVE records through its ADP container. CISA's repository says it takes new and recent CVEs through an SSVC scoring process and adds key decision points. CVEs rated "Total" technical impact, "Automatable", or with Exploitation of "Proof of Concept" or "Active Exploitation" get further analysis, and CISA may add a CWE or a CVSS score where the CNA did not provide one.

SSVC, Stakeholder-Specific Vulnerability Categorization, is CISA's decision tree. It reaches one of four decisions, Track, Track*, Attend and Act, from five values: exploitation status, technical impact, automatable, mission prevalence and public well-being impact. CISA recommends remediating Act vulnerabilities as soon as possible and Attend vulnerabilities sooner than standard update timelines. Three of the five values come from Vulnrichment. The last two are about your organisation, and a person has to answer them once per asset or service, not once per CVE.

CVSS, used for what it measures

CVSS v4.0, published by FIRST, has four metric groups: Base, Threat, Environmental and Supplemental. The specification says the Base metrics reflect qualities that are constant over time and assume the reasonable worst case impact across deployed environments. The Threat metrics adjust for things like proof of concept code or active exploitation, and the Environmental metrics adjust for your environment. A Base score alone (CVSS-B in the v4.0 naming) answers "how bad could this be in general?", not "how urgent is it for us?". It is a sorting input, not the answer to question 2 or 3.

OSV and the project's own advisory

OSV is an open, distributed vulnerability database format and service for open source. The OSV site describes itself as an aggregator of databases that publish in the OSV schema, including several ecosystem advisory databases, and it offers an API that answers "which known vulnerabilities affect this package at this version?" or "this commit?".

The OSV schema is why OSV is fast for question 1. Each record lists affected packages by ecosystem and name, with ranges built from introduced, fixed, last_affected and limit events, of type SEMVER, ECOSYSTEM or GIT, plus aliases and a withdrawn field. Matching your installed version against those events is mechanical.

The project's own advisory and fix commit are the final word on what is affected and fixed, because the maintainers wrote the code. Link them in your research note.

How do you measure research time per finding without inventing numbers?

If you want to cut research time, you need a baseline you can defend. The honest way is to measure it, on a sample, with timestamps.

1. Pick a sample. Take the next 30 to 50 findings that need a human look, across a few repositories and ecosystems, easy and hard alike.
2. Timestamp, do not estimate. Add "research started" and "research finished" fields to the ticket and fill them in at the moment. Estimates made afterwards are optimistic and nobody can check them.
3. Record where it ended. Note which of the five questions closed each finding. This tells you where the time goes.
4. Record reuse. Note whether the same CVE and component had already been researched for another project.
5. Report the median, not the mean. One finding that took two days distorts an average. Report the median and the spread.
6. Repeat after each change. Change one thing (for example, start reading KEV and EPSS before anything else), then measure another sample the same way.

A worked example (illustrative, not measured)

The following numbers are invented to show the arithmetic. They are not a benchmark and do not describe any team.

Suppose a team timestamps 40 findings. The median research time is 50 minutes. Twelve findings were closed at question 1 (the vulnerable version was not in a production build), and their median was 15 minutes. Nine of the 40 were repeats of CVEs already researched for another project that month, and each repeat was researched again from scratch.

From that sample the team learns two things without any vendor claim. First, a reliable inventory lookup at question 1 would have closed nearly a third of the sample in its cheapest step. Second, nearly a quarter of the work was repeated research, which a shared record removes entirely. Those are the two levers to pull first, and the next sample shows whether they worked.

When do databases disagree on affected versions, and which do you trust?

Disagreement is normal. The common causes are predictable.

Different version schemes. An advisory written against git commits or tags does not map cleanly to package versions. The OSV schema handles this by separating GIT ranges from ECOSYSTEM and SEMVER ranges and recommends keeping them in separate entries so strict version parsers do not get confused.

Product lists built for a different purpose. NVD product configurations describe products and vendors in a naming scheme designed for products, not for package registry names. A library repackaged under several names in different ecosystems can be listed under one name, or none.

Backports. A fix released on several maintained branches produces several "fixed" events; a database that records only the newest one marks patched older branches as affected.

Late corrections. Advisories get corrected after publication, and OSV records can be marked withdrawn. NIST said in 2026 it will reanalyse modified CVEs only when a change materially affects its enrichment.

A trust order that holds up

When sources disagree on which versions are affected, use this order and write down which one you used.

1. The project's own advisory and fix commit. The maintainers know which code changed. If the fix commit is available, read the diff to confirm which release first contains it.
2. Ecosystem records in OSV format for that package registry, because their ranges use the ecosystem's own version ordering.
3. The CNA's CVE record, including any ADP container data.
4. Product oriented enrichment, such as NVD product configurations, as a cross check.

If the sources still disagree after step 1, treat the wider range as affected until you have read the fix commit. Being wrong in the conservative direction costs an upgrade; being wrong the other way costs an incident.

How do you reuse a research result across every project that has the same component?

This is the largest saving most teams can make, and it needs no new tool, only a habit.

Make the research note the unit, not the ticket. One note per CVE, per component, per affected version range. The note holds the five answers, the sources you read, the date and who wrote it. Tickets in each project link to the note instead of repeating it.

Separate global answers from local ones. Questions 2 and 4 (exploited? fix?) have the same answer for every project. Questions 1, 3 and 5 (present? reachable? what breaks?) depend on each project. Write the global part once. For the local part, record one line per project.

Use your inventory to fan out. Query your SBOMs or dependency inventory for every project with the component in the affected range. One query answers the slowest part of question 1 for all of them.

Write statuses in a standard shape. CISA's Minimum Requirements for Vulnerability Exploitability eXchange (VEX), published in April 2023, define four statuses: not affected, affected, fixed and under investigation. A "not affected" statement should carry a justification, and must carry an impact statement if it has none. Even if you never publish VEX outside the company, using the same four statuses and a justification internally makes reuse and audit much easier.

Set an expiry. Research goes stale. EPSS changes daily, KEV grows, new fixed versions ship. Give every "not affected" or "accepted risk" note a review date.

Which questions can be automated safely, and which need a person?

The rule is simple: automate lookups, matching and arithmetic; keep judgment and acceptance with a person.

The first five questions are about facts in the world, and a machine collects facts faster than a person. The decisions that follow (accept, defer, fix now) are about your business, and they need a name next to them.

An AI assistant can collect those facts quickly, but it can also state a wrong affected range with full confidence. Ground it in tools that return the CVE record, KEV status and EPSS from source data, and make it cite the source for each answer. Our post on asking an LLM to explain a CVE without hallucination covers the prompting side.

A research routine you can run with your own tools

1. Open the research note first. If one exists for this CVE and component and has not expired, copy the global answers and go straight to the local ones.
2. Present? Check the installed version from the lockfile or SBOM against OSV ranges and the project advisory, and whether it ships in a production build. If not, record why and stop.
3. Exploited? Record KEV status, the EPSS probability and the Vulnrichment SSVC values, with today's date.
4. Reachable? Read your reachability result, or search for imports of the vulnerable module and calls to the named function. Record reachable, conditionally reachable, unreachable or unknown.
5. Fix? Find the lowest fixed version on your line, any backport, or the workaround.
6. What breaks? Note the semantic version change, read the changelog, run the tests on a branch.
7. Decide, assign and fan out. Fix now, fix in the normal cycle, or accept with an expiry; name the owner; link the note from every project with the same component and range.

For signals beyond the CVE itself, such as maintainer activity and project health, see what dependency risk signals exist beyond CVEs.

How Safeguard does this job

Safeguard automates the lookups in the routine above and keeps the decisions with your team. Here is the flow, step by step, with each capability's maturity label. Commands are exactly as Safeguard's docs show them.

Step 1: look up the CVE or package in Gold Open Source (GA, free, no login)

Gold Open Source is Safeguard's free public directory of open source software and what is publicly known about its security. Anyone can use it without an account. Search a CVE or a package to see CVSS, EPSS, CISA KEV status, affected and fixed versions and remediation guidance on one page.

Two features map directly to the routine:

• "Am I affected?" Every CVE page has a check where you enter the version you run and get a verdict against the advisory's affected and fixed versions. That is question 1's matching step, done for you.
• Recommended safe version. Every package page with known vulnerabilities shows a recommended safe version, which the docs describe as the lowest version that clears the most advisories, with a copy ready upgrade command for your ecosystem. That is the lookup half of question 4.

Safeguard's docs say Gold aggregates, normalises and enriches public data from sources including the NVD, the CVE and CWE programs and OSV. It is also available as a Chrome extension.

Step 2: check a whole repository from the command line (GA, free)

For question 1 across a whole repository, the Gold scan's command line form runs locally, in pre-commit hooks or in any CI system. The docs say it needs no account or token and sends only dependency names to the public read API, so your source stays on the runner.

The docs say it discovers npm, PyPI, crates.io, Go, RubyGems and Packagist manifests, flags dependencies that are in CISA KEV or known vulnerable, and fails open if the API is unreachable. Install it only the way the Gold docs describe: @safeguard-sh is Safeguard's own package scope, and the docs warn not to install a similarly named package from a public registry.

Step 3: triage in the Vulnerabilities tab (GA)

Inside the platform, vulnerability management is GA. The Vulnerabilities tab in Enterprise Software Supply Chain Manager groups findings into Critical, High, Medium, Low and Exploitable, where Exploitable means known active exploitation in the wild. The docs say Safeguard scans projects daily and re-evaluates them automatically when new CVEs are published, so question 1 is answered as data arrives rather than when someone asks.

For each vulnerability the tab shows the CVE ID, CVSS score, EPSS score, whether it is exploited in the wild, the affected component and version, the fixed version, references and reachability, and you can filter on each. Most of the facts from the source table above sit in one row of one table.

The reachability docs list these common filters for the table:

reachable:true
kev:true
epss:>0.3
env:production reachable:true kev:true

The last one is what the docs call the P0 backlog: reachable, KEV listed findings in production.

Step 4: rank by reachability (GA)

Reachability analysis and prioritisation is GA. Safeguard's docs describe three kinds of reachability: static (a call graph from source, lockfile and bytecode), dynamic (which modules and functions are loaded and invoked at runtime) and configuration (whether framework configuration wires the code in at all). Each finding is classified as reachable, conditionally reachable, unreachable or unknown, and the docs say unknown is marked conservatively as potentially reachable.

It combines reachability with EPSS, KEV, runtime context and business context you declare in policy into a priority score from 0 to 100, with weights configurable per tenant. Safeguard's docs say this typically shrinks open findings by 60 to 80%; that is Safeguard's stated figure, not a promise for your codebase.

Language support differs. The docs list static reachability as GA for JVM languages, Python, JavaScript and TypeScript, Go, Rust, C and C++, C# and .NET, Ruby, PHP, and Swift and Objective-C. The reachability docs also show /v1 API examples under a banner that says those endpoints are not available yet, so use the Vulnerabilities tab rather than scripting against them.

Step 5: ask in plain language with Griffin search (GA)

In-app agentic search is generally available. The Search page lets you type questions instead of building filters, for example "Which projects have exploitable vulnerabilities?" or "What packages are affected by Log4j?", and keep refining in a conversation. Results come back grouped as components (with the projects where each is used), vulnerabilities (with fix availability) and projects. The docs say search runs against your indexed SBOM and scan data, so a scan still in progress may not show up yet.

This is where step 8 of the routine, the fan out, gets quick: one question returns every project that carries the component. You can star a search you run every week and export results as JSON, CSV or PDF.

Step 6: open search next to any page with the browser extension (GA as a surface)

The browser extension is GA as a delivery surface. The docs say it opens a side panel (Chrome and Edge) or sidebar (Firefox) with the same AI search page as the web app, using your normal session, and declares no host permissions. The search inside it is the same search from step 5. You can read an advisory on one side and ask "which of our projects run this version?" on the other.

Step 7: research from your assistant with the MCP server (GA)

The MCP server is GA. Safeguard is listed in Claude's connector directory as a community connector, which is the shortest route: open the directory entry, connect, sign in to Safeguard and click Authorize access. The docs also describe a manual route using a custom connector with the URL https://mcp.safeguard.sh/mcp/anthropic and OAuth.

Once connected, the docs say Claude can query your vulnerabilities, SBOMs, packages, licenses and findings. A new workspace starts with a small read only set of tools, and an administrator turns on more, tool by tool. For research the read only set is enough, and the assistant answers from your tenant's data instead of from memory.

Step 8: record the decision once (GA)

From the Vulnerabilities tab you can mark a finding as a false positive with a justification, submitted for approval if your policy requires it, or accept the risk with an expiration date and a business justification. That is the written, expiring decision the routine asks for, stored next to the finding rather than in a chat thread.

Step 9: hand the fix to a pull request (GA, ships switched off)

When the answer to question 4 is "a fixed version exists", AI Remediate (GA) analyses the vulnerabilities and generates remediation plans; you review the proposed changes and create pull requests. "View Fix" shows upgrade options with breaking change warnings, which speaks to question 5. Autonomous remediation is GA and ships switched off, with every category set to Manual, so nothing runs on its own until your team chooses to turn it on.

How the routine maps to Safeguard

How do you show leadership the time you got back?

Leadership does not need a tool demo. It needs before and after numbers you measured the same way.

1. Report your own medians. Baseline and follow up, with sample sizes, stated as your measurements.
2. Show where findings closed. A stacked bar of "closed at question 1 to 5", before and after. More findings closing at the cheap questions means the routine works.
3. Show reuse. The share of findings that reused an existing research note connects directly to fewer hours.
4. Show the queue, not just the hours. Time saved on research is only useful if it moves fixes. Pair the research numbers with how long findings wait before a fix is merged. Our post on Little's Law and the vulnerability backlog shows how arrival rate and fix time set backlog size.
5. Translate hours into money only with your own rates. If finance asks, multiply your measured hours by your own loaded cost, and show the formula. See how to explain vulnerability backlog cost to a CFO.

Do not use vendor percentages, including Safeguard's, as your result. Use them, if at all, as the hypothesis you tested.

What Safeguard does not do

Honest limits, so you can plan around them.

1. It does not make public data correct. Gold and the Vulnerabilities tab aggregate public sources and add Safeguard's own scoring layer on top. If the NVD, a CNA record or an ecosystem advisory has a wrong affected range, that error can carry through until the source is corrected. For a disputed range, read the project's fix commit yourself.
2. Griffin search is generally available. The plain language search, and therefore the search inside the browser extension panel, is generally available. Results depend on scans that have finished processing. Do not build an audit process that depends on it alone.
3. Reachability has limits in dynamic code. Reflection, dynamic dispatch, native code and data driven bugs weaken any reachability analysis, which is why "unknown" is not suppressed.
4. It does not decide risk for you. Accepting risk, marking a finding "not affected" and choosing to take a major upgrade stay with a named person. Safeguard records the decision and its expiry; it does not make it.
5. It does not answer your organisation's SSVC questions. Mission prevalence and public well-being impact, and BOD 26-04's asset exposure for agencies, depend on your environment. Runtime and business context in Safeguard's prioritisation come from labels and policy you supply.
6. No scripted priority queries today. The reachability docs say there is no CLI command for querying findings by priority yet, and the /v1 endpoints shown there are not available; use the Vulnerabilities tab, search or the MCP server. For a repository wide Gold check, use the command line form described above.

Common mistakes

• Starting with the upgrade. Opening a pull request before asking whether the version ships in production spends the most expensive step on findings a lookup would close.
• Treating CVSS Base as urgency. A 9.8 that is unreachable, not in KEV and with a very low EPSS probability can wait behind a 7.5 that is in KEV and reachable in an internet facing service.
• Reading the EPSS percentile as a probability. A 95th percentile score is a ranking, not a 95% chance.
• Assuming "not in KEV" means "not exploited". KEV lists vulnerabilities with reliable evidence of exploitation and a clear remediation. Absence is not evidence.
• Trusting the NVD's silence. In 2026 many CVEs carry no NIST enrichment by design. A missing product list or score is a gap to fill from the CNA record, OSV or the project advisory.
• Researching per ticket instead of per component. If the note lives inside one project's ticket, the next project repeats the work.
• "Not affected" with no reason and no expiry. It cannot be reviewed or reused, and it quietly becomes permanent.
• Measuring with estimates. "It feels faster" will not survive a budget meeting. Timestamps will.

FAQ

What is the fastest free source to check if a CVE is being exploited?

CISA's Known Exploited Vulnerabilities catalog for confirmed exploitation, plus FIRST's EPSS for the probability of exploitation in the next 30 days. CISA Vulnrichment adds an SSVC Exploitation value (none, proof of concept or active) to many CVE records.

Why does the NVD page for my CVE have no score or product list?

Since 15 April 2026 NIST prioritises enrichment for CVEs in KEV, software used in the federal government and EO 14028 critical software, and labels the rest "Lowest Priority". NIST also stopped routinely adding its own score when the CNA already supplied one. Read the CNA's CVE record, any ADP data and OSV instead.

NVD and OSV list different affected versions. Which is right?

Check the project's own advisory and fix commit first. Then prefer ecosystem records in OSV format, which use the registry's own version ordering, over product oriented lists. If sources still disagree, treat the wider range as affected until you confirm.

Is EPSS better than CVSS for prioritising?

They measure different things. CVSS Base describes severity in general under a reasonable worst case; EPSS estimates the probability of exploitation in the next 30 days. Use both, together with KEV and reachability, rather than either alone.

What replaced CISA BOD 22-01?

CISA revoked BOD 22-01 and issued BOD 26-04, "Prioritizing Security Updates Based on Risk", on 10 June 2026. It sets remediation timelines from asset exposure, KEV status, exploit automation and technical impact.

Can AI research vulnerabilities for me?

It can collect and summarise facts quickly if it reads them from source data through tools. It should not decide that a finding is "not affected" or accept risk. Ask it to cite the source for every answer and check affected ranges against the advisory.

How do I avoid researching the same CVE for every project?

Make one research note per CVE, component and version range, split global answers (exploited, fix) from per project answers (present, reachable, what breaks), and use your SBOM inventory to find every project with the component in one query.

How do I measure time spent on vulnerability research?

Timestamp the start and end of research on a sample of 30 to 50 findings, record which question closed each one and whether it was a repeat, and report the median. Change one thing, then measure again the same way.

When the research ends in "we need a fix"

Research tells you which findings matter; the remaining risk sits in how long it takes a fix to reach production, or to exist at all. The section below is the same for every post in this series and covers the remediation options Safeguard offers once your research says "fix it".

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo walks through connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. For research, that is the setup that lets an assistant answer "which of our projects run this version, and is it in KEV?" from your own tenant data instead of from memory, with the tool set kept read only.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session. After installing, safeguard opens the interactive terminal and the user asks it to fix the lodash CVE in the repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan .. That covers questions 4 and 5 of the routine: the fix, and whether the tests still pass with it.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session with the mobile app. It sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. When a KEV listed finding lands while you are away from your desk, it is a way to start the fix run on your own machine and still approve each command that changes something.

Click through it at your own pace, or open it full screen.

To try the CLI, the apps or the browser extension, start at safeguard.sh/download, and read the setup guides at docs.safeguard.sh. Related reading in this series: keeping a contract promise of no known exploited vulnerabilities and running AppSec at one security engineer per hundred developers.

Quick check

Sources

• NIST NVD: News and announcements (15 April 2026 operations update; Deferred status)
• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 22-01 (Revoked)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities (KEV criteria)
• CISA Vulnrichment repository
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
• FIRST: Exploit Prediction Scoring System (EPSS)
• FIRST: EPSS frequently asked questions
• FIRST: CVSS v4.0 Specification Document
• OSV: Open Source Vulnerabilities
• OSV schema
• CVE Program: CVE JSON record format repository
• Safeguard docs: Gold Open Source
• Safeguard docs: Vulnerabilities (ESSCM)
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Search
• Safeguard docs: Browser Extension
• Safeguard docs: Claude MCP integration
• Gold Open Source

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.