Was ist DevSecOps wirklich? Sicherheit als Eigenschaft des Prozesses

DevSecOps ist eines dieser Wörter, die so lange gedehnt werden, bis sie nichts mehr bedeuten. Man klebt es auf ein Produkt, eine Stellenbezeichnung oder einen einzelnen Scanner in der Pipeline. Ohne das Marketing beschreibt es etwas Einfaches und Wertvolles: Sicherheit in die Art einzubauen, wie Software entsteht, statt sie als Schranke am Ende zu behandeln.

Welches Problem es löst

Das klassische Modell ist eine Sicherheitsprüfung kurz vor dem Release: Eine Fachperson testet die fertige Anwendung, liefert einen Stapel Befunde, und das Team hetzt unter Termindruck, um sie zu beheben. Das findet echte Probleme, aber im denkbar schlechtesten Moment: dann, wenn ihre Behebung am teuersten ist und sie den Launch am ehesten verzögern. Schlimmer noch: Es ist eine Momentaufnahme. Schon am Tag nach dem Test sammelt neuer Code neue Risiken an, die niemand im Blick hat.

DevSecOps verschiebt die Prüfungen nach links, also früher in den Prozess, in den Pull Request und die Pipeline. So fallen Probleme auf, wenn sie entstehen, solange sie billig zu beheben sind und der Autor sie noch frisch im Kopf hat.

Wie es konkret aussieht

Konkret taucht Sicherheit in einem so geführten Projekt an mehreren Stellen auf, und keine davon bremst das Team aus:

• Statische Analyse (SAST) bei jeder Änderung, so abgestimmt, dass das Signal echt ist und keine Flut von Fehlalarmen entsteht, die alle zu ignorieren lernen.
• Scans von Abhängigkeiten und Lieferkette mit festgelegten Versionen, damit eine Bibliothek mit bekannter Schwachstelle gemeldet wird, bevor sie ausgeliefert wird, und nicht erst, wenn sie in den Nachrichten ist.
• Erkennung von Secrets in Code und CI, damit ein API-Schlüssel oder Passwort gar nicht erst eingecheckt wird.
• Gehärtete Build-Pipelines mit minimalen Rechten, verifizierten Abhängigkeiten und signierten Artefakten, damit die Pipeline selbst nicht das schwache Glied ist.
• Bedrohungsmodellierung für neue Funktionen, damit Risiken auf Designebene erkannt werden, bevor sie gebaut sind.
• Ein gezielter Penetrationstest vor jedem größeren Release, der auf all dem aufsetzt, statt die ganze Last allein zu tragen.

Das Schwierige sind nicht die Tools

Einen Scanner an die CI anschrauben kann jedes Team. Der Unterschied zwischen DevSecOps, das funktioniert, und DevSecOps-Theater liegt in Feinabstimmung und Kultur. Eine Pipeline, die Entwickler mit Fehlalarmen überflutet, erzieht alle dazu, den Sicherheitsschritt wegzuklicken. Das ist schlimmer als gar kein Schritt, weil nun ein falsches Sicherheitsgefühl entsteht. Die Kunst besteht darin, die Tools so zu konfigurieren, dass ihre Befunde vertrauenswürdig sind, die schnellen Prüfungen inline und die langsamen separat laufen zu lassen und die meisten Ergebnisse als Information für den Autor zu behandeln statt als harte Sperre.

Sicherheit ist dann keine einmalige Prüfung mehr, sondern eine Eigenschaft des Prozesses. Ganze Fehlerklassen fallen schon beim Merge auf, bevor irgendjemand darüber nachdenken muss.

Ersetzt es Penetrationstests?

Nein. Es verändert, wofür der Test da ist. Wenn die Routineprobleme ohnehin laufend erkannt werden, ist ein Penetrationstest keine hektische Fehlerjagd mehr, sondern das, was er sein sollte: Ein erfahrener Mensch sucht nach Fehlern in der Geschäftslogik, Lücken in der Zugriffskontrolle und kreativen Angriffsketten, die kein Scanner findet. Beides verstärkt sich gegenseitig. Kontinuierliche Prüfungen sorgen für Breite, der Mensch für Tiefe.

Wo man anfängt

Sie müssen nicht alles auf einmal einführen, und Sie sollten es auch nicht. Beginnen Sie mit den Maßnahmen mit der größten Wirkung und der geringsten Reibung: Secret-Erkennung, damit keine Zugangsdaten mehr durchsickern, und Abhängigkeitsscans, damit Sie wissen, welche verwundbaren Bibliotheken Sie ausliefern. Nehmen Sie SAST hinzu, sobald Sie es abgestimmt haben. Ergänzen Sie Bedrohungsmodellierung für neue Arbeit. Entscheidend ist die Richtung, nicht die Einführung mit einem großen Knall. Jede Prüfung, die Sie nach vorn verlagern, fängt Risiko günstiger ab.

Genau diesen Ansatz bringen wir in die Projekte ein, die wir liefern. Wenn Sicherheit etwas sein soll, das Ihr Prozess standardmäßig hervorbringt, statt etwas, das unter Termindruck angeflanscht wird, dann ist das die Arbeit, und wir helfen gern dabei, sie aufzusetzen.