A classic SCA tool cannot find a vulnerability that has not been published, because it works by matching your dependency versions against known advisories. Finding unpublished flaws needs a different capability, such as analysis of the dependency code itself. Ask any vendor which of the two they offer and how they label results.
What SCA matches against
SCA looks up each package and version in advisory data. The OSV format describes records with an identifier, affected packages, version ranges, and references. If no record exists, the match returns nothing, and the report shows no finding. That is a statement about the database, not about the code.
The lag is real. A flaw can exist for a long time before anyone reports it, and then a further gap can follow between disclosure and a record that your tool reads.
Three states a package can be in
| State | What SCA shows | What you know |
|---|---|---|
| Known and matched | A finding | A published flaw affects this version |
| Disclosed but not yet in your tool's data | Nothing | You cannot tell from the report |
| Not disclosed at all | Nothing | Nobody has told you |
A clean report therefore means "no known match in the data we hold today", which is a weaker claim than "this package is safe".
What helps with the gap
- Fast re-scanning. If a new advisory appears tomorrow, you want your inventory re-checked automatically, not at the next build. This does not find unpublished flaws, but it shortens exposure after publication.
- Exploited-in-the-wild signals. CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of active exploitation and recommends using it as an input to prioritization.
- Code-level analysis of dependencies. Some platforms analyze dependency source to look for flaws before a record exists. Safeguard's zero-day discovery is one GA capability in this area.
- Fewer and better dependencies. Every package you remove is a package whose undisclosed flaws cannot reach you.
Questions to ask a vendor
- When you report a possible flaw with no advisory, how do you label it, and how is it different from a matched finding?
- How do you disclose findings you make to maintainers?
- How soon after publication does a new record reach my results?
- Can I see evidence for a code-level finding, or only a score?
Treat any claim of finding unpublished flaws as something to test. Ask for a sample result on a package you know and check the evidence yourself.
A worked timeline
Consider a library with a flaw introduced in one release. These are the stages that can follow, and what your SCA report shows at each.
- The flaw ships. Nobody knows. Your report is clean.
- A researcher finds it and reports it privately to the maintainers. Your report is still clean.
- A fix is prepared. Your report is still clean.
- An advisory is published. An aggregated database ingests it. Some time later your tool's data updates, and a finding appears.
- Exploitation in the wild is observed and the flaw may be added to a known exploited list. The finding's priority rises.
Between steps one and four, your report said nothing. That is the gap that fast rescanning shortens only after step four, and that code-level analysis tries to address before it.
Step by step: shrink your exposure to unpublished flaws
- Inventory every dependency and know which services use each.
- Remove dependencies you do not need. Fewer packages mean fewer undisclosed flaws can reach you.
- Pin versions with lockfiles so you know exactly what you run.
- Set up automatic rechecking of stored inventories against new advisories, so step four becomes a same day event.
- Subscribe to the exploited-in-the-wild signal and route those findings to a short deadline.
- For libraries that matter most, such as parsers, authentication, and cryptography, review releases and maintainer activity.
- Add controls that limit the impact of a flaw: least privilege, network limits, and input validation.
- Decide in advance who acts when a new advisory lands outside business hours.
What code-level analysis adds
Code-level analysis reads dependency source and looks for patterns that indicate flaws. Results are less certain than a published advisory, so a responsible tool labels them differently, shows evidence, and has a path for disclosing to maintainers. If a vendor offers this, ask for a sample result on a package you know, and judge the evidence yourself. Safeguard's zero-day discovery sits in this category, and the right way to assess any such capability is to examine specific results rather than accept a claim.
What not to expect
No tool finds every flaw. A claim that a tool finds all vulnerabilities, or that a clean result means safety, should be treated with caution. Honest vendors describe what they cover and what they do not.
How to talk about it internally
When leadership asks whether the report means you are safe, a better answer is: "It means we have no known matches in current data, and here is what we do about what we cannot see." That sentence is accurate, and it invites the right follow-up about controls.
A note on disclosure
If you or your tool find a flaw in someone else's package, follow coordinated disclosure: tell the maintainers privately, give them time to fix, and avoid publishing details that help attackers before a fix exists.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a possible flaw is presented compared with a matched, published one.
Quick check
If my SCA report is empty, am I safe?
Not necessarily. It means there are no matches in the data the tool holds. Unpublished flaws and very recent disclosures would not appear.
Does a KEV listing mean the flaw is unpublished?
No. KEV lists published flaws that have been exploited. It helps with prioritization, not with discovery.
How do I handle a possible flaw my tool reports with no advisory?
Verify the evidence, check whether your code reaches it, apply mitigations, and report it to the maintainers privately. Track it as a distinct kind of finding.
Sources
Last reviewed: 19 October 2026.
