Spend your time on the vulnerabilities that can actually be reached.
Most findings in a long CVE list can never be triggered in your code. Quaze proposes a reachability and exploitability verdict for each one, so your team triages the real risk first instead of working through the whole list.
A long list of CVEs is not a list of your real risks.
Plenty of vulnerabilities sit in code paths your application never calls. Triaging every one by hand spends your team's attention on findings that can never be triggered.
Most of the list is noise
A vulnerable package is only a problem if your code actually reaches the vulnerable part of it. A lot of the time, it does not.
Manual triage does not scale
Reading advisories and tracing call paths by hand is slow, and it competes with everything else your team has to ship.
The real ones get buried
When every finding looks urgent, the ones that are genuinely reachable and exploitable are harder to spot, not easier.
How does Quaze decide what's reachable?
For a finding in one of your dependencies, Quaze looks at two things: whether your own first-party code can reach the vulnerable package, and whether it is exploitable in the way you use it. Each comes back as a clear verdict, not a maybe.
- Reachability: reachable, not reachable, or uncertain
- Exploitability: exploitable, not exploitable, or uncertain
- A confidence score, and the files and lines the verdict is based on
Graph-derived where it's certain, AI where it isn't.
Reachability starts with a deterministic pass over your import and dependency graph. When the graph settles a case on its own, the verdict is labelled graph-derived. When it cannot, AI source-code analysis reads the relevant first-party code and the verdict is labelled AI-inferred.
This is build-time source analysis. Quaze reads code; it does not run an agent on your servers or trace live traffic.
- A deterministic import and dependency-graph gate handles the clear-cut cases
- AI source analysis covers what the graph cannot resolve on its own
- Every verdict is labelled graph-derived or AI-inferred, with file and line evidence
- Connect a GitHub repo and map components to repos to turn it on
What changes in your day-to-day triage?
Instead of a flat list of every CVE, you get a risk funnel that shows what has not been ruled out yet and burns down as you work. An in-use view shows which live environments and releases contain each affected component version. And one-click filters put the findings that matter on top.
- A risk funnel that shows what is still open, not just what exists
- An in-use view tying each finding to the environments and releases that run it
- Priority filters like Exploitable and live, to start where it counts
- The prefilter proposes verdicts, so people spend their time deciding, not searching
Automation you turn on, on your terms.
These are off by default. An owner enables the ones that fit how your team works. Quaze proposes; people decide. The AI never sets a workflow status or overrides a human triage decision.
Auto-analyze new findings
Pick a severity threshold, and Quaze analyzes new findings at or above it as they arrive, so a proposed verdict is waiting when you look.
Auto-close what is not exploitable
Optionally let Quaze close findings its analysis concludes are not exploitable, gated on a confidence threshold. If a later verdict disagrees, it reopens automatically.
Reuse decisions you already made
When the same CVE shows up on a new version of the same component, reuse the human decision from last time. Set it to off, suggest, or auto.
Auto-close is a convenience, not a verdict on your workflow. The decision of record is always a person's, and the evidence behind every change stays attached to the finding.
Two ways to run the analysis.
Bring your own model access, or use Quaze managed AI. Either way the analysis is opt-in, and an owner turns it on.
Bring your own API key
Add your own API key and your source connection, run a quick test to confirm both work, then run analysis on your own key. You control the account and the spend.
EU managed AI, no key required
Use Quaze-operated, EU-region AI inference, paid from a prepaid credit wallet you top up in the app. Credits are prepaid in USD and valid for 12 months. The advantage: your data and the analysis stay in the EU.
Same analysis either way. The only difference is whose key runs it, and where the inference happens.
Common questions
Is reachability analysis based on runtime or build time?
Does the AI close findings on its own?
Can I use my own API key?
Where does the managed AI run?
Turn your triage into evidence.
Every triage decision carries the reachability and exploitability evidence behind it. Export it as CycloneDX VEX to tell the people who consume your software which vulnerabilities do not affect it, and why. It is the kind of record that supports your CRA preparation.
- Decisions export as CycloneDX VEX, with the evidence attached
- Show downstream consumers which findings are not exploitable, and why
- Supports your EU Cyber Resilience Act preparation
Keep reading
- GuideRead more
Reachability and exploitability explained
Why most findings are noise, and how reachability tells the real risks apart.
- ProductRead more
Ownership and triage
Route each finding to the team that owns the affected component.
- ProductRead more
Release and environment tracking
See which live releases and environments contain an affected version.
Cut the list down to what's actually reachable.
Turn on reachability and exploitability analysis with your own key or EU managed AI. Start on the Free plan and connect one repository.