Security scanning
Every image is scanned for CVEs automatically — on push and nightly against the fresh CVE database — with a fix-first report and live-verified runtime hardening per app.
You don’t set up a vulnerability scanner on nyxory — you already have one. The registry every build lands in scans each image for known CVEs the moment it’s pushed, and re-scans every stored image nightly as the global CVE database updates. That second half matters: a vulnerability published after you shipped still surfaces, without you redeploying anything. The console shows the result the useful way round — the fixable list, each entry with the version that fixes it — next to a hardening posture that’s verified live against your app’s actual runtime, not asserted.
Always scanned, stays fresh
Scanning runs at the registry level, against the image your app actually runs — the same artifact, not a copy of your repo. A freshly pushed image shows pending until its first scan completes, then scanned with a timestamp, so you always know how current the report is.
Reading the report
The Security tab on each app summarizes the scan by severity and lists every fixable finding:
Each row is one CVE: severity, the affected package, the installed version, and the version(s) that fix it — linked to the advisory for the full story. The list is deliberately filtered to findings with a fix available, because that’s the actionable set: a report you can work through, not a wall you scroll past.
Remediation is a natural agent task. Hand the list to your coding agent: it bumps the dependency or base image, rebuilds with nyx_build_and_push_image, and redeploys — and because the new push is scanned on arrival, the next report is the proof the fix landed. Find, fix, verify, all inside the loop you already ship with.
Hardening, verified live
The same tab shows the app’s runtime hardening — and these are live checks computed from the namespace’s actual state, not a static claims list. For your app:
- Egress lockdown — no path into private networks: RFC1918 ranges (10/172.16/192.168) blocked, only DNS and the internet.
- IMDS / metadata block — the cloud metadata endpoint (169.254.0.0/16) is unreachable, closing off credential theft via IMDS.
- Resource quota & limits — CPU, RAM, and storage are capped, so no noisy neighbors and no resource escalation.
These flip green when the enforcing NetworkPolicies and quotas are actually applied to your namespace — still provisioning shows as exactly that. On top sit two platform-wide guarantees that hold for every app: the NET_RAW capability is dropped cluster-wide fail-closed with seccomp on the runtime default profile, and everything is EU-hosted — data doesn’t leave the EU.
Acting on what it finds
Today the report lives in the Security tab, refreshed nightly — check it the way you check Monitoring. On operated plans, responding to what the scanner surfaces is nyxory’s job: CVE response is one of the operations runs your plan’s credits power, written up on the record like every other change. Alerting for self-operated projects — a push the moment a new CVE lands on one of your images, instead of a tab you visit — is coming on the same telemetry.