Cybersicherheit nach BSI-Grundschutz: Was Software-Dienstleister leisten müssen

Die Struktur des BSI IT-Grundschutz

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.

NIS2: Was sich mit dem Umsetzungsgesetz geändert hat

Die NIS2-Richtlinie, in Deutschland seit Ende 2025 durch das NIS2-Umsetzungsgesetz in Kraft, 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.

Secure Software Development Lifecycle

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.

Vertragsklauseln, die Wirkung zeigen

Generische Sicherheitsklauseln sind wertlos. Spezifische Klauseln kosten wenig in der Verhandlung und viel im Schadensfall — umgekehrt.

Beispiele für wirksame Formulierungen:

1. „Der Auftragnehmer führt SAST und SCA in der CI/CD-Pipeline durch und dokumentiert kritische Funde vor der Produktivschaltung."
2. „Der Auftragnehmer gewährleistet die Durchführung eines externen Penetrationstests durch einen unabhängigen Prüfer vor dem Go-Live. Der Testbericht wird dem Auftraggeber übergeben."
3. „Bei Bekanntwerden einer Sicherheitslücke in einer eingesetzten Komponente wird der Auftraggeber innerhalb von vierundzwanzig Stunden informiert."
4. „Der Quellcode wird in einer dokumentierten Secure-Coding-Richtlinie entwickelt, die dem Auftraggeber auf Verlangen vorgelegt wird."

Diese Klauseln sind einklagbar. Allgemeine „der Auftragnehmer sorgt für angemessene Sicherheit" sind im Zweifelsfall nicht.

Pentest: Umfang und Grenzen

Ein Penetrationstest ist kein Rundum-Sicherheitsbeweis. Er testet gezielt gegen einen definierten Angriffsvektor in einem definierten Zeitrahmen. Für Webanwendungen typischer Umfang:

• Blackbox-Test (Tester kennt nur die URL): identifiziert von außen sichtbare Angriffsflächen.
• Greybox-Test (Tester hat Nutzerkonto): realistischeres Szenario für B2B-Anwendungen.
• Whitebox-Test (Tester hat Codezugang): tiefgehender, deckt mehr auf, teurer.

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 — planen Sie für die Nachbesserung nach einem ersten produktiven Pentest einen eigenen Puffer ein.

Wie D'Cloud Sicherheit operationalisiert

Welche Sicherheitsmaßnahmen ein Projekt umfasst, legen wir vor Projektbeginn schriftlich fest — etwa SAST und SCA in der Pipeline, Threat Modeling zu Projektbeginn und Secure Coding Guidelines nach OWASP ASVS, mit einem Level passend zur Kritikalität der Anwendung. Ein externer Pentest wird bei Bedarf bei einem unabhängigen Prüfer beauftragt, dessen Auswahl Sie mitbestimmen.

Vertraglich: spezifische Cybersicherheit-Klauseln als Anlage zum Werkvertrag, vereinbarte Meldefristen für Sicherheitsvorfälle, Dokumentationspflicht für Architektur und kritische Designentscheidungen. Diese Leistungen sind Bestandteil unseres Cybersicherheits-Portfolios und werden eng verzahnt mit DevOps und Cloud-Infrastruktur umgesetzt.

Nächster Schritt

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.

Häufige Fragen

Müssen wir unsere Entwickler ISO-27001-zertifizieren?

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.

Ist NIS2 auch für KMU unter fünfzig Mitarbeitern relevant?

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.

Wie oft sollte ein Penetrationstest wiederholt werden?

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.

Was kostet ein externer Penetrationstest für eine mittelgroße Webanwendung?

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.

Können wir SAST und SCA selbst betreiben?

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.