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.
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
11. Konkrete Implementierungsschritte
- Bestandsaufnahme der betroffenen Systeme und Datenflüsse (CMDB, Netzplan).
- Schutzbedarfsfeststellung nach BSI-Standard 200-2 (normal/hoch/sehr hoch).
- Risikoanalyse mit Bedrohungskatalog des IT-Grundschutz-Kompendiums.
- Maßnahmenkatalog ableiten aus den relevanten Bausteinen.
- Pilotierung auf ausgewähltem Subsystem, Lessons Learned dokumentieren.
- Rollout mit Rollbackplan, Change-Management, Schulungen.
- Monitoring über SIEM, regelmäßige Vulnerability-Scans.
- Wirksamkeitsprüfung über interne Audits und Pentests, mindestens jährlich.
- Dokumentation im ISMS-Tool (verinice., AdaptiveGRC, Compliance Aspekte).
- 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
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?
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.