Publish your own advisory only if your library is actually affected, meaning it calls the vulnerable code in a way an attacker can reach. If it is not affected, say so in a short statement. If you are unsure, say that, and keep investigating.
Three possible answers
When a dependency gets an advisory, your library falls into one of three states. These line up with the status values in the OpenVEX specification: not_affected, affected, and under_investigation, plus fixed once you have shipped a fix.
| State | Meaning | What to publish |
|---|---|---|
| Not affected | Your library includes the dependency but the flaw cannot be triggered through you | A short statement with a reason |
| Affected | Users of your library can be exposed | Your own advisory and a patch release |
| Under investigation | You have not worked it out yet | A holding note, then an update |
How to decide
- Read the advisory carefully. Which functions, inputs or configurations are involved? Which versions are affected, and which is the first fixed one?
- Check your usage. Search your code for the vulnerable function or feature. Reachability tools exist for some ecosystems. Go's vulnerability tooling, for example, reports only vulnerabilities whose vulnerable functions are transitively called by your code, according to the Go documentation.
- Ask whether users can reach it through you. You might not call the flaw, yet expose a setting that lets users send input to it.
- Decide the state and write it down.
If you are affected
Publish an advisory through your normal flow, list the affected and patched versions of your own library, release the patch with the raised dependency floor, and credit the reporter if there was one. Link the upstream advisory so scanners and readers can connect the two. Related posts on this site cover advisory contents and the publishing checklist.
If you are not affected
You do not need a full advisory. Scanners will still flag your library because it depends on the vulnerable package, and users will ask. A short, dated statement helps. OpenVEX defines justification labels for a not affected status:
component_not_presentvulnerable_code_not_presentvulnerable_code_not_in_execute_pathvulnerable_code_cannot_be_controlled_by_adversaryinline_mitigations_already_exist
A plain sentence in your security policy can use the same reasoning, for example: "Version 3.2 of our library includes parser 2.3.0. We do not call the affected function, so we consider the library not affected. We will still raise the minimum version in our next release."
Even when not affected, raising the floor is cheap and removes the scanner noise.
If you are unsure
Say so, with a date. A statement that you are investigating is honest and better than silence. OpenVEX treats under investigation as a real status.
Do not do this
- Do not claim you are not affected without checking.
- Do not delete the alert and move on. Record the decision so you can show it later.
- Do not publish an advisory that merely copies the upstream text. Your readers need to know about your versions.
Quick check
Does every dependency CVE need a CVE of my own?
No. Only when your library is affected, and then you decide whether to request an identifier for your own advisory.
Is it fine to update the dependency anyway?
Yes. Raising the floor is a low cost way to quiet scanners, even if you are not affected.
Safeguard's reachability analysis helps you answer the second step by showing whether your code reaches the vulnerable function. The free scan is a good place to start.
Sources
- OpenVEX specification: https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md
- Go vulnerability management: https://go.dev/doc/security/vuln/
Last reviewed: 19 October 2026.
