In den meisten Organisationen ist Sicherheit weiterhin ein Tor am Ende des Wegs: Ein Team baut wochenlang ein Produkt und stößt dann auf ein Audit vor dem Release, das alles um mehrere Sprints zurückwerfen kann. Für einen CISO oder Head of Security ist das ein täglicher Konflikt, denn je später Sie eine Schwachstelle finden, desto teurer wird ihre Behebung. DevSecOps dreht die Reihenfolge um: Sicherheit hört auf, eine nachträgliche Prüfung zu sein, und wird zu einer Eigenschaft des Delivery-Prozesses selbst.
Aus unserer Erfahrung ist der schwierige Teil nicht der Kauf eines weiteren Scanners, sondern Kontrollen so in den Rhythmus des Teams zu weben, dass sie niemanden bremsen. Wir haben in sicherheitskritischen Systemen und Domänen mit hohen Anforderungen geliefert, darunter im Bankensektor, wo Compliance und Datenschutz nicht optional sind. Diese Kompetenz bringen wir in Delivery-Teams ein, indem wir die meist fehlenden Rollen besetzen: DevSecOps-Engineers, Identity-Spezialisten und Security-Architekten.
Warum muss Sicherheit im gesamten Delivery-Zyklus verankert sein?
Weil Bedrohungen nicht auf den Release-Tag warten. Eine verwundbare Bibliothek kommt in dem Moment ins Repository, in dem ein Entwickler die Abhängigkeit hinzufügt, und nicht im Moment des Audits. Ist die einzige Kontrolle ein Review am Ende, baut das Team einen ganzen Sprint lang auf wackligem Grund, und jede Korrektur bedeutet, bereits fertigen Code noch einmal zu überarbeiten.
Sicherheit über den ganzen Zyklus zu verankern verändert die Ökonomie eines Fehlers. Eine im Pull Request gefundene Schwachstelle kostet einen Entwickler ein paar Minuten; dieselbe Schwachstelle in der Produktion ist ein Vorfall, eine Meldung an den Regulator und Überstunden für das ganze Team. DevSecOps fügt keine Stufe hinzu, es verteilt die Kontrolle auf viele kleine Prüfpunkte entlang des Wegs - vom Commit über den Build bis zum Deployment. Sicherheit konkurriert dann nicht mehr mit dem Termin, sondern schützt ihn.
Wie steuern Sie Identitäten und Zugriffe (IAM) im Delivery-Zyklus?
Die Identitätsverwaltung ist das Fundament, denn die meisten schweren Vorfälle beginnen mit übermäßigen oder kompromittierten Zugriffen. In der Praxis achten wir auf einiges:
- minimale Rechte für Menschen wie für Dienste, keine Vollzugriffskonten „für alle Fälle”,
- Maschinenidentitäten (Service-Konten, Workload Identity), ebenso ernst genommen wie menschliche,
- kurzlebige Zugangsdaten und Rotation statt dauerhaft eingefügter statischer Schlüssel,
- zentrale Authentifizierung (SSO, MFA) mit klarem Audit Trail darüber, wer wann Zugriff hatte.
Ein gut aufgebautes IAM führt dazu, dass selbst ein erfolgreicher Phishing-Versuch einem Angreifer nicht die ganze Umgebung öffnet, sondern nur einen engen, zeitlich begrenzten Ausschnitt.
Wie scannen Sie Abhängigkeiten und Schwachstellen, bevor sie in die Produktion gelangen?
Eine moderne Anwendung besteht zu großen Teilen aus fremdem Code, deshalb zählt die Kontrolle der Abhängigkeiten ebenso viel wie die des eigenen Codes. Wir verdrahten mehrere Scan-Schichten in die Pipeline:
- SCA (Software Composition Analysis), um verwundbare Open-Source-Bibliotheken zu erkennen,
- SAST für die statische Analyse des eigenen Codes auf verbreitete Sicherheitsfehler,
- DAST, um die laufende Anwendung aus der Sicht eines Angreifers zu testen,
- Container- und IaC-Scans auf bekannte CVEs und Fehlkonfiguration.
Entscheidend ist nicht das Scannen selbst, sondern die Schwellen, die den Build bei kritischen Funden anhalten, dazu ein vernünftiger Umgang mit den weniger dringenden, damit das Team nicht im Alarmrauschen ertrinkt.
Wie verwalten Sie Secrets in CI/CD-Pipelines?
Bei Secrets weicht die Praxis am häufigsten von der Theorie ab. Passwörter, Token und API-Schlüssel landen in Umgebungsvariablen, Konfigurationsdateien und im schlimmsten Fall direkt im Repository, von wo sie für immer in der Git-Historie leben. Jedes solche Secret ist ein fertiger Schlüssel für jeden Angreifer, der an den Code kommt.
Deshalb holen wir Secrets aus dem Code in einen eigenen Speicher (etwa Vault oder einen Secrets Manager in der Cloud) und geben sie der Pipeline nur für die Dauer eines konkreten Jobs frei. Dazu ergänzen wir Scans des Repositorys auf durchgesickerte Zugangsdaten und automatische Rotation, damit selbst ein offengelegtes Token schnell an Wert verliert. Es ist eine unglamouröse Schicht von DevSecOps, aber auf ihr ruht die Glaubwürdigkeit alles Übrigen.
Wie führen Sie ein Security-Review von CI/CD-Pipelines durch?
Die Pipeline selbst ist oft das höchstprivilegierte System im Unternehmen, denn sie hat Zugriff auf Code, Secrets und Produktion. Deshalb behandeln wir sie als Angriffsziel und prüfen:
- Rechte von Runnern und Agenten sowie die Isolation der Builds voneinander,
- Integrität der Artefakte - Signieren und Prüfen dessen, was wir tatsächlich ausliefern,
- Herkunft der Abhängigkeiten und vertrauenswürdige Registries statt Bezug „von irgendwo”,
- Funktionstrennung, damit eine einzelne Person keine Änderung still in die Produktion bringen kann.
Ein solches Review schließt den Weg, den Angreifer zunehmend bevorzugen: Statt die Anwendung anzugreifen, greifen sie die Art an, wie sie gebaut wird.
Was bedeutet Shift-Left und wie bauen Sie eine Sicherheitskultur auf?
Shift-Left heißt, Sicherheitskontrollen so nah wie möglich an den Moment zu rücken, in dem Code entsteht - in die IDE, den Pull Request, den ersten Build. Es geht darum, dass eine Entwicklerin von einer Schwachstelle erfährt, solange sie noch weiß, was sie geschrieben hat und warum, und nicht drei Wochen später von einem separaten Team.
Werkzeuge sind allerdings nur die halbe Gleichung. Die andere Hälfte ist eine Kultur, in der Sicherheit gemeinsame Verantwortung ist und nicht die Abteilung der anderen. Wir bauen sie in kleinen Schritten auf: klare Leitlinien in Pull Requests, Security Champions in den Teams, kurze schuldfreie Retrospektiven nach Vorfällen. Technik fängt bekannte Fehler ab, aber die Menschen entscheiden, ob Sicherheit ernst genommen oder nur abgehakt wird.
Welche DevSecOps-Kompetenzen stellen wir?
Wir formen das Team um die echte Lücke in der Organisation des Kunden, nicht um einen fertigen Katalog. Am häufigsten besetzen wir diese Rollen:
- einen DevSecOps-Engineer, der Scans, Secrets und Sicherheitsschwellen in CI/CD verdrahtet,
- einen IAM- bzw. Identity-Spezialisten, der menschliche und Dienstzugriffe ordnet,
- einen Security-Architekten, der Bedrohungsmodell und Standards für die Teams setzt,
- einen Platform- bzw. Cloud-Engineer, der Laufzeitumgebungen und Infrastructure as Code härtet.
Dieser Aufbau verstärkt ein bestehendes Team genau dort, wo ihm Hände oder Know-how fehlen, ohne eine eigene Sicherheitsabteilung von null aufzustellen.
Individualsoftware oder Team-Verstärkung - was passt zu DevSecOps?
Das hängt davon ab, ob Sie etwas Neues bauen oder einen bestehenden Prozess härten. Für ein neues Produkt eignet sich ein Individualsoftware-Projekt gut, mit Sicherheit als Anforderung vom ersten Tag der Architektur an. Für einen gereiften Delivery-Zyklus brauchen Sie häufiger Team-Verstärkung oder ein dediziertes Team - Menschen, die in Ihre Pipelines einsteigen und deren Widerstandsfähigkeit erhöhen, ohne die ganze Organisation umzubauen. Die Unterschiede zwischen diesen Ansätzen haben wir in unserem Artikel zu IT-Kooperationsmodellen dargelegt.
Wie machen wir das bei RITS?
Wir tun das als Nearshore-Partner aus Polen, mit echter Erfahrung in sicherheitskritischen Systemen:
- wir bringen Kompetenz ein, die unter anderem in Projekten für den Bankensektor entstanden ist, wo Datenschutz und Compliance harte Randbedingungen sind,
- wir prüfen die Kompetenzen vor dem Start und formen das Team um die konkrete Lücke, nicht „auf Vorrat”,
- wir ziehen Sicherheit durch den gesamten Zyklus - von IAM und Secrets bis zu Scans und Pipeline-Review,
- wir arbeiten in einer nahen Zeitzone, sodass unsere Spezialisten ohne langen Anlauf in Ihre Code Reviews und Ihren Arbeitsrhythmus einsteigen.
Am häufigsten tun wir das als Team-Verstärkung, wenn eine DevSecOps-Lücke schnell zu schließen ist, oder als Individualsoftware, wenn wir Sicherheit von Grund auf mit entwerfen.
Womit beginnen Sie bei DevSecOps?
Beginnen Sie damit, einen einzelnen, wichtigsten Ablauf zu kartieren: vom Commit bis in die Produktion, mit Markierung der Stellen, an denen es heute keine Kontrolle gibt. Das zeigt die am günstigsten zu schließenden Lücken - meist Secrets im Code und fehlende Scans der Abhängigkeiten - und weist auf die Rollen hin, die Sie zuerst brauchen. Machen Sie nicht alles auf einmal; bauen Sie eine Kontrolle ein, bestätigen Sie, dass sie das Team nicht bremst, und ergänzen Sie die nächste.
Wollen Sie DevSecOps in Ihrem Delivery-Zyklus verankern? Sprechen wir darüber - wir stimmen Spezialisten und eine Schrittfolge auf Ihren Prozess ab.