Ich konnte auf der DevOpsCon der Keynote "From Static to Strategic: Reimagining Application Security for a DevOps World" von John D. Wood nicht entgehen. Um ehrlich zu sein: Die Keynote hat mich nicht begeistert. Am ehesten noch fand ich interessant das er Zahlen hatte, das die meisten Sicherheitslücken (auch nach Bekanntwerden) noch über ein Dreiviertel-Jahr offen sind. Aua. Ein Satz am Ende ist bei mir hängengeblieben:

"DevOps bekommt jetzt auch Security."

Was simpel klingt, ist in der Realität alles andere als einfach – und betrifft uns ganz konkret. In einer Zeit, in der wir als Unternehmen KRITIS-relevant geworden sind, ist es für viele Risiken nicht mehr möglich sie einfach zu übernehmen (AKA aussitzen). Wir müssen sie aktiv mitigieren – und das gilt besonders auch für Security-Risiken.

Security: Aus DevOps wird "DevSecOps"?

Dev ist schon schwer. Ops noch schwieriger. Und jetzt kommt Security obendrauf. Nicht jedes Team kann oder will alle drei Disziplinen gleich gut abdecken. Und dennoch ist klar: Es kommt mehr Arbeit auf uns zu.

Wir werden bei bestimmten Anwendungen in Zukunft viel stärker darauf achten müssen:

• Dass Betriebssysteme (in Docker-Containern) aktuell sind,
• Dass Projektabhängigkeiten regelmäßig gepflegt werden,
• Dass wir verstehen, welche Sicherheitslücken für uns relevant sind – nicht nur, weil ein Scanner sie anmeckert, sondern weil unsere eigene Risikoabwägung sie als kritisch einstuft.

Wunsch-Szenario: Expertise teilen, nicht duplizieren

Mein Wunsch wäre, dass nicht jedes Team die komplette Security-Expertise selbst aufbauen muss. Stattdessen sollten sich diejenigen, die sich besonders für das Thema interessieren, tiefer einarbeiten können – und jederzeit unkompliziert Zugang zu Spezialist\:innen haben. Idealerweise entsteht daraus eine Art Mentoring-Beziehung.

Das Ziel: Schnell und unbürokratisch Expertise bekommen, wenn man merkt, dass man sie braucht. Entwickler\:innen sollen lernen, Security-relevante Situationen zu erkennen und wissen, wo sie gezielt und niederschwellig Unterstützung finden.

Compliance-Checkbox oder echte Verteidigung?

Ein starkes Bild aus dem Vortrag war die Kritik an klassischen Security-Prozessen: Wöchentliche Scans, lange Backlogs mit offenen CVEs, endlos False Positives, wenig konkreter Nutzen. All das erzeugt ungeplante Arbeit, und widerspricht damit dem DevOps-Grundsatz "No unplanned work" – und hilft im Ernstfall wenig. Letztlich müssen wir ja die Daten unserer Versicherten Schützen, dass der Bug den ein Angreifer bei uns Ausgenützt hat schon lange bekannt war, hilft uns nicht weiter.

Fazit

Ich nehme aus dem Talk vor allem eines mit: Security können wir in Zukunft nicht länger als "Problem von jemand anderem" verstehen. Sie ist jetzt (oder wird es bald) integraler Teil von DevOps – ob uns das passt oder nicht.

Und wir müssen Wege finden, wie wir das gemeinsam schultern können – weil wir eben nicht jeden Entwickler zum Security-Experten machen können.

Vor einigen Wochen war ich auf der DevOpsCon in Berlin. Einer der spannenderen Vorträge war für mich: "Supply Chain Security and the real world: Lessons from Incidents". Offiziell ging es um Sicherheit in Container-Umgebungen. Inoffiziell war es eine Abrechnung mit dem Chaos, das wir im Alltag mit Docker-Containern erleben.

Wir alle lieben Docker Hub: Schnell ein Image ziehen, starten, fertig. Aber was dabei oft vergessen wird: Selbst die als "offiziell" markierten Container bieten keinerlei Garantien. Weder über die Aktualität noch über Sicherheit. Fast alle dieser Container werden monatelang nicht aktualisiert, obwohl es CVEs für enthaltene Komponenten gibt.

Wenn man das ernst nimmt, müsste man:

• Alle Container regelmäßig selbst neu bauen und dabei Updates der darin enthaltenen Distributionen installieren
• Bei jeder Abhängigkeit überwachen, ob es CVEs oder Updates gibt
• Die Upstream-Projekte verstehen, ihre Update-Kanäle abonnieren
• Alle Dockerfiles durchdringen (insbesondere bizarr manuell installierter Binaries)

Kurz: Wer Container sicher betreiben will, muss eigentlich selbst zur Distribution werden.

Die Lösung: "Start Left" statt "Shift Left"

Die Firma Chainguard hat in dem Vortrag ihre Alternative vorgestellt: Ein Repository von sicherheitsoptimierten, rootlosen Containern, die alle:

• ohne bekannte CVEs ausgeliefert werden
• auf einem selbstgebauten, deterministischen OS basieren ("Wolfi", im wesentlichen Alpine mit GLibC statt Musl)
• reproduzierbar gebaut werden (jede\:r kann sie nachbauen, wenn auch nicht Bit für Bit)
• mit Software-Bill-of-Materials (SBOM) ausgeliefert werden
• Auch im Container als normale Nutzer ausgeführt werden anstatt als `root`
• und bei neuen Upstream-Vulnerabilities innerhalb von 7 Tagen gepatcht werden

Die Container sind FIPS-kompatibel, in zwei Varianten (Production vs. Dev - mit mehr Tools) verfügbar und mit bekannten Tools wie trivy problemlos scannbar. Offen Statistiken zeigen beeindruckend wie viel weniger CVEs sieh in Ihren Containern haben. Nämlich in der Regel gar keine.

Warum das für viele ein Game-Changer sein könnte

Wie in vielen Unternehmen, ist auch bei uns die Nutzung von Docker-Containern ein "Free for All": Jeder zieht, was er braucht, hauptsache es läuft. Sicherheitsrichtlinien? Nicht vorhanden. Updates? Machen wir Manuell alle Jubeljahre. Genau hier setzen die Container von Chainguard (oder auch Dockers eigene "Hardened Images") an:

Man könnte sagen:

Was sonst niemand zuverlässig macht, macht ChainGuard automatisch.

Und das Beste: Die Basis-Container sind sogar kostenlos (und damit z.B. auch für Open Source Projekte) verwendbar. Damit kann man ohne großen Aufwand den Produktivbetrieb auf eine wesentlich sicherere Basis stellen.

Gerade wenn man – wie bei KRITIS-Vorgegeben – innerhalb eines festen Zeitrahmens Sicherheitsupdates einspielen muss, ist eine verlässliche Update-Garantie Gold wert.

Mein Fazit

Container sind kein Selbstzweck – und sie haben einen großen Nachteil gegenüber Veränderbarer Infrastruktur: Man verliert die automatisch installierten Updates der Linux Distributionen. Wer diesen Aufwand nicht selbst stemmen will, braucht Alternativen. Die gehärteten Container von ChainGuard oder Docker sind ein vielversprechender Weg, um mit minimalem Aufwand viel weniger CVEs und fehlender Updates, sowie weit mehr Transparenz gewinnen kann.

Probiert es doch mal aus. Ich würde mich sehr über Feedback freuen wo die Grenzen und Probleme dieses Ansatzes liegen. Offensichtlich ist schon mal, dass dort nicht so viele Container gibt.

Grundsätzlich aber immer: Bitte Entscheidet euch bewusst für Images, die gepflegt werden. Und nicht für das erste, das die Suche auf Docker Hub zurück gibt.

Weil ich es heute wiederholt nachschlagen musste, hier noch eine Erinnerung an mich selbst, wie einfach es ist auf der Shell set Operationen durchzuführen.

In unserem Beispiel: ~10k Datenbank-IDs hier, ~15k Datenbank-IDs da, und die Frage welche davon nur in der einen Liste enthalten sind. Das ist dann einfach zu beantworten, wenn man die auf eine ID pro Zeile ausgibt, und dann einfach mit set_difference bearbeitet.

set_union () {
   sort $1 $2 | uniq
}

set_intersection () {
   sort $1 $2 | uniq --repeated
}

set_difference () {
   sort $1 $2 $2 | uniq --unique
}

set_symmetric_difference() {
   sort $1 $2 | uniq --unique
}

Quelle