Know which dependency is actually the risk
CloudLens scans your lockfiles and manifests with Trivy for vulnerable and risky open-source packages. Every finding carries the CVE, the fixed version and the import path that pulls it in — so you fix the one that matters, not a wall of transitive noise.
- 1The real findings list
Every open finding in one list — severity, service, where it sits and SLA, ranked by what it actually reaches.
- 2Open it on the right
Click a finding and it opens in a side panel: what it means, and every data store it can reach.
- 3See why it's critical
The access path from the scan’s network graph shows how an attacker reaches the data — internet, workload, role, store.
- 4File it
One click raises a Jira issue with the evidence attached, mirrored to Slack and Teams so the owner is paged.
A list of CVEs is not a plan
Hundreds of transitive advisories, no import path, and no idea which are actually reachable.
You can't tell which dependency to touch
What usually happens: A CVE is reported on a package you never imported directly, with no path showing how it got into the build.
How CloudLens resolves it: The full import path is shown, so you bump the parent that pulls it in — spring-boot-starter-log4j2, not log4j-core by hand.
ResolvedEvery advisory looks equally urgent
What usually happens: A scanner lists hundreds of CVEs with no sense of which are imported, reachable or already mitigated.
How CloudLens resolves it: CloudLens marks whether a package is imported and whether it is internet-reachable, so the real risks rise to the top.
ResolvedReachability is overclaimed
What usually happens: Some tools label everything 'exploitable' to look thorough, which teams learn to ignore.
How CloudLens resolves it: CloudLens states what it knows — imported, and reachable or not — and never claims runtime-confirmed exploitability it hasn't proven.
ResolvedFrom a CVE to the line to change
Every finding is a package, a fixed version and the path that pulls it in.
- One row per package, grouped
- Lowest fix and recommended version
- KEV and public-exploit flags in the row
See every risk in your repositories in one view
How a Log4Shell alert got sized in ten minutes
A morning at Lumora Retail: a dependency scan flags log4j-core, and the import path tells the team what to do.
Lumora Retail is a fictional company. The people, names and numbers are sample data.
A Critical dependency finding
Reads the import path
Checks exposure
Files the fix
Dependency risk you can actually action
Every ecosystem
npm, Maven, pip and Go lockfiles and manifests, read directly, so no package manager is a blind spot.
The import path
Direct or transitive, with the chain that pulls the package in, so you change the right line once.
Honest exposure
Imported and internet-reachable are stated plainly, never inflated into a confidence CloudLens doesn't have.
Software composition analysis questions
CloudLens reads npm, Maven, pip and Go lockfiles and manifests using Trivy, across all your connected repositories.
Yes. Every finding shows whether the vulnerable package is a direct or transitive dependency, with the full import path so you fix the parent that pulls it in.
We state what we can verify: whether the package is imported and whether the affected path is internet-reachable in your estate. We do not claim runtime-confirmed exploitability — reachability at runtime is on our roadmap.
Yes. The same checks run in the pull request, so a policy can fail a build that reintroduces a known-vulnerable version.
Ready to see CloudLens in action?
Connect a read-only AWS role or Azure service principal. We'll walk you through your bill, your security graph and the first things worth fixing.