Dein Blog zum Thema digitales Business

Viele Teams scannen ihren Quellcode auf Schwachstellen und übersehen dabei das, was am Ende wirklich in Produktion läuft: das Container-Image. Zwischen dem Code im Repository und dem laufenden Container liegen Base-Images, Systembibliotheken und Paketabhängigkeiten, die niemand bewusst ausgewählt hat. Genau dort sitzen die meisten Lücken.

Das Image ist das eigentliche Artefakt

Ein Container-Image ist kein Abbild deines Codes. Es ist ein Stapel aus Schichten: ein Base-Image vom Hersteller, darüber Systempakete, dann die Anwendung mit ihren Abhängigkeiten. Eine einzige veraltete Bibliothek im Base-Image bringt Schwachstellen mit, die im eigenen Code gar nicht vorkommen. Wer nur den Quellcode prüft, sieht diese Schicht nie. Das laufende Image ist das, was ein Angreifer tatsächlich vor sich hat.

Was ein Scanner findet, und was nicht

Image-Scanner wie Trivy, Grype oder die in der Registry eingebauten Werkzeuge vergleichen die installierten Pakete mit bekannten CVE-Datenbanken. Das deckt veraltete Systembibliotheken, unsichere Versionen von OpenSSL oder verwundbare Sprachpakete zuverlässig auf. Was sie nicht finden: Konfigurationsfehler, zu weit gesetzte Rechte, Secrets im Image oder logische Schwachstellen im eigenen Code. Ein Scan ist eine Schicht der Verteidigung, nicht die ganze. Wer das verwechselt, hält ein grünes Ergebnis für mehr Sicherheit als es ist.

Drei Stellen, an denen es klemmt

Erstens das Base-Image. Wer „latest“ verwendet, weiß nicht, was drin ist. Ein schlankes, auf eine feste Version gepinntes Base-Image reduziert die Angriffsfläche deutlich. Zweitens die eigenen Layer. Wer im Build Pakete installiert und Caches nicht aufräumt, schleppt unnötige Software mit, die mitgeprüft und mitgepatcht werden muss. Drittens Secrets. Tokens oder Schlüssel, die während des Builds ins Image geraten, lassen sich später aus den Layern auslesen, auch wenn sie im finalen Schritt scheinbar gelöscht wurden.

Scannen ist ein Prozess, kein einmaliges Gate

Ein Image, das heute sauber ist, kann morgen verwundbar sein, weil eine neue CVE veröffentlicht wurde. Das Paket im Image hat sich nicht geändert, die Bewertung schon. Deshalb gehört der Scan nicht nur in die Pipeline beim Build, sondern auch regelmäßig auf die Images, die bereits in der Registry liegen. Sonst sicherst du den Moment der Erstellung ab und ignorierst die Zeit danach, in der das Image tatsächlich läuft.

Wo der Mittelstand anfangen sollte

Nicht mit dem teuersten Tool. Mit drei Schritten: Base-Images auf feste Versionen pinnen, einen Scanner in die Build-Pipeline einbauen, der bei kritischen Funden blockiert, und einen wiederkehrenden Scan auf die Registry legen. Das kostet wenig und schließt den Großteil der typischen Lücken. Entscheidend ist, dass die Funde auch jemand bearbeitet. Ein Scanner, dessen Report niemand liest, erzeugt nur ein gutes Gefühl und keine Sicherheit.

Ob eure Pipeline ihre Images überhaupt prüft und ob die Funde irgendwo landen, sehen wir uns im GitSecOps QuickCheck an. Wir gehen eure Build- und Deploy-Strecke durch und zeigen konkret, wo Schwachstellen unbemerkt durchrutschen. Festpreis 1.990 Euro netto, Ergebnis in drei Werktagen. Kontakt: mm@crank.zone.