You know your applications don’t live in a bubble. They’re put together from open source packages, containers, cloud-managed resources, VMs, APIs, and more. Each part has its own security surface area, and its own scanner: static code analysis tools (SAST) scan for vulnerabilities in source code, software composition analysis (SCA) tools scan for dependencies, cloud security tools watch configurations, and container scanners look for known exploits in images.
So once you’ve got all these scanners in place… you’re secure, right?
Kind of. You’re definitely scanning each layer.
But at what cost?
Why Security Scanners Overwhelm You With False Positives
A scanner might alert you to a vulnerable function in your code, without knowing it’s protected by an upstream API. Or it might sense danger about a CVE in a container base layer, oblivious to the fact that your actual application never reaches that code path. Similarly, a cloud scanner could flag an IAM role that overreaches its permissions, without realising that it’s only linked to a staging workload that can’t access production data.
The result? Your teams get flooded with a ton of isolated findings. Yep, they’re all technically accurate, but they come with little context to determine whether the issue is really dangerous.
Or as a security engineer from a large enterprise recently said: “Can you tell if a vulnerability affects my crown jewels or the virtual lunch menu?”
While false positives and false negatives in isolation are a risk, the bigger risk is missing dependency chains that determine if seemingly harmless issues combine into real exploit paths — or if a lot of seemingly harmful issues are not an issue at all.
And we hear it from teams all the time:
“We don’t control our dependencies.”
The reason? It’s too challenging to manage the supply chain; open source packages bring with them indirect dependencies. Even with container scanning or cloud-native tools, most organizations can’t determine what matters confidently. As a result, they end up chasing vulnerabilities reactively.
Why Vulnerability Context Matters in Application Security and Cloud Security
The typical SAST or SCA tools take a very simplistic and literal view.
For instance, when it sees that a package is listed in a CVE, it will flag it as critical.
That sounds like best practice on paper; it is better to be risk-averse after all, you’d think. But in reality, it just sets off false alarms because:
- Often your application isn’t even calling the vulnerable function
- The function could be buried inside a transitive dependency you never directly touched
- Or it’s behind an import that’s only meant for devs, that never ships to production
So teams get an overly thorough list of “critical” issues and have to spend hours chasing them down, only to realize they’re not even critical.
At the same time, the actual paths that could be exploited may go unnoticed.
Building a Complete Dependency Graph Across Code, Containers, and Cloud
The reason many scanners give you noisy or incomplete results is that they don’t have the additional context necessary to provide clarity. Traditional tools treat each layer - source code, open source packages, containers, cloud resources - as separate problems, often handled by separate products.
That means they lack a single dependency graph that unites them all. There’s no cross-dependency visibility. meaning you’ll get notified of non-critical issues, and may miss the issues that actually matter.
But visibility isn’t just about context; it’s about consistency. Package managers all manage transitive vulnerabilities differently.
For example:
- npm/yarn in JavaScript offer dependency trees and let you override/pin nested packages.
- Maven in Java can pull in unexpected library versions, requiring extra configs to keep risky transitive packages out.
Without a unified graph, teams end up bolting on more tools just to get a grip on what they’ve shipped.
Some engineers think: “if we didn’t install it directly, it can’t hurt us”; which compounds the issue. Vulnerabilities live several layers deep.
So what should teams be doing?
Use Reachability Analysis to Eliminate False Alarms in Dependencies
True reachability analysis should mean that rather than just flagging “you have a vulnerable package in the graph”, your platform can figure out if your code is:
- Actually calling on the vulnerable function, or
- Involved in a flaw exposed to user input, or
- Running in a container that’s accessible from the internet
If the answer to all of these questions is no, then it ignores it. If yes, it escalates.
It’s also important to filter out transitive vulnerabilities behind developer dependencies or test packages that never ship to production. This can cut a lot of noise, meaning fewer false positives and more time for developers to focus on building software.
Most scanners might check if a package is listed in a CVE. But very few can trace if your actual code calls the vulnerable function, if it’s bundled in a container exposed to the internet, and if it runs on a cloud resource with risky IAM — all in one view.
Correlating Vulnerabilities Across Code, Containers, and Cloud Configurations
This is the big one. Understanding what’s happening everywhere is key to saving your team a ton of time, and reducing the chances of getting caught out.
That means extending this dependency graph beyond the package level into containers, infrastructure as code, cloud configs — and overlaying reachability across these.
For example, it could ask:
- Does this vulnerability affect your dependencies? Yes
- Is it actually called by your app? No
- Is it bundled in a deployed container with public ingress? No
→ Ignore - Does this vulnerability require a specific port to be open? Yes
- Is the vulnerability present in a cloud virtual machine? Yes
- Is the required port open on the VM? No
→ Ignore
Automated Remediation: Fixing Real Vulnerabilities Faster
Once confirmed as a real, reachable vulnerability, the ideal scenario is to determine the minimal safe upgrade and fix it automatically.
Some tools can:
- Automatically figure out the minimal safe upgrade
- Check it won’t break your semver constraints
- Auto-fix it without introducing regressions
That means no manual dependency chasing, and far fewer sleepless nights.
Manage Dependencies as Part of a Unified Security Strategy
By tying your code, containers, and cloud configs into one graph, you cut down the noise and see what’s actually exposed. No chasing false alarms.
And when there’s a real problem, it’s not just flagged — it’s fixed. So your team spends less time digging through pointless alerts and more time shipping.
Check out how Aikido scans dev dependencies for CVEs in our docs. Check out our all-in-one vulnerability management, here.
.avif)
