DevSecOps Engineer

Was macht ein DevSecOps Engineer?

Er baut Sicherheit in den Weg, den Software vom Quellcode bis in den Betrieb nimmt. Praktisch heißt das: Prüfungen in die Bereitstellungskette einhängen – statische Codeanalyse, Abhängigkeits- und Lizenzprüfung, Scans der Container-Abbilder, Prüfungen der Infrastrukturbeschreibung, Suche nach versehentlich eingecheckten Geheimnissen. Dazu kommt die Verwaltung dieser Geheimnisse selbst, die Härtung der Laufzeitumgebung, meist Kubernetes, und die Frage, wer in der Kette überhaupt etwas verändern darf.

Der zweite, oft größere Teil ist nicht technisch. Ein Befund ist erst erledigt, wenn ein Entwicklungsteam ihn behebt, und dieses Team hat eigene Termine. Die Arbeit besteht deshalb zu einem erheblichen Teil darin, Prüfungen so zu bauen, dass sie nicht im Weg stehen: wenige, gut erklärte Befunde statt tausend Warnungen, klare Regeln, wann ein Bau abbricht, und ein Weg, eine Ausnahme sauber zu genehmigen statt sie zu umgehen.

Wie wird man DevSecOps Engineer?

Über die Entwicklung oder über den Betrieb, nicht über die Sicherheit. Die Stellen setzen fast immer voraus, dass Sie vorher selbst gebaut oder betrieben haben: eine Sprache, eine Bereitstellungskette, Container, eine Cloud-Umgebung. Üblich sind ein Studium der Informatik oder der Fachinformatiker für Anwendungsentwicklung mit anschließenden Jahren in der Entwicklung oder im Plattformbetrieb. Ein Sicherheitslehrgang ohne diese Praxis reicht für diesen Beruf nicht.

Die nützlichen Nachweise sind plattformbezogen: Zertifizierungen zu Kubernetes, zu AWS oder Azure, dazu die Sicherheitsprüfungen der Anbieter. Wer den Anschluss an die Anwendungssicherheit sucht, arbeitet mit den Vorgaben und Prüflisten der OWASP; sie sind kostenlos, in der Praxis verbreitet und in Gesprächen ein besserer Beleg als ein allgemeines Managementzertifikat.

Was der Beruf verlangt

Zuerst die Bereitschaft, überzeugen zu müssen. Sie bauen Hürden in die Arbeit anderer ein und werden daran gemessen, ob diese Hürden akzeptiert werden. Wer Sicherheit als Verbotsschild versteht, wird umgangen – und zwar wirksam, weil Entwicklungsteams das technisch können. Die wiederkehrende Erfahrung ist deshalb, dass die Durchsetzung über Nützlichkeit läuft und nicht über Anweisungen.

Fachlich verlangt der Beruf, mit einer hohen Änderungsrate zu leben. Abhängigkeiten, Basisabbilder und Werkzeuge veralten in Wochen, und ein großer Teil der Arbeit ist Pflege. Dazu kommt Bereitschaftsdienst, wo die Kette selbst zum kritischen Dienst gehört. Die Arbeitszeiten sind ansonsten regulär, und dieser Beruf ist einer der wenigen, in denen überwiegend ortsunabhängig gearbeitet wird.

Aussichten

Die Nachfrage ist hoch und bleibt es, weil die Zahl der Systeme wächst und die Prüfung von Hand nicht mitkommt. Zwei Entwicklungen treiben sie zusätzlich: die Anforderungen an die Nachvollziehbarkeit von Software und ihren Bestandteilen, die inzwischen von Kunden und Regulierung verlangt wird, und die Verlagerung von Anwendungen in Cloud-Umgebungen, in denen Konfiguration und Identität die eigentlichen Angriffsflächen sind. Weiterwege führen in die Sicherheitsarchitektur, in die Plattformverantwortung und in die Leitung eines Plattform- oder Sicherheitsteams.