Container-Scans blockieren Rollouts. So prüft das Betriebsteam Sicherheitslücken sicher vor dem Livegang

Ein Container-Image ist für das Release freigegeben, die Pipeline läuft, das Team wartet – und dann schlägt der Security-Scanner Alarm. Mittelrisiko-Schwachstelle entdeckt, Rollout gestoppt. Was für die Sicherheit richtig ist, bringt Betriebsteams in ein Dilemma: Wie unterscheidet man echte Blocker von harmlosen Altlasten? Und wer entscheidet, ob ein Rollout trotz Warnungen weiterlaufen darf?

Das Problem: Scanner-Outputs ohne Betriebskontext

Container-Security-Tools wie Trivy, Snyk oder Twistlock spucken bei jedem Scan hunderte von Findings aus. Das Team sieht eine Liste mit CVE-Nummern, CVSS-Scores und kryptischen Paketbeschreibungen – aber keine Antwort auf die entscheidende Frage: Betrifft diese Schwachstelle unseren konkreten Service?

Ein typischer Scan-Report zeigt zum Beispiel eine kritische Lücke in einer Python-Bibliothek. Aber diese Bibliothek wird nur für Development-Tools verwendet, die in der produktiven Laufzeitumgebung gar nicht aktiv sind. Trotzdem blockiert der Fund den Rollout, weil die Pipeline nicht zwischen „theoretisch vorhanden“ und „praktisch relevant“ unterscheiden kann.

Ohne klare Bewertungsregeln entscheidet am Ende oft der Zeitdruck: Entweder das Team überstimmt alle Warnungen pauschal (gefährlich) oder jeder Fund führt zu stundenlangen Einzelfallprüfungen (ineffizient). Beides ist keine nachhaltige Lösung.

Lösung 1: Risikokategorien mit Handlungsregeln definieren

Das Betriebsteam braucht eine verbindliche Matrix, wann ein Scanner-Fund wirklich blockieren darf und wann nicht. Diese Regeln müssen vor dem ersten Rollout stehen, nicht erst bei der ersten Blockade.

Kritische Blocker (Rollout stoppen):

• Schwachstellen mit CVSS-Score über 9,0 in Libraries, die zur Laufzeit aktiv sind
• Remote Code Execution (RCE) Lücken in Netzwerk-zugänglichen Komponenten
• Bekannte Exploit-Kits verfügbar (EPSS-Score über 0,5)
• Container läuft mit Root-Rechten UND enthält kritische Schwachstelle

Bedingte Blocker (Prüfung erforderlich):

• CVSS-Score zwischen 7,0 und 8,9 in produktionsrelevanten Komponenten
• Privilege Escalation Lücken bei nicht-privilegierten Containern
• Schwachstellen in Base-Image-Komponenten (OS-Level)

Monitoring-Fälle (Rollout erlaubt, Nachverfolgung erforderlich):

• Schwachstellen in Development-Dependencies, die zur Laufzeit nicht geladen werden
• Lücken in Komponenten ohne Netzwerk-Zugang
• CVSS-Score unter 7,0 ohne bekannte aktive Exploits
• Deprecated Libraries ohne Ersatz, aber mit Workaround-Maßnahmen

Lösung 2: Scanner-Integration mit Approval-Workflow

Statt Scanner-Outputs als absolute Blocker zu behandeln, sollte das Betriebsteam einen Freigabe-Workflow etablieren. Dabei prüft nicht die Pipeline automatisch alle Funde, sondern ein definierter Ansprechpartner bewertet kritische Findings im Kontext.

Ähnlich wie bei Change Management mit Risikoklassen sollten auch Container-Security-Findings nach klaren Kriterien kategorisiert werden.

Technische Umsetzung:

• Scanner läuft als separater Job vor dem Deployment-Step
• Bei kritischen Funden: automatisches Ticket im ITSM-Tool mit Kontext-Informationen
• Security-Verantwortlicher hat 4-Stunden-Fenster für Bewertung
• Ohne Rückmeldung: automatische Freigabe für Monitoring-Kategorie, Blockade für kritische Befunde
• Jede Freigabe-Entscheidung wird mit Begründung im Ticket dokumentiert

So entstehen automatisch Precedent-Cases für ähnliche Findings. Das Team lernt mit jedem Rollout, welche Scanner-Meldungen in ihrem konkreten Setup wirklich relevant sind.

Lösung 3: Baseline-Scans und Drift-Detection

Viele Scanner-Blockaden entstehen durch „bekannte Altlasten“ – Schwachstellen, die schon seit Monaten im Base-Image stecken und plötzlich als neuer Fund erscheinen. Hier hilft eine Baseline-Strategie:

Einmalige Baseline etablieren:

• Vollscan des aktuell produktiven Images durchführen
• Alle Findings bewerten und in „akzeptierte Risiken“ vs. „Behebungsplan“ einteilen
• Akzeptierte Baseline-Risks in Allowlist überführen

Rollout-Scans fokussiert auf neue Findings:

• Scanner vergleicht nur neu hinzugekommene Komponenten
• Baseline-Findings werden nicht mehr als Blocker gewertet
• Monatlicher Baseline-Review prüft, ob akzeptierte Risiken noch vertretbar sind

Diese Methode reduziert Scanner-Noise drastisch und fokussiert die Aufmerksamkeit auf wirklich neue Risiken durch Code-Changes oder Dependencies-Updates.

Praxis-Tipp: Scanner-Konfiguration für den Betrieb optimieren

Die meisten Container-Scanner kommen mit „Security-Research-Settings“ – sie melden alles, was theoretisch ein Risiko sein könnte. Für Rollout-Pipelines sind diese Settings zu sensitiv.

Wie bei Sicherheitswarnungen mit Service-Check muss auch hier der Betriebskontext berücksichtigt werden.

Produktionstaugliche Scanner-Einstellungen:

• Nur Schwachstellen mit verfügbaren Patches als kritisch werten
• Development-Dependencies von Laufzeit-Dependencies unterscheiden
• Container-Kontext berücksichtigen (Root-User, exposed Ports, Network-Policy)
• False-Positive-Filtering für bekannt harmlose Library-Versionen

Ein gut konfigurierter Scanner sollte in 90% der Fälle grünes Licht geben. Wenn jeder zweite Rollout gestoppt wird, ist die Konfiguration zu restriktiv für den Betriebseinsatz.

Integration ins ITSM: Security-Findings als Konfigurationselemente

Für eine nachvollziehbare Governance sollten Container-Security-Findings nicht nur in der CI/CD-Pipeline verschwinden, sondern als Konfigurationselemente im CMDB erfasst werden.

Ähnlich wie beim CMDB-Aufbau mit klaren Servicefragen müssen auch Security-Findings strukturiert erfasst werden:

Strukturierte Erfassung:

• Container-Image als Configuration Item mit Dependency-Mapping
• Scanner-Findings als Security-Attribute des CI
• Freigabe-Entscheidungen als Change-Records mit Risikobewertung
• Patch-Zyklen als geplante Changes mit Security-Kontext

So können IT-Manager auf Audit-Fragen konkret antworten: Welche Sicherheitslücken sind bekannt, wie wurden sie bewertet und wann werden sie behoben? Ohne diese Nachvollziehbarkeit wird Container-Security zur Compliance-Lücke.

Das Ergebnis: Sichere Rollouts ohne Blockade-Chaos

Ein durchdachtes Container-Security-Konzept macht Rollouts berechenbar. Entwicklungsteams wissen im Voraus, welche Findings wirklich blockieren. Das Betriebsteam hat klare Eskalationswege für Grenzfälle. Und das Management bekommt transparente Risiko-Reports statt „Pipeline ist rot“-Meldungen.

Der Schlüssel liegt in der Balance: Security-Scanner als Warnungssystem nutzen, aber nicht als Vollbremse. Mit den richtigen Bewertungsregeln und Approval-Workflows wird Container-Security vom Rollout-Killer zum Risiko-Navigator.

Bildquelle: Pexels / Foto-ID 442150 / CC0-Lizenz