We all know Software Composition Analysis (SCA) is currently broken, and the root cause of most of the symptoms is the high false positive rate and absurd severity rankings. Enterprises are faced with these two realities:
You can’t just bump everything all the time, because that will break stuff, and you won’t ever get anything else done – even if it’s just the Highs+Criticals.
You can’t just fully investigate every vulnerability that comes in, because the volume is too high, and you won’t ever get anything else done.
Thus, the great unmet need in SCA is 10x better automated triage. Isolating the true positive signal would enable targeted, evidence-driven and most importantly – infrequent – interruptions. To get there, we need a solution that understands the vulnerability, the application, and the business context like nothing we’ve seen yet.
Reachability: SOTA Just Isn’t Good Enough
The solutions in the market that purport to solve this problem use the term “reachability”. Being “reachable” to them means there is evidence of a connection between two places. I’m not sure I’ve seen many cases in my study of CVEs where “reachable” in this sense means “exploitable”. When I look at the results I feel underwhelmed and unconvinced.
True analysis of “exploitability” requires more than a method chain (or lack thereof). It’s a combination of factors, some high level, some low level, and some indirect or contextual – like the nature of deployment, data flow, API arguments, configuration, and lots of other stuff that just isn’t captured in a call graph.
Note that there is an incredibly high pre-test probability that any result is a false positive. So, if you hardcoded a triage tool to just say everything that comes in as a false positive, you’d be right a lot. So, it’s super important that the depth of analysis meets our standards of quality. Simply saying “I can’t find a path” doesn’t necessarily mean there was a solid basis for the conclusion. Asking “how well does it perform on the true positives” might elicit some seat stirring.
Pixee SCA: Research, Context, Transparency
Many months ago, after persistent prodding to bring our “philosophy” to triaging SCA results, we started testing an approach that we thought would be disruptive. A combination of research agents, coding agents, and the right context allowed us to do a remarkable job of triaging results.
After a few months, we found our approach was weeding out the noise spectacularly, and highlighting the signal convincingly. Today it regularly outperforms human analysis.
Let’s see it in action.
Case Study of CVE-2025-11226: More Convincing (and Transparent!) than a Call Graph
We ran a “big box” SCA tool on an open source project called StirlingPDF, a webapp with enterprise-ish features. It found CVE-2025-11226, an issue in logback, a Java logging library. If a user can control elements of the log configuration, they could potentially write files they shouldn’t. The idea of initializing your loggers with user input is so alien to me, I’m not sure I personally have enough neurons to contrive how that scenario would come to pass. But, the tools don’t know that.
This issue (CVSS 5.9 btw) is a great example of the pain that developers, security and compliance have to deal with. Each CVE is its own unique research project, requiring an exhausting context switch, and the mail just never stops. The vulnerability also shows how almost every CVE is more than just “does method A call method B”.
We connect the tool to Pixee, and we’re off to the races. The agents research the vulnerability, determine the exploitable conditions, and assess the code. Importantly, Pixee shows its work, isolating the exact exploitability conditions and how they are/are not present in this application context:
![]()
This is what it looks like when a thorough, indefatigable security researcher analyzes a CVE report. Based on this evidence, a defensible assessment is reached:
Pixee firmly classifies this one as Not Exploitable, provides evidence, is easily verified to be correct, and we can all move on with our lives.
The transparency, depth of the evidence, and resultantly – the accuracy – are wildly different from anything we’ve seen in the market yet. This is the 10x better experience we’ve been looking for with SCA.
We can’t wait to share more, because Pixee was never just about SAST. Our loftiest goal is to build an AI Security Engineer to cover all intelligence-based work around Product Security. But, our medium-term goal is to build a Resolution Platform that takes results from all your tools and scales the intelligence-led functions of triage and remediation, from analytic to business outcome. ASPMs are a place to store vulnerability data. We’re a place to resolve vulnerability reports.
We are intentional about calling this Resolution, rather than Remediation. While remediation is critical to achieving secure software, it’s only the right action to take for a small subset of the vulnerabilities flagged by your scanners and processes that truly require it. In this context, triage is more critical than remediation, given that the vast majority of findings need intelligent validation, evidence, and in-depth analysis before we can determine if remediation is necessary. Blindly remediating simply because AI can perform the action when asked is exactly what the industry refers to as "AI slop."
If your team is dealing with a high volume of false positives and crazy severity ratings, and you’re ready for real automated triage – I’d love to spend a few minutes introducing you to our approach with Pixee for SCA!
