Teams create remediation plans directly from deduplicated, prioritized findings in Phoenix, see the cost before any model runs, and spend their time reviewing fixes that will ship.
AppSec and vulnerability management teams adopting AI remediation are paying twice for automated pull requests that never merge: once in model spend to generate them, and again in reviewer hours to close them. Many of those pull requests target a library that a container base-image update would already remove, or a vulnerability that SCA and container scanning reported as two separate findings. Phoenix Security today announced general availability of Green AI Remedy, the SCA remediation flow in Phoenix Green.
Green AI Remedy lets a security team create a remediation plan directly from the Phoenix platform, starting from findings that have already been deduplicated, prioritized, and assigned to an owning team. The cost estimate appears before any model runs. The agent assesses each repository and returns its evidence for every finding. A pull request opens only when a person with the right permission publishes it, and the finding closes when the next scan confirms the fix.
Where the budget goes
Automated remediation usually starts from what a scanner can see in a repository and proposes an upgrade for all of it. The same vulnerable library often appears twice in the backlog, once from the application’s build file and once from the container image the service ships in. When the library arrives through the base image, editing the build file does not remove it. The container finding reopens on the next scan, and the model call and the review that went into the pull request changed nothing in production.
Service owners then face a stack of changes with no evidence attached. A pull request that does not state which findings it addresses, which it leaves behind, or whether the build still resolves forces the reviewer to rebuild that context by hand. Developers learn to close security pull requests unread, including the one that mattered.
What Green changes
- Remediation starts from the backlog the team already trusts. A plan is created in a few clicks from the Libraries view, a build file, an asset, a team dashboard or a library’s remediation details. The selection is exact: only the chosen findings enter the plan. Phoenix groups them by repository, branch and build file, and lists anything it cannot map to a repository with confidence as an exclusion with a reason.
- Each vulnerability is fixed once, in the layer it lives in. Phoenix’s contextual deduplication merges the SCA and container findings for the same vulnerable library before the agent is involved, and container lineage shows whether that library comes from the application or from the base image. Where the base image is the source, Phoenix points the owning team to the latest base image instead of proposing a build-file edit. The agent’s budget goes to the findings that need a code change.
- Reviewer time replaces token burn. The opening screen shows the finding count, repositories, exclusions and an estimate in US dollars against the organization’s remaining budget, all before the first model call. The agent then assesses each repository at a pinned commit and returns the proposed changes with the findings each covers, the candidates it deferred and why, a status for every finding, and the validation that ran. Publishing is a separate action. If the base branch has moved since the assessment, Phoenix asks for a new one before anything is pushed.
Green AI Remedy assessing a repository, with spend metered against the budget.Executive perspective
“Burning tokens to auto-fix everything a scanner reports just moves the noise into pull requests. Green spends the model only on findings that need a code change, and puts the evidence in front of the person who approves it.”
— Francesco Cipollone, CEO and Co-Founder, Phoenix Security
Context first, then the agent
Green is the final step in a workflow that begins by reducing volume. Phoenix correlates findings from code to cloud, removes duplicates across scanners, and applies reachability, exploitability, deployment context, and ownership before anyone selects what to fix. ClearBank, a Phoenix customer, reported a 98% reduction in container vulnerabilities after applying that context. Green’s agent works on what is left.
Selection can draw on public exploitation signals, including the CISA Known Exploited Vulnerabilities catalog and EPSS scores, alongside Phoenix’s own reachability analysis. Phoenix Security was named a Major Player in the IDC MarketScape: Worldwide ASPM 2025 Vendor Assessment.
How teams use it
A vulnerability manager filters the backlog to reachable findings listed in CISA KEV and picks one library that appears across three Java services. Phoenix has already merged each service’s SCA and container findings for that library into a single entry. Two services declare the library in their build files, so they go into the plan. In the third, the library ships inside the container base image, so Phoenix routes it to the platform team with the latest base image as the fix rather than spending an agent run on a build-file change that would not remove it.
The scope screen shows the two repositories, the base-image exclusion with its reason, and the estimate against the monthly budget. The manager starts the assessment and closes the panel. The run continues in the background and the plan waits under Security > Remediation plans.
The next morning, the owning engineering team reads the status for each finding before the diff, routes the two marked for review to the engineer who knows the service, and publishes one pull request per repository. They merge through their usual process. The platform team rebuilds on the updated base image. The following scan closes the SCA and container findings together.
Availability
Green AI Remedy is generally available today for Phoenix customers. It covers SCA findings in repositories connected to Phoenix and runs on the organization’s own model key, configured under Settings > Organization > AI settings. Starting an assessment and publishing a pull request require a dedicated permission, which organization administrators, security administrators, and security developers have by default. Documentation is available at phoenix.security.
About Phoenix Security
Phoenix Security is an Actionable ASPM platform that correlates vulnerabilities from code to cloud and turns fragmented findings into a single, prioritized remediation flow. Through reachability analysis, contextual deduplication, container lineage, team attribution, and risk-based prioritization, Phoenix helps security and engineering teams cut the noise, fix what counts, and scale without scaling headcount. Phoenix Green brings agentic remediation to that backlog. Phoenix AI is assistive and human-aligned: teams review, approve and merge.
