Look at the last few advisories for the package and compare three dates: when the issue was reported or disclosed, when a fixed version was published, and whether older release lines also got a fix. The gaps show security response better than a count of CVEs.
What to measure
The OpenSSF Concise Guide has a Security Response rule: assess whether the project fixes bugs, especially security bugs, in a timely manner, whether they release security fixes for older releases, and whether they have a long term support version. That is a short list of measurable things.
| Measure | Where to find it | What it tells you |
|---|---|---|
| Disclosure to fixed release | Advisory text, changelog, publish times | Speed of response |
| Fixed in a patch or only in a new major | Advisory fixed versions | Cost of upgrading for you |
| Older lines patched | Advisory affected ranges | Support for users who cannot jump |
| Clear advisory text | Advisory | Quality of communication |
| Reporting path | SECURITY.md | Whether reports can arrive |
A simple procedure
- Pull the advisories that affect the package. The deps.dev API lists advisory keys for a version, and the GetAdvisory method returns detail for a key.
- For each of the last three to five, note the disclosure date and the version that fixed it.
- Use the version publish times from the package endpoint to find the date of the fixed release.
- Compute the gap in days. Do not average across a long period. Look at the recent ones.
- Note whether a fix reached older minor or major lines.
- Write a one line summary, such as fixed in days, patch release, older line patched.
Reading the result fairly
A small gap is encouraging, but check the sample size. Two advisories say little. A large gap may reflect a volunteer project with limited time, a hard fix or a difficult disclosure. Context matters, and the project's own advisory text often explains it.
Compare against peers, not against an ideal. A volunteer library that fixes within weeks may be doing very well for its size. A commercially backed library that takes months deserves a question.
Also read what happens when a report is wrong. A maintainer who engages, explains and closes cleanly shows the same care as one who ships fast fixes.
What to do with the answer
If the response looks slow for a package in a sensitive role, plan for it. Pin a version, watch the project's advisories, set up automated notification and keep a replacement in mind. If you depend on a project heavily, consider contributing a fix or a security policy file yourself.
Try it yourself
Click through it at your own pace, or open it full screen. See how a finding is paired with the version that fixes it, the same pairing you read in advisories.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis and autonomous remediation with fix PRs, off by default with every category on Manual. A free scan is at gold.safeguard.sh/scan.
Quick check
How many advisories do I need to judge a maintainer?
Three to five recent ones give a rough view. Fewer than that is too little to conclude much.
What if a package has no advisories?
Then you cannot measure response. Look at the reporting path and recent bug fix cadence instead.
Sources
Last reviewed: 19 October 2026.
