Grundschutz++ Entwicklung: sichere Software von Anfang an (DEV)
Grundschutz++ Entwicklung: was die Praktik DEV zu Security by Design, sicherem Code, SBOM, Updates und Freigabe verlangt und was das für Auftraggeber bedeutet.
Die Grundschutz++ Entwicklung betrifft alle Betriebe, die Software selbst entwickeln oder entwickeln lassen: eine eigene Web-Anwendung, ein Kundenportal, eine Schnittstelle zur Warenwirtschaft oder Erweiterungen für ein bestehendes System. Die Praktik «Entwicklung» (Kürzel DEV) im neuen IT-Grundschutz des BSI verlangt, dass Sicherheit von Anfang an mitgeplant wird und nicht erst nach dem ersten Vorfall.
Warum das wichtig ist
Sicherheitslücken, die beim Entwerfen und Programmieren entstehen, sind später teuer zu beheben. Typische Fehler sind ungeprüfte Eingaben in Formularen, unsicher gespeicherte Passwörter, fest eingebaute Standardzugänge oder veraltete fremde Bausteine im Code. Wer das von Beginn an vermeidet, spart Aufwand und schützt Kundendaten.
Was verbindlich ist
Verpflichtend ist ein festgelegtes Vorgehen für die Entwicklung, das aufgeschrieben, Zuständigen zugewiesen, bekannt gemacht und regelmäßig überprüft wird. Empfohlen sind unter anderem Sicherheit im Entwurf («Security by Design»), sichere Voreinstellungen («Security by Default»), geprüfte Eingaben, sicher gespeicherte Passwörter, eine Liste aller verwendeten Fremdbestandteile, zugesagte Sicherheitsupdates und eine Freigabe erst nach Tests.
Der erste Schritt
Wenn Sie Software entwickeln lassen, nehmen Sie Sicherheitsanforderungen in den Auftrag auf: Wie werden Eingaben geprüft und Passwörter gespeichert? Welche fremden Bausteine werden verwendet? Wie lange gibt es Sicherheitsupdates? Wer selbst entwickelt, sollte diese Punkte als feste Regeln für das Team festlegen.
Die Praktik «Entwicklung» (DEV) regelt im Anwenderkatalog Grundschutz++ die Sicherheit bei der Software- und Systementwicklung. Dieser Artikel stellt die Grundschutz++ Entwicklung nach dem Katalogstand vom 22. Oktober 2026 vor.
Ziel der Praktik
Nach der Katalogbeschreibung stellt DEV sicher, «dass Sicherheitsanforderungen bereits von Beginn an in die Planungs- und Entwicklungsphase von IT-Systemen und Anwendungen integriert werden». Potenzielle Schwachstellen sollen so frühzeitig erkannt und vermieden werden. Die Praktik umfasst die Erzeugung und Integration neuer IT-Komponenten in die IT-Infrastruktur der Institution. Der Katalog betont die enge Zusammenarbeit mit anderen Praktiken wie IT-Betrieb, Asset Management und Konfiguration, damit entwickelte Komponenten auch sicher betrieben und gepflegt werden können.
Aufbau: sieben Gruppen, 34 Anforderungen
| Gruppe | Inhalt |
|---|---|
| DEV.1 Grundlagen | Verfahren und Regelungen zur Entwicklung von IT-Produkten, Zuständigkeiten, Überprüfung |
| DEV.2 Security by Design | sichere Architektur und deren Dokumentation, minimale Rechte, Zugriff auf Quellcode und Zugangsdaten, Schutz gegen gängige Angriffsmuster, Eingabevalidierung, Ausgabekodierung |
| DEV.3 Härtung | Schutz gegen Replay-Angriffe, Fehlerbehandlung, keine schützenswerten Daten in Fehlermeldungen, Passwort-Hashing |
| DEV.4 Code | Nutzerinformation bei kritischen Ereignissen, externe Software, SBOM, Integrität und Updates externer Software, Compileroptionen, Default-Zugangsdaten, Security by Default, Protokollierung von Codeänderungen, Tests |
| DEV.5 Updates | Zeitraum für Sicherheitsupdates festlegen und mitteilen, Integritätsprüfung |
| DEV.6 Freigabe | Freigabe nach Änderungen und Tests |
| DEV.7 Bereitstellung und Betrieb | sichere Bereitstellung, Zertifikatsmonitoring |
Die verbindlichen MUSS-Anforderungen
DEV.1.1 «Entwicklung MUSS Verfahren und Regelungen zur Entwicklung von IT-Produkten verankern.»
DEV.1.1.1 «Entwicklung MUSS die Verfahren und Regelungen dokumentieren.»
DEV.1.1.2 «Entwicklung MUSS die mit den Verfahren und Regelungen verbundenen Aufgaben zuständigen Personen oder Rollen zuweisen.»
DEV.1.1.3 «Entwicklung MUSS die zuständigen Personen oder Rollen über die Verfahren und Regelungen informieren.»
DEV.1.2 «Entwicklung MUSS die Verfahren und Regelungen regelmäßig und anlassbezogen auf Aktualität überprüfen.»
Wichtige SOLLTE-Anforderungen
SOLLTE bedeutet nach der BSI-Definition, dass eine Anforderung normalerweise erfüllt werden muss; Abweichungen sind sorgfältig abzuwägen und stichhaltig zu begründen.
DEV.2.1 «Entwicklung SOLLTE die Architektur nach dem Prinzip "Security by Design" verankern.»
DEV.2.3 «Entwicklung für Anwendungen SOLLTE die fehlerfreie Ausführung mit den geringst möglichen Berechtigungen verankern.»
DEV.2.6.1 «Entwicklung für Anwendungen SOLLTE Eingabedaten auf eingeschleuste Befehle testen.»
DEV.3.4 «Entwicklung für Anwendungen SOLLTE das Hashing von Passwörtern, die zur Authentifizierung an der Anwendung verwendet werden vor der Verarbeitung oder Speicherung aktivieren.»
DEV.4.2 «Entwicklung für Anwendungen SOLLTE die Einbindung externer Softwareartefakte und -Schnittstellen aus unzuverlässigen oder unbekannten Quellen untersagen.»
DEV.4.3 «Entwicklung für Anwendungen SOLLTE die Bestandteile mit Hilfe einer Software Bill of Materials (SBOM) vor dem Release dokumentieren.»
DEV.4.9 «Entwicklung für Anwendungen SOLLTE Voreinstellungen nach dem Prinzip "Security by Default" aktivieren.»
DEV.5.1 «Entwicklung für Anwendungen SOLLTE die Bereitstellung von Sicherheitsupdates mindestens für einen bestimmten Zeitraum verankern.»
DEV.6.1 «Entwicklung SOLLTE die Freigabe zur Nutzung im Einklang mit den entsprechenden Verfahren und Regelungen für Änderungen und Tests autorisieren.»
DEV.7.2 «Entwicklung für Anwendungen SOLLTE die Ausstellung neuer Zertifikate für die von der Anwendung verwendeten Domains überwachen.»
DEV.6.1 und DEV.4.11 zeigen die enge Verbindung zur Praktik Änderungen und Tests (TEST): Freigaben und Tests von Quellcodeänderungen sollen nach deren Verfahren erfolgen. DEV.5.1 verlangt einen festgelegten Zeitraum für Sicherheitsupdates, nennt aber keine Mindestdauer. DEV.5.2 empfiehlt, Auftraggeber über diesen Zeitraum zu informieren.
Normale und erhöhte Sicherheitsstufe
DEV ist fast vollständig der Standard-Sicherheitsstufe «normal-SdT» zugeordnet: 33 Anforderungen (5 MUSS, 28 SOLLTE). Nur eine Anforderung gehört zur Stufe «erhöht» und ist als KANN formuliert, also nach BSI je nach Situation und Risikoanalyse sinnvoll:
DEV.4.7 «Entwicklung für Anwendungen KANN eine reproduzierbare Vorgehensweise zur Erstellung eines bestimmten Binärcodes aus dem Quellcode dokumentieren.»
Gemeint sind reproduzierbare Builds, mit denen sich nachweisen lässt, dass ein ausgeliefertes Programm tatsächlich aus dem geprüften Quellcode stammt.
Typische Nachweise
- Freigabeplan (13 Anforderungen): Tests auf Eingabevalidierung, Angriffsmuster, minimale Rechte, Passwort-Hashing, Codeänderungen
- Entwicklungsdokumentation (10): Architektur, SBOM, Default-Zugangsdaten, Update-Zeitraum, Freigabe
- Codehistorie (2): Protokollierung von Codeänderungen, Voreinstellungen
- außerdem Inventar Berechtigungen (Zugriff auf Quellcode und Zugangsdaten), IT-Betriebskonzept, Geschäftsverteilungsplan und Übungs- und Prüfplan
Betroffene Zielobjekte
25 der 34 Anforderungen nennen ausdrücklich das Zielobjekt «Anwendungen». Die übrigen gelten für das Entwicklungsverfahren insgesamt. Für einen Betrieb ohne eigene oder beauftragte Entwicklung kann die Praktik in der Strukturmodellierung entfallen; diese Entscheidung sollte begründet festgehalten werden.
Bezug zum bisherigen IT-Grundschutz
Im Kompendium 2023 lagen die Inhalte vor allem in den Bausteinen CON.8 Software-Entwicklung, CON.10 Entwicklung von Webanwendungen und APP.7 Entwicklung von Individualsoftware. Der Mapping-Entwurf des BSI ordnet Anforderungen aus diesen Bausteinen der Praktik DEV zu.
Grundschutz++ Entwicklung in kleinen und mittleren Unternehmen
Wenn Sie selbst entwickeln:
- Entwicklungsrichtlinie schreiben: Sicherheitsprinzipien, Code-Review, Umgang mit Fremdbibliotheken, Zugangsdaten nie im Quellcode, Freigabe nach Tests.
- Zugriffe beschränken: schreibenden Zugriff auf den Quellcode und Zugriff auf Zugangsdaten beschränken (DEV.2.4, DEV.2.5), Geheimnisse in einem Secret-Speicher statt im Code.
- Abhängigkeiten im Griff behalten: SBOM aus dem Build erzeugen, Bibliotheken nur aus vertrauenswürdigen Quellen, Updates und Integrität prüfen (DEV.4.2 bis DEV.4.5).
- Typische Angriffe abwehren: Eingabevalidierung, Ausgabekodierung, sichere Fehlerbehandlung, Passwort-Hashing. Die OWASP Top Ten sind eine verbreitete Orientierung.
- Update-Zeitraum festlegen und mitteilen (DEV.5.1, DEV.5.2).
Wenn Sie entwickeln lassen:
- Anforderungen in den Vertrag: DEV-Anforderungen als Leistungsmerkmale vereinbaren, etwa SBOM, Update-Zeitraum, sichere Voreinstellungen, Tests vor Auslieferung.
- Freigabe behalten: Abnahme und Inbetriebnahme laufen über Ihr Verfahren nach TEST und DEV.6.1.
- Dienstleister steuern: Die Praktik Dienstleistersteuerung (DLS) regelt die übergreifende Steuerung externer Partner.
Für Hersteller, die Produkte mit digitalen Elementen in der EU anbieten, kann zusätzlich der Cyber Resilience Act relevant sein.
Häufige Fragen
Betrifft uns die Praktik Entwicklung, wenn wir nur Standardsoftware nutzen?
In der Regel nur am Rand. DEV richtet sich an die Entwicklung von IT-Produkten. Wer weder selbst entwickelt noch Software entwickeln lässt, kann die Praktik in der Strukturmodellierung begründet ausklammern. Anpassungen und Erweiterungen bestehender Systeme können aber bereits Entwicklung sein.
Was ist eine SBOM?
Eine Software Bill of Materials ist eine Stückliste der Bestandteile einer Software, insbesondere der verwendeten Fremdbibliotheken mit Versionen. DEV.4.3 empfiehlt, sie vor dem Release zu dokumentieren. So lässt sich bei neuen Schwachstellen schnell prüfen, ob die eigene Software betroffen ist.
Wie lange müssen wir Sicherheitsupdates für unsere Software liefern?
Der Katalog legt keine Dauer fest. DEV.5.1 verlangt, die Bereitstellung von Sicherheitsupdates mindestens für einen bestimmten Zeitraum zu verankern, DEV.5.2, Auftraggeber darüber zu informieren. Gesetzliche Vorgaben, etwa für Hersteller im Geltungsbereich des Cyber Resilience Act, sind gesondert zu prüfen.
Wie hängen DEV und TEST zusammen?
DEV regelt, wie sicher entwickelt wird. Tests von Quellcodeänderungen (DEV.4.11) und die Freigabe zur Nutzung (DEV.6.1) sollen nach den Verfahren der Praktik Änderungen und Tests erfolgen. So gibt es ein gemeinsames Freigabeverfahren für Eigenentwicklungen und andere Änderungen.