Das BSI-IT-Grundschutz-Kompendium ist ein modulares Werk mit mehreren hundert „Bausteinen". Für die Softwareentwicklung sind vier Gruppen zentral:
APP-Bausteine (Anwendungen). APP.1 definiert Sicherheitsanforderungen an Client-Anwendungen, APP.3 an allgemeine Dienste wie Webserver und Datenbanken, APP.4 an Geschäftsanwendungen wie ERP und CRM. APP.6 behandelt mobile Apps.
CON-Bausteine (Konzepte). CON.8 ist der Baustein „Software-Entwicklung" — der direkte Bezug zum Entwicklungsprozess. CON.3 regelt Datensicherungskonzepte, die auch Entwickler betreffen.
ISMS-Bausteine. Beschreiben das Informationssicherheits-Managementsystem, das als Rahmen für die Umsetzung dient. Für die meisten mittelständischen Auftraggeber ist ein vollständiges ISMS nicht zertifiziert, die Struktur aber hilfreich als Gliederung.
OPS-Bausteine (Betrieb). Relevante Bausteine wie OPS.1.1.1 (Festlegung und Durchsetzung von Sicherheitsrichtlinien) oder OPS.1.2.5 (Fernwartung) gelten auch für Software-Dienstleister.
Ein Dienstleister, der „BSI-konform" arbeitet, sollte auf Nachfrage pro Baustein konkret sagen können, wie die Anforderungen umgesetzt sind — nicht pauschal bestätigen.
Die NIS2-Richtlinie erweitert den Kreis der regulierten Unternehmen erheblich. Betroffen sind mittlere und große Unternehmen (über fünfzig Mitarbeiter oder zehn Millionen Euro Jahresumsatz) in achtzehn Sektoren: Energie, Transport, Gesundheit, Trinkwasser, digitale Infrastruktur, öffentliche Verwaltung, Weltraum, Post, Chemie, Lebensmittel, Industrie, Forschung und weitere.
Für diese Unternehmen gelten seitdem verbindliche Pflichten: Risikoanalyse, Vorfallmeldepflicht (binnen 24 Stunden Erstmeldung), Business-Continuity-Planung, Lieferkettensicherheit. Die Lieferkettensicherheit ist der Punkt, der externe Dienstleister direkt betrifft: Als Auftraggeber müssen Sie prüfen können, ob Ihr Software-Partner die Anforderungen erfüllt.
Praktische Konsequenz für Verträge: Dokumentationspflichten, Audit-Rechte, Incident-Response-Verpflichtungen müssen spezifisch formuliert sein — nicht als generische Klausel.
Ein belastbarer Entwicklungsprozess umfasst mindestens folgende Elemente:
Threat Modeling zu Projektbeginn. Eine strukturierte Analyse möglicher Angriffsvektoren auf die zu entwickelnde Anwendung. STRIDE oder PASTA sind gängige Methoden. Das Ergebnis ist eine priorisierte Liste von Sicherheitsanforderungen, die in das Backlog einfließen.
Secure Coding Guidelines. Verbindliche Regeln für die Entwicklung — Sprache- und Framework-spezifisch. Für Webanwendungen: Eingabevalidierung, sichere Session-Handhabung, korrekte Verwendung kryptografischer Primitive, Schutz vor OWASP Top Ten.
Static Application Security Testing (SAST) in der Pipeline. Automatische Analyse des Quellcodes bei jedem Commit. Werkzeuge wie Semgrep, SonarQube oder spezialisierte Sprach-Linter identifizieren bekannte Muster unsicherer Programmierung.
Dynamic Application Security Testing (DAST). Laufzeit-Tests gegen eine Testumgebung. Werkzeuge wie OWASP ZAP oder Burp Suite scannen die laufende Anwendung auf Schwachstellen.
Software Composition Analysis (SCA). Analyse der eingebundenen Open-Source-Bibliotheken auf bekannte Schwachstellen. Dependabot, Snyk oder Trivy decken den Standardbedarf.
Penetrationstest vor Go-Live. Ein unabhängiger Prüfer (extern, nicht der Entwickler) testet die Anwendung gegen aktuelle Angriffsmuster. Für kritische Anwendungen jährlich wiederholt.
Keines dieser Elemente ist teuer in der einmaligen Einrichtung. Alle zusammen sind der Unterschied zwischen „wir achten auf Cybersicherheit" und einer belastbaren Sicherheitsarchitektur.
Generische Sicherheitsklauseln sind wertlos. Spezifische Klauseln kosten wenig in der Verhandlung und viel im Schadensfall — umgekehrt.
Beispiele für wirksame Formulierungen:
Diese Klauseln sind einklagbar. Allgemeine „der Auftragnehmer sorgt für angemessene Sicherheit" sind im Zweifelsfall nicht.
Ein Penetrationstest ist kein Rundum-Sicherheitsbeweis. Er testet gezielt gegen einen definierten Angriffsvektor in einem definierten Zeitrahmen. Für Webanwendungen typischer Umfang:
Für die meisten B2B-Webanwendungen ist ein Greybox-Test über fünf bis zehn Werktage der wirtschaftlichste Einstieg. Der Bericht enthält gefundene Schwachstellen mit Kritikalitätsbewertung (oft nach CVSS) und Empfehlungen zur Behebung.
Wichtig: Der Pentest findet Schwachstellen, repariert sie aber nicht. Die Behebung ist Teil des Entwicklungsbudgets — rechnen Sie mit zehn bis zwanzig Prozent zusätzlichem Aufwand für die Nachbesserung nach einem ersten produktiven Pentest.
Unser Standardvorgehen: SAST und SCA in jeder Pipeline. Threat Modeling zu Projektbeginn als Pflicht. Secure Coding Guidelines basierend auf OWASP ASVS Level 2 für reguläre Anwendungen, Level 3 für sicherheitskritische. Externer Pentest vor jedem Major-Release — über einen Partner mit CREST- oder OSCP-Zertifizierung.
Vertraglich: spezifische Cybersicherheit-Klauseln als Anlage zum Werkvertrag, Incident-Response-Zeitfenster von vierundzwanzig Stunden, Dokumentationspflicht für Architektur und kritische Designentscheidungen. Diese Leistungen sind Bestandteil unseres Cybersicherheits-Portfolios und werden eng verzahnt mit DevOps und Cloud-Infrastruktur umgesetzt.
Wenn Ihr Unternehmen unter NIS2 fällt oder sich gerade auf eine Zertifizierung vorbereitet, lohnt eine strukturierte Bestandsaufnahme Ihrer bestehenden Software-Beauftragungen. Welche Dienstleister haben welche Cybersicherheit-Klauseln vertraglich zugesichert? Vereinbaren Sie eine kostenlose Online-Sondierung — wir schauen uns die Ist-Lage an, bevor der Gesetzgeber fragt. Für die datenschutzrechtliche Flankierung liefert der Beitrag zu DSGVO-konformer Softwareentwicklung die nötige Ergänzung — Artikel 32 DSGVO und BSI-Grundschutz greifen inhaltlich eng ineinander.
Nicht zwingend, aber zertifizierte Auftragnehmer erleichtern die eigene Compliance erheblich. Wenn Sie selbst ISO-27001 oder TISAX führen, sollten kritische Dienstleister entsprechend zertifiziert sein — oder mindestens ein gleichwertiges ISMS nachweisen.
Direkt nur in Sonderfällen (kritische Infrastrukturbetreiber sind unabhängig von der Größe betroffen). Indirekt oft schon — weil Sie möglicherweise Zulieferer eines NIS2-pflichtigen Unternehmens sind und über die Lieferkette Nachweise erbringen müssen.
Für kritische Anwendungen jährlich oder nach wesentlichen Änderungen. Für weniger kritische alle zwei Jahre. Nach einem größeren Architekturumbau immer — auch wenn der letzte Pentest zeitlich erst kurz zurückliegt.
Der Marktpreis bewegt sich in Abhängigkeit von Umfang und Prüfer-Qualifikation. Konkrete Angebote kommen nach Scope-Abstimmung (betroffene Anwendungsteile, Testtiefe, Testtage). Unter fünf Werktagen Testaufwand ist die Tiefe meist nicht ausreichend für Kritische Anwendungen.
Ja, und Sie sollten. Werkzeuge wie Dependabot (in GitHub kostenlos), Trivy oder SonarCloud decken den Grundbedarf ab. Die wichtigere Investition ist weniger das Werkzeug als der Prozess, Funde zeitnah zu bewerten und zu beheben.