A wrong finding costs more than the time it takes to check it. It interrupts a developer, pulls the security team into another investigation and makes the next alert easier to ignore.
The same pattern appears elsewhere. When a security tool blocks an open-source package without offering a safe way forward, delivery slows down or the control gets bypassed. A finding that only becomes a ticket creates more work without reducing risk.
This release focuses on those points of failure. It helps teams confirm what is real, understand what matters and move the right security work forward.
Phoenix Purple
A finding should come with evidence
A convincing explanation is not proof that a vulnerability exists. If the analysis cannot show the code behind its conclusion, the security team still has to investigate the finding from the beginning.
Phoenix Purple’s Threat-Led Hunt is an automated investigation that looks for weaknesses an attacker could exploit. It could already map an application’s functions, dependencies, call paths and data flows. That structure helped identify likely problems, but it could not always confirm what the relevant code actually did.
The Hunt now examines the source code as it investigates, judges and verifies a potential weakness. Each verdict is tied to the exact code it examined, grounding the conclusion in what the application actually does.
If the analysis returns a refusal, an empty answer or one that cannot be read, an evidence gate stops the finding from being reported as high confidence. It is better to report uncertainty than give a weak conclusion the appearance of certainty.
The same principle applies after a fix is proposed. An independent checker tests it again and returns an inconclusive result when there is not enough evidence to confirm that the fix worked.
That evidence does not have to remain with the person who ran the investigation. Hunts can be shared with colleagues and exported for engineers, team leads or auditors, so nobody has to rebuild the investigation by hand.
All capabilities in this section are generally available.
Protect yourself with Phoenix Purple – find TRUE critical chainable vulnerabilities with exploits
Reach the code where it lives
Evidence only improves a finding if Purple can reach the code behind it. In practice, that code may be spread across several providers, managed in the customer’s own environment or held inside networks that cannot accept incoming connections.
Purple now supports Azure DevOps, Bitbucket and GitLab, whether hosted in the cloud or managed by the customer. Teams can connect and import repositories, scan pull requests and, if they choose, run an exploit hunt on just the code affected by a proposed change. They do not have to move their code or redesign their development workflow before analysis can begin.
For code held inside restricted networks, a new outbound connector lets the customer’s environment start the connection to Phoenix. This removes the need to open an inbound route through the firewall, while allowing each organisation to choose the connection method that fits its network.
A repository can also be tracked across several workspaces and branches at the same time. Each view keeps its own code map, findings, history and search while sharing one underlying copy of the code. Platform and product teams can work from the same repository without storing it twice or forcing every team into the same view.
Large codebases are easier to work with as well. Imports continue in the background, large code maps stay responsive and a damaged map repairs itself instead of failing the entire scan.
Purple can now read code in 26 languages, although the depth of security analysis still varies between them.
All capabilities in this section are generally available.
Know which AI your applications depend on
Security teams are increasingly being asked two questions: which AI components are present in our applications, and how are they being assessed?
Purple can generate an AI bill of materials in CycloneDX 1.6 format, inventorying the models, AI SDKs, providers, MCP servers and agent artifacts in an application. Separately, its AI security scan can map findings to OWASP AISVS v1.0 requirements, showing which code-verifiable requirements have evidence of gaps. It does not certify compliance.
Together, they give technical teams and security leaders a clearer answer to what AI they are running and where further scrutiny may be needed.
All capabilities in this section are generally available.
Phoenix Blue and Blue Shield
A block should come with a safe way forward
Not every risk starts in code your team wrote. Much of it arrives through the open-source packages developers install. Phoenix Blue Shield is the firewall that stops dangerous packages getting in, using threat intelligence from Phoenix Blue.
A developer who discovers a blocked package shortly before a release needs more than a warning. If the only way forward is a support ticket with no clear owner or response time, delivery slows down. Or the team looks for a way around the control.
Blue Shield now lets developers request an exception when a package is blocked. If the request is approved, the decision becomes a rule that the firewall applies the next time it sees that package. The exception is part of the control itself, not a note held somewhere else.
That path still has safeguards. Packages with confirmed links to malicious activity cannot be approved, and there is a limit on how many exceptions each team can hold. Decisions that need approval now reach the approval queue, so a real person can review and resolve them.
The malware model has changed too. It now ranks packages by how suspicious they look instead of making the final block decision on its own. Better evaluation of packages and regularly refreshed training data also mean fewer safe packages get blocked by mistake.
The result is a control that can stay strict without becoming a dead end for developers.
All capabilities in this section are generally available.
Protect yourself with the latest threat intelligence, get free access to Phoenix Blue Today
Phoenix Green
A fix should arrive as a pull request
A security decision only reduces risk when it leads to a change. A ticket identifies work that someone still needs to do. A pull request gives the developer something they can inspect, test and review.
For vulnerable dependencies, Phoenix Green creates a remediation plan and opens a pull request against the affected repository. The reasoning travels with the proposed change, so the reviewer can understand why it was made rather than seeing only the changed lines.
Not every automatic update is safe to merge. Before a change moves forward, Green assesses how likely it is to break the build. It identifies safer upgrades and warns when a dependency change may need additional work before it can be merged.
- Dependency fixes come with context, not just a version number. (Green, shown in Orange) Rather than simply telling you to upgrade from one version to another, Green explains the change. A team view also gathers all of a team’s remediation work in one place. Private preview.
Dependency fixes also explain what is changing rather than offering only a new version number.
Security teams can organise fixes using recognised weakness categories such as the OWASP Top 10 and CWE Top 25, or prioritise them by how often each weakness is being exploited in real attacks. A team view also gathers each team’s remediation work in one place.
The aim is not to remove the developer from the decision. It is to give them a reviewable change with enough context to make that decision safely.
All capabilities in this section are private preview.
Phoenix Orange
Give every finding the context to move
A finding may be serious, but a security team still needs to know whether the affected asset is exposed, how long the problem has existed and when it needs to be fixed. Without that context, deciding what deserves attention becomes another investigation.
Phoenix Orange now lets teams filter assets, components and services by their effective exposure. Instead of investigating whether something can be reached from outside, teams can bring externally exposed risks directly into view.
Finding age is also more accurate. Orange records when the problem actually began separately from when Phoenix first discovered it. Deadlines and audit timelines can therefore reflect the real age of the risk rather than the date the organisation started using Phoenix Security.
Once a finding has the right context, that information can move with it. Orange workflows can send a webhook, an automatic message to another system, containing the finding, its severity, the affected asset, its exposure and the remediation deadline. The receiving system, or an AI agent, has enough information to decide what should happen next without someone copying the details by hand.
Teams can also work with Orange through a command-line tool and an MCP server. MCP is a standard way for AI tools to connect to a service, so scripts and authorised agents can work with findings without relying entirely on the browser. The API can also tag findings automatically as they arrive.
The result is less time working out what matters and less manual work moving that decision to where action happens.
All capabilities in this section are generally available.
Control the AI behind Phoenix
Using AI across security workflows creates another governance problem: who controls the provider credentials, model choices and spending?
Token Hub gives organisations one place to manage AI provider credentials and costs across Purple and Blue Shield. Teams can bring their own supported provider, manage credentials centrally and set a spending limit for the organisation instead of keeping keys in separate places. Purple can also use custom models hosted on Azure, Amazon Bedrock and Google Vertex AI. Generally available.
Model controls add another level of oversight to Green’s remediation work. Where a model supports it, teams can adjust how much reasoning it applies or tune its creativity for the task. Token usage is recorded for each run, giving administrators a clearer basis for tracking cost. Early access.
Four platforms, one outcome
The four platforms do different jobs, but they work towards the same outcome: reducing the distance between discovering a security problem and taking action that lowers the risk.
Purple strengthens the evidence behind a finding. Blue and Blue Shield keep package controls effective without leaving developers at a dead end. Green turns dependency remediation into a reviewable pull request. Orange provides the exposure, timing and workflow context needed to move the right work forward.
Several Green capabilities are currently accessed through the Orange interface. Green creates the remediation plan and proposed change, while Orange is where teams can see and manage that work.
These are not four steps in a fixed pipeline, but the decisions reinforce one another. A pull request is only useful for a problem supported by evidence. That evidence depends on reaching the relevant code. Package controls remain effective only when legitimate exceptions have a safe route. Operational action depends on having enough exposure, age and deadline context to decide what should move first.
The principle connecting this release is not simply that Phoenix uses more AI. Automated conclusions should be supported by evidence. Security controls should leave a safe path for people. Proposed fixes should arrive in a form developers can review.
A finding is not a fix, and automation is not an outcome. The value comes from giving teams enough evidence to trust the decision, enough context to understand it and a clear path to act.
