Was macht ein DevSecOps Engineer?

Warum DevSecOps heute so relevant ist

Continuous Delivery, Public Cloud und Microservices erhöhen Tempo und Angriffsfläche zugleich. Organisationen reagieren, indem sie Security nicht mehr als „letzten Gatekeeper“, sondern als durchgängigen Teil des Software-Lebenszyklus denken. Genau hier setzt die Rolle des DevSecOps Engineers an: Sie verankert Security in der täglichen Delivery-Praxis – von der Pipeline bis zur Produktion.

Aktuelle Branchenbefunde unterstreichen die Dynamik: Laut dem 2024 Global DevSecOps Report von GitLab priorisieren Unternehmen Investitionen in Security, AI und Automatisierung. 67% der Befragten geben an, dass ihr Software Development Lifecycle weitgehend automatisiert ist. Gleichzeitig arbeitet Entwicklung massiv mit Open-Source-Komponenten, während bislang nur ein Teil der Organisationen durchgängig Software-Stücklisten (SBOM) nutzt – ein klares Signal, dass Supply-Chain-Risiken weiter aktiv gemanagt werden müssen. In regulierten Branchen bleibt Security laut Report die Top-Priorität. Diese Trends definieren die Erwartungshaltung an DevSecOps-Profile.

Kernaufgaben eines DevSecOps Engineers

Die Rolle kombiniert drei Perspektiven: Sicherheit denken (Risiken priorisieren), Sicherheit bauen (Kontrollen implementieren) und Sicherheit betreiben (Signale deuten, Prozesse verbessern). In der Praxis drehen sich viele Aufgaben um die CI/CD-Pipeline, die Infrastruktur und die Kollaboration mit Entwicklungsteams.

Sicherheit in CI/CD implementieren

DevSecOps Engineers integrieren Security-Checks in Build- und Deployment-Stufen. Typischerweise gehören dazu:

• SAST: statische Codeanalyse zur frühzeitigen Erkennung von Schwachstellen.
• DAST: dynamische Tests gegen laufende Anwendungen.
• SCA: Analyse von Abhängigkeiten und Lizenzen in Drittbibliotheken.
• IAST: instrumentierte Laufzeitanalyse während Tests.

Ziel ist nicht „Scannen um des Scannens willen“, sondern ein Pipeline-Design, das relevante Findings früh sichtbar macht, ohne die Developer Experience dauerhaft zu verschlechtern. DevSecOps Engineers stimmen Schwellwerte, Break-the-Build-Kriterien und Ausnahmen eng mit den Teams ab.

Infrastruktur- und Container-Security

Moderne Workloads laufen in Containern und Cloud-Services. Häufige Maßnahmen sind zum Beispiel:

• IaC-Scanning (Infrastructure as Code), um Fehlkonfigurationen vor dem Provisioning zu finden.
• Container-Image-Scans in Build und Registry; je nach Umgebung ergänzt um Richtlinien für Basis-Images oder Prüfungen der Artefakt-Integrität.
• Konfigurationsprüfungen und – wo sinnvoll – die Auswertung von Laufzeit-Signalen in Orchestrierungsumgebungen.

Secrets- und Konfigurationsmanagement

Ein zentrales Problem in Pipelines sind exponierte Zugangsdaten. DevSecOps Engineers sorgen für Secret-Scanning im Code, bewährte Rotations- und Kurzlebigkeits-Policies sowie die Integration von Secrets-Managern in Build- und Deploy-Prozesse.

Automatisierung, Rule-Tuning und False-Positive-Management

Berichte wie der „State of DevSecOps 2024“ von Datadog zeigen: Viele Unternehmen nutzen Automatisierung noch nicht durchgängig. Für DevSecOps-Teams heißt das, Automatisierung gezielt auszubauen – und ebenso wichtig: Rauschen reduzieren. Dazu gehören Regel-Tuning in Scannern, sinnvolle Baselines, Priorisierung nach Risiko und die Entlastung der Teams durch Workflows, die nur dort blockieren, wo es fachlich geboten ist.

Threat Modeling und Risikopriorisierung

Threat Modeling verlagert Sicherheit nach links („Shift Left“). DevSecOps Engineers moderieren Modellierungs-Workshops, übersetzen Erkenntnisse in konkrete Kontrollen (z. B. zusätzliche Tests, Härtung, Logging) und helfen Teams, technische mit geschäftlicher Priorität zu verknüpfen.

Tools und Technologien: Was Arbeitgeber erwarten

In Stellenausschreibungen werden oft spezifische Produkte genannt; wichtiger ist, die Toolklassen und ihre Einbettung zu verstehen.

• Code- und App-Security: SAST, DAST, IAST, SCA; linters und sichere Build-Konfigurationen.
• IaC- und Cloud-Security: IaC-Scanner, Policies für Cloud-Konfigurationen, Container- und Registry-Scans.
• Secrets-Management: Scanner, Secret-Stores, Policies zur Schlüsselrotation.
• Observability und Incident-Fluss: Logs, Metriken und Alarme, die Security-relevante Signale in Entwicklungs-Workflows zurückspiegeln.

Als vertiefende, herstellerunabhängige Ressource empfiehlt sich das OWASP-DevSecOps-Kapitel. Es bündelt gängige Aktivitäten und zeigt, wie Sicherheitsprüfungen in Pipelines verankert werden können. Ein guter Startpunkt ist das OWASP Developer Guide Kapitel zu DevSecOps: OWASP DevSecOps Guideline.

Wie DevSecOps im Unternehmen funktioniert

Die Rolle ist anschlussfähig an mehrere Teams – und genau darin liegt ihre Wirkung.

Schnittstellen und Verantwortlichkeiten

• Entwicklung: Beratung zu sicheren Defaults, Review von Findings, Pairing beim Beheben wiederkehrender Muster, Enablement von Security Champions.
• Plattform/Cloud-Ops: Policies in Kubernetes/Cloud, Härtungsstandards und Automatisierung von Sicherheitskontrollen in Infrastruktur.
• Security/CSIRT: Priorisierung von Findings, Reaktion auf Vorfälle, Abgleich mit Compliance-Anforderungen.

Organisatorische Modelle

• Zentralisierte DevSecOps-Teams stellen Plattformbausteine, Standards und Self-Service-Guardrails bereit.
• Eingebettete Rollen („embedded“) arbeiten direkt mit Produktteams und priorisieren gemeinsam. In hybriden Modellen liefern zentrale Teams die Plattform, eingebettete Rollen sorgen für Adoption und Feedback.

Kultur und Prozesse

„Shift Left“ gelingt nur, wenn Security nicht als Hindernis wahrgenommen wird. Das bedeutet: verständliche Policies, transparente Metriken (z. B. Zeit bis Fix, Anteil blockierender Findings) und eine geteilte Verantwortung zwischen Entwicklung, Plattform und Security. Studien wie die SANS-DevSecOps-Surveys betonen den kulturellen Aspekt – wer Kommunikation und Zusammenarbeit systematisch verbessert, kann messbare Sicherheitsgewinne erzielen.

Typische Anforderungen und Skills – Bewerber:innenfokus

Jedes Unternehmen gewichtet anders; folgende Kompetenzfelder sind jedoch breit gefragt.

Hard Skills

• Scripting/Programmierung: Mindestens eine Sprache (z. B. Python, Go, Bash) für Pipeline-Logik, Tools und kleine Automatisierungen.
• CI/CD-Praxis: Branch-Strategien, Build/Release-Patterns, Artefaktmanagement und der sichere Umgang mit Credentials in Pipelines.
• Scanning-Fundamentals: Verständnis für SAST/DAST/SCA/IAST, Metriken, False-Positive-Handling und Break/Alert-Strategien.
• Cloud- und Container-Grundlagen: Kubernetes-Basics, Registry- und Image-Härtung, IaC-Patterns und Konfigurationsrichtlinien.

Soft Skills

• Kommunikation: Findings so erklären, dass Teams Entscheidungen treffen können – inklusive Trade-offs.
• Priorisierung: Technische Scores mit Business-Kontext verheiraten; nicht jedes High ist ein Blocker.
• Enablement: Security-Champions-Programme mitgestalten, Onboarding-Materialien verbessern, Routinen etablieren.

Erwartete Erfahrungslevels (Beispiele)

• Junior: führt und betreut einzelne Scanner in der Pipeline, arbeitet an Dokumentation und unterstützt bei Ticket-Triage.
• Professional/Medior: verantwortet eine oder mehrere Produktlinien, optimiert Regeln, etabliert IaC-/Container-Scans und leitet kleinere Threat-Modeling-Sessions.
• Senior: designt unternehmensweit wiederverwendbare Controls als Plattformbausteine, definiert Metriken und koordiniert übergreifende Verbesserungsprogramme.

Alltag, Herausforderungen und realistische Trade-offs

Wer als DevSecOps Engineer arbeitet, wird schnell merken: Sicherheit ist ein Produkt, kein Projekt. Drei typische Spannungsfelder prägen den Alltag.

• Automatisierung vs. manuelle Reviews: Nicht alles lässt sich sinnvoll automatisieren. Der Mehrwert liegt darin, Routinearbeit zu automatisieren und Hochrisikofälle gezielt manuell zu bewerten.
• Rauschen vs. Relevanz: Scanner liefern viele Findings. Effektives Rule-Tuning, Baselines und eine klare Policy, wann Builds brechen, halten Teams arbeitsfähig und verbessern die Akzeptanz.
• Risiko-Score vs. Business-Impact: Ein technisches „High“ hat nicht automatisch höchsten geschäftlichen Schaden. Ein guter DevSecOps Engineer übersetzt Scores in Konsequenzen für Verfügbarkeit, Daten und Compliance und empfiehlt entsprechend priorisierte Maßnahmen.

Konkrete Bewerbungstipps: So richten Sie Ihr Profil aus

Ein guter Lebenslauf zeigt, dass Sie Security in Delivery-Prozessen wirksam gemacht haben – messbar und nachvollziehbar.

Lebenslauf und Portfolio

• Projekte beschreiben: Nennen Sie konkrete Pipelines, Services oder Produktlinien und Ihren Anteil daran.
• Ergebnisse quantifizieren: Beispielhaft „False-Positive-Rate von SAST-Regeln um X% gesenkt“ oder „Zeit bis zum Fix für kritische Abhängigkeiten von Y auf Z Tage reduziert“. Wenn Sie keine exakten Zahlen nennen können, beschreiben Sie Prozessverbesserungen präzise (z. B. neue Break/Alert-Policy, Einführung eines Secrets-Scans pro Commit).
• Artefakte verlinken: Policy-Beispiele, Skripte, IaC-Module oder Demos in einem neutralen, unternehmenskonformen Rahmen (keine vertraulichen Details!).

Gesprächsvorbereitung

Rechnen Sie mit Fragen zu:

• Pipeline-Design: Wo platzieren Sie SAST/DAST/SCA? Wann brechen Sie Builds, wann nur warnen?
• Rauschen und Regelpflege: Wie identifizieren Sie systematische False Positives und verbessern Regeln?
• Secrets: Wie integrieren Sie Secret-Scanning und -Rotation in CI/CD?
• Zusammenarbeit: Beispiel für ein Threat-Modeling, das technische Maßnahmen in Roadmaps übersetzt hat.

Üben Sie, ein reales Beispiel Ende-zu-Ende zu erklären: Ausgangslage, gewählte Kontrollen, Trade-offs, Ergebnis.

Weiter lernen: sinnvolle Ressourcen

• OWASP DevSecOps Guideline (Developer Guide): Überblick über gängige Sicherheitsaktivitäten in Pipelines und deren Einbettung in den SDLC. Startpunkt: OWASP DevSecOps Guideline
• Aktuelle Branchentrends: Der GitLab 2024 Global DevSecOps Report liefert Zahlen zu Automatisierung, Toolchain-Konsolidierung und Supply-Chain-Security und hilft, Prioritäten einzuordnen: GitLab 2024 Global DevSecOps Report
• Operative Realität: Presseinfos und Analysen wie Datadogs „State of DevSecOps 2024“ benennen u. a. die unvollständige Automatisierung; der Umgang mit Scanner-Rauschen ist darüber hinaus eine verbreitete Praxis-Hürde in vielen Teams: Datadog State of DevSecOps 2024

Deutschland-Perspektive: Erwartungen und Rahmenbedingungen

Im deutschen Umfeld sind regulierte Branchen häufig vertreten (z. B. Finanzdienstleistungen, öffentliche Verwaltung). Für Bewerber:innen bedeutet das: Erfahrungen mit auditierbaren Prozessen, nachvollziehbaren Metriken und reproduzierbaren Pipelines sind Pluspunkte. Ebenso zählt die Fähigkeit, Security-Policies so zu operationalisieren, dass sie in Teams akzeptiert und gelebt werden.

Remote- und Hybrid-Setups kommen je nach Arbeitgeber vor; zugleich bleibt die enge Abstimmung mit Entwicklungsteams entscheidend. Wer in cross-funktionalen Settings moderieren kann – etwa bei der Einführung von Guardrails in Plattformen oder beim Etablieren von Security-Champions – erhöht seinen Wirkungsradius deutlich.

Ausblick: Wohin sich die Rolle entwickelt

Drei Signale sind derzeit besonders sichtbar:

• Mehr Automatisierung in der Sicherheitskette: Von IaC-Policies über geprüfte Artefakte bis zu automatisierten Remediation-Vorschlägen.
• Toolchain-Konsolidierung: Viele Teams wollen weniger Brüche in der Toolkette – Plattform-Ansätze und integrierte DevSecOps-Lösungen stehen verstärkt im Fokus im Kontext dieser Konsolidierung.
• Supply-Chain-Security rückt weiter nach vorn: Open-Source-Anteile bleiben hoch; Transparenz über Komponenten und Prozesse rückt stärker in den Fokus – viele Organisationen stehen jedoch bei SBOMs noch am Anfang.

Für die Rolle heißt das: Wer sowohl Plattform-Denken (Security als Produkt) als auch Team-Enablement (Security als gemeinsame Praxis) beherrscht, bleibt gefragt.

Fazit für Bewerber:innen

Was macht ein DevSecOps Engineer? Kurz gesagt: Sie oder er sorgt dafür, dass Sicherheit in den Softwarefluss eingebaut, gemessen und kontinuierlich verbessert wird – ohne die Lieferfähigkeit zu opfern. Erfolg zeigt sich nicht an der Zahl der Scanner, sondern daran, wie reibungslos Risiken sichtbar werden, wie zielgerichtet Teams handeln können und wie stabil die Sicherheitspraktiken den Alltag überdauern. Richten Sie Ihre Bewerbung auf genau diese Wirkung aus: nachvollziehbare Prozesse, kluges Regel-Design, messbare Verbesserungen – und die Fähigkeit, zusammen mit Entwicklung, Plattform und Security tragfähige Entscheidungen zu treffen.