Reachability, chainability, and one-click assessment and remediation — the scanning you trust, turned into a single ranked plan your engineers can actually action.
Let me take you back a few years. I was leading an engineering and security team, and I had a stack of scanners. One found things in the code. Another found things in the libraries. A third found things somewhere else. Every one of them handed me a list.
My engineers only ever asked me two questions. Which of these do I fix first? And how do I fix it without breaking the application? For years, the industry answered with words like prioritization, deduplication, and correlation. Useful words. But no engineer has ever cared whether finding A is correlated with finding B, or whether this is CWE-22 or CWE-84. They care about one thing: give me the list of fixes I actually need to make, and tell me whether the fix is going to break something.
The dream was never a better scanner. It was a single, honest list of fixes — and a straight answer on whether each one is safe to ship.
That’s what we’re launching today in Phoenix Purple: graph-native SAST and SCA, with one-click assessment and one-click remediation on top. This is the second major batch in the Phoenix Purple launch campaign, and it’s the one I’ve personally waited longest to ship.
The problem with scanning the old way
Traditional scanning reads your codebase file by file. Static code analysis runs in one pass. Dependency analysis runs in another. Each class of scan works in isolation, sequentially, blind to the others. You end up with thousands of findings and no idea how any of them relate — which means no idea which ones actually matter.
In a world where the gap between a vulnerability being disclosed and being exploited is measured in hours, not weeks, that isolation is expensive. You can’t afford to hand your team a flat list and hope they guess right about what to fix first.
What we launched: the scanning you trust, on a graph that connects it
Phoenix Purple takes deterministic, rule-based SAST and SCA — the scanning methodology you already rely on — and runs it on a knowledge graph that correlates every finding across your code and dependencies. The rules stay deterministic. What changes is that the results are no longer isolated. The graph connects them.
Graph-native SAST
Static code analysis runs against the knowledge graph, not against raw files in a vacuum. Because the graph knows the call paths — what reaches what, what carries untrusted input, what’s actually live — the analysis follows the real path through your code rather than matching a pattern and hoping it’s reachable. You pick the ruleset that fits your language, and the graph does the rest.
SCA with reachability — and four scan modes
Software composition analysis doesn’t just hand you a list of vulnerable dependencies. It’s summarised per library, with the CVEs and the affected code surfaced against each one — and reachability analysis tells you which of those libraries are actually reachable in code that runs, and which are noise you can safely deprioritize.
You choose how deep to go with four scan modes:
- Quick — fast triage: the libraries that need fixing, surfaced in seconds.
- Full — comprehensive coverage across the dependency surface.
- Smart — graph-guided depth where it matters, efficiency where it doesn’t.
- Deep — the deepest analysis, for high-stakes review.
Quick and full are the everyday workhorses — fast, effective, and enough to tell you which libraries to fix. Deep and smart are there when a finding warrants a closer look.
The question engineers actually ask: can this hurt me?
Here’s where the graph earns its place. A single finding rarely tells the whole story. The real question is whether findings chain together into something that can actually be exploited.
Can a remote code execution lead into a buffer overflow, and can that chain into a working exploit? Could an attacker, looking at your threat model, link these findings into a path all the way in? That’s what matters — and it’s exactly what a file-by-file scanner can never tell you, because it never sees two findings in the same frame.
Phoenix Purple builds a chainability map: it correlates findings across code and libraries, ranks them by complexity, chainability, and exploitability, and shows you which bundles of vulnerabilities can be used together to deliver an attack. Not CWE-22 versus CWE-84. A picture of what an attacker could actually do in your codebase.
The chainability map is the difference between a list of problems and an attack path. One is noise. The other is a decision.
Two buttons: one-click assessment, one-click remediation
Once the scan is done, everything comes down to two buttons. Internally we started calling them YOLO fix and YOLO remediate — a joke, because you only live once, but the point behind the joke is serious: the whole assessment-and-fix loop collapses to a single click.
One-click assessment
Assessment answers the questions your team is going to ask anyway. Is this finding real? Is it reachable? Can it be chained with others into an active exploit? Phoenix works systematically through the graph, file by file, evaluating which vulnerabilities need remediation and how dangerous they really are — with an exploitability ranking and the chainability picture attached. And critically, it tells you whether the fix is a breaking change.
That breaking-change verdict comes in clear tiers, because that’s the information that lets security talk to engineering without an argument:
- Simple to execute — safe to schedule now, or ship tonight.
- Potentially breaking — needs attention and a review before it merges.
- Definitely breaking — a heavy change; plan for full regression testing.
- Unknown — a library upgrade Phoenix can’t fully assess yet, so it flags that you need to take a deeper look before acting.
A minor front-end library bump is easy — low risk, ship it. A major version upgrade of that same library is a different animal: heavy, breaking, needs full regression testing. Same finding on paper, completely different fix. The assessment tells you which one you’re looking at before you commit to it.
One-click remediation
Remediation produces a plan, not a ticket. Phoenix analyses each finding for breaking versus non-breaking, works out which files are affected, and produces a table of what should be bundled together into a single remediation plan — along with any compensating controls available if you’d rather mitigate a particular vulnerability than change the code right now. Where code remediation is warranted, it delivers the fix as a pull request, with the reasoning already in it.
The remediation plans are broken down by simplicity, so your team can look at the queue and know immediately: I can do this one tonight, this one goes in this week’s sprint, and this one needs a regression cycle because it’s a major upgrade. The engineer’s job shrinks to reviewing the assessment Phoenix delivered and saying yes or no.
Give the remedy that matters, to the team that matters, in a way they can act on today. That’s the whole point.
Chat with your vulnerabilities
There’s one more thing that, honestly, is the part I dreamed about most. You can talk to your code. Ask Phoenix Purple to assess everything it found and tell you what to do next. Ask what you can safely avoid. Ask it to prepare a remediation plan, then have a conversation about that plan — what’s in it, what to skip, what to sequence first. It’s the single tool I wanted for my team for years: the ability to sit down with your findings and ask, plainly, are these bad, and are they bad for me?
Why it’s fast, and why it’s cheap
All of this runs at the speed of the knowledge graph, with token consumption taken down to the minimum. The graph is built and rebuilt automatically, and the model navigates that graph to reason rather than re-reading your entire codebase to reconstruct context on every run.
That’s the whole economic trick. Every token you spend goes into producing remediation for your engineering team, not into rebuilding context the graph already holds. It’s what lets this scale to thousands of repositories without the token bill that sinks a build-your-own harness. Model the numbers for your own fleet at ai-scan-cost.phoenix.security.
Modeled cost comparisons are available at ai-scan-cost.phoenix.security. Figures are modeled on a representative fleet, not measured customer results.
Available today
Graph-native SAST and SCA, with reachability, the chainability map, one-click assessment, and one-click remediation, are in general availability in Phoenix Purple now. More capabilities are shipping through the campaign over the coming weeks.
Go fix your vulnerabilities at scale, and make your engineering team happier for it.
