TYPO3 auf Kubernetes unter IT-Grundschutz, Teil 4: Keine CVEs über 7

01 — Was „über 7“ genau bedeutet

CVSS-Werte ab 7,0 gelten als HIGH, ab 9,0 als CRITICAL. „Keine CVEs über 7“ heißt in der Praxis: kein Befund der Schwere HIGH oder CRITICAL. Scanner filtern direkt nach diesen Schweregraden. Sie übernehmen dabei die Einstufung der jeweiligen Datenquelle, die vom CVSS-Wert abweichen kann.

Wichtig ist die zweite Einschränkung: nur Befunde, für die es einen Fix gibt. Ein Gate, das auch unfixbare CVEs zählt, blockiert Releases, ohne dass jemand etwas tun kann. Das Team lernt dann vor allem, das Gate zu umgehen. Unfixbare Befunde gehören in die Risikobewertung und in die Überwachung, nicht in die Ampel der Pipeline.

Zwei Stellen brauchen einen Scan. Das Container-Image enthält Betriebssystem-Pakete und die Laufzeit. Die Anwendung bringt ihre eigenen Abhängigkeiten mit, bei TYPO3 im composer.lock und oft zusätzlich im package-lock.json für das Frontend.

02 — Gate eins: das Image

Nach dem Build scannt ein Job das fertige Image, typischerweise mit Trivy. Ein zweiter Job, das Urteil, liest den Bericht und entscheidet. Die Trennung hat einen Grund: Der Scan sammelt Fakten, das Urteil wendet Regeln an. So lässt sich die Regel ändern, ohne den Scan anzufassen.

Das Urteil kennt drei Modi:

• report: Befunde werden nur berichtet.
• warn: Der Job wird gelb, die Pipeline bleibt grün.
• block: Die Pipeline wird rot, es gibt kein Release.

Begründete Ausnahmen stehen in einem VEX-Dokument nach OpenVEX. Es nennt die CVE, das betroffene Paket und den Grund, etwa dass der verwundbare Code im Image gar nicht ausgeführt wird. Das ist besser als eine Ignore-Liste. Jede Ausnahme hat eine Begründung und lässt sich prüfen.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.org/vex/typo3-runtime",
  "author": "Platform Team",
  "timestamp": "2026-10-08T00:00:00Z",
  "version": 1,
  "statements": [{
    "vulnerability": {"name": "CVE-2026-00000"},
    "products": [{"@id": "pkg:apk/wolfi/example@1.2.3"}],
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path"
  }]
}

Daneben gibt es oft eine Baseline: Befunde, die beim Einführen des Gates schon da waren und bewusst hingenommen werden. Sie ist ein Übergang, kein Dauerzustand. Das Ziel ist eine leere Baseline.

03 — Gate zwei: die Abhängigkeiten der Anwendung

Der Image-Scan sieht die Anwendung gar nicht, denn ihr Code liegt nicht im Image (Teil 3). Deshalb läuft ein zweiter Scan direkt auf den Lockfiles, schon im Merge-Request:

trivy fs --scanners vuln \
  --severity HIGH,CRITICAL \
  --ignore-unfixed \
  --exit-code 1 .

Findet er etwas, ist der Weg meist kurz. Entweder gibt es ein Update, oder eine transitive Abhängigkeit lässt sich gezielt anheben. Bei npm geht das mit overrides, bei Composer mit einer expliziten Anforderung der gefixten Version. Danach sollte sich im Lockfile nur das betroffene Paket ändern.

Eine Eigenschaft sollte man vorher kennen: Eine neu veröffentlichte CVE kann einen Merge blockieren, obwohl niemand Code geändert hat. Genau das ist der Zweck des Gates. Es funktioniert aber nur, wenn Updates schnell ankommen. Automatische Dependency-Updates sind deshalb kein Komfort, sondern Voraussetzung. Wie das über viele Repositories funktioniert, beschreibt der Beitrag zu pinup.

04 — Nach dem Release: Nachscan und Fristen

Ein Image, das heute sauber ist, kann morgen eine bekannte Schwachstelle haben. Viele CVEs werden erst nach dem Release veröffentlicht. Der Scan beim Build reicht deshalb nicht.

Ein täglicher Job scannt die Digests, die tatsächlich im Cluster laufen. Nicht die Tags, denn ein Tag kann sich bewegen. Neue Befunde lösen einen Alarm mit Frist aus, zum Beispiel 24 Stunden für CRITICAL und 7 Tage für HIGH. An dieser Stelle greift das Patch- und Änderungsmanagement nach OPS.1.1.3.

Von warn zu block

Ein Gate direkt auf block zu stellen, legt oft alle Pipelines auf einmal lahm. Bewährt hat sich diese Reihenfolge:

1. Gate im Modus warn einführen und messen.
2. Befunde abbauen, bis die Baseline leer ist.
3. Einzelne Repositories auf block stellen.
4. Wenn fast alle sauber sind, block zur Vorgabe machen und nur noch Ausnahmen führen.

Jede Ausnahme bekommt einen Grund und ein Datum. Eine Ausnahme ohne Grund ist kein Risikomanagement, sondern ein abgeschaltetes Gate.

Bezug zum IT-Grundschutz

Das Gate deckt mehrere Anforderungen aus SYS.1.6 ab: die Verwendung sicherer Images (SYS.1.6.A6), ihre Verteilung (SYS.1.6.A12), die Freigabe (SYS.1.6.A13) und die Aktualisierung (SYS.1.6.A14). Die Fristen nach dem Release gehören zu OPS.1.1.3.

Fazit

„Keine CVEs über 7“ wird erst dann eine Eigenschaft der Plattform, wenn ein Verstoß ein Release verhindert. Dafür braucht es zwei Scans, eine klare Schwelle für fixbare Befunde, begründete Ausnahmen und einen Nachscan für alles, was schon läuft. Die Einführung gelingt am besten schrittweise: erst messen, dann scharf schalten.

Weiter geht es mit Teil 5: mTLS auf jeder Strecke. Zurück zu Teil 3: Code als signiertes Artefakt.