Phoenix Security is a threat-centric ASPM platform that connects vulnerability findings across the SDLC with ownership attribution, exploitability validation, and AI-generated remediation pull requests.
What is Phoenix Security?
Most ASPM tools stop at a prioritized list. For me, Phoenix Security’s differentiator is closing the loop from risky finding to owner-routed fix PR.
The tagline captures the angle: “Security from generation to remediation.” Phoenix pairs threat-centric scoring with ownership routing so ranked findings land on the person who can act on them.
Phoenix tracks findings against SLA windows and ranks the most vulnerable applications and services by severity.
Key features
| Capability | What Phoenix does |
|---|---|
| Threat-centric scoring | Ranks by CISA KEV, EPSS, reachability, and runtime exposure, not raw CVSS |
| Ownership attribution | Auto-assigns each finding to its repository or asset owner |
| Agentic remediation | AI agents open fix pull requests; a human reviews and merges |
| ASPM correlation | Ingests SAST, SCA, container, IaC, and runtime findings into one queue |
| SLA/SLO tracking | Measures findings against service-level windows by severity |
Threat-centric prioritization
Phoenix layers vulnerability intelligence on top of scanner output. It combines the sources below to rank issues by what an attacker could realistically use.
| Source | What it adds |
|---|---|
| CISA KEV | Vulnerabilities with confirmed in-the-wild exploitation |
| EPSS | Probability of exploitation in the next 30 days |
| Reachability | Whether vulnerable code is called from production entry points |
| Zero-day tracking | Monitoring of disclosed but unpatched issues |
| OWASP Top 10 / CWE | Web-risk taxonomy and weakness grouping |
Ownership attribution and remediation
Phoenix auto-assigns each finding to the specific repository or asset owner. That removes the shared backlog where every ticket is everyone’s and therefore no one’s.
On remediation, AI agents generate fix pull requests against the affected repositories. Phoenix does not auto-merge — a human reviews and approves — but the work of writing the fix shifts to the platform.
AI-code security line
Phoenix has extended into securing AI-generated code. Phoenix Purple runs SAST, SCA, and autofix against AI-written code, Phoenix Blue supplies threat-centric CVE intelligence, and Phoenix Blue Shield acts as a supply-chain firewall.
Public threat-intelligence explorers
Phoenix publishes free Vulnerability Data Explorers built on the same intelligence its platform uses. They cover CISA KEV, VulnCheck KEV and EPSS, OWASP, and CWE datasets.
The explorers are a useful sanity check on the vendor’s threat-centric claims: you can inspect exploitability, zero-day, and ransomware-linked data before ever booking a demo.
Leadership and advisory
| Role | Person | Background |
|---|---|---|
| Founder & CEO | Francesco Cipollone | AppSec entrepreneur and community organiser |
| CTO | Alfonso Eusebio | Engineering leadership at Telefónica, IBM, Vodafone, Dell EMC, and Yahoo! |
| Advisor | Jim Manico | Manicode Security, original author of the OWASP Top 10 |
The advisory bench also lists the CEO of Signal Sciences (acquired by Fastly), a former CTO of Digital Shadows, a former Head of Engineering at Qualys, and the CISO of Oracle Advertising. A genuine OWASP-Top-10 author on the board is unusual for an ASPM vendor.
When to use Phoenix Security
Phoenix fits teams that already run multiple scanners and have a backlog caused by weak prioritization or unclear ownership. The two problems it targets — “everything is critical” and “whose ticket is this” — are exactly what ASPM exists to solve.
Comparing Phoenix against the field: Apiiro and OX Security overlap on prioritization, Cycode and Jit on ownership and developer routing, and ArmorCode on agentic remediation at larger scale.
How does Phoenix fit into a pipeline?
Phoenix ingests scanner and runtime results, maps them to owners, and can open remediation pull requests. Its integration catalog covers source control, scanners, cloud platforms, ticketing, and developer workflows.
I would onboard it in this order:
- Connect repositories and one or two high-signal scanners.
- Validate asset identity, deduplication, and ownership mappings.
- Add runtime or cloud context to test reachability-based prioritization.
- Enable opt-in fix pull requests after triage results are trusted.
This sequence separates data-quality problems from remediation quality. If owners or deployments are mapped incorrectly, faster ticket and pull-request creation only spreads the error.
Phoenix’s ASPM overview says the platform connects code, containers, cloud, and runtime. Buyers should test that trace across their own build and deployment chain.
How is Phoenix licensed and delivered?
Phoenix now publishes three pricing paths . The Free tier covers up to 1,000 assets and two premium users, while Professional is listed at £1,495 per month.
The Enterprise tier remains quote-based. The pricing page also says qualifying startups can pay monthly for Professional and teams can move from the free license to another tier later.
The public product pages do not provide a downloadable self-hosted edition or versioned release archive. Buyers should confirm deployment, data residency, and update controls.
What are Phoenix Security’s limitations?
Phoenix’s workflow uses scanner, repository, cloud, runtime, and ownership context. Incomplete inputs affect which findings are linked, prioritized, and assigned.
Reachability and AI-generated fixes reduce work; they do not remove the need for review. I would sample suppressed findings and require tests on every generated pull request.
The platform’s broad code-to-runtime model also creates onboarding work. Teams with inconsistent asset names or weak ownership data should expect mapping and cleanup before automation becomes reliable.
Finally, several performance percentages on the product site are vendor-reported. Treat them as evaluation hypotheses and measure noise reduction, time to ownership, and accepted fixes against your own baseline.
The free tier can show interface and asset-model fit, but a small evaluation may not reveal the cleanup needed across a larger portfolio. Include inconsistent names, shared services, and inherited findings in the pilot.
Remediation automation also needs repository safeguards. Branch protection, required tests, code-owner review, and rollback remain necessary when Phoenix proposes a technically plausible fix.
I would score accepted pull requests separately from generated ones. Generation volume is not a useful outcome if developers rewrite or reject most changes.