To tell whether a dependency can respond to a vulnerability, check six things: a way to report one, a record of timely fixes, fixes for older releases, a long term support version, security guidance, and secure defaults. These come from the OpenSSF guide for evaluating open source software.
Why check this before an incident
A project's security response is easiest to judge when nothing is wrong. During an incident you have no time to find out that nobody reads the security mailbox. The OpenSSF guide lists security response among its security practices and vulnerability reporting under usability.
The six questions
| Question | What the guide asks |
|---|---|
| Reporting route | Are there instructions for how to report a vulnerability? |
| Timely fixes | Does the project fix bugs, especially security bugs, in a timely manner? |
| Older releases | Does it release security fixes for older versions? |
| LTS | Is there a Long Term Support version? |
| Security guidance | Is there guidance on how to use the software securely? |
| Secure defaults | Are default configuration and simple examples secure? If not, the guide says to avoid it. |
How to check each
- Reporting route. Look for a security policy file, a private reporting feature or a security contact. See security policy versus security.txt.
- Timely fixes. Read closed security advisories and compare report and fix dates.
- Older releases. Check whether advisories name fixed versions in more than one release line. A supported versions table helps, as in supported versions in a security policy.
- LTS. Look for a stated long term support policy and end dates.
- Guidance. Check the docs for a security section.
- Defaults. Follow the quick start and look at what is turned on.
Reading the answers
| Finding | What it suggests |
|---|---|
| No reporting route | Reports may go public by default |
| Fixes only on the newest release | You must upgrade the major version to get a patch |
| No LTS and fast major releases | Plan for frequent upgrades |
| Insecure defaults | The guide advises avoiding the software |
What to record
Keep the answers beside the dependency record, with the date. If the project fails the reporting question, decide ahead of time how you would disclose a finding. See where maintainers announce security fixes.
What it will not tell you
Process is not outcome. A project can have a policy and be slow, or have none and be quick. Treat these questions as a way to find gaps, then look at behavior over time. For a maintainer-side view, see how fast a maintainer should fix a vulnerability. Safeguard can help with the inventory part. Its SBOM and dependency scanning lists what your projects actually pull in, so you can see which components you depend on and decide where to look closer. You can try a free scan at gold.safeguard.sh/scan.
Quick check
What if a project has no security policy?
Treat it as a gap. Look for another contact route, and plan how you would disclose a finding.
Do all projects offer long term support?
No. The guide asks whether an LTS version exists so you can plan upgrades. Many projects do not have one.
Sources
Last reviewed: 19 October 2026.
