# SCA that investigates every dependency like your best security engineer **URL:** https://mazehq.com/blog/sca-that-investigates-every-dependency-like-your-best-security-engineer **Date:** 2026-09-30 Open-source packages are built into every application, and so are the countless vulnerabilities found in their direct and transitive dependencies. For years, SCA tools have been great at finding vulnerabilities but awful at telling you whether they’re a problem (or where they are). That gap is the difference between vulnerable in theory and vulnerable in your application. As we write code faster than ever, that gap leaves us with noisy, inaccurate alerts that hide the real risk you need to fix. Maze finds every vulnerability in your dependencies, direct and transitive, and goes beyond simple reachability by investigating, prioritizing, and helping you fix vulnerabilities that are exploitable in your environment. *Want to learn more about how Maze reviews your first-party code with AI-SAST?* [*Read more here*](https://mazehq.com/blog/maze-ai-sast-the-ai-security-engineer-for-your-code)*.* ## **The new way to do SCA, and why it needs AI** Think about how a security engineer handles a dependency vulnerability. The vulnerability itself is never the end; it’s often just the starting point for an investigation. They open the repo, find what pulled the package in and where it gets called, check whether it survives the build, and look at where the service is deployed. In most organizations, you’d probably just patch the vulnerability, because the investigation takes way more work than updating the version. Rules-based tools can’t run that investigation accurately, because every vulnerability needs its own set of checks and context. That’s why SCA needs AI, and it’s why Maze’s agents run the investigation your best engineer would if they had the time, on every finding. For every vulnerability in your backlog, our agents find the manifest that pulled in the package, the exact version your build used, and the function that calls it. Then they follow the package through the build to see whether it ships or gets stripped out along the way. That chain, from the function that calls the package, to the image it ships in, to the workload it runs on, gives the agents the context they need to determine whether a vulnerability is exploitable. On every pull request, Maze investigates the packages you’re adding, traces what new risk they bring into your code, and tells you whether any of those packages are exploitable in your environment. Because every finding comes with evidence, you’re able to block merges on real risk only, instead of slowing development down with false positives. The agents don’t stop on merge, so when a new advisory lands against something you shipped months ago, Maze’s AI agents run the same in-depth investigation against the code already in production, pulling in context from your cloud. ### **Finding where the vulnerability breaks** Every vulnerability is exploited differently, so every investigation starts with one question: what has to be true for this vulnerability to be exploitable in your application? When we can answer that question, we know what breaks the chain and makes a vulnerability not exploitable. A deserialization bug needs an attacker to control a serialized input. A decompression bug needs them to control what gets decompressed. A rules-based checklist can tell you a decompression bug exists, and maybe that the code is reachable. It can’t tell you whether an attacker controls what gets decompressed. That’s why the agents start with the vulnerability and research the fix and the library’s source, because advisories don’t always tell the whole story about what changed. That investigation and understanding of the vulnerability drives their plan, telling them what to check in your application and where to look. ### **Moving from reachability alone to exploitability** In most SCA tools, reachability was the gold standard, because at the time it was the best the technology could do. The problem is that the trace often gets stuck, and when it does, traditional tools can’t tell you whether the vulnerable code is reachable. Using AI agents instead of traditional call graphs, Maze gets past those points of friction and traces the entire call path, through your code and the open-source packages in between, in whatever language you write. Even when you get reachability right, a reachable vulnerability just means there’s a door, but what we actually need to know is whether it’s exploitable. Can an attacker open that door and step inside? Beyond reachability, the agents check things like whether an attacker can control what reaches the vulnerable code, whether a setting turns the vulnerable feature off, and whether the vulnerable code is even running. If any one of those requirements isn’t met, the vulnerability isn’t exploitable, even if it’s reachable, and you get the evidence to prove it, with every step the agents took. ### **Context should influence the severity** After the agents prove a finding is exploitable, they determine its severity using context from your environment. They weigh impact, how much damage an attacker could do, and likelihood, how realistic the attack is given how and where the code runs. Is the vulnerable package in a checkout flow that handles customer payments, or in a staging environment that never sees real traffic? The risk in those two places isn’t the same, so Maze doesn’t treat them the same. ## **Reasoning you can trust and afford** Over the last two years, we’ve built the foundation behind our agents with Maze Cloud. Those learnings helped us build the infrastructure and cost optimizations for Maze Code’s AI agents, which allow them to run frequently and at scale. Behind that scale is knowing when to use which model, along with an in-depth context layer shared across your investigations. While more goes into cost optimization, these are two ways we’re able to give customers high-quality reasoning on every finding, every day. ## **What goes into a real AI-SCA investigation** In one investigation, our agents looked at a high-severity vulnerability in a billing service. The service uses requests, a common Python library, to talk to an internal API, and requests relies on urllib3, which had a known flaw: a decompression bomb that could exhaust the billing service’s memory and take it down. The agents started by determining if the vulnerability was reachable, finding five separate paths from the service’s entry points to the vulnerable code, each one running through the service’s own client code and requests into urllib3. Once the agents confirmed this vulnerability was reachable, they began evaluating if it was exploitable. To execute this flaw, an attacker would have to control the server the billing service fetches from, so the agents traced how every outbound request gets built. The agents confirmed the internal API client reads its destination from a single setting that no request can change, and every other HTTP call in the codebase goes to a hardcoded internal service or a trusted third-party API, which means an attacker can never point the service at a server they control. Without that, they can never send urllib3 a payload to decompress, and the flaw can’t be triggered. While the vulnerable code was reachable five different ways, it was not exploitable. A reachability-only tool would have turned this into a ticket and sent an engineer off to upgrade a library an attacker could never touch. Maze closed the finding as not exploitable, with every call path and outbound request attached as evidence. ## **Let Maze handle your dependencies** Most of the vulnerabilities flagged in your dependencies are not exploitable in your environment. The ones that are exploitable, we find. Maze investigates every dependency, both direct and transitive, and shows your team only the ones that can actually hurt you, with the evidence behind that decision, so you can move fast and patch what counts. See what it finds in your dependencies. [Book a demo](https://mazehq.com/demo).