What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
- The vendor_url supplied in the catalog data points at Harness Security Testing Orchestration; confirm current ownership, product name and canonical URL before publishing
- Language coverage: confirm the current supported list and which languages support reachability versus scanning only
- AI assisted remediation capability: confirm current scope and naming
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Qwiet AI is built around a code property graph, a single representation that merges the abstract syntax tree, the control flow graph and the data flow graph into one queryable structure. The analysis lineage here is the open Joern tooling, and the graph is the reason the product behaves differently from a pattern matching scanner. Queries traverse the graph to follow attacker controlled values from entry points through the application, which is how it produces taint based static analysis findings with a traced path rather than a line number and a rule name.
The composition analysis piece extends that graph across the dependency boundary. Rather than only reporting that a package version carries a known advisory, it determines whether your code reaches the specific vulnerable function inside that package. Findings are split into reachable and unreachable, which changes the triage conversation: a large advisory list collapses into a much smaller set with a real path from your code. Unreachable findings are still recorded, because an unused code path becomes a used one after a refactor.
Where it fits
It runs as a scan step in CI or against a repository connection, with results reviewed in a hosted console. Reachability only works when the graph can be built properly, so it wants a compilable, resolvable project: missing build configuration or unresolved dependencies degrade the analysis quietly. Security typically owns policy and triage, with developers consuming the filtered output. It is most valuable where you have a large unmanaged backlog of dependency findings and need a defensible way to rank it.
Strengths
- Reachability filtering that is grounded in real data flow, not just a check for whether a package is imported.
- One graph serves both the first party code analysis and the dependency analysis, so a finding can show a path that crosses into library code.
- Findings arrive with a traced data flow, which makes developer pushback easier to resolve than with rule name only output.
Limitations
- Graph construction needs a well formed, resolvable build. Polyglot monorepos and partial checkouts produce incomplete graphs and quietly weaker results.
- Reachability is a prioritization signal, not proof of safety. Reflection, dynamic dispatch and configuration driven wiring are hard for any static graph to follow, so unreachable is not the same as unexploitable.
- Scan times on large codebases are longer than a manifest lookup, which limits how tightly you can wire it into fast feedback loops.
Who it suits
Teams drowning in dependency advisories who need a principled way to cut the list, and who have builds clean enough to analyze. Teams with small codebases, or build systems the graph builder cannot resolve, will pay for sophistication they cannot use.
Used Qwiet AI? Recommend it under your own name and title.
Recommend this tool