Question 1
Is it in the image?
Every CVE in every layer, including the ones your application never touches. Your scanner already answers this one.
Question 2
Does anything load it?
A base image ships an OS, a runtime and dozens of system libraries. Your service imports a fraction of them.
Question 3
Can an attacker reach it?
Whether the affected service is exposed, and whether attacker-controlled input reaches the vulnerable code in the running container.
Scanners answer the first. Konvu answers all three, and attaches the evidence for each.
Cut base image noise
Most container CVEs aren't exploitable in your context. Konvu filters them out with evidence.
Focus on what's exploitable
Identify which container CVEs are reachable from your code and whether the exploit conditions are present.
Evidence for every decision
Audit-ready reasoning for every exploitability verdict. No black-box scores.
No workflow changes
Konvu reads findings from the container scanners you already run.
Container findings, in the same queue as the rest
Container CVEs are assessed the same way as dependencies and code, land in the same queue, and carry the same evidence. One process, not a separate tool for images.
Your container has hundreds of packages. Your service loads a handful.
A base image ships an operating system, a runtime and dozens of system libraries before any of your code arrives. Your scanner enumerates all of it. Konvu resolves what the running process actually imports, which is the question that separates a container CVE from a container risk.
A verdict that survives the next image rebuild
Base images change weekly, so a decision made once has to be re-checkable. Every verdict records the layer, the package, the import path it looked for, and the condition that decided it, so the call can be checked again when the image changes.
