There is no single legal deadline, but the OpenSSF Best Practices passing badge gives two useful yardsticks: an initial response to a vulnerability report within 14 days, and no unpatched medium or higher severity vulnerability that has been publicly known for more than 60 days. Use them to judge how a project handles security.
Where the numbers come from
The OpenSSF Best Practices badge is a set of criteria a project can meet and self-certify against. The passing level groups criteria into basics, change control, reporting, quality, security and analysis. Two criteria bear directly on speed:
- Reporting: the project must publish its vulnerability reporting process, and its initial response to a report received in the last six months must come within 14 days, unless the criterion is marked not applicable.
- Fixing: there must be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days. Critical ones should be fixed rapidly.
These are criteria for a badge, not laws. But they are specific and public, which makes them better than a vague sense of "responsive".
Turning them into checks on a dependency
| Yardstick | How to check it | Warning sign |
|---|---|---|
| Reporting process published | Look for a security policy in the repository or on the site | No way to report privately |
| First response in 14 days | Read closed security reports or advisories, if public | Reports sitting unanswered |
| No medium or higher flaw known over 60 days | Compare advisory publish date to fix release date | Long gaps, or still open |
Run it like this:
- Open the project's advisories and list the last three to five.
- For each, note the date it became public and the date of the fixed release.
- Subtract. A pattern of fixes within weeks looks healthy. A pattern of months looks different.
- Check whether fixes reached the versions people actually use, not only the newest major.
The OpenSSF evaluation guide adds a related item: assess timely bug and security fixes, patches for older releases, and long term support versions.
What the numbers do not prove
A badge is self reported against criteria, so it shows a project has addressed them, not that your risk is zero. A project with few advisories may be well built or may have few researchers looking. And one slow fix does not make a project bad, since volunteers have limited time.
Use the pattern, not a single data point. Also decide your own bar. If a dependency sits in a payment path, you may want faster than 60 days and a plan for when the upstream does not deliver, such as a patch or a replacement.
Setting your own internal clock
Maintainers' timelines are only half the picture. Your own service level matters too: how quickly do you update after a fix ships? A fast upstream fix is worth little if it sits in your backlog. Measure the time from fixed release to merged update, and set it by how exposed the component is.
Try it yourself
Open the demo and follow a vulnerability from detection to a fix decision. Notice where time passes between steps.
Click through it at your own pace, or open it full screen.
Quick check
Is 60 days a legal requirement?
No. It is a criterion in the OpenSSF Best Practices passing badge, useful as a yardstick.
What should I look at to judge a maintainer's speed?
The gap between public disclosure and the fixed release across several recent advisories, and whether older supported versions got the fix.
Safeguard's SBOM and dependency scanning flags known vulnerabilities in your dependencies, and its autonomous remediation can open fix pull requests, off by default with every category on Manual, so your own response time can keep pace. Try the free scan.
Sources
- OpenSSF Best Practices badge criteria (passing)
- OpenSSF Concise Guide for Evaluating Open Source Software
Last reviewed: 19 October 2026.
