NIS2 Sichere Entwicklung: Wie Unternehmen Anhang 6 der CIR 2024/2690 in ihren SDLC integrieren

Viele Unternehmen behandeln NIS2-Konformität als Sammlung isolierter Projekte – ein Risikomanagementrahmen hier, ein Incident-Response-Plan dort. Abschnitt 6 des Anhangs zur Durchführungsverordnung (EU) 2024/2690 macht diesen Ansatz falsch: Die Verordnung betrachtet den gesamten IKT-Lebenszyklus als eine regulatorische Einheit, von der Beschaffungsentscheidung (6.1) über den Entwicklungsprozess (6.2) bis zur Patch-Verwaltung (6.6). Wer diese Einheit zerrstückelt, riskiert Compliance-Lücken, die erst beim BSI-Audit sichtbar werden.

Dieser Leitfaden zeigt, welche konkreten Maßnahmen Abschnitt 6 verlangt, wie BSI IT-Grundschutz (CON.8, APP.7) und BSI TR-03185 als Umsetzungsrahmen dienen, und welche sieben Nachweise Prüfer für Abschnitt 6 verlangen werden.

Dieser Artikel dient der allgemeinen Information und stellt keine Rechts- oder Compliance-Beratung dar. Anforderungen variieren je nach Einrichtungstyp, Sektor und nationalem Umsetzungsrecht. Konsultieren Sie für Ihren konkreten Fall einen qualifizierten Rechts- oder Compliance-Experten.

Rechtlicher Rahmen: Wer muss Abschnitt 6 umsetzen?

Artikel 21 Absatz 2 Buchstabe e der NIS2-Richtlinie (EU) 2022/2555 verpflichtet wesentliche und wichtige Einrichtungen, Sicherheit in der Beschaffung, Entwicklung und Wartung von Netz- und Informationssystemen zu gewährleisten – einschließlich des Umgangs mit Schwachstellen und ihrer Offenlegung. Die Durchführungsverordnung (EU) 2024/2690 (CIR 2024/2690) konkretisiert diese Vorgabe technisch für eine klar abgegrenzte Gruppe von Einrichtungen.

Wer ist direkt durch CIR 2024/2690 gebunden?

CIR 2024/2690 gilt unmittelbar für Anbieter digitaler Infrastrukturen und digitaler Dienste: DNS-Diensteanbieter, TLD-Registrierungsstellen, Cloud-Computing-Anbieter, Rechenzentrumsbetreiber, Content Delivery Networks (CDN), Managed-Service-Provider (MSP), Managed-Security-Service-Provider (MSSP), Online-Marktplätze, Online-Suchmaschinen, Plattformen sozialer Netzwerke und Vertrauensdiensteanbieter [6].

Alle anderen wesentlichen und wichtigen Einrichtungen – Energieversorger, Krankenhäuser, Wasserversorger, Finanzinstitute, Verkehrsunternehmen – unterliegen Artikel 21 Absatz 2 Buchstabe e NIS2 und § 30 NIS2UmsuCG (in Kraft seit 6. Dezember 2025), ohne dass CIR 2024/2690 für sie rechtsverbindlich ist. Das BSI empfiehlt diesen Einrichtungen, Abschnitt 6 als technischen Orientierungsrahmen zu nutzen, da er den aktuellen Stand der Technik widerspiegelt.

Abschnitt 6 im Überblick – zehn Unterabschnitte

Abschnitt 6 gliedert sich in zehn Unterabschnitte, die den gesamten IKT-Lebenszyklus abdecken [2]:

6.1 Sicherheit in der IKT-Beschaffung
6.2 Sicherer Entwicklungszyklus
6.3 Konfigurationsmanagement
6.4 Änderungsmanagement und Wartung
6.5 Sicherheitstests
6.6 Patch-Management
6.7 Netzwerksicherheit
6.8 Netzwerksegmentierung
6.9 Schutz vor Schadsoftware
6.10 Schwachstellenmanagement und -offenlegung

Dieser Leitfaden behandelt schwerpunktmäßig 6.1 bis 6.6 – die Unterabschnitte, die den Lebenszyklus von der Beschaffungsentscheidung bis zur Wartung abdecken. Einen vollständigen Überblick über die Verordnung bietet unser Leitfaden zur NIS2-Durchführungsverordnung. Die zehn Risikomanagementmaßnahmen nach Artikel 21, darunter Maßnahme (e) zur Beschaffungs- und Entwicklungssicherheit, erläutert unser Artikel zu den NIS2-Anforderungen.

Abschnitt 6.1 – Sicherheit in der IKT-Beschaffung

Bevor eine Einrichtung ein IKT-Produkt erwirbt oder einen IKT-Dienst beauftragt, muss sie risikobasierte Beschaffungsprozesse implementieren. Die Grundannahme: Viele Sicherheitslücken entstehen nicht intern, sondern werden durch unsichere Drittkomponenten eingeschleppt. Abschnitt 6.1 soll diesen Einfallsweg an der Quelle schließen [2].

Erstens müssen Sicherheitsanforderungen vor der Beschaffungsentscheidung definiert und vertraglich verankert werden. Das schließt Anforderungen an Sicherheitsupdates über die gesamte Produktlebensdauer ein – nicht nur zum Zeitpunkt der Lieferung. Die entscheidende Prüffrage lautet: Wie lange liefert der Anbieter Sicherheits-Patches? Was geschieht beim End-of-Life?

Zweitens fordert 6.1 eine Dokumentation der Hardware- und Softwarekomponenten der beschafften Systeme – die regulatorische Grundlage für Software-Bill-of-Materials-Anforderungen (SBOM), auf die wir im Abschnitt zu DevSecOps zurückkommen. Drittens müssen gelieferte Produkte validiert werden: Entsprechen sie tatsächlich den vereinbarten Sicherheitsanforderungen? Eine Zusicherung des Anbieters allein genügt nicht [2].

Beschaffungsprozesse müssen in geplanten Zeitabständen überprüft und aktualisiert werden. Anbieter, die heute sichere Produkte liefern, tun dies nicht zwangsläufig in drei Jahren – das Risikobild ändert sich. Eine jährliche Überprüfung kritischer Lieferantenbeziehungen entspricht dem Stand der Praxis.

Abschnitt 6.2 – Sicherer Entwicklungszyklus: Die fünf Pflichtmaßnahmen

Abschnitt 6.2 ist der regulatorische Kern der sicheren Entwicklung nach NIS2. Die Vorgabe: Vor Entwicklungsbeginn müssen Sicherheitsvorschriften festgelegt und konsequent angewendet werden – unabhängig davon, ob intern oder durch externe Dienstleister entwickelt wird [1].

6.2.1 – Sicherheitsvorschriften für alle Entwicklungsphasen

Die Sicherheitsvorschriften müssen alle Phasen abdecken: Spezifikation, Konzeption, Entwicklung, Umsetzung und Tests. Das ist keine Methodik-Vorgabe – Wasserfall, Agile und DevOps sind alle konform – sondern eine Prozessanforderung: In jeder Phase muss Sicherheit explizit adressiert sein und dokumentiert werden [1].

6.2.2 – Die fünf Pflichtmaßnahmen im Detail

Fünf Maßnahmen sind in Abschnitt 6.2.2 verbindlich vorgeschrieben [1]:

Sicherheitsanalyse in der Spezifikations- und Entwurfsphase: Sicherheitsanforderungen müssen vor der eigentlichen Entwicklung ermittelt werden – nicht als nachträglicher Audit-Punkt. Werkzeuge wie Threat Modeling (nach STRIDE oder PASTA) machen in dieser Phase sichtbar, welche Angriffsflächen eine geplante Systemarchitektur eröffnet und wo kritische Abhängigkeiten entstehen. Ein Threat Model, das vor dem ersten Code-Commit fertig ist, kostet einen Bruchteil dessen, was eine Schwachstelle nach dem Deployment kostet.
Secure-by-Design und Zero-Trust-Architekturen: CIR 2024/2690 benennt zwei Prinzipien explizit: konzeptintegrierte Cybersicherheit (Secure-by-Design) und Null-Vertrauen-Architekturen (Zero Trust). Zero Trust bedeutet: Kein System, kein Nutzer, keine Komponente erhält automatisch Vertrauen – jede Verbindung wird authentifiziert und autorisiert, unabhängig vom Netzwerksegment oder Standort. Dieser Ansatz ersetzt die überholte Perimeter-Annahme, dass alles innerhalb des Unternehmensnetzes sicher sei.
Sicherheitsanforderungen an Entwicklungsumgebungen: Entwicklungsumgebungen sind ein häufig übersehener Einstiegspunkt für Angreifer. Kompromittierte Build-Systeme oder Code-Repositories können Schadcode in die Produktionssoftware einschleusen, ohne dass der Entwickler es bemerkt (Supply-Chain-Angriff). 6.2.2 verlangt, dass Sicherheitsanforderungen für Entwicklungsumgebungen explizit definiert werden: isolierte Build-Systeme, gesicherte Code-Repositories, rollenbasierte Zugriffskontrolle.
Sicherheitstestverfahren im Entwicklungszyklus: Sicherheitstests müssen in den Entwicklungsablauf integriert sein – nicht auf ein abschließendes Sicherheits-Review beschränkt. Das schließt statische Codeanalyse (SAST) und dynamische Anwendungstests (DAST) ein. Je später eine Schwachstelle gefunden wird, desto teurer ist die Behebung: Ein SAST-Befund im Entwicklungsstadium kostet im Durchschnitt ein Zehntel eines Produktionsbefundes.
Testdatenverwaltung: Produktionsdaten dürfen nicht unverändert als Testdaten verwendet werden. 6.2.2 verlangt Bereinigung oder Anonymisierung gemäß Risikobewertung. Wer personenbezogene Produktionsdaten zu Testzwecken nutzt, riskiert nicht nur einen NIS2-Verstoß, sondern auch eine DSGVO-Verletzung.

6.2.3 – Ausgelagerte Entwicklung

Wird Entwicklung extern vergeben, gelten zusätzlich die Anforderungen aus Abschnitt 5 (Lieferkettensicherheit) und 6.1 (Beschaffungssicherheit). Konkret: Entwicklungsverträge müssen Sicherheitsanforderungen für den Entwicklungsprozess explizit einschließen – Secure-Coding-Anforderungen, Testpflichten, SBOM-Lieferpflichten des Dienstleisters [1].

6.2.4 – Regelmäßige Überprüfung

Sicherheitsvorschriften für die Entwicklung müssen in geplanten Abständen überprüft und aktualisiert werden. Das Bedrohungsumfeld ändert sich schnell – eine Entwicklungsrichtlinie von 2022 ist 2026 möglicherweise nicht mehr ausreichend. Ein jährlicher Review-Zyklus der SDLC-Sicherheitsrichtlinie gilt als gute Praxis [1].

Konfiguration, Änderungsmanagement und Patches – Abschnitte 6.3, 6.4 und 6.6

Diese drei Unterabschnitte verlängern die Sicherheitsanforderungen in den Betrieb. Sie sind konzeptionell Teil des Entwicklungslebenszyklus: Was entwickelt und beschafft wird, muss auch sicher konfiguriert, kontrolliert geändert und zeitnah gepflegt werden [2].

6.3 Konfigurationsmanagement: Sicherheitskonfigurationen für Hardware, Software, Dienste und Netze müssen dokumentiert, implementiert und überwacht werden. Standardkonfigurationen – Default-Passwörter, unnötige offene Ports, nicht benötigte Dienste – müssen vor der Inbetriebnahme deaktiviert sein. Konfigurationen müssen in geplanten Abständen oder nach wesentlichen Vorfällen überprüft werden.

6.4 Änderungsmanagement: Alle Änderungen an Systemen, einschließlich Notfall-Änderungen, müssen dokumentiert, risikobewertet und getestet werden, bevor sie produktiv gehen. Notfall-Änderungen, die ohne formelles Review durchgeführt wurden, sind nachzudokumentieren und zu begründen. Undokumentierte Änderungen sind ein klassischer Audit-Befund.

6.6 Patch-Management: Sicherheits-Patches müssen zeitnah nach Verfügbarkeit eingespielt werden. Die Verordnung verlangt: Patches vor dem Einspielen testen, Herkunft und Integrität des Patches prüfen. Entscheidungen, einen Patch nicht einzuspielen, müssen begründet und dokumentiert werden. Undokumentierte Patch-Ausnahmen – also bekannte Schwachstellen ohne Behebungsplan – sind beim BSI ein rotes Flag [2].

BSI IT-Grundschutz und TR-03185 als Umsetzungsrahmen

Für deutsche Einrichtungen bietet das BSI zwei komplementäre Rahmenwerke zur praktischen Umsetzung von Abschnitt 6.

BSI IT-Grundschutz: CON.8 und APP.7

CON.8 (Software-Entwicklung) des IT-Grundschutz-Kompendiums (Edition 2023) adressiert die Auftragnehmerperspektive: Welche Sicherheitsanforderungen muss ein Softwareentwickler erfüllen? APP.7 (Entwicklung von Individualsoftware) ergänzt die Auftraggeberperspektive: Welche Anforderungen muss ein Auftraggeber an seinen Entwicklungsdienstleister stellen [7]?

Zusammen decken CON.8 und APP.7 die Anforderung aus Abschnitt 6.2.3 ab: Einrichtungen müssen sowohl ihre eigene Entwicklung als auch ausgelagerte Entwicklung durch explizite Sicherheitsanforderungen absichern. Das BSI ordnet IT-Grundschutz ausdrücklich als Umsetzungshilfe für NIS2 ein. Eine Gap-Analyse gegen alle zehn Unterabschnitte von Abschnitt 6 – nicht nur 6.2 – ist jedoch erforderlich, da einige Managementanforderungen im Grundschutz-Kompendium weniger stark betont werden als in der CIR.

BSI TR-03185 – Sicherer Software-Lebenszyklus in sechs Phasen

BSI TR-03185 ist der technische Leitfaden des BSI für den sicheren Software-Lebenszyklus. Er strukturiert die Anforderungen in sechs Phasen, die direkt auf Abschnitt 6.2 der CIR 2024/2690 einzahlen [3]:

Phase (TR-03185)	Kernanforderung	CIR 2024/2690 Abschnitt
Projektmanagement	Threat Modeling, Sicherheitsanforderungen definieren	6.2.2 Maßnahme 1 und 2
Dokumentation	Sicherheitsanforderungen schriftlich festhalten	6.2.1
Entwicklung	Sichere Coding-Prinzipien, Secure-by-Design	6.2.2 Maßnahme 2
Testen	Code Reviews, SAST, DAST, Penetrationstests	6.2.2 Maßnahme 4, 6.5
Auslieferung	Sichere Ausliefermechanismen, Integritätsprüfung	6.3, 6.6
Fehlerbehebung	Schnelle Reaktion auf Schwachstellen	6.10

Einrichtungen, die BSI TR-03185 implementieren, erfüllen damit gleichzeitig die zentralen Anforderungen aus Abschnitt 6.2 – ein wesentlicher Vorteil bei der Audit-Vorbereitung [3].

DevSecOps in der Praxis: SAST, DAST und SBOM

SAST und DAST als Pflichtbestandteile der Entwicklungspipeline

Die Anforderung aus 6.2.2 Maßnahme 4 – Sicherheitstestverfahren im Entwicklungszyklus – lässt sich über zwei komplementäre Testmethoden erfüllen:

SAST (Static Application Security Testing) analysiert den Quellcode oder kompilierten Code ohne Ausführung der Anwendung. SAST-Tools identifizieren Schwachstellenklassen wie SQL-Injection, unsichere Kryptografie oder Pufferüberläufe direkt im Code – bevor das System deployed wird. In modernen CI/CD-Pipelines läuft SAST automatisch bei jedem Code-Commit und liefert sofortiges Feedback an den Entwickler [5].

DAST (Dynamic Application Security Testing) testet die laufende Anwendung von außen, wie ein Angreifer es täte. DAST findet Laufzeitfehler, die SAST nicht sieht – unsichere Session-Verwaltung, Konfigurationsprobleme, Zugriffskontrollfehler im Betrieb. Beide Verfahren sind komplementär: SAST findet Fehler früh im Zyklus, DAST findet Fehler, die erst in der laufenden Anwendung entstehen. Zusammen decken sie die Anforderung an entwicklungsbegleitende Sicherheitstests vollständig ab [5].

SBOM – Software Bill of Materials als regulatorischer Nachweis

Eine Software Bill of Materials (SBOM) ist eine maschinenlesbare Auflistung aller Softwarekomponenten, Abhängigkeiten, Versionen und Lizenzen eines Systems. BSI TR-03183-2 (veröffentlicht August 2023) definiert die formalen und inhaltlichen Anforderungen an SBOMs für den deutschen Markt [4].

Der Bezug zu Abschnitt 6: Die Dokumentationspflicht in 6.1 (Komponenten beschaffter Systeme) und die Testdatenverwaltung in 6.2.2 setzen beide eine vollständige Komponentenübersicht voraus. Ohne SBOM lässt sich weder validieren, was ein Lieferant tatsächlich liefert, noch bestimmen, welche Drittkomponenten in eigener Entwicklung stecken – und damit auch nicht, welche Schwachstellenwarnungen für das eigene System relevant sind.

Die regulatorische Entwicklung verschärft den Bedarf: Der Cyber Resilience Act (CRA) wird SBOMs ab 2027 für viele Produktkategorien verpflichtend machen. BSI und CRA fordern kryptografisch signierte SBOMs – Betreiber müssen die Integrität der empfangenen SBOM maschinell überprüfen können, statt dem Lieferanten auf Vertrauen zu vertrauen [4][5]. Frühzeitig SBOM-fähige Build-Prozesse einzurichten ist daher strategisch sinnvoll.

Rollen und Verantwortlichkeiten: Eine Zuständigkeitsmatrix

Abschnitt 6 der CIR 2024/2690 verteilt Pflichten auf verschiedene Rollen im Unternehmen. Artikel 20 NIS2 verpflichtet Leitungsorgane direkt – die Genehmigung und Überwachung der Maßnahmen nach Artikel 21 liegt in ihrer persönlichen Haftung. Die folgende Matrix zeigt, wer was nachweisen muss:

Rolle	Hauptpflicht nach Abschnitt 6	Praktische Aufgabe	Nachweis für Prüfer
CISO / IT-Sicherheitsbeauftragter	6.2.1: Sicherheitsvorschriften festlegen und pflegen	SDLC-Sicherheitsrichtlinie erstellen, jährlich überprüfen	Richtliniendokument + Review-Protokoll
Entwicklungsteam	6.2.2: Secure Coding, Tests, Testdatenverwaltung	SAST/DAST in CI/CD integrieren, Testdaten anonymisieren	Test-Protokolle, CI/CD-Konfiguration
Einkauf / Beschaffung	6.1: Sicherheitsanforderungen in Beschaffungsprozessen	Sicherheitskriterien in Ausschreibungen und Verträge aufnehmen	Verträge, Lieferanten-Validierungsberichte
Dienstleistermanagement	6.2.3 und 6.1: Externe Entwicklung absichern	Sicherheitsanforderungen in Entwicklungsverträge schreiben	Vertragsklauseln, SBOM-Lieferpflichten
Compliance Officer	6.2.4 und 6.5: Regelmäßige Überprüfung	Audit-Plan erstellen, interne Reviews koordinieren	Review-Protokolle, Maßnahmen-Tracking
Geschäftsleitung	Art. 20 NIS2: Verantwortung der Leitungsorgane	Sicherheitsrichtlinien genehmigen, Budget bereitstellen	Beschlüsse, Sitzungsprotokolle

Prüfnachweis: Was Prüfer für Abschnitt 6 sehen wollen

Einrichtungen, die einem BSI-Audit oder einer Sicherheitsüberprüfung unterliegen, benötigen für Abschnitt 6 folgende sieben Kernnachweise:

SDLC-Sicherheitsrichtlinie (6.2.1): Schriftliche Richtlinie, die alle Entwicklungsphasen abdeckt, mit Datum der letzten Überprüfung und Genehmigung der Leitungsebene
Secure-Coding-Standard (6.2.2 Maßnahme 2): Dokumentierte Coding-Standards – mindestens OWASP Top 10 als Grundlage, ergänzt um Zero-Trust-Architekturprinzipien
Testprotokolle (6.2.2 Maßnahme 4, 6.5): SAST/DAST-Ergebnisse, Penetrationstest-Berichte, Befunde und durchgeführte Maßnahmen – für den gesamten Prüfungszeitraum (in der Regel zwölf Monate)
Konfigurationsbaseline (6.3): Dokumentierte Sicherheitskonfigurationen für alle kritischen Systeme mit Nachweis der Abweichungsbehandlung
Änderungsmanagement-Protokolle (6.4): Nachweise, dass alle Änderungen bewertet, genehmigt und – bei Notfall-Änderungen – nachträglich dokumentiert wurden
Patch-Management-Protokolle (6.6): Nachweis zeitnaher Patch-Implementierung oder begründeter und dokumentierter Ausnahmen
SBOM oder Komponentendokumentation (6.1): Für beschaffte und selbst entwickelte kritische Systeme

Stichprobenhafte Tests ohne vollständige Protokollierung für den gesamten Prüfungszeitraum sind nicht ausreichend. Für die vollständige Vorbereitung Ihrer NIS2-Compliance empfehlen wir unsere NIS2-Compliance-Checkliste, die alle zehn Maßnahmenbereiche nach Artikel 21 abdeckt.

Häufige Fragen

Gilt CIR 2024/2690 Abschnitt 6 für alle NIS2-Unternehmen?

Nein. CIR 2024/2690 ist unmittelbar verbindlich nur für Anbieter digitaler Infrastrukturen und digitaler Dienste (DNS, Cloud, MSP, MSSP u. a.). Für alle anderen wesentlichen und wichtigen Einrichtungen gilt Artikel 21 Absatz 2 Buchstabe e NIS2 und § 30 NIS2UmsuCG. Das BSI empfiehlt diesen Einrichtungen, Abschnitt 6 als technischen Orientierungsrahmen zu nutzen – die technischen Anforderungen spiegeln den Stand der Technik wider und sind als Benchmark geeignet.

Müssen wir eine SBOM für eigene Software erstellen?

Noch nicht generell verpflichtend nach NIS2 selbst – aber Abschnitt 6.1 fordert die Dokumentation von Komponenten beschaffter Systeme, und 6.2.2 erfordert Testdatenverwaltung, die eine Komponentenübersicht voraussetzt. Der Cyber Resilience Act wird SBOMs ab 2027 für viele Produktkategorien verbindlich machen. Frühzeitig SBOM-fähige Build-Prozesse einzurichten ist daher strategisch sinnvoll.

Reicht BSI IT-Grundschutz als Umsetzungsnachweis für Abschnitt 6?

BSI IT-Grundschutz (CON.8 und APP.7) deckt die meisten Anforderungen aus Abschnitt 6.2 ab. BSI TR-03185 ergänzt als strukturierter Lebenszyklus-Leitfaden. Vollständige Compliance erfordert jedoch eine Gap-Analyse gegen alle zehn Unterabschnitte von Abschnitt 6 – insbesondere Konfigurationsmanagement (6.3), Patch-Management (6.6) und Schwachstellenmanagement (6.10) müssen separat adressiert werden.

Quellen

NIS2-Anforderungen: Sicherer Entwicklungszyklus. nis2-umsetzung.com: nis2-umsetzung.com/nis2umsvoannex/6-2-sicherer-entwicklungszyklus/
CIR 2024/2690 Anhang: Technische und methodische Anforderungen (Volltext). Advisera: advisera.com/cir-2024-2690
BSI TR-03185: Leitfaden für sicheren Software-Lebenszyklus. ISB Dresden (zitiert als [3])
BSI TR-03183-2: SBOM-Anforderungen. BSI Presse (zitiert als [4])
CRA und NIS2: Software-Sicherheit wird technisch überprüfbar. Security Insider: security-insider.de
BSI: NIS-2 für IT und TK – Durchführungsverordnung (EU) 2024/2690. BSI.bund.de (zitiert als [6])
NIS-2 konkret: Durchführungsverordnung und BSI-Grundschutz. Secuvera: secuvera.de