Recomputed after every sync
Each control re-reads scans, remediation, exceptions and roles when new data lands, with the date it was last checked on the row.
The platform
One record per finding, from first detection to verified closure.
PYXA is not a scanner and not a dashboard. It is the operating layer between them: it holds the finding, the decision, the owner, the deadline and the proof, so the security team stops keeping that state in spreadsheets.
DeploymentSelf-hosted only
RuntimeDocker Compose
LicenceAGPL-3.0 (Community), commercial (paid editions)
EgressNone required
01 · Centralise
One queue, every source.
Scanners, penetration test reports, bug bounty programmes, code scanning and attack-surface exports all land in the same register. Connectors normalise severity and identifiers, and the same vulnerability reported by two sources becomes one finding with both reports attached. Assets are matched on hostname, address and cloud identifier so the graph does not fork.
Each connector is grouped by what it lets PYXA conclude. A scanner can find a vulnerability and prove it gone. A pentest or a bug bounty report adds findings but cannot prove a fix. A deployment tool can only say a patch was pushed.
All 25 connectors →
02 · Prioritise
A priority you can defend.
Scanner severity is one input. The 0–100 risk score reads active exploitation from CISA KEV and VulnCheck, exploit availability, EPSS, national CERT advisories and your own asset context, then bands the result P0 to P3.
It takes the worst score any host carries, not an average, because averaging would let one internet-facing crown jewel disappear into thirty lab machines.
CVSS 9.8Risk 99EPSS 0.71CISA KEV yes12 internet-facing
03 · Assign and remediate
Campaigns, not backlogs.
Action plans group findings into Routine or Emergency campaigns, each with its own SLA clock. Auto-triage rules open and assign work after every sync, and Jira, GLPI, TheHive or ServiceNow tickets follow the lifecycle.
Plans are ordered by risk, then blast radius, then compliance deadline, then quick wins. The demo estate runs 87 plans over 16,431 host tasks, and names the 20 that will miss their window before they do.
04 · Automate
Faster to a fix. Never faster to a claim.
Auto-triage rules open and assign work after every sync, and fifteen AI tasks draft what people used to write by hand. Both shorten the path from detection to remediation. Neither can close a finding, approve an exception or change a priority band.
All fifteen AI tasks →Auto-triage rules
Conditions on risk score, EPSS, the KEV list, scope or a title pattern. Actions: join a plan, open one per vulnerability, name an owner, open a ticket, ask AI to draft the instructions. One run on the demo estate placed 100 unplanned vulnerabilities in 100 new plans, each with a named owner, and held 533 back for the next run.
AI tasks, routed one by one
Remediation guidance, root-cause clustering, plan proposals, rule drafting, knowledge entries and ten more, each in the screen it serves. Every row states what would leave your environment; on a local model, nothing does.
05 · Verify and govern
Nothing closes on a claim.
A remediation closes only when a verifying scanner's rescan confirms the vulnerability is gone. When a fix will not happen, risk acceptance needs a second person: the one who asks can never be the one who approves, checked on each request. Accepted risk stays in the register and reopens 30 days before it expires.
06 · Report
The pack, not the spreadsheet.
Evolution trends, SLA compliance, benchmarks and a live compliance self-assessment are views of the same data. The one-page CISO board report is generated on demand, with no external service involved.
Trends are computed on the scanned estate only. The 154 assets that never appeared in a snapshot are excluded from every panel, and the page says so before the first chart.
PCI-DSS 4.0NIS2CRASOC 2TISAXHIPAAOWASP ASVS
Seven frameworks, control by control →
07 · Comply
NIS2, TISAX, PCI‑DSS. Evidence from the work itself.
The data that runs the remediation also answers the auditor. PYXA computes the vulnerability-management controls of seven frameworks from scans, remediation, exceptions and roles, and recomputes them after every sync. Professional includes one of NIS2, TISAX or PCI DSS v4.0; Enterprise covers all seven. No control is marked as passing that PYXA cannot see, and evidence starts on the day PYXA is installed: it cannot be back-dated.
Fail
Evidence exists and contradicts the control.
Evidence incomplete
PYXA cannot answer: no connector feeds it the data.
Pass · evidenced
Connector data supports the control.
Needs a person
Not something a scanner can observe, so a person attests it.
Not applicable
Out of scope, with a recorded reason.
Each control names its evidence.
Every row states the requirement, what PYXA observed, which connector the evidence came from and when it was last checked. These are the framework sections as the app shows them.
Article 21.2(e) remediation fails on the demo estate: 1,134 high or critical vulnerabilities open longer than 30 days, excluding approved exceptions. Article 23's 24-hour early warning is a process, not a scan result, so PYXA marks it for a person to attest rather than guess.
Asset inventory passes because 4,322 assets were seen in the last 30 days. Timely remediation fails: 604 critical vulnerabilities, risk score 80 or more, are open longer than 30 days. Supplier risk is outside what a scanner can see, and the row says so.
Timely security updates passes: no actively exploited vulnerability has been open longer than 14 days. The SBOM control stays evidence incomplete until a software composition analysis connector runs, and fills in on its own once one does.
Requirement 6.3.3 can also drive the work: switch it on and a critical or high vulnerability open longer than a month makes its plan P0, ahead of the risk order.
SOC 2 CC7.2 fails for a reason the platform can fix: the escalation job exists but has no scheduled run. The row names the task to schedule.
A deadline can set the priority
With PCI-DSS 6.3.3 switched on, a critical or high vulnerability open longer than a month makes its plan P0, ahead of the risk order.
A self-assessment, not a certificate
PYXA assesses the 27 controls its data can speak to, not each framework end to end. For the rest, the Compliance readiness mission maps your controls and wires in the evidence.