BSI Secure Coding: Leitfaden Entwickler 2026

In einem Satz. Der BSI-Baustein CON.8 “Software-Entwicklung” im IT-Grundschutz-Kompendium verbindet sichere Architektur, Threat Modeling, OWASP Top 10, Code-Reviews und automatisierte Tests zu einem ganzheitlichen Vorgehen — und ist mit DSGVO Art. 25 (Privacy by Design) untrennbar verknüpft.

Sicherheitslücken in Eigenentwicklungen sind Top-Ursache für Datenpannen in deutschen Unternehmen. Siehe ergänzend BSI-Grundschutz, DSGVO Art. 32, Privacy by Design.

Wichtige Punkte

• CON.8 mit Basis-, Standard- und erhöhten Anforderungen.
• OWASP Top 10 als praktische Referenz.
• Threat Modeling vor Coding-Start.
• SAST und DAST als automatisierte Prüfwerkzeuge.
• Code-Reviews durch zweite Person Pflicht.

1. CON.8 Basisanforderungen

• Anforderungen an Software-Entwicklung definieren.
• Trennung Entwicklungs-, Test-, Produktionsumgebung.
• Versionskontrolle (Git) mit Zugangskontrollen.
• Build-Pipeline mit reproduzierbarem Output.

2. Standardanforderungen

• Sichere Architektur (Defense in Depth).
• Threat Modeling (z.B. STRIDE).
• Statische Code-Analyse (SAST).
• Dynamische Code-Analyse (DAST).
• Sicherheits-Review Pflicht.

3. OWASP Top 10 (2021/2025)

#	Kategorie	Beispiel
A01	Broken Access Control	IDOR, Privilege Escalation
A02	Cryptographic Failures	Plaintext-Passwörter
A03	Injection	SQL, XSS, LDAP
A04	Insecure Design	Fehlende Threat Models
A05	Security Misconfiguration	Default-Credentials
A06	Vulnerable Components	Outdated Libs
A07	Identification/Auth Failures	Schwache MFA
A08	Software/Data Integrity	Supply Chain
A09	Logging Failures	Keine Audit-Logs
A10	SSRF	Unfiltered URL-Requests

4. Threat Modeling (STRIDE)

• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege

Pro Komponente durchspielen, Maßnahmen ableiten.

5. SAST-Werkzeuge

• SonarQube
• Checkmarx
• Snyk Code
• Semgrep
• GitHub CodeQL

Integration in CI/CD, Build-Break bei Critical Findings.

6. DAST-Werkzeuge

• OWASP ZAP
• Burp Suite Pro
• Acunetix
• Netsparker

DAST nach Deployment in Test-/Staging-Umgebung. Ergänzend prüfen Penetrationstests nach BSI-Methodik die Anwendung aus Angreifersicht.

7. Supply Chain Security

• Dependency-Scanning (Snyk, Dependabot, Renovate).
• SBOM (Software Bill of Materials) ab 2025 für KRITIS Pflicht.
• Signaturprüfung von Containern (cosign, Sigstore).
• Lock-Files für reproduzierbare Builds.

8. Secrets-Management

• Niemals Secrets im Code/Git.
• Vault-Lösungen: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault.
• Pre-Commit-Hooks (gitleaks, trufflehog).
• Rotation alle 90 Tage.

9. Privacy by Design

DSGVO Art. 25 (Privacy by Design und by Default) verlangt Datenschutz-freundliche Voreinstellungen und Privacy-by-Design-Implementierung. Konkret:

• Datenminimierung in API-Responses.
• Pseudonymisierung statt Klartext.
• Verschlüsselung at-rest und in-transit.
• Logging ohne personenbezogene Daten.
• Recht auf Vergessen technisch implementiert.

Für die Transportverschlüsselung gelten dabei die BSI-Mindeststandards für TLS.

10. Code-Review-Praxis

• Mindestens 4-Augen-Prinzip (Pull Request).
• Security-Review für sicherheitskritische PRs.
• Checkliste: Input-Validation, Output-Encoding, AuthN/AuthZ, Logging.
• Schulung Entwickler 1-2x/Jahr.

11. Tool-Unterstützung

Legiscope verknüpft Coding-Standards mit DSGVO Art. 25-Anforderungen und dokumentiert SDLC-Compliance für Audits.

11. Konkrete Implementierungsschritte

1. Bestandsaufnahme der betroffenen Systeme und Datenflüsse (CMDB, Netzplan).
2. Schutzbedarfsfeststellung nach BSI-Standard 200-2 (normal/hoch/sehr hoch).
3. Risikoanalyse mit Bedrohungskatalog des IT-Grundschutz-Kompendiums.
4. Maßnahmenkatalog ableiten aus den relevanten Bausteinen.
5. Pilotierung auf ausgewähltem Subsystem, Lessons Learned dokumentieren.
6. Rollout mit Rollbackplan, Change-Management, Schulungen.
7. Monitoring über SIEM, regelmäßige Vulnerability-Scans.
8. Wirksamkeitsprüfung über interne Audits und Pentests, mindestens jährlich.
9. Dokumentation im ISMS-Tool (verinice., AdaptiveGRC, Compliance Aspekte).
10. Re-Zertifizierung spätestens alle drei Jahre.

12. Tool-Empfehlungen (Open-Source und kommerziell)

Bereich	Open-Source	Kommerziell
ISMS	verinice., OpenVAS	RSA Archer, ServiceNow GRC
SIEM	Wazuh, Graylog, ELK	Splunk, Microsoft Sentinel, IBM QRadar
Pentest	Kali Linux, Metasploit Framework	Burp Suite Pro, Cobalt Strike
Vulnerability-Scan	OpenVAS, Nuclei	Tenable Nessus, Qualys VMDR
Endpoint Detection	Wazuh, OSSEC	CrowdStrike Falcon, SentinelOne
Backup	Bacula, Restic	Veeam, Rubrik

Open-Source-Stacks sind für KMU oft ausreichend, erfordern aber qualifizierte Administration. Kommerzielle Lösungen liefern Support, Hardening-Defaults und Compliance-Reports out-of-the-box.

13. Voraussetzungen und Vorwissen

Für die Umsetzung empfiehlt der BSI mindestens: ISO 27001 Foundation oder BSI IT-Grundschutz-Praktiker-Zertifizierung, praktische Erfahrung mit Netzwerktechnik und Linux/Windows-Administration, Verständnis von Identitäts- und Zugriffsmanagement (IAM), Kenntnisse in Kryptographie nach BSI TR-02102. Für Audits zusätzlich ISO 27001 Lead Auditor oder BSI-zertifizierter Auditor. Mittlere Projekte erfordern ein Team aus DSB, ISB, Netzwerk-Admin und Anwendungsverantwortlichem.

14. ROI-Metriken und Kennzahlen

Typische Kennzahlen zur Erfolgskontrolle:

• Mean Time to Detect (MTTD): Ziel < 24 Stunden, ohne SIEM oft > 200 Tage (IBM Cost of a Data Breach Report).
• Mean Time to Respond (MTTR): Ziel < 4 Stunden für kritische Vorfälle.
• Patch-Compliance-Quote: Ziel > 95 % binnen 30 Tagen nach CVE-Veröffentlichung.
• Schulungsquote: 100 % aller Mitarbeitenden pro Jahr (E-Learning + Phishing-Tests).
• Audit-Befund-Schließung: Critical-Findings binnen 30 Tagen, High binnen 90 Tagen.
• Backup-Wiederherstellungstest: mindestens quartalsweise, RTO/RPO dokumentiert.

Ein durchschnittlicher Datenpannen-Vorfall kostet laut Bitkom-Studie 2024 in Deutschland 4,3 Mio. €. Investitionen in präventive Maßnahmen amortisieren sich typisch nach 18-30 Monaten.

15. Häufige Pitfalls

• Maßnahmen werden eingeführt, aber nicht in Betrieb gehalten (kein Lifecycle-Management).
• Fehlende Asset-Management-Disziplin — Schatten-IT bleibt unberücksichtigt.
• Verlassen auf Standard-Hardening ohne unternehmensspezifische Risikoanalyse.
• Keine Awareness-Schulungen für nicht-technische Mitarbeitende.
• Verträge mit Cloud-Anbietern ohne Sicherheits-SLA und Audit-Recht.
• Pentests ohne Re-Test nach Befundbehebung — Mängel bleiben offen.
• Logmanagement ohne Aufbewahrungspflicht-Konformität (DSGVO Art. 5 Abs. 1 lit. e).

16. Integration mit ISO 27001 und NIS2

ISO 27001:2022 und BSI-Grundschutz sind weitgehend kompatibel; eine Mapping-Tabelle des BSI ordnet die ISO-Controls (Annex A) den Grundschutz-Bausteinen zu. Doppelzertifizierungen sind möglich und reduzieren Audit-Aufwand um ca. 30 %. Für NIS2 Deutschland-pflichtige Einrichtungen (KRITIS, wesentliche/wichtige Einrichtungen nach § 28 NIS2UmsuCG) gilt: BSI-Grundschutz wird als geeigneter Sicherheitsstandard akzeptiert, ISO 27001 ebenso. Wer beides hat, deckt zugleich DORA-Anforderungen (für Finanzinstitute) und DSGVO Art. 32 Sicherheit ab.

17. Vergleich BSI vs ANSSI vs NIST

Aspekt	BSI (DE)	ANSSI (FR)	NIST (US)
Ansatz	Bausteinbasiert (modular)	Risikobasiert (EBIOS)	Funktion-basiert (CSF 2.0)
Hauptstandard	IT-Grundschutz / 200-2	PSSI-E, EBIOS RM	NIST CSF, SP 800-53
Zertifizierung	ISO 27001 auf Basis Grundschutz	LSTI, SecNumCloud	FedRAMP, FISMA
Cloud-Bewertung	C5 (Cloud Computing Compliance Criteria Catalogue)	SecNumCloud	FedRAMP High/Moderate
Pflichtkraft	KRITIS-Verordnung, NIS2UmsuCG	LPM, NIS2-Transposition	FISMA, Executive Orders

In multinationalen Konzernen wird häufig NIST CSF als Mantel verwendet, mit BSI-Grundschutz für DE-Tochterunternehmen und SecNumCloud für FR-Cloudnutzung.

Fazit

Secure Coding ist kein Plugin, sondern ein Prozess. Wer SAST, DAST, Threat Modeling und Privacy by Design konsequent in den SDLC integriert, vermeidet 80% der typischen Datenpannen — und reduziert Bußgeldrisiken massiv.

FAQ

Was ist SAST vs. DAST?

SAST analysiert Quellcode statisch (vor Deployment). DAST testet die laufende Anwendung von außen wie ein Angreifer.

Sind OWASP Top 10 Pflicht?

Nicht direkt gesetzlich, aber faktischer Standard. Aufsichtsbehörden erwarten OWASP-Konformität bei DSGVO Art. 32-Prüfungen.

Was ist ein SBOM?

Software Bill of Materials — vollständige Liste aller Komponenten und Abhängigkeiten. EU Cyber Resilience Act macht dies ab 2027 Pflicht.

Wie oft sollten Code-Reviews durchgeführt werden?

Bei jedem Pull Request. Security-Reviews bei sicherheitskritischen Änderungen (Auth, Crypto, Datenflüsse).

Welche Sprache ist am sichersten?

Memory-safe Sprachen (Rust, Go, Java, C#) reduzieren ganze Klassen von Bugs (Buffer Overflows). C/C++ erfordert besondere Sorgfalt.

Wie integriere ich BSI-Grundschutz mit bestehender ISO 27001?

Mapping-Tabellen des BSI zeigen Äquivalenzen zwischen Annex A und Grundschutz-Bausteinen. Praxis: Ein ISMS-Dokument für beide Standards, Audit kombiniert, Zertifizierungsaufwand sinkt um ca. 30 %. Voraussetzung ist ein zentrales ISMS-Tool wie verinice. mit beiden Profilen. Für die Re-Zertifizierung alle drei Jahre reicht ein gemeinsames Audit-Team.

Welche Kosten entstehen für die Erstimplementierung?

Für ein mittleres Unternehmen (250-500 Mitarbeitende): externe Beratung 80.000-180.000 €, Tooling 15.000-60.000 €/Jahr, interne Personalkosten 1-2 FTE über 12 Monate, Audit-Kosten 25.000-50.000 €. Gesamtprojekt typisch 250.000-450.000 € in Jahr 1, danach jährlich 60.000-120.000 € Betrieb. ROI über reduzierte Vorfallskosten und Versicherungsprämienrabatte (typisch 10-20 % bei Cyber-Versicherungen).

Wie verhält sich BSI-Grundschutz zu NIS2?

Die NIS2 Deutschland-Umsetzung (NIS2UmsuCG) akzeptiert BSI-Grundschutz und ISO 27001 als geeignete Sicherheitsstandards. KRITIS-Betreiber und wesentliche Einrichtungen müssen alle zwei Jahre den Nachweis erbringen. Wer bereits zertifiziert ist, hat den Compliance-Nachweis für NIS2 weitgehend erbracht.

Welche BSI-Technische-Richtlinien sind besonders relevant?

BSI TR-02102 (Kryptographische Verfahren), TR-03116 (eHealth-Sicherheit), TR-03161 (Anforderungen mobile Anwendungen), TR-03145 (Sichere CA-Betriebsprozesse), TR-03150 (Sichere Verarbeitung in der elektronischen Patientenakte). Für Cloud-Nutzung zusätzlich der C5-Katalog (Cloud Computing Compliance Criteria Catalogue) in Version C5:2020.