Most security platforms are built to find. Phoenix Security is built to help you identify how to reach the finish line with remediation.

“Finish” means one thing: remediation — not vulnerabilities, not reports, not endless triage, not queues that reset every sprint. The Phoenix model starts where scanners fail: it attributes vulnerabilities, aggregates vulnerability data across code, cloud, containers, endpoints, and infrastructure, then reduces the problem to the smallest set of high-impact changes your teams can ship. Industry frameworks like OWASP Top 10 continue to highlight the systemic nature of application risk — but prioritization and remediation remain the real bottleneck.

That philosophy shows up everywhere in the platform:

• Making sure each team has the right vulnerabilities they need to see and that the risk-based narrative is aligned with organizational risk objectives
  
• The right vulnerabilities are prioritized, not just libraries, the ones that are reachable and deployed in production on externally facing systems
  
• Remediation is framed as “what change removes the most risk”, not “which CVE is loudest.”
  

How Phoenix decides what matters

Phoenix aggregates signals into a prioritization model tuned for action.

1) Severity is only the starting point

CVSS arrives from scanners. Then Phoenix adds what scanners miss: probability of exploitation, evidence and real-world signals such as CISA Known Exploited Vulnerabilities (KEV) advisories, whether a fix exists, and whether the target is externally exposed. The vulnerability layer becomes the sink for those inputs and carries that risk upward into assets, applications, and environments.

2) Criticality is a curve, not a checkbox

Business criticality isn’t linear. Phoenix uses a curve where the midpoint is stable and extremes drive stronger risk shifts. You don’t need perfect data on day one: set a default (commonly 5) and move the needle only where it matters.

3) Reachable + exploitable + critical

Phoenix Security Intelligence prioritizes vulnerabilities based on:

• Reachability (can this vulnerable code/path actually execute at runtime?)
  
• Exploitability (signals, exploitation likelihood, ransomware relevance)
  
• Criticality (business impact curve + exposure)
  

That trio is the difference between “we have 40k vulns” and “we have 12 fixes that matter.”

The remediation model: one platform, many fix-paths

Phoenix structures remediation as change types. Each category has a different “best fix,” and Phoenix pushes toward the fix with the best risk-to-effort payoff.

Infrastructure, laptops, servers: patch to the highest safe version

For endpoint and server-class remediation, the winning move is usually blunt and predictable:

• Upgrade the product or OS to the highest approved version
  
• Reduce repeat exposure from recurring CVEs by eliminating old baselines
  

Phoenix helps teams stop patching one CVE at a time and start patching by upgrade outcome.

What Phoenix surfaces:

• Which patch/upgrade removes the most critical risk
  
• Where the affected systems are, who owns them, and what SLA clock applies
  
• The remediation item that yields the biggest risk drop per change
  

Libraries (SCA): the smallest upgrade that fixes the most

SCA noise exists because most tools treat dependency issues as independent findings. Real engineering work doesn’t.

Phoenix treats library remediation as an optimization problem:

• Goal: upgrade to the minimal version that resolves the maximum number of vulnerabilities across systems
  
• Constraint: avoid unnecessary churn and reduce break risk
  

This is remediation that developers will actually accept because it’s not “upgrade everything,” it’s “upgrade this to that and kill the most risk.”

SCA capability callout: SCA smallest library upgrade that does not break the code.

Containers: delete the unsolvable, trace the fix to where it lives

Container vulnerability programs fail for two reasons:

1. Huge counts from containers that don’t run
   
2. Fix paths that are unclear because the vulnerable component lives in:
   
   • a build file dependency
     
   • the base image
     
   • an external base image lineage
     
   • a node image that spawns multiple downstream images
     

Phoenix addresses this through code-to-cloud tracing:

• identify containers that do not run and eliminate their vulnerability load
  
• trace container vulnerabilities to the Dockerfile/build file, the base image, or the external base image that generates the image graph
  
• express remediation as the concrete change: library upgrade, base image bump, or upstream image replacement
  

Container capability callout

• TRACE and THREAD agents map repo → build files → images → base images → runtime
  
• Container tracing to Dockerfile/Helm/etc. (in release)

Code vulnerabilities: fix the biggest class in a single file

Developers don’t fix “ten findings.” They fix one pattern.

Phoenix surfaces code remediation opportunities as:

• The largest vulnerability class is concentrated in a single file
  
• the change that removes a set of repeated issues (secure pattern replacement, shared utility refactor, hardening a handler)
  

That’s how you get real velocity without turning AppSec into whack-a-mole.

Code capability callout

• AI SATS fixes the biggest, most impactful fix that does not break the code (in release)
  

Secrets: remove the highest-frequency leak source first

Secret remediation isn’t about one accidental commit. It’s about repetition.

Phoenix highlights:

• The most frequent secret type
  
• the most common source locations
  
• The remediation pattern: move to env/secret manager, rotate, add ignore rules, stop reintroduction
  

Secrets capability callout

• Removing secrets from files, env patterns, gitignore guardrails (upcoming)
  

Cloud workloads: fix the AMI that produces the fleet

Workload remediation scales when you patch the golden image, not each instance.

Phoenix focuses on:

• the AMI/base artifact producing many machines
  
• the remediation action that collapses fleet exposure through one fix event
  

Cloud misconfiguration: fix the class, not the instance

Misconfiguration programs drown because fixes are applied resource by resource.

Phoenix pushes remediation into classes of issues:

• one policy or IaC correction that closes a family of exposures
  
• one change that prevents reintroduction during provisioning
  

Cloud IaC capability callout

• Fix IaC/Terraform that generates vulnerabilities and remediate by changing code (upcoming)
  

From insight to execution: tickets, alerts, or direct code fixes

A remediation recommendation that doesn’t land in an engineering workflow is trivia.

Phoenix routes actions three ways:

1) Ticketing systems

• Jira
  
• ServiceNow
  
• other ITSM/work-management pipelines
  

Phoenix can generate tickets tied to the remediation unit (“upgrade X to Y”, “bump base image”, “remove non-running container lineage”), not just raw CVE lists.

2) Alerts

• Slack
  
• Teams
  
• and other notification hooks
  

3) Direct code fixes

Where appropriate and approved, Phoenix can generate remediation plans and code changes as PRs.

Remediation SLAs without gamesmanship

Phoenix supports two SLA clocks:

• Discovery SLA: from when the vulnerability is discovered
  
• Remediation SLA: from when a ticket is opened or work is acknowledged
  

This splits “we didn’t know” from “we knew and didn’t act.”

Phoenix also supports:

• one SLA matrix for clean reporting and governance
  
• overrides through automation where exposure or labels demand tighter timelines (e.g., externally facing assets)
  

The agent stack: AI where it’s useful, not where it’s risky

Phoenix operationalizes remediation with focused agents — not one generic “AI security bot.”

Security Research & Analyst Agent (Gemini)

• monitors advisories and threat intel early
  
• predicts exploitation likelihood and ransomware relevance
  
• maps vulnerabilities to threats and threat actors
  

Attribution agents: Security Analyst Agent + PYRUS

• developer-friendly CMDB behavior
  
• automatic grouping and ownership attribution that stays current
  

Engineering agents: TRACE + THREAD

• map repos to deployed build files
  
• detect non-running containers
  
• identify base image lineage and image generators
  

GRC agent: Risk & Analyzer

• enriches vulnerabilities with threat models and attack paths
  
• accelerates developer decision-making when a human still must judge risk
  

Engineering agent: The Remediator

• produces remediation plans
  
• generates auto-code fixes via PRs
  
• calculates minimum-impact changes that address the majority of vulnerabilities
  

Copilot / Orchestrator layer

• coordinates agents
  
• interacts with Phoenix platform data
  
• uses MCPs and agent workflows to deepen investigations and drive action
  

Use cases: where Phoenix consistently wins

Phoenix is built for teams that already know scanners aren’t the problem — throughput is.

Containers: reduce reachable vulnerable code, delete dead noise

• Reduce reachable vulnerable code in containers by 78–91%
  
• Remove 430,000+ container vulnerabilities by eliminating non-running containers
  
• Trace fixes to Dockerfiles, base images, and upstream external images
  

SCA: cut dependency noise by connecting to runtime

• Cut SCA noise by up to 78% by linking dependency findings to runtime reality
  

Remediation velocity: move faster without burning teams out

• Accelerate remediation by up to 10x without inflating cognitive load
  

Phoenix brings AI to the parts of AppSec that are genuinely broken — not to replace humans, but to multiply their impact.

Real-world results: from visibility to measurable reduction

ClearBank | Fintech

Outcome: Reduced critical vulnerabilities to single digits.

Quote: “Phoenix helped us move from noise to precision. We now focus on what truly matters — and fix faster than ever before.” — Neil Reed, Principal AppSec Engineer, ClearBank

Read the Case Study

Bazaarvoice | Retail

Outcome: Dropped critical vulnerabilities to zero and achieved a 40% reduction in high-risk issues in two weeks.

Quote: “We didn’t just improve visibility — we eliminated criticals. Phoenix made that operationally possible in days, not months.” — Nate Sanders, Senior Manager, Security Engineering & Operations

Read the Case Study

Ad-tech client

Outcome: Reduced 78% of container vulnerabilities and 82% of SCA issues with unified remediation.

Quote: “Phoenix gave us the missing bridge between code and cloud. The visibility is deep, the actions are clear — and the results speak for themselves.” — Director of Application Security

Read the Case Study

See it in action

If your remediation program still starts with “export to CSV,” Phoenix will feel like a hard reset.

• See it in action
  
• Data behind the research

FAQ: Remediation-first vulnerability management (Phoenix Security)

How do we reduce SCA noise without ignoring real risk?

Stop treating every finding as a separate work item. Phoenix groups dependency findings by library + version constraint across all repos, services, and images, then recommends the minimum safe upgrade that clears the maximum vulnerabilities. The output shifts from “hundreds of findings” to “dozens of upgrades.”

How does Phoenix decide what to fix first?

Phoenix prioritizes vulnerabilities using three signals that map to action: reachable, exploitable, and business-critical. If a vulnerable path executes at runtime, threat intelligence shows active exploitation, and the service is high criticality, it rises to the top — regardless of how noisy the scanner output is.

What does “reachable” mean in Phoenix?

Reachable means the vulnerable component is not just present, but exercised. Phoenix links findings to runtime execution context — containers that actually run, packages that are loaded, code paths that are invoked — so remediation work targets what can be hit in production.

For container vulnerabilities, do we fix the Dockerfile or the base image?

Phoenix traces the vulnerability to the correct layer:

• Dockerfile/build dependency → upgrade the dependency in Maven/Gradle/npm/pip
  
• Base image → rebase to a patched image or bump OS packages
  
• Upstream external image lineage → patch the image that produces downstream images
  
• Non-running containers → remove them and delete the noise
  

Why do container programs get stuck at scale?

Two blockers show up repeatedly: massive counts from non-running containers, and unclear fix paths when the vulnerable component lives in an upstream image or build chain. Phoenix removes dead noise first, then uses container lineage to point to the exact remediation unit: build file upgrade, base image bump, or upstream replacement.

How does Phoenix turn “273 findings” into a plan engineers will ship?

Phoenix collapses duplicates across applications, components, scanners, images, and environments, then outputs remediation units — typically upgrades. A common outcome is “273 findings → 35 upgrades across 7 libraries,” because the work unit becomes “upgrade commons-compress to ≥1.21,” not “close 40 CVEs.”

Why does Phoenix recommend minimum versions instead of “upgrade to latest”?

Latest creates churn and break risk. Phoenix targets the lowest safe version that resolves the largest set of vulnerabilities. That keeps remediation shippable, reduces regression risk, and prevents dependency upgrades from becoming quarter-long rewrites.

How does Phoenix handle cases where a vulnerability appears both in code and the container?

Phoenix links them into one remediation story. Example: bzip2 might be flagged as an OS package (libbz2) in the container and also appear via application dependency chains (or runtime modules like Python bz2). Phoenix correlates both surfaces through code-to-cloud mapping and shows which change removes risk across the system.

How do Phoenix tickets avoid getting ignored in Jira or ServiceNow?

Phoenix tickets are written as engineering actions with proof:

• exact upgrade target (X → Y)
  
• scope (which apps/assets/images)
  
• evidence (reachable in production, lineage to runtime)
  
• expected outcome (findings reduced + risk magnitude drop)
  
  They’re “upgrade commons-compress + rebase base image,” not “fix 273 vulnerabilities.”
  

Can Phoenix push remediation directly into repos?

Yes, where enabled. Phoenix can generate remediation plans and produce PR-ready changes for dependency bumps and code fixes. The goal is to ship the minimum-impact change that clears the most risk, not generate a wall of suggestions.

What about legacy runtimes like Python 2 or old JVM stacks?

Phoenix doesn’t hide legacy— it traces it. If Python 2 calls bz2 and links to a vulnerable libbz2, Phoenix treats it as reachable and pushes the remediation to the correct layer: rebase the image, replace tooling, or isolate the runtime path while upgrades are staged.

How do we measure whether remediation is actually working?

Avoid “vulns closed.” Track outcomes:

• Findings → remedies compression ratio
  
• Risk reduction per remedy
  
• Reachable risk trend in production
  
• Mean time to open vs. mean time to patch (two SLA clocks)
  
  If one upgrade removes hundreds of findings and drops reachable risk, that’s real progress.
  

What’s the fastest way to improve remediation velocity in Phoenix?

Start with the remediation surfaces that scale:

1. remove non-running containers
   
2. rebase base images / golden images (AMI)
   
3. apply minimum-impact library upgrades across systems
   
4. fix repeated code patterns in a small number of files

That sequence yields measurable reduction without burning out engineering teams.