5 Min. Lesezeit

---

Security am Ende der Entwicklung dranzuhängen war schon immer teuer. Jetzt wird es auch illegal. NIS2, der Cyber Resilience Act und ein wachsendes Bewusstsein für Supply-Chain-Risiken zwingen deutsche Softwareteams, Sicherheit von der ersten Codezeile an mitzudenken. DevSecOps ist der Weg dahin — aber der Kulturwandel wiegt schwerer als jedes Tool.

Das Wichtigste in Kürze

• Die NIS2-Richtlinie, deren Umsetzungsfrist im Oktober 2024 ablief und die Deutschland im Dezember 2025 in nationales Recht überführt hat, verpflichtet rund 30.000 deutsche Unternehmen zu nachweisbaren Sicherheitsmaßnahmen in der Softwareentwicklung — inklusive Supply-Chain-Security.
• Laut einer Bitkom-Erhebung setzen erst 38 Prozent der deutschen Softwareteams automatisierte Sicherheitstests in der CI/CD-Pipeline ein — bei Unternehmen über 1.000 Mitarbeitern sind es 57 Prozent.
• SAST, DAST und Software Composition Analysis (SCA) bilden das Dreieck der automatisierten Code-Sicherheit und lassen sich ohne Codeänderungen in bestehende Pipelines integrieren.
• Die Kosten eines Sicherheitsvorfalls in der Softwarelieferkette liegen laut IBM X-Force bei durchschnittlich 4,46 Millionen US-Dollar — frühzeitige Erkennung in der Pipeline senkt diesen Wert um bis zu 80 Prozent.
• Shift Left funktioniert nur, wenn Entwickler Security nicht als Bremse, sondern als Feature erleben — Tooling, Kultur und Ausbildung müssen zusammenspielen.

Die Zahlen sind eindeutig: Der Großteil aller Software-Schwachstellen lässt sich auf Fehler zurückführen, die in der Entwicklungsphase entstehen — aber erst in Produktion entdeckt werden. Eine Schwachstelle, die in der Designphase behoben wird, kostet laut IBM Systems Sciences Institute das Sechsfache weniger als eine Behebung nach dem Deployment. Trotzdem findet Security in vielen deutschen Entwicklungsteams immer noch erst am Ende des Zyklus statt — als Penetrationstest vor dem Release, als Audit vor der Zertifizierung.

DevSecOps bricht mit diesem Muster. Der Ansatz integriert Sicherheitsprüfungen direkt in die CI/CD-Pipeline: Jeder Commit wird automatisch auf bekannte Schwachstellen, unsichere Codepraktiken und verwundbare Open-Source-Dependencies geprüft. Das Ziel: Security wird Teil des Entwicklungsalltags, nicht Ausnahme vor dem Go-Live.

NIS2 und der regulatorische Druck

Die NIS2-Richtlinie, hätte bis Oktober 2024 in nationales Recht umgesetzt werden sollen — Deutschland schloss die Umsetzung im Dezember 2025 ab. Die Richtlinie erweitert den Kreis der betroffenen Unternehmen erheblich. Neben kritischer Infrastruktur fallen nun auch Unternehmen aus den Bereichen Produktion, Lebensmittel, Abfallwirtschaft, Post und Chemie unter die Regelung — insgesamt schätzt das BSI rund 30.000 betroffene Organisationen in Deutschland.

Für Softwareentwicklung relevant sind vor allem drei NIS2-Anforderungen:

Risikomanagement in der Lieferkette: Unternehmen müssen die Sicherheit ihrer Zulieferer bewerten — inklusive der Software-Zulieferer. Wer Open-Source-Bibliotheken einsetzt, ohne deren Sicherheitsstatus zu kennen, verstößt potenziell gegen die Richtlinie.

Incident Reporting: Sicherheitsvorfälle müssen innerhalb von 24 Stunden gemeldet werden. Wer keine automatisierte Erkennung in der Pipeline hat, erfährt von Schwachstellen oft erst durch den Exploit.

Nachweispflicht: Unternehmen müssen belegen können, dass sie angemessene technische Maßnahmen getroffen haben. Eine dokumentierte DevSecOps-Pipeline mit automatisierten Scans ist ein solcher Nachweis.

Parallel dazu wird der Cyber Resilience Act (CRA) der EU ab 2027 Hersteller verpflichten, Produkte mit digitalen Elementen über den gesamten Lebenszyklus sicher zu halten. Für Softwareanbieter bedeutet das: Security by Design wird zur gesetzlichen Pflicht.

Das SAST-DAST-SCA-Dreieck

Die drei Säulen der automatisierten Code-Sicherheit lassen sich in jede moderne CI/CD-Pipeline integrieren — oft innerhalb weniger Tage:

SAST (Static Application Security Testing) analysiert den Quellcode, ohne ihn auszuführen. Tools wie SonarQube, Checkmarx oder Semgrep prüfen auf bekannte Muster unsicherer Programmierung: SQL Injection, Cross-Site Scripting, hartcodierte Credentials, unsichere Kryptographie. SAST läuft idealerweise bei jedem Pull Request und gibt Entwicklern Feedback, bevor Code gemergt wird.

DAST (Dynamic Application Security Testing) testet die laufende Anwendung von außen. Tools wie OWASP ZAP oder Burp Suite simulieren Angriffe auf die deployete Applikation und finden Schwachstellen, die erst zur Laufzeit sichtbar werden — etwa fehlerhafte Authentifizierung, offene API-Endpunkte oder Server-Fehlkonfigurationen. DAST läuft typischerweise in der Staging-Umgebung als Teil der Release-Pipeline.

SCA (Software Composition Analysis) scannt die Abhängigkeiten einer Anwendung — npm-Pakete, Maven-Dependencies, Python-Libraries — auf bekannte Schwachstellen. Angesichts der Tatsache, dass moderne Anwendungen zu 80 bis 90 Prozent aus Drittanbieter-Code bestehen, ist SCA kein Nice-to-have. Tools wie Snyk, Dependabot oder Mend (ehemals WhiteSource) melden bekannte CVEs und liefern oft gleich den Patch mit.

Die Kombination aller drei Ansätze deckt den Großteil der automatisch erkennbaren Schwachstellen ab. Laut Veracode sinkt die Mean Time to Remediation (MTTR) bei Unternehmen mit integrierter Pipeline-Security um 60 Prozent gegenüber denen, die nur periodische Audits durchführen.

Praxis: Wie deutsche Teams DevSecOps umsetzen

Der Kulturwandel ist die eigentliche Herausforderung. Technik ist lösbar — aber Entwickler, die Security als Blockade erleben, werden Wege finden, die Tools zu umgehen.

„Security am Ende der Entwicklung dranzuhängen war schon immer teuer. Jetzt wird es auch illegal.“

Allianz Technology: Die IT-Tochter der Allianz hat 2024 ein Programm gestartet, das jeden Entwickler zum „Security Champion“ ausbildet. Pro Team gibt es eine Person, die als Ansprechpartner für Security-Fragen fungiert und dafür 20 Prozent ihrer Arbeitszeit freigestellt bekommt. Die Security-Champions entscheiden gemeinsam mit dem zentralen AppSec-Team, welche SAST-Regeln als „Breaking“ (Pipeline blockieren) und welche als „Warning“ (nur melden) konfiguriert werden.

SAP: Als größter europäischer Softwarehersteller betreibt SAP eine der umfangreichsten DevSecOps-Pipelines in Deutschland. Jeder Commit in die Produktcodebasis durchläuft automatisch SAST, SCA und Container-Scanning. Die Ergebnisse sind für Entwickler direkt in der IDE sichtbar — nicht erst in einem separaten Security-Dashboard. Das Prinzip: Security-Feedback muss dort ankommen, wo der Code entsteht.

Mittelstand: Viele mittelständische Softwarehäuser starten pragmatischer. Ein verbreiteter Ansatz: SCA als erstes Tool einführen (Aufwand: ein Tag), dann SAST in der Pipeline aktivieren (eine Woche) und DAST für kritische Anwendungen nachrüsten (zwei bis vier Wochen). Die Open-Source-Variante — SonarQube Community, OWASP ZAP, Trivy — kostet kein Budget, nur Implementierungszeit.

Was bleibt: Kultur frisst Tooling

Die Erfahrung zeigt: Unternehmen, die DevSecOps rein über Tooling einführen, scheitern häufiger als solche, die den kulturellen Wandel priorisieren. Drei Prinzipien haben sich bewährt:

Entwickler nicht bestrafen: Wenn die Security-Pipeline einen Build blockt, muss das Feedback konstruktiv sein. Der Entwickler braucht den Kontext — was ist das Risiko, wie ist der Fix, warum ist das wichtig. Tools, die nur „Critical Finding“ ausgeben, ohne Erklärung und Fix-Vorschlag, erzeugen Frustration statt Sicherheit.

Schwellenwerte schrittweise verschärfen: Am Anfang nur Critical und High Findings als Pipeline-Blocker konfigurieren. Medium und Low als Warnings behandeln und in einem separaten Backlog tracken. Erst wenn die Teams Routine haben, die Schwellenwerte anziehen.

Security sichtbar machen: Dashboards, die zeigen, wie sich die Schwachstellenzahl über die Zeit entwickelt, wie schnell Findings behoben werden und welche Teams besonders gut performen. Positive Reinforcement funktioniert besser als Compliance-Druck.

DevSecOps ist kein Zustand, den man erreicht, sondern ein Prozess, der reift. Die Unternehmen, die jetzt starten, haben einen Vorsprung — nicht nur regulatorisch, sondern auch in der Qualität ihres Codes.

Häufige Fragen

Was ist der Unterschied zwischen DevOps und DevSecOps?

DevOps integriert Entwicklung und Betrieb in einen kontinuierlichen Prozess. DevSecOps erweitert diesen Ansatz um Security als gleichberechtigte Dimension — Sicherheitsprüfungen werden nicht nachgelagert, sondern in jeden Schritt der Pipeline integriert.

Müssen alle Unternehmen NIS2 umsetzen?

NIS2 betrifft Unternehmen ab 50 Mitarbeitern oder 10 Millionen Euro Umsatz in 18 definierten Sektoren. Auch kleinere Unternehmen können betroffen sein, wenn sie als Zulieferer kritischer Infrastruktur gelten. Eine Prüfung gegen die Sektorenliste des BSI ist empfehlenswert.

Was kostet die Einführung von DevSecOps?

Die Open-Source-Variante (SonarQube Community, OWASP ZAP, Trivy, Dependabot) verursacht keine Lizenzkosten — nur Implementierungsaufwand. Kommerzielle Plattformen wie Snyk, Checkmarx oder Veracode starten bei circa 10.000 Euro pro Jahr für kleine Teams. Der ROI ergibt sich aus reduzierten Incident-Kosten und beschleunigten Release-Zyklen.

Weiterführende Lektüre

• Cloud-Fachkräfte: Warum Deutschland beim Upskilling aufholt — cloudmagazin
• SaaS-Konsolidierung: Wie CIOs den Tool-Wildwuchs stoppen — cloudmagazin
• Edge Computing und Industrie 4.0 — cloudmagazin

Mehr aus dem MBF Media Netzwerk

• KI Made in Germany: 935 Startups — MyBusinessFuture
• EU AI Act 2026: Was Unternehmen umsetzen müssen — Digital Chiefs
• Cybersecurity-Trends 2026 — SecurityToday

Quelle des Titelbildes: Pexels / Tima Miroshnichenko