Security-Scans
Jedes Image wird automatisch auf CVEs geprüft, beim Push und jede Nacht gegen die aktuelle CVE-Datenbank. Dazu kommen ein Bericht, der mit dem Behebbaren beginnt, und eine live geprüfte Härtung zur Laufzeit für jede App.
Jedes Image, das Ihre Builds pushen, wird auf bekannte CVEs geprüft, und jedes gespeicherte Image wird jede Nacht erneut geprüft. So taucht auch eine Schwachstelle auf, die erst nach Ihrer Auslieferung veröffentlicht wurde. Die Console listet, was Sie beheben können, neben der Härtung zur Laufzeit, die live an Ihrer App geprüft wird.
Immer geprüft, immer aktuell
Die Prüfung läuft auf Ebene der Registry, gegen das Image, das Ihre App tatsächlich ausführt. Es ist dasselbe Artefakt, keine Kopie Ihres Repos. Ein frisch gepushtes Image zeigt pending, bis der erste Scan abgeschlossen ist, danach scanned mit Zeitstempel. So wissen Sie immer, wie aktuell der Bericht ist.
Bericht lesen
Die Seite Security des Projekts fasst den Scan jeder App nach Schweregrad zusammen und listet jeden behebbaren Fund:
Jede Zeile ist eine CVE: Schweregrad, betroffenes Paket, installierte Version und die Version oder Versionen, die sie beheben, verlinkt mit dem Advisory für alle Details. Die Liste ist bewusst auf Funde mit verfügbarem Fix gefiltert, denn mit diesen Funden können Sie arbeiten. Sie bekommen einen Bericht, den Sie abarbeiten, keine Wand, an der Sie vorbeiscrollen.
Ihr Coding-Agent liest denselben Bericht über MCP mit nyx_app_security und erfährt dabei eines mehr: Jeder Fund gibt an, ob er in Ihren eigenen Abhängigkeiten liegt (Fix im Lockfile) oder im Basis-Image bzw. in der Toolchain (Fix durch ein neueres Basis-Image). Hat der Build keine Stückliste (Bill of Materials) angehängt, sagt das Tool das. Eine leere Liste bedeutet dann „nichts sichtbar“, nicht „sauber“.
Um Funde zu beheben, geben Sie die Liste Ihrem Coding-Agenten. Er aktualisiert die Abhängigkeit oder das Basis-Image, baut mit nyx_build_and_push_image neu und rollt erneut aus. Das neue Image wird beim Eintreffen geprüft, der nächste Bericht zeigt also, ob der Fix gegriffen hat.
Härtung, live geprüft
Dieselbe Seite zeigt die Härtung jeder App zur Laufzeit. Das sind Live-Prüfungen, berechnet aus dem tatsächlichen Zustand des Namespace, keine statische Liste von Behauptungen. Für Ihre App:
- Egress-Sperre. Kein Weg in private Netze. Die RFC1918-Bereiche (10/172.16/192.168) sind gesperrt, erlaubt sind nur DNS und das Internet.
- IMDS- und Metadaten-Sperre. Der Metadaten-Endpunkt der Cloud (169.254.0.0/16) ist nicht erreichbar. Das verhindert den Diebstahl von Zugangsdaten über IMDS.
- Ressourcenkontingent und Limits. CPU, RAM und Speicher sind gedeckelt. So gibt es keine störenden Nachbarn und keine Ausweitung von Ressourcen.
Diese Punkte werden grün, sobald die durchsetzenden NetworkPolicies und Kontingente tatsächlich auf Ihren Namespace angewendet sind. Was noch eingerichtet wird, wird auch genau so angezeigt. Darüber liegen zwei plattformweite Garantien, die für jede App gelten. Die Capability NET_RAW ist clusterweit entzogen, fail-closed, mit seccomp im Runtime-Default-Profil. Und die geteilte Plattform wird in der Schweiz betrieben (Infomaniak), gedeckt durch den Angemessenheitsbeschluss der EU; eine dedizierte Instanz läuft in der Region Ihrer Wahl. Jeder Unterauftragsverarbeiter und sein Standort steht im AVV.
Wer auf Funde reagiert
In selbst betriebenen Projekten tun Sie das. Der Bericht steht auf der Seite Security und wird jede Nacht aktualisiert. Eine Benachrichtigung, wenn eine neue CVE eines Ihrer Images trifft, gibt es noch nicht. In Tarifen mit Betrieb durch nyxory ist die Reaktion auf CVEs Aufgabe von nyxory, abgerechnet über die Operator-Credits Ihres Tarifs und in der Betriebsakte festgehalten.