Coordinated Vulnerability Disclosure: CNAs, CVE IDs, Embargoes, 90 Days

Coordinated vulnerability disclosure (CVD) is the agreed process for getting a newly found vulnerability from the person who found it to the vendor who can fix it, and then to the public, in an order that gives users a fix or a mitigation before attackers get a roadmap. A CVE Numbering Authority (CNA) with the right scope assigns the CVE ID and must publish the CVE Record within 72 hours of the ID going public. An embargo keeps details private until an agreed date. Deadlines such as Google Project Zero's 90+30 days and the CERT Coordination Center's 45 days set how long a vendor gets before details come out anyway.

This post explains each of those pieces from the primary rules, then shows what an AppSec or product security team should do on the receiving end of a disclosure, and where Safeguard helps on that response side. It does not cover finding vulnerabilities. It covers what happens once someone has found one.

Key takeaways

• CVD has five roles: finder, reporter, vendor, coordinator and deployer. Most AppSec teams play two of them, vendor for their own products and deployer for everything they consume.
• The CVE Program runs on the CNA Operational Rules, version 4.0, effective 8 August 2024. The CNA with the most appropriate scope gets the first chance to assign an ID, and an assigned ID must eventually be made public or rejected.
• A CNA must publish the CVE Record within 72 hours of publicly disclosing the ID it assigned, and should do it within 24 hours.
• An embargo is a hold on publishing details until affected vendors can ship fixes or mitigations. It only works if every party honors it, and it can break.
• Project Zero gives vendors 90 days, then publishes 30 days after a patch ships. Exploited in the wild bugs get 7 days. CERT/CC defaults to 45 days. Neither is a law.
• For your consuming side, Safeguard SBOM generation (GA), vulnerability management with EPSS and CISA KEV enrichment (GA), reachability analysis (GA), CSAF and VEX upload (GA), and policies and gates (GA) turn a disclosure into a list of affected projects, a priority and a stop on new vulnerable builds.
• Autonomous remediation (GA) opens fix pull requests when a fixed version exists. It ships switched off, with every category set to Manual.
• For your producing side, Trust Center (GA) lets you post a security advisory and notify the security contacts your customers named.

What coordinated vulnerability disclosure is

The CERT Coordination Center's guide to CVD, the reference text most programs borrow from, frames the process around a small set of roles. A finder discovers the problem. A reporter tells someone about it, and is often but not always the same person. A vendor owns the affected product and can produce a fix. A coordinator helps when there are many vendors, when a vendor will not respond, or when the reporter wants a neutral party in the middle. A deployer runs the affected software and has to apply the fix.

"Coordinated" sits between full disclosure, where details go public with no warning to the vendor, and private disclosure, where the public may never be told. The vendor is told first and given a reasonable window, the public is told on an agreed date, and if the vendor stalls, a deadline means the public is told anyway.

Most AppSec teams sit in more than one seat: vendor for the software they ship, deployer for every package, image and service they build on, and sometimes finder, when a pentest turns up a bug in someone else's code.

For a shorter primer, see the six phases of coordinated vulnerability disclosure and the older coordinated vulnerability disclosure guide.

Why the process exists: the window you are trying to shrink

Every vulnerability has a period when someone knows about it and the people running the software cannot yet protect themselves. If attackers know first, that period is a zero-day. If the vendor knows first, the period is the time to build, test and ship a fix. CVD exists to keep that second window short and to keep attackers out of it.

Three things go wrong without a shared process.

Reports get lost. A researcher who cannot find a security contact sends the report to a sales or support inbox, where it sits. RFC 9116, published in April 2022, exists because this happens so often. It defines a security.txt file served at /.well-known/security.txt with a required Contact field and a required Expires field, so a finder can locate the right inbox in seconds.

Disclosure happens on the wrong day. If a reporter publishes before the vendor has a fix, deployers face a known bug with no patch. If the vendor sits on a fix for months, deployers carry a risk they do not know about. A shared deadline settles the argument before it starts.

Everyone uses a different name for the same bug. Without a common identifier, an advisory, a scanner finding and a news story can describe one flaw three ways. The CVE ID solves that, which is why CVE assignment is part of CVD.

Standards and regulators have been pushing organizations to treat disclosure as a defined process rather than a favor. ISO/IEC 29147 covers how a vendor receives reports and publishes advisories, and its companion ISO/IEC 30111 covers the internal handling process between receiving a report and shipping a fix. NIST's Secure Software Development Framework, SP 800-218 published in February 2022, has a Respond to Vulnerabilities practice group, and task RV.1.3 asks producers to have a policy that addresses vulnerability disclosure and remediation. In the United States, CISA Binding Operational Directive 20-01, issued 2 September 2020, required every federal civilian agency to publish a vulnerability disclosure policy. The FIRST PSIRT Services Framework describes the same work from the point of view of a vendor's product security team, with vulnerability disclosure as one of its service areas.

The CVE Program in one picture

Before you can understand CVE assignment, it helps to know who is who. The program's own site lists "the CVE Program is run entirely by the MITRE Corporation" as a myth. The structure is more distributed than that.

• The CVE Board oversees operations and sets strategic direction. It approves the CNA Operational Rules and any exceptions to them.
• The Secretariat, currently The MITRE Corporation, provides administrative and logistical support to the Board and maintains the program's infrastructure.
• Top-Level Roots report directly to the Board and manage their own hierarchies. The program lists two: CISA and MITRE.
• Roots perform the managerial work for the CNAs in their part of a hierarchy, including approving scope and reviewing rule infractions.
• CNAs do the operational work: they assign CVE IDs and publish CVE Records within their approved scope.
• CNAs of Last Resort (CNA-LRs) cover vulnerabilities that fall outside every other CNA's scope. The rules note, as an example, that MITRE currently acts as the Secretariat, a Top-Level Root and a CNA-LR at the same time.
• Authorized Data Publishers (ADPs) enrich CVE Records after a CNA publishes them. The program site lists one active ADP, run by CISA. An ADP writes into its own container in the record and cannot change what the CNA wrote.

The rules list many kinds of CNA: suppliers with product security teams, open source projects and foundations, service providers, researchers, national CSIRTs, coordinators, vulnerability databases and bug bounty providers. Many are suppliers assigning IDs for their own products, so for much of the software you run, the vendor itself decides whether a CVE exists and what the record says.

The published posts on what a CVE Numbering Authority is and on why CNA status matters when a vendor discloses go further into becoming a CNA. Here we focus on the rules a CNA must follow, because they set the clock you work against.

How a CVE ID gets assigned, step by step

The CVE Program describes the lifecycle in five verbs: discover, report, request, reserve and publish. The CNA Operational Rules, version 4.0, approved by the CVE Board on 8 May 2024 and effective 8 August 2024, fill in the detail. Rule numbers below are from that document.

1. Someone decides it is a vulnerability

Section 4.1 sets out what counts. The program's glossary defines a vulnerability as a weakness in a product that can be exploited to harm confidentiality, integrity or availability. The rules then narrow it in ways that matter for real reports:

• If the supplier says a vulnerability exists, CNAs should agree (4.1.1).
• Behavior with no security impact should not be called a vulnerability (4.1.2).
• An insecure default configuration should be (4.1.4). A documented, non-default setting that an authorized user chose should not (4.1.3).
• Deliberately malicious code is not a vulnerability (4.1.8), though a product modified to become malicious, such as a backdoored build, may be (4.1.9).
• Updating a dependency is never itself a vulnerability (4.1.12). If your product pulls in a vulnerable library and you upgrade it, that upgrade does not get a new CVE in your product just because you did it.

The idea that holds most decisions together is "independently fixable" (4.1.10). If two problems can be fixed separately, they are usually two vulnerabilities. If one only happens because of the other, such as a buffer overflow that only occurs after an integer overflow, they are one (4.1.11).

2. The right CNA gets the first chance

Rule 4.2.1.1 says the CNA with the most appropriate scope must be contacted and given the first opportunity to assign. In many cases that is the supplier of the affected product. This is "first refusal", and it is why a reporter who goes straight to a CNA-LR is usually sent back to the vendor.

For a vulnerability that is already public, the rules set a clock. If the CNA with scope says it will not assign, has documented in advance that it will not, or does not answer within 72 hours, a Root must step in and make a determination (4.2.1.2). For a vulnerability that is not yet public, a refusal goes to the dispute process in 4.6 instead (4.2.1.3).

One rule speaks directly to supply chain cases. If a supplier CNA finds a vulnerability in an upstream dependency, and the upstream supplier is itself a CNA, the downstream CNA must notify the upstream supplier and defer first refusal to it (4.2.16.6). In practice, if a vendor you buy from finds a bug in an open source library it uses, and that library's project or foundation is a CNA, the library's CNA should assign. You should expect one CVE for the library, not one per downstream product.

The published post on the CVE request process and CNA first refusal walks through this from a small vendor's side.

3. The CNA decides whether to assign

Rule 4.2.2.1 says a CNA should assign if it has reasonable evidence of a vulnerability, the vulnerability has been or is expected to be made public, and it is in scope. Rule 4.2.2.2 adds that a CNA should disclose and assign when the issue could cause significant harm or needs action by parties other than the CNA or supplier. Several other rules shape the result:

• CNAs assign IDs to vulnerabilities, not to fixes, and should assign whether or not a fix exists (4.2.7). A CVE with no fixed version is normal.
• The type of technology, such as cloud, on-premises or AI, must not be the sole reason to assign or refuse (4.2.3).
• Products that are not and never were publicly available should not get IDs (4.2.10).
• When the same independently fixable flaw sits in shared code used by several products, there must be one ID shared by all of them (4.2.13).
• For end-of-life products that no longer receive fixes, CNAs should still assign, and must tag the record "unsupported-when-assigned" (4.2.17.1).
• When the CNA cannot reach a clear decision after a good faith effort, it should err on the side of assigning (4.4.3).

4. The ID is reserved

Once a CNA decides to assign, the ID is reserved. A reserved ID tells the world nothing about the vulnerability. It is a placeholder the CNA, the vendor and the reporter can all use in private while a fix is built. Rule 4.3.3 says the CNA must give the ID to the reporter.

The year in a CVE ID is the year the ID was reserved or the year the vulnerability was made public, not the year it was found. A CVE with an older year that suddenly appears in your scanner is not necessarily an old bug you missed. It may have been reserved long ago and only published now.

Reserving creates an obligation. Rule 4.2.4 says that if a CNA assigns an ID, the vulnerability must be made public by the CNA or someone else, or the CNA must reject the ID. Rule 4.2.5 says CNAs must not assign IDs for vulnerabilities they do not intend to make public. A CVE ID is a commitment to eventual public disclosure, not a private tracking number.

5. The record is published

When the vulnerability goes public, the CNA publishes the CVE Record. Two rules set the clock:

• The CNA should publish within 24 hours of publicly disclosing the ID (4.5.1.3).
• The CNA must publish within 72 hours. If it does not, its Root may direct a CNA-LR to publish instead (4.5.1.4).

If someone else makes the ID public first, for example a researcher who publishes a write-up on the agreed day before the vendor's record is live, the CNA should still publish within 72 hours of finding out (4.5.1.6). In exigent cases, a Top-Level Root may direct a CNA-LR to publish when the CNA with scope has not (4.5.1.5).

The rules also require supplier CNAs to keep at least one public distribution point, such as a security advisories page, where they publish information about the vulnerabilities they assign (4.5.2.2). That page must not require registration or login, and must not carry terms that restrict general use of the information (4.5.2.4). The advisory must not contradict the CVE Record (4.5.2.3).

Section 5 sets the minimum content of a record, including a description and public references. Note what is not on that list. The program's own myths page is clear that the CVE Program does not assign severity scores. Scores in a record come from the CNA, if it chooses to provide them, or from enrichment such as the CISA ADP container or downstream databases. When two sources show different scores for the same CVE, that is why.

6. The record may later be rejected or disputed

A reserved ID that is never made public must be rejected (4.2.4). A published record can be disputed through the process in section 4.6, and the CVE Program publishes a separate policy for that. As a deployer, treat a rejected CVE as a signal to close the finding with a note, and a disputed one as a signal to read the supplier's own advisory before acting.

The published post on reading CVE JSON 5 records and affected versions shows how to read the CNA and ADP containers in a real record.

Embargoes: how the private window works

The FIRST PSIRT Services Framework defines an embargo as a hold on publishing vulnerability details until affected vendors can release security updates or mitigations and workarounds. The framework says a product security team should honor the embargo terms set by the finder or reporting organization, and expect its own to be honored in turn. It also says those information sharing terms should be written down.

An embargo usually has four parts:

1. A date and time. Often a specific hour in a named time zone, because "Tuesday" means different things in different places.
2. A list of who knows. The reporter, the vendor, any coordinator, and sometimes downstream vendors who ship the affected code, such as operating system distributions.
3. Rules for what each party may do before the date. Usually: build and test fixes, prepare advisories, stage packages, but not publish anything, not push public commits that reveal the fix, and not tell customers outside the list.
4. A break clause. What happens if details leak or the bug is seen exploited before the date. In most programs the answer is to publish early.

Why embargoes matter to deployers

If you consume software, you are usually not on the list. You find out on disclosure day with everyone else, including attackers who diff patches. A well run embargo means the advisory, the CVE Record and the fixed release land together. A broken one means public discussion of a bug with no fix and no record yet. Two consequences follow:

• You cannot prepare for a specific embargoed bug, but you can prepare for disclosure day. That means knowing what you run before any advisory lands, which is an SBOM problem.
• Treat a leaked disclosure differently from a scheduled one. If details are public and no fix exists, you are in mitigation mode, not patch mode.

Why embargoes matter to vendors

If you ship software, embargoes are where most disclosure mistakes happen. The usual ones are:

• Pushing a fix to a public repository with a commit message that describes the bug, days before the agreed date.
• Telling a large customer early, informally, which breaks the embargo for everyone else.
• Not telling downstream vendors that bundle your code, so they find out on disclosure day and their users wait days longer.
• Publishing the advisory but not the CVE Record, so scanners and databases cannot match it.

The OpenSSF guide for open source maintainers recommends a small private vulnerability management team with its own private alias, separate from the intake address, so fixes can be built without exposing them.

The 90 day norm and where it comes from

There is no law that says a vendor gets 90 days. The number is a norm, and it comes from a few published policies that many others copied. Here is what each says, from its own page.

Google Project Zero: 90+30

Project Zero's published policy gives a vendor 90 days from notification to make a patch available. If the vendor patches within 90 days, Project Zero publishes technical details 30 days after the patch ships. The policy's own examples: a patch on day 47 means details on day 77, and a patch on day 83 means details on day 113. If there is no patch by day 90, details come out at the end of the 90 day period.

A vendor that will ship within an extra 14 days, by day 104, can ask for a grace period. Details then come out on day 120.

For bugs Project Zero finds being exploited against real users, a 7 day deadline replaces the 90 day one. The 30 day window after a patch still applies if the patch ships within 7 days. The grace period for exploited bugs is 3 days, and details come out on day 37 in that case. The policy also allows the vendor and Project Zero to agree to publish earlier than any of these dates.

The "+30" is easy to miss. A patch existing is not the same as users having installed it, and the extra month gives deployers time to roll it out before the technical write-up.

CERT/CC: 45 days

The CERT Coordination Center's published policy says vulnerabilities reported to it will be disclosed to the public 45 days after the initial report, regardless of whether patches exist. The policy says evidence of active exploitation or other serious threats may cause CERT/CC to shorten the schedule, and that it may extend the schedule in some cases, for example when a vendor is making real progress on a hard problem. It also says CERT/CC may decline to coordinate or publish some reports. The published post on CERT/CC's 45 day disclosure origin covers the history.

Federal agencies: BOD 20-01 and VDPs

CISA's BOD 20-01 is not a deadline policy for vendors. It tells federal civilian agencies how to receive reports about their own systems. It required agencies to update their security contact at the .gov registrar within 30 days, to publish a vulnerability disclosure policy within 180 days, and to bring every internet-accessible system into scope within 2 years. It required agencies to authorize good faith research, to commit not to pursue legal action against people who follow the policy, and not to limit testing to vetted or registered parties. CISA said it would check for the policy at the /vulnerability-disclosure-policy path of each agency's main .gov site.

The lesson for any organization: publish a clear policy at a predictable address and say plainly that good faith research is authorized.

The norms side by side

The published posts on disclosure deadlines of 90, 30 and 45 days and the seven day rule for exploited bugs go deeper on choosing your own numbers.

What CVD looks like on disclosure day, from the receiving end

This is where most AppSec teams actually live. A vendor or an open source project publishes an advisory. A CVE Record appears. Within hours, it may show up in downstream databases, in your scanners and, if exploitation is confirmed, in the CISA Known Exploited Vulnerabilities catalog.

A few facts about that flow are worth knowing:

• The CVE Record may arrive before or after the advisory, by up to 72 hours under the rules. A record that says little beyond a description and a reference is normal on day one. Enrichment comes later.
• Severity can differ by source. The CNA may score it, an ADP may add a score, and a downstream database may add another. Pick a policy for which one you use and stick to it.
• KEV status changes the urgency. The KEV catalog lists vulnerabilities with evidence of active exploitation. Its entries now point federal agencies to BOD 26-04, "Prioritizing Security Updates Based on Risk", which replaced BOD 22-01 and its fixed KEV due dates. If you used to plan around the old 22-01 two week deadline, treat that as history.
• The fix may not exist yet. CNAs assign IDs whether or not a fix exists (4.2.7). An open CVE with no fixed version is a mitigation problem.
• Vendors increasingly publish machine-readable advisories. CSAF is the OASIS standard format for security advisories, and VEX documents state whether a given product is actually affected. When your vendor publishes them, you can load them rather than reading PDFs.

The first questions are always the same. Do we run the affected component, in which versions and products? Is the vulnerable code reachable? Is it exploited? Is there a fixed version? Those are inventory and prioritization questions.

How Safeguard helps on the response side, step by step

Safeguard does not take part in the disclosure itself. It does not receive reports for you, negotiate embargoes or assign CVE IDs. What it does is make disclosure day shorter for the teams on the receiving end, and give vendors a place to tell their own customers. Every capability below is GA. Screen names and steps are as shown in Safeguard's docs.

Step 1: Have an SBOM for every project before the advisory lands

You cannot answer "do we run it" quickly if you have to rebuild an inventory from scratch. Safeguard SBOM generation and analysis (GA) builds SPDX and CycloneDX SBOMs from your connected repositories, container images or uploads. Once a project has an SBOM, the Project Overview page shows its components. Click any project in the Projects list to open it. The Info tab shows how the SBOM was generated (SCM, Container or Manual) and charts such as Supply Chain Risk by Components. The Dependencies tab has a sortable, filterable table of every component and version.

Do this before disclosure day. It decides how fast you can respond.

Step 2: Find every project carrying the new CVE

Safeguard vulnerability management (GA) matches components against vulnerability data and enriches each finding. Safeguard's docs list the National Vulnerability Database among its data sources, and the offering files list NVD, OSV, CISA KEV and vendor bulletins. The Vulnerabilities view shows, for each finding, the CVE ID, CVSS score, EPSS score, whether it is exploited in the wild, the affected component and version, and the fixed version where one exists.

You can filter by severity, CVSS range, EPSS range, exploitable status and reachability status. You can also ask in plain English. The docs give this example:

Show me critical vulnerabilities in production that are actively exploited

On disclosure day, the useful query is narrower: the new CVE ID, or the affected package, across every project. The result is your affected list.

Step 3: Rank by whether the code is reachable and whether it is exploited

Not every project that carries a vulnerable package calls the vulnerable code. Safeguard reachability analysis (GA) ranks findings by whether your application actually reaches the vulnerable path, and combines that with EPSS and KEV. Use reachability to decide the order of work, not to close findings on its own. A finding that is unreachable today can become reachable after the next feature ships.

Step 4: Load the vendor's CSAF advisory or VEX statement

When the affected component comes from a vendor that publishes machine-readable advisories, load them. Safeguard CSAF and VEX upload (GA) accepts CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile, all as JSON. The flow in the docs:

1. Go to Integrations from the sidebar and filter by Upload.
2. Click Connect on the Upload CSAF/VEX card.
3. Enter a Name for the upload, then drag and drop the file or click Browse.
4. Configure the project the document applies to.
5. Click Upload.

A vendor CSAF advisory adds the vendor's own view of affected and fixed versions. A VEX document can mark vulnerabilities as not affected for a product, or record mitigation status. A minimal CSAF VEX status block from the docs looks like this:

"product_status": {
  "known_not_affected": ["PRODUCT-1.0"]
}

Step 5: Publish your own "not affected" statements

If you are a vendor, your customers will ask whether you are affected within hours of a big disclosure. If your analysis shows the vulnerable code is not present or not reachable in a given release, record that as a VEX statement and upload it the same way. That gives you one place to keep the decision, the justification and the product version together, instead of a chain of emails. VEX is your assertion. Be ready to defend it.

Step 6: Stop new vulnerable builds from shipping

While teams work through the affected list, you do not want new builds to add the same vulnerable version somewhere else. Safeguard policies and gates (GA) handle that. Policies generate findings. Gates enforce at checkpoints such as build, CI and release, with actions to block, warn or notify; approval runs through exceptions. In the docs, you go to Settings, then Policies, and click Create Policy. Templates include "No Critical Vulnerabilities". Gates can block deployments when policies fail and require approvals for exceptions.

During a disclosure, a common pattern is to start a new policy on warn for the first hours, so teams see it without being blocked, then move it to block once a fixed version exists and the first upgrades have merged.

Step 7: Open the fix pull requests

When a fixed version exists, Safeguard autonomous remediation (GA) can open tested, policy gated pull requests that move the dependency to the safe version, one repository at a time or in bulk. It ships switched off, with every category set to Manual. Turn on only what your team is ready to let run, and keep a human approval on anything that touches production.

Step 8: If you are the vendor, tell your customers in one place

If you ship software, your own customers are deployers waiting on your word. Safeguard Trust Center (GA) gives you a public page at an address of the form your-slug.trust.safeguard.sh. Per the docs, an update on the page can be an Announcement, an Incident or a Security advisory, and an incident carries a status: Investigating, Identified, Monitoring, Resolved or Not affected, with a dated history. Visitors can subscribe by email. Where security contacts are switched on, your customers can name the people who should receive security notifications, and Notify about an update sends a published update to every security contact.

This does not replace the public advisories page the CNA rules require. It makes sure your customers' security teams hear from you directly, with "Not affected" as a status rather than silence.

Step 9: Ask from Claude or the CLI

Safeguard is listed in Claude's connector directory as a community connector. Add it from the directory, sign in with OAuth, choose which tools Claude may use, then ask which projects carry a package version in plain words. The Safeguard CLI (GA) works from a terminal and, since v11.10.0, asks before running any command that changes something.

Who owns what: a decision table

What Safeguard does not do

• It does not assign CVE IDs or act for you in the CVE Program. IDs come from the CNA with scope under the CNA Operational Rules. Using Safeguard does not change who that is.
• It does not receive vulnerability reports from outside researchers in the flows described here. Your intake address, your security.txt file and your disclosure policy page are yours to run. Trust Center security contacts are for notifying your customers, not for taking reports in.
• It does not negotiate or enforce embargoes. Embargo terms are agreements between people. Safeguard can help you stage a VEX statement or a Trust Center advisory, but publishing on the right day, and not before, is your process.
• It cannot see components that are not in an SBOM. Vendored code copied into a repository without a manifest, binaries dropped onto servers by hand and software running in a vendor appliance will not show up until you bring them into an inventory.
• It does not fix vendor appliances, hosted services or operating system runtimes you do not build. Those fixes come from the vendor or distribution.
• It does not make VEX statements true. A "not affected" statement is your claim. If your analysis is wrong, the tooling will repeat the mistake faithfully.
• It does not give legal advice. Safe harbor language, researcher authorization and contract terms with reporters need your counsel.

Common mistakes

Treating a reserved CVE ID as confidential forever. Rule 4.2.4 is clear: an assigned ID must be made public or rejected. If you reserve IDs as internal tracking numbers, you are breaking the rules your CNA agreed to.

Assigning a new CVE in your product for a library you upgraded. Rule 4.1.12 says updating a dependency is not a vulnerability. Ship a release note and, if useful, a VEX statement that maps your versions to the upstream CVE.

Going around the upstream CNA. If you find a bug in an upstream library whose project is a CNA, rule 4.2.16.6 says you notify it and let it assign. Assigning your own ID creates a duplicate that every scanner downstream will have to reconcile.

Publishing the advisory and forgetting the record. The CVE Record must be published within 72 hours of the ID going public. Without it, databases and scanners cannot match the advisory, and your customers find out from someone else.

Leaking the fix through a public commit. A commit titled after the bug, pushed to a public branch before the embargo date, is a disclosure. Develop in private, merge on the day.

Assuming 90 days is a right. Project Zero's 90 days apply to Project Zero's reports. CERT/CC uses 45. A researcher may set their own deadline, and exploitation can cut any window to days. Write your own policy and say what you will commit to.

Using an old federal deadline as your internal SLA. BOD 22-01 is revoked and superseded by BOD 26-04. If your internal policy still says "fix KEV entries in two weeks because CISA says so", update the reasoning even if you keep the number.

FAQ

What is coordinated vulnerability disclosure in simple terms?

Tell the vendor first, give it a fair window to fix, then tell the public on an agreed date, ideally with a fix available.

Who assigns CVE IDs?

CVE Numbering Authorities. The CNA with the most appropriate scope, often the vendor of the product, gets the first chance under rule 4.2.1.1 of the CNA Operational Rules. If no CNA covers the product, a CNA of Last Resort can.

How long does a CNA have to publish a CVE Record?

Under rules 4.5.1.3 and 4.5.1.4, a CNA should publish within 24 hours of publicly disclosing the ID and must publish within 72 hours. After that, the CNA's Root may direct a CNA of Last Resort to publish it.

What happens if a vendor does not respond to a CVE request?

For a vulnerability that is already public, if the CNA with scope does not answer within 72 hours or says it will not assign, a Root must make a determination (rule 4.2.1.2). For one that is not public, the request goes through the dispute process in section 4.6.

Why does Project Zero use 90 days?

Project Zero's policy gives vendors 90 days from notification to ship a patch, then publishes details 30 days after the patch so users have time to install it. Exploited bugs get 7 days. Other organizations use other windows, for example 45 days at CERT/CC.

What is an embargo in vulnerability disclosure?

The FIRST PSIRT Services Framework defines it as a hold on publishing details until affected vendors can release updates or mitigations. In practice it is an agreed date and time, a list of parties who know, and rules for what each may do before then.

Does the CVE Program set the severity score?

No. The program lists that as a myth. Scores come from the CNA if it provides one, from enrichment such as the CISA ADP container, or from downstream databases.

Where does Safeguard fit in coordinated disclosure?

On the response side. SBOMs, vulnerability management, reachability, CSAF and VEX upload, policies and gates, and fix pull requests (all GA, with autonomous remediation shipping off) help you find and fix affected projects. Trust Center (GA) helps vendors notify their own customers. Safeguard does not assign CVE IDs or run embargoes.

Coordinated disclosure decides when you learn about a vulnerability. What happens next, in the dependencies and images you build yourself, is up to you, and the section below covers the options Safeguard gives you for that part.

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 shows Claude connected to Safeguard: you add the connector, sign in with OAuth and choose which tools Claude can use. On disclosure day, that is how you would ask which of your projects carry an affected package version, or which open findings are on the KEV list, without leaving the chat.

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

The second demo is a real Safeguard CLI session. You install it, open the interactive terminal and ask it to fix a lodash CVE in a 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. The same loop applies to any newly disclosed CVE with a fixed version: read the advisory, upgrade, test, review.

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

The third demo sets up the local runner on your own machine, approves it with a device code and then scans from the terminal. It suits teams that want to re-scan a repository the moment an advisory lands, without waiting for the next scheduled scan.

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

To try it on your own projects, start at safeguard.sh/download, and read the setup guides at docs.safeguard.sh.

Quick check

Sources

• CVE Program: CNA Operational Rules, version 4.0
• CVE Program: process overview
• CVE Program: overview and myths
• CVE Program: program structure
• CVE Program: Authorized Data Publishers
• Google Project Zero: vulnerability disclosure policy
• Google Project Zero: vulnerability disclosure FAQ
• CERT/CC: Guide to Coordinated Vulnerability Disclosure
• CERT/CC: vulnerability disclosure policy
• CISA: BOD 20-01, Develop and Publish a Vulnerability Disclosure Policy
• CISA: Known Exploited Vulnerabilities catalog
• NIST SP 800-218, Secure Software Development Framework
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
• FIRST: PSIRT Services Framework 1.1
• OpenSSF: guide to coordinated vulnerability disclosure for open source maintainers
• Safeguard docs: CSAF/VEX upload
• Safeguard docs: Vulnerabilities
• Safeguard docs: Explore SBOM
• Safeguard docs: Policies and Gates
• Safeguard docs: Trust Center setup
• Safeguard docs: CycloneDX VEX
• Gold Open Source

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