DevSecOps: Sicherheitsprüfungen, die Entwickler nicht ausbremsen

In vielen Firmen lief Sicherheit lange so: Das Entwicklungsteam baut ein neues Release, kurz vor dem Start prüft ein Sicherheitsteam, und dann kommt eine lange Liste mit Mängeln. Der Termin wackelt, alle sind verärgert. Am Ende geht die Software oft trotzdem live, mit dem Versprechen, die Mängel später zu beheben.

DevSecOps will diesen Kreislauf durchbrechen. Der Begriff verbindet Entwicklung (Development), Sicherheit (Security) und Betrieb (Operations). Die Idee: Sicherheitsprüfungen laufen automatisch und laufend mit, so wie Tests und Builds. Fehler fallen auf, solange sie klein und billig zu beheben sind.

Das klingt einfach. In der Praxis scheitert es oft an Scannern, die Hunderte Warnungen ausgeben, und an Teams, die nicht wissen, was sie damit tun sollen. Dieser Beitrag zeigt, wie Sie Sicherheitsprüfungen so einbauen, dass sie helfen statt bremsen.

Die Pipeline als Ort für Sicherheit

Moderne Software entsteht in einer Pipeline. Jede Änderung am Code durchläuft automatisch mehrere Schritte: bauen, testen, verpacken, ausliefern. Fachleute sprechen von CI/CD, kurz für Continuous Integration und Continuous Delivery. Jeder dieser Schritte ist ein möglicher Ort für eine Sicherheitsprüfung.

Die Grundregel lautet: Eine Prüfung gehört dorthin, wo sie schnell genug ist und ihr Ergebnis noch etwas ändert. Was Sekunden dauert, kann bei jeder Änderung laufen. Was eine Stunde braucht, läuft besser nachts oder vor einem Release. Und was nur Hinweise liefert, sollte keinen Build abbrechen.

Ein zweiter Grundsatz betrifft die Pipeline selbst. Sie hat oft weitreichende Rechte, etwa zum Ausliefern in die Produktion. Wer sie übernimmt, kann Schadcode in jedes Release schmuggeln. Zugangsschlüssel für die Pipeline gehören deshalb in einen geschützten Speicher, und Änderungen an ihr sollten dieselbe Prüfung durchlaufen wie Änderungen am Code.

Welche Prüfung wohin gehört

Die gängigen Prüfarten lassen sich grob den Stufen der Entwicklung zuordnen:

• Im Editor und beim Commit: Suche nach Geheimnissen wie Passwörtern und Zugangsschlüsseln, die versehentlich im Code landen. Diese Prüfung ist schnell und sollte immer laufen.
• Bei jedem Merge Request: statische Codeanalyse, auch SAST genannt, sowie die Prüfung von Abhängigkeiten auf bekannte Schwachstellen.
• Beim Bau von Containern: Scan der Images auf veraltete Pakete und Prüfung von Infrastruktur als Code auf riskante Einstellungen, etwa öffentlich lesbare Speicher.
• Vor der Auslieferung: dynamische Tests gegen die laufende Anwendung, kurz DAST, in einer Testumgebung.
• Im Betrieb: Überwachung von Protokollen und ein regelmäßiger Abgleich der eingesetzten Komponenten mit neuen Schwachstellenmeldungen.

Nicht jedes Team braucht alles ab dem ersten Tag. Für den Anfang reichen oft drei Bausteine: Geheimnissuche, Abhängigkeitsprüfung und eine einfache statische Analyse. Sie sind schnell eingerichtet und finden viele der häufigsten Fehler.

Ist ein Geheimnis erst einmal im Code gelandet, reicht Löschen übrigens nicht. Die Versionsverwaltung bewahrt alte Stände auf. Ein veröffentlichter Schlüssel muss deshalb immer ausgetauscht werden, auch wenn er nur kurz sichtbar war.

Das größte Risiko steckt oft in fremdem Code

Moderne Anwendungen bestehen zu einem großen Teil aus Open-Source-Bibliotheken. Jede davon bringt eigene Abhängigkeiten mit. So landen schnell sehr viele fremde Komponenten in einem Projekt. Die meisten davon hat das Team nie bewusst ausgewählt.

Wie heikel das ist, zeigte Ende 2021 die Lücke Log4Shell in einer weit verbreiteten Java-Bibliothek für Protokollierung. Viele Unternehmen wussten zunächst nicht einmal, ob und wo sie die Bibliothek einsetzten. Wer eine aktuelle Stückliste seiner Software hatte, war klar im Vorteil.

Diese Stückliste heißt SBOM, kurz für Software Bill of Materials. Sie verzeichnet alle Komponenten mit Version. Viele Werkzeuge erzeugen sie automatisch beim Build. Auch Gesetzgeber verlangen solche Nachweise zunehmend, etwa der europäische Cyber Resilience Act für Hersteller vernetzter Produkte.

Neben bekannten Lücken gibt es gezielte Angriffe auf die Lieferkette. Angreifer veröffentlichen Pakete mit Namen, die beliebten Bibliotheken zum Verwechseln ähnlich sind. Oder sie übernehmen das Konto eines Entwicklers und schleusen Schadcode in ein echtes Update. Feste Versionsangaben und ein interner Spiegel für Pakete senken dieses Risiko.

Ein Sicherheitsfund, den niemand versteht, wird nicht behoben, sondern weggeklickt.

Wenn Scanner nur Lärm erzeugen

Wer zum ersten Mal einen Scanner auf ein älteres Projekt loslässt, bekommt oft eine erschlagende Liste. Viele Funde sind irrelevant. Die betroffene Funktion wird nie aufgerufen, die Lücke ist in diesem Zusammenhang nicht ausnutzbar, oder es handelt sich schlicht um einen Fehlalarm. Stoppt jeder Fund den Build, schalten Teams die Prüfung bald genervt ab.

Bewährt hat sich ein gestuftes Vorgehen. Erstens: Altlasten in eine Liste übernehmen und getrennt abarbeiten, neue Funde aber sofort beachten. Zweitens: Nur schwere und gut belegte Funde dürfen den Build blockieren. Drittens: Bewusste Ausnahmen werden mit Begründung und Ablaufdatum dokumentiert. Viertens: Regeln, die nur Fehlalarme liefern, werden angepasst.

Wichtig ist auch die Form. Ein Fund sollte dort erscheinen, wo Entwickler ohnehin arbeiten, etwa als Kommentar im Merge Request. Er sollte erklären, was das Problem ist und wie man es behebt. Eine nackte Kennnummer aus einer Datenbank hilft wenig.

Kultur und Zuständigkeiten

Werkzeuge allein machen noch kein DevSecOps. Entscheidend ist, wer für einen Fund verantwortlich ist. In gut funktionierenden Teams gilt: Wer den Code schreibt, behebt auch seine Sicherheitsmängel. Das Sicherheitsteam berät, liefert Regeln und hilft bei schwierigen Fällen.

Viele Unternehmen benennen in jedem Team eine Ansprechperson für Sicherheit, oft Security Champion genannt. Sie braucht kein Expertenwissen, aber Zeit und Interesse. Kurze Schulungen zu typischen Fehlern helfen ebenfalls. Eine gute Grundlage ist die bekannte OWASP-Top-10-Liste häufiger Schwachstellen in Webanwendungen.

Auch das Bedrohungsmodell gehört dazu. Bevor eine neue Funktion entsteht, fragt das Team kurz: Was könnte ein Angreifer hier tun? Diese halbe Stunde am Whiteboard verhindert oft Fehler, die kein Scanner findet, etwa eine fehlende Berechtigungsprüfung.

Ein realistischer Einstieg

Versuchen Sie nicht, alles auf einmal einzuführen. Wählen Sie ein Projekt mit einem motivierten Team und beginnen Sie mit den drei Grundprüfungen. Messen Sie, wie lange es dauert, bis ein kritischer Fund behoben ist. Diese Zahl ist aussagekräftiger als die Menge der Funde.

Erweitern Sie dann Schritt für Schritt. Vorgefertigte Pipeline-Bausteine helfen, damit nicht jedes Team das Rad neu erfindet. Nach einigen Monaten zeigt sich, ob Sicherheit tatsächlich Teil der Routine geworden ist. Sie erkennen es daran, dass kaum noch jemand darüber spricht, weil es einfach läuft.