There is no universal law, but a widely cited practice is a fixed deadline. Google Project Zero gives a vendor 90 days to make a patch available after being told of a bug, and 7 days if attackers are already exploiting it. After that, details can become public. Other researchers and programs use different timelines.
What "responsible disclosure" means here
When a researcher finds a flaw in software you use, they usually tell the vendor privately first. The vendor builds a fix. Then the details are published so everyone can learn from them. The open question is how long the private phase lasts. Too short, and users are exposed before a fix exists. Too long, and a vendor has no reason to hurry.
The Project Zero example
Project Zero's published policy sets these timelines:
| Situation | Deadline for the vendor |
|---|---|
| Normal case | 90 days from notification to make a patch available |
| Patch ships within 90 days | Details published 30 days after the patch reaches users |
| No patch by day 90 | Details published at the end of the 90 days |
| Attacks against real users already seen | 7 days |
| Vendor needs a little longer | A grace period may be granted on request |
The policy also says the two sides can agree to disclose earlier than these dates. Check the policy page for current wording, since teams adjust their rules over time.
Why this matters to you as a user
The deadline is a pressure tool for vendors, not a promise to you. A fix existing is not the same as the fix being on your device. Between "patch available" and "patch installed" sits your own update habit. CISA warns that attackers may keep targeting a flaw for months or years after a fix is available.
So there are two clocks. The vendor's clock ends when the fix ships. Yours ends when you install it.
What to do on your side
- Turn on automatic updates where the vendor offers them, as CISA recommends.
- Watch for security notices from vendors whose products you rely on.
- When a notice says a flaw is being exploited, treat the update as urgent rather than routine.
- Retire software that no longer gets security updates.
What to ask a vendor
- Do you have a published disclosure policy?
- What is your target time to fix a critical bug?
- How will you tell customers when a fix is out?
A vendor that can answer all three has thought about the process. One that cannot may still ship good software, but you have less to rely on when something goes wrong.
Where Safeguard fits
Safeguard keeps watching the components in your software after release, so when a new advisory lands you can see which products are affected and whether the flaw is reachable. Policies and gates control what ships, and fix PRs can be opened for review. Autonomous remediation is off by default, with every category on Manual.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new advisory is matched to the components you already use, and note how quickly you can tell whether you are affected.
Quick check
Is 90 days the law?
No. It is one team's published policy and a common reference point. Contracts, regulators and other programs may set different timelines.
Why 7 days when attacks are happening?
Because users are already being harmed. A shorter deadline pushes the vendor to ship a fix or mitigation quickly.
Sources
- Google Project Zero: Vulnerability Disclosure Policy
- CISA: Understanding Patches and Software Updates
Last reviewed: 19 October 2026.
