Autonomous Novel Vulnerability Detection and Elimination at Scale

Novel vulnerabilities (zero-days) are flaws nobody has catalogued yet: no CVE, no advisory, no vendor fix, so a scanner that only matches against public feeds cannot see them. Eliminating them at scale means running a closed loop that detects, decides, fixes, verifies and prevents recurrence on its own, while people set the policy and the approval thresholds. This guide explains why the feed-driven model has stopped scaling, how to build that loop with the tools you already have, and where an autonomous platform fits.

Key takeaways

• Define the target first. A novel vulnerability (zero-day) is a previously unknown weakness with no CVE and usually no fix. CISA's KEV catalog cannot list one until it has a CVE ID, evidence of exploitation and a clear remediation.
• The feed is falling behind. NIST says CVE submissions rose 263% between 2020 and 2025, and in April 2026 it stopped trying to enrich every CVE. CISA had already added more entries to KEV in 2026 by 23 October than in all of 2025.
• Exploitation windows are closing. CISA's BOD 26-04 warns that AI may shrink the time defenders have, and sets a three day timeline plus forensic triage for the highest risk cases.
• Autonomy is a loop, not a feature. Detect, decide, fix, verify and prevent hand off without a ticket queue; humans own policy, thresholds and exceptions.
• Roll out in stages. Spend 30 days in suggest only mode, 30 days opening pull requests automatically for low risk fixes, then let your repository rules auto-merge the safest class.
• Measure the loop, not the scanner. Track mean time to remediate, the exploitable and reachable backlog, and the fix pull request acceptance rate.
• Safeguard capabilities covered here, all GA: Zero-Day Discovery (GA), software composition analysis (GA), SAST (GA), vulnerability management with EPSS and KEV enrichment (GA), reachability analysis and prioritisation (GA), continuous scanning (GA), policies and gates (GA), autonomous remediation with Griffin fix pull requests (GA, ships switched off), Gold Open Source (GA), IDE extensions (GA), Package Firewall (GA) and the CLI (GA).

What a novel vulnerability (zero-day) actually is

NIST's glossary defines a vulnerability as a weakness in a system, its procedures, internal controls or implementation that a threat source could exploit or trigger. The same glossary, citing CNSSI 4009-2022 and NISTIR 8011 Vol. 3, defines a zero-day attack as one that exploits "a previously unknown hardware, firmware, or software vulnerability". Together they give the working definition this post uses:

A novel vulnerability (zero-day) is a weakness that is not yet publicly known or catalogued. It has no CVE record, no published advisory and, usually, no vendor or maintainer fix.

The consequence is operational. CISA's KEV catalog has three inclusion criteria: an assigned CVE ID, reliable evidence of active exploitation, and a clear remediation action such as a vendor update. A novel vulnerability (zero-day) fails the first and third by definition. NVD enrichment and EPSS scores are keyed on CVE IDs too, so a tool that matches your dependency list against public feeds has nothing to match.

Novel vulnerabilities (zero-days) live in two places:

1. Your own code. Any pull request can add an injection path or a broken authorisation check that will never get a CVE.
2. Your dependencies. Packages, base images and AI models can carry flaws their maintainers have not found. The time between "someone found it" and "your feed lists it" is your exposure window.

The situation: why patching what the feed says no longer scales

Most vulnerability programs were built around a simple contract. A feed publishes a CVE, a scanner matches it against an inventory, a ticket lands with an owner, and someone upgrades the package before an SLA expires. That contract is under strain from three directions at once.

Volume has outrun enrichment

On 15 April 2026, NIST announced that it was changing how it operates the National Vulnerability Database. Its own numbers explain why:

• CVE submissions increased 263% between 2020 and 2025.
• Submissions in the first three months of 2026 were nearly one third higher than in the same period of 2025.
• NIST enriched nearly 42,000 CVEs in 2025, 45% more than in any prior year, and says that still was not enough to keep up.
• A backlog of unenriched CVEs has existed since early 2024. Under the new process, backlogged CVEs with an NVD publish date earlier than 1 March 2026 moved to a "Not Scheduled" category.

From 15 April 2026, NIST prioritises enrichment for CVEs in CISA's KEV catalog (with a goal of one business day), CVEs for software used in the federal government, and CVEs for critical software as defined under Executive Order 14028. Everything else is listed but labelled lowest priority.

The central source many tools use for severity scores is now explicitly triaging. A process that waits for an NVD score will sometimes wait a long time.

Exploitation is fast, and the known exploited list keeps growing

We counted entries in CISA's KEV JSON feed (catalog version 2026.10.23, downloaded 26 October 2026). The catalog held 1,756 entries. By year added:

2026 had passed 2025's total with more than two months left, and most entries each year carry a CVE ID from the same year: catalogued and confirmed exploited within one calendar year. The ID year reflects reservation, not publication, so treat this as a rough indicator of speed.

In the background to Binding Operational Directive 26-04 (10 June 2026), CISA writes that attackers' "use of AI may further narrow the time defenders have to react". BOD 26-04 replaced BOD 22-01 and BOD 19-02. Its remediation timelines are driven by four decision points: whether the asset is publicly exposed, whether the CVE is in KEV, whether exploitation is automatable, and whether the technical impact is partial or total control. The shortest timeline is three calendar days with a forensic triage of the asset; the longest is "fix on system upgrade". It binds federal civilian agencies, not private companies, but it shows where a regulator sets the bar.

We found no government source for a single "average time to exploit" figure and left vendor estimates out. The KEV data and BOD 26-04 make the point: days, not quarters.

AI-written code is raising change volume

The third pressure is on the input side. In the 2025 Stack Overflow Developer Survey, 84% of respondents said they use or plan to use AI tools in their development process, up from 76% the year before, and 51% of professional developers said they use them daily. The same survey found that more developers distrust the accuracy of AI tool output (46%) than trust it (33%).

More generated code means more pull requests, more suggested dependencies and more code nobody wrote line by line. Each change can introduce a novel vulnerability (zero-day) that will never appear in a CVE feed.

What a bad week looks like

A critical flaw lands in a library four levels deep in your tree. NVD has no score yet. The scanner shows it in 140 repositories, nobody knows which ones call the vulnerable function, and 30 teams get tickets. By Thursday a third have merged, a third have broken builds from a major version bump, and a third have not opened the ticket. Meanwhile the same library carries a second flaw nobody is looking for. The bottleneck is a process that assumes a human hands every finding to another human.

The standard behind it: what NIST and CISA actually ask for

This section summarises the primary texts. It is not legal or audit advice; read the documents themselves for anything you will attest to.

NIST SP 800-218 (SSDF), the Respond to Vulnerabilities practice group

The Secure Software Development Framework splits vulnerability response into three practices, and they map almost one to one onto an autonomous loop:

RV.1.2 is the one most programs skip: it asks for "previously undetected" vulnerabilities, the novel vulnerability (zero-day) problem in standards language. RV.3.3 expects you to hunt the whole class of a flaw, not just the reported instance.

NIST SP 800-40 Rev. 4, patching as preventive maintenance

NIST's enterprise patch management guide frames patching as preventive maintenance, "a cost of doing business", and defines the process as identifying, prioritising, acquiring, installing and verifying patches. The verify step matters for autonomy: a fix that was proposed but never confirmed in a fresh scan is not a fix.

CISA BOD 26-04 and EPSS, the prioritisation inputs

BOD 26-04 gives a defensible way to rank work: exposure, KEV status, automatable exploitation and technical impact, the last three published by CISA for every CVE ID through its Vulnrichment program. FIRST's EPSS adds a daily probability, from 0 to 1, that a published CVE will be exploited in the next 30 days. Neither exists for a novel vulnerability (zero-day) until it has an identifier, so detection has to start before the feed.

What "autonomous" means in practice

In practice "autonomous" means five stages that hand off without a person moving a ticket between them, inside limits people set in advance.

The human role does not disappear. It moves up a level. Instead of approving each fix, people decide:

• which classes of fix may run without review,
• which repositories and environments are in scope,
• what evidence a fix must carry before merge (tests, a clean rescan, no breaking change flag),
• who can grant an exception and for how long.

Step by step: building the loop with or without Safeguard

These steps work with whatever scanners, CI system and repository host you use today.

1. Inventory everything you build and ship. Generate an SBOM per build for every service, container image and AI model you deploy.
2. Run two kinds of detection. Feed matching (SCA against CVE, OSV and vendor advisories) finds known flaws. Code analysis (SAST with dataflow tracing, plus research or fuzzing on high value dependencies) is how you meet SSDF RV.1.2 and find novel vulnerabilities (zero-days).
3. Enrich every finding with exploit signals. Pull KEV status and EPSS daily. Add CISA's Vulnrichment decision points where they exist.
4. Add reachability and asset context. Mark whether your code actually calls the vulnerable function, whether the asset is internet facing and whether it handles regulated data. Treat "unknown" reachability as reachable.
5. Write the autonomy policy before you turn anything on. Use the matrix below. Decide which tier each class of fix lands in.
6. Wire gates into CI. Fail builds on the findings you have agreed are unacceptable, warn on the rest, and route exceptions through an approver with an expiry date.
7. Generate fixes as pull requests, not tickets. A pull request carries the change, the reason and the test results. A ticket carries only the request.
8. Verify on the merged commit. Rescan after merge, compare against the previous scan, and close the finding only when the rescan agrees.
9. Feed root causes back into prevention. For each novel vulnerability (zero-day) in your code, write a rule or policy that catches the class, add it to the IDE and the CI gate, and review whether a dependency should be replaced.
10. Report the loop's health monthly with the metrics checklist below.

Template: autonomy policy matrix

Copy this into your security policy and fill it in with your own thresholds. The tiers are illustrative.

Decision table: what to do with a new finding

A novel vulnerability (zero-day) has no KEV status or EPSS score yet. Treat a validated one in reachable, internet facing code like a KEV entry.

The five stages in more detail

Detect: known and novel

Software composition analysis is the baseline for known flaws. Two choices decide whether it scales: rescan on events (a new advisory, a KEV addition, an EPSS jump, a new commit or image) rather than on a calendar, and match on package URL and version range rather than names.

Novel vulnerabilities (zero-days) need different tools. In your own code, static analysis with dataflow tracing follows untrusted input from a source to a dangerous sink and shows the whole path; run it on every pull request. In dependencies, finding unknown flaws means watching releases, analysing changes, building reproducers and running coordinated disclosure, which few teams can staff. If you buy it, ask how findings are validated, how disclosure works, and how a finding reaches your inventory and gates while it is still embargoed.

Decide: policies, gates and exceptions

A decision layer turns a finding into one of three outcomes: stop the release, let it through with a warning, or let it through and tell someone. Everything else is an exception with an owner, a reason and an expiry date. Good gate policies are narrow ("no reachable KEV vulnerabilities on internet facing production services", not "no criticals"), run on fresh data, fail safe when they cannot be evaluated, and write their own audit trail.

Fix: pull requests, not tickets

Automated fixing earns its place when it picks the safest version that resolves the finding rather than the newest, resolves transitive conflicts and lockfiles, flags breaking changes before merge, and attaches your test results. Bulk matters as much as single fixes: when one library affects 140 repositories, you want one pull request per repository from one run.

Source safe components

Sometimes the fix is "replace", not "upgrade". When upstream has no fix or a package is abandoned, decide in advance who can approve a patched fork or alternative, who maintains it, and how you return to upstream once a fix ships.

Verify: rescan and test

A fix is done when the pull request's tests passed, a rescan of the merged commit no longer shows the finding, the failing gate passes on fresh data, and no new finding of equal or higher severity arrived in the same change. Skip the rescan and you will count fixes that never landed, such as an upgrade a lockfile silently pinned back.

Prevent recurrence: CI, the IDE and install time

Prevention is SSDF RV.3 in practice. For each class of flaw, ask where it could have been stopped earlier: in the IDE before commit, at install time before a bad package reaches a build, or in a CI gate. MITRE's Common Weakness Enumeration is the shared vocabulary for classes of flaw. Tag each novel vulnerability (zero-day) you fix with its CWE and look for repeats each quarter; a repeated CWE tells you which rule, training or library choice to change.

The 30/60/90-day rollout: from suggest only to auto-merge

Do not switch everything on at once. Trust in an autonomous loop is earned one class of fix at a time.

Days 1 to 30: suggest only

• Connect repositories and container registries; generate SBOMs for every production service.
• Turn on continuous rescanning and exploit enrichment.
• Write the autonomy matrix and the gate policies, starting every policy in warn or notify mode.
• Generate fix proposals but open no pull requests automatically. Have engineers review a sample each week and record whether they would have merged it.
• Baseline mean time to remediate, the exploitable and reachable backlog, and a first acceptance rate.

Days 31 to 60: auto-open pull requests for low risk fixes

• Allow pull requests to open automatically for the lowest risk class: patch and minor upgrades with no breaking change flag, with tests required.
• Keep a human merge on every pull request.
• Move the narrowest, best understood gate policy (for example, reachable KEV findings on internet facing services) from warn to block.
• Start the exception workflow for real, with expiry dates.
• Run your first bulk fix across the long tail of old findings.

Days 61 to 90: auto-merge the safest class

• For repositories with good test coverage, let your repository's own auto-merge rules merge the lowest risk class once tests pass and the rescan is clean.
• Expand blocking gates to the next policy.
• Add IDE and install-time controls for the top recurring CWEs you saw in the first 60 days.
• Compare metrics with the baseline and pick the next class to move up a tier.

A worked example, illustrative only, with round invented numbers: if your team reviews 100 proposed fixes in the first 30 days and would merge 70, your baseline acceptance is 70%. If 150 pull requests open automatically in the next 30 days and 120 merge, it is 80%, which is evidence for the auto-merge tier. Redo this with your own numbers; it is not a predicted outcome.

Metrics to track: a checklist, not a promise

Measure the loop, not the scanner. Each metric below has a definition you can compute from your own data.

• Mean time to remediate (MTTR), by priority band. Median and 90th percentile days from finding created to finding closed by a verified rescan. Report the median; the average hides the long tail.
• Exploitable and reachable backlog. Count of open findings that are reachable or unknown, and KEV listed or above your EPSS threshold, on production assets. This is the number to put in front of the board.
• Fix pull request acceptance rate. Merged fix pull requests divided by fix pull requests opened, per tier. Falling acceptance is your early warning that a tier is too aggressive.
• Time from novel finding to merged fix. For validated novel vulnerabilities (zero-days), days from the finding reaching you to a verified fix or a documented mitigation.
• Exception health. Number of open exceptions, number past expiry, and median exception age.
• Regression rate. Findings that reappear after being closed, per quarter.
• Recurring classes. Top five CWEs among fixed first-party findings, quarter on quarter.

How Safeguard does this

Everything in this section comes from Safeguard's offering documentation and the public docs at docs.safeguard.sh. Where the docs show a screen or command, it is named; where they do not, the outcome is described instead. Every capability below is GA.

1. Detect known vulnerabilities continuously

Enterprise Software Supply Chain Manager (ESSCM, GA) is the product that runs the loop. Its software composition analysis (GA) builds a full transitive inventory of each project, and its vulnerability management (GA) matches components against NVD, OSV, CISA KEV, other public advisory databases, vendor bulletins and researcher disclosures, according to the Vulnerabilities docs page.

Continuous scanning (GA) is event driven. The docs list three triggers: vulnerability feed updates (a new advisory, a KEV addition or an EPSS change affecting a component you use), Safeguard's own zero-day publication, and asset changes such as a new commit or image tag. Advisories are matched by package URL, version range and CPE, and only affected assets are rescored.

2. Detect novel vulnerabilities (zero-days) in your code with SAST

Safeguard SAST (GA) traces untrusted input from a source to a dangerous sink across functions and files, and each finding carries the dataflow trace, a CWE and OWASP mapping, a severity and a code location. The docs list JavaScript and TypeScript, Python and Java as the first languages. It runs in your pipeline, or on a local runner so source never leaves your perimeter, and the CLI form shown in the docs is:

safeguard appsec sast --dir ./src --tenant-id <tenant> --product-id <product>

We did not run this command for this post.

3. Detect novel vulnerabilities (zero-days) in dependencies with Zero-Day Discovery

As the docs describe it, Zero-Day Discovery (GA) runs a continuous research pipeline across open source packages, container base images and AI models. The docs describe four stages:

1. Ingestion. Public commits on watched repositories across the major package ecosystems, new releases, maintainer signals such as issues and draft advisories, and container base image changes.
2. Analysis. Static analysis (taint tracking, dataflow, symbolic execution and fuzz driven input generation), sandboxed dynamic analysis, differential analysis against the previous version, dependency graph analysis, and a review of each candidate by Griffin, Safeguard's security model.
3. Validation. A candidate becomes a zero-day only if a reproducer runs without manual tweaking, a minimum qualifying context analysis shows a realistic path to exploitation, and at least one human researcher signs off on impact and severity.
4. Publishing. Subscribers receive the finding through ESSCM, the Portal and the CLI and IDE clients, and SBOMs are rescored. In parallel, the upstream maintainer gets a coordinated disclosure with a 90 day default embargo, shorter if active exploitation is observed, and Safeguard requests a CVE assignment.

The docs say research targets medium severity and above with a realistic exploit path, and filters out bugs that do not cross a trust boundary.

In your tenant, a validated zero-day appears as a new ESSCM finding in the zero-day category, triggers a Griffin remediation pull request when a patched version or safe configuration exists, and raises a policy alert if the component violates a gate.

4. Decide what matters with reachability, EPSS and KEV

Reachability analysis and prioritisation (GA) combines four signals according to the docs: reachability, exploitability (EPSS, KEV and public proof of concept availability), runtime context and business context. Reachability comes in three forms (static call graph, dynamic observation at runtime, and configuration parsing), and each finding is classed as reachable, conditionally reachable, unreachable or unknown. Unknown is treated conservatively as potentially reachable, which is the behaviour you want for novel findings.

Each finding gets a Priority Score from 0 to 100, with weights configurable per tenant under Settings, Prioritization. The Vulnerabilities tab has Priority and Reachability columns, and you can filter with expressions such as env:production reachable:true kev:true or ask Griffin in plain English for reachable production findings. Support varies by language, so check the language table on the reachability docs page for your stack.

5. Enforce decisions with policies and gates

Policies, gates and guardrails (GA) separate the rule from the checkpoint: a policy evaluates your SBOMs and produces findings, and a gate enforces linked policies. You build a policy under Settings, Policies, Create Policy, using the visual builder or YAML, with conditions such as vulnerability severity, CVSS, EPSS, license, component age and maintenance status. Templates include "No Critical Vulnerabilities" and "No Abandoned Packages". Policies can also be drafted from a plain English description (GA).

Each policy has one Action, and the docs define exactly three:

Approval runs through exceptions. A developer selects Request Exception, picks the policy and finding, gives a business justification and an expiration date, and submits it. Approvers are notified, decide, and the audit trail records the result. The Vulnerabilities page adds Mark False Positive and Accept Risk, each with a justification.

Gate outcomes fail safe: any failed Block policy fails the gate, an Error is never counted as a pass, and a gate never evaluated shows "Not evaluated", never "Passed". One caveat from the docs: policy outcomes are switched on per workspace by Safeguard, so ask your Safeguard contact if you do not see the Outcome column.

6. Put the gate in CI

This is the GitHub Actions workflow exactly as the docs publish it; with no checkout step, Safeguard clones the repository itself. You first create a secret key under Settings, Developer with the scopes scans:trigger and scans:read, and store it in the repository as SAFEGUARD_API_KEY.

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs list --fail-on-gate all as the option to fail on a policy gate instead of, or as well as, a severity threshold. With it, the job exits zero when the gate is Passed or Warning, and non-zero when it is Failed, Error or Not evaluated. We did not run this workflow for this post; copy it from the docs page, which is the maintained version.

7. Fix with autonomous remediation

Autonomous remediation (GA) is Griffin's AI Remediate flow. The docs describe five steps: analysis of the vulnerability and your codebase, choice of the safest upgrade path, an impact assessment for breaking changes, creation of a pull request with all changes, and validation by running automated tests. It upgrades packages, resolves transitive conflicts, updates lock files, fixes configuration issues such as insecure defaults, and in some cases changes code.

There are three ways to run it, all in the docs:

1. Single. Open a vulnerability, select AI Remediate, review the proposed change, then Create Pull Request.
2. Bulk. Select several vulnerabilities, choose AI Remediate Selected, review, and Griffin opens one pull request per repository with compatible fixes batched.
3. Page level. From the Vulnerabilities page, select AI Remediate at the top, review the plan for all fixable vulnerabilities, then approve and create the pull requests.

Each pull request carries a title with the CVE reference, a description, a summary of changes, breaking change warnings and test results if tests are configured. Breaking changes are classed Safe, Minor, Major or Critical, which maps directly onto the autonomy matrix earlier in this post. Settings, AI Remediate holds Auto-Create PRs, Require Approval, Test Integration, Breaking Change Policy and Branch Naming.

At the platform level, the offering documentation describes remediation categories (vulnerabilities, dependencies, license, security posture, findings and more), each set separately to Manual or Auto with its own strategy, from Safest (backward compatible only) to Aggressive (including major versions). Autonomous remediation ships switched off, with every category set to Manual. Nothing is applied until an administrator turns it on, which is what makes the 30/60/90-day rollout possible.

8. Source a safe version

Gold Open Source (GA), at gold.safeguard.sh, is free and needs no login. It gives CVE intelligence with affected and fixed versions, an "Am I affected?" check, and a recommended safe version for each package with known vulnerabilities. It is a quick way for an engineer reviewing a fix pull request to confirm the target version independently. When upstream has no fix at all, see the fork and patch path in the section on fixing without waiting for upstream, below.

9. Verify by rescanning

Verification is built into the same continuous scanning loop: a merged fix is a new commit, and a new commit triggers a rescan. Every asset has a Timeline of scans showing what triggered each one and the diff from the previous scan (added, resolved and changed severity findings), with a Griffin summary. The CI gate then evaluates on the new data. Combine that with the Test Integration setting so every fix pull request carries test results before anyone merges.

10. Prevent recurrence in the IDE, at install time and in CI

• IDE extensions (GA) for VS Code, Cursor and JetBrains IDEs scan dependency manifests as you work, surface vulnerabilities inline and offer AI-assisted fixes. Sign in uses an OAuth device flow.
• Package Firewall (GA) is an install-time proxy for npm and pip. It blocks malicious, typosquatted and dependency confusion packages at install time, with Allow, Warn and Block outcomes plus audit and quarantine modes. Start in audit mode to baseline.
• CI gates from step 6 stop a known bad component or pattern from merging again.
• The CLI (GA) runs scans locally or in CI, and the local runner keeps source on your machine.

For buyers who cannot send code to a third-party model, Zero AI mode (GA) runs the platform deterministically with no LLM in the loop, and bring your own model (GA) lets you plug in a model you already approve.

Requirement, Safeguard and what you still own

What Safeguard does not do

• It does not guarantee that every novel vulnerability (zero-day) will be found. Zero-Day Discovery is a research pipeline with validation rules and suppression criteria; no pipeline can promise complete coverage, and Safeguard makes no detection rate claim.
• It does not merge on its own by default. Autonomous remediation ships switched off with every category set to Manual. The docs do not describe a Safeguard auto-merge setting; in this post's rollout, auto-merge is a rule in your own repository host.
• It does not fix vendor appliances, hosted services or operating system kernels you do not build. Those fixes still come from the vendor or distribution, and compensating controls remain your job.
• It does not decide your risk appetite. Policies, thresholds, exception approvals and the autonomy tiers are written and owned by your people.
• It does not yet expose a CLI command or working REST endpoint for the zero-day feed. The docs say there is no CLI command for the feed yet, and the /v1 REST endpoints are not yet available. Use the in-app findings, gates and notifications.
• SAST language coverage is narrower than SCA. The docs list JavaScript and TypeScript, Python and Java first. Reachability depth also varies by language.
• It does not notify regulators, customers or upstream maintainers on your behalf. Safeguard runs coordinated disclosure for its own research; your incident and disclosure obligations stay with you.

Common mistakes

1. Treating "zero-day" as a synonym for "critical". A novel vulnerability (zero-day) is defined by being unknown, not by its severity. Plenty of zero-days are medium severity, and plenty of critical CVEs are years old.
2. Waiting for an NVD score before acting. NIST now openly prioritises enrichment. Use KEV, EPSS, reachability and your own asset context instead of waiting.
3. Turning on auto-merge before measuring acceptance. Without a baseline acceptance rate per tier, you have no evidence the tier is safe.
4. Blocking on severity alone. "No criticals" gates fail every build in a large estate, and teams learn to route around them. Block on reachable and exploited, warn on the rest.
5. Exceptions without expiry. An exception with no end date is a permanent risk acceptance nobody signed.
6. Closing findings when the pull request merges. Close them when the rescan of the merged commit agrees.
7. Fixing instances, not classes. If you fix the same CWE five times in a quarter, the fix is in the IDE rule or the library choice, not the sixth pull request.

FAQ

What is a novel vulnerability?

A novel vulnerability is a zero-day: a weakness that is not yet publicly known or catalogued, with no CVE record, no advisory and usually no vendor fix. The NIST CSRC glossary, quoting CNSSI 4009-2022, defines a zero-day attack as one that exploits a previously unknown vulnerability. Because feed-based scanners match against public identifiers, they cannot see novel vulnerabilities (zero-days) until a CVE exists.

Can a vulnerability scanner find zero-days?

A scanner that only matches your inventory against CVE, OSV or vendor feeds cannot, because there is nothing to match yet. Finding novel vulnerabilities (zero-days) takes code analysis such as SAST with dataflow tracing for your own code, and research on third-party code: watching releases, analysing changes, building reproducers and validating exploitability.

Why can't the CISA KEV catalog list zero-days?

CISA's criteria require an assigned CVE ID, reliable evidence of active exploitation and a clear remediation action. A novel vulnerability (zero-day) has none of the first and usually none of the third, so it enters KEV only after it is catalogued and exploited.

What does autonomous vulnerability remediation mean?

It means a closed loop in which findings are detected, prioritised, fixed through pull requests, verified by rescans and prevented from recurring, without a person moving each item between stages. People still write the policies, set which fixes may run without review, and approve exceptions.

Is it safe to auto-merge security fixes?

For the lowest risk class, once you have evidence. Measure how often engineers accept proposed fixes, then allow automatic pull requests with human merge, and only then auto-merge patch level upgrades with passing tests and no breaking change flag. Keep major upgrades and first-party code changes under review.

How does reachability analysis help prioritise vulnerabilities?

It checks whether your code actually calls the vulnerable function or path. Combined with KEV status, EPSS and whether the asset is internet facing, it turns a flat list of CVEs into a ranked queue. Findings the analyser cannot decide should be treated as reachable.

What should I do when there is no patch for a vulnerability?

Mitigate first (configuration change, feature flag, network control), record an exception with a short expiry, and plan a sourcing route: a maintained alternative, a patched fork, or a hardened build. Rescan as soon as a fix ships upstream.

Does Safeguard Zero-Day Discovery work without sending my code anywhere?

Zero-Day Discovery researches open source packages, container base images and AI models, not your private repositories. For your own code, SAST can run on a local runner so source stays inside your perimeter.

Closing the gap when there is no fix yet

Everything above assumes that once a novel vulnerability (zero-day) becomes known, a fixed version eventually exists for your remediation loop to move to. The section below covers both cases, including the harder one where upstream has no fix and you need a patched build rather than a ticket.

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 is a real CLI session: asked to "fix the lodash CVE in this repo", the CLI reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. It is this post's fix and verify stages on one repository, with a human approving each change.

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

The second demo sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. Detection runs where your source lives, which matters when that code cannot leave your network.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use, so an assistant can work with your findings while you control what it may touch.

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

Quick check

For related reading, see what a fix pull request is, which signal should drive patching between KEV, EPSS and CVSS, pull request time policy gates that developers accept, bulk remediation of an aged backlog, a primer on taint analysis for zero-day discovery and security risks in AI-generated code.

To try the loop yourself, download the apps and CLI at safeguard.sh/download and read the setup guides at docs.safeguard.sh.

Sources

• NIST CSRC glossary: zero day attack (CNSSI 4009-2022, NISTIR 8011 Vol. 3)
• NIST CSRC glossary: vulnerability
• NIST NVD news, including "NIST Updates NVD Operations to Address Record CVE Growth" (15 April 2026)
• CISA Known Exploited Vulnerabilities catalog
• CISA KEV catalog JSON feed (catalog version 2026.10.23)
• CISA: criteria for the Known Exploited Vulnerabilities catalog
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk (10 June 2026)
• NIST SP 800-218, Secure Software Development Framework 1.1
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• FIRST: Exploit Prediction Scoring System (EPSS)
• MITRE: Common Weakness Enumeration
• Stack Overflow Developer Survey 2025: AI
• Safeguard docs: Zero-Day Discovery
• Safeguard docs: AI Remediate
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Vulnerabilities
• Safeguard docs: Continuous Scanning
• Safeguard docs: Griffin AI
• Safeguard docs: Application Security Testing (SAST and DAST)
• Safeguard docs: GitHub Actions
• Safeguard docs: IDE Support
• Safeguard docs: Package Firewall
• Safeguard docs: Gold Open Source

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