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.
Every image your builds push is scanned for known CVEs, and every stored image is re-scanned nightly, so a vulnerability published after you shipped still shows up. The console lists what you can fix, next to runtime hardening checked live against your app.
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 project’s Security page summarizes each app’s 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.
Your coding agent reads the same report over MCP with nyx_app_security, and gets one thing more: each finding says whether it sits in your own dependencies (fix it in the lockfile) or in the base image or toolchain (fix it with a newer base image). If the build attached no bill of materials, the tool says so, and an empty list then means “nothing visible”, not “clean”.
To fix findings, hand the list to your coding agent: it bumps the dependency or base image, rebuilds with nyx_build_and_push_image, and redeploys. The new image is scanned on arrival, so the next report shows whether the fix landed.
Hardening, verified live
The same page shows each 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 the shared platform is hosted in Switzerland (Infomaniak), covered by the EU adequacy decision; a dedicated instance runs in the region you choose. Every sub-processor and its location is listed in the DPA.
Who acts on findings
On self-operated projects you do: the report is on the Security page, refreshed nightly, and there is no alert yet when a new CVE lands on one of your images. On operated plans, CVE response is nyxory’s job, run on your plan’s credits and written up on the record.