NIS2 in einem Absatz
Die NIS2-Richtlinie (EU 2022/2555) erweitert EU-Cybersicherheitspflichten auf etwa 160.000 Organisationen in 18 Sektoren — Energie, Verkehr, Bankwesen, Gesundheit, digitale Infrastruktur, Herstellung kritischer Produkte und mehr — eingeteilt in „wesentliche" und „wichtige" Einrichtungen nach Sektor und Größe (grob: 250+ Beschäftigte oder 50 Mio. €+ Umsatz in Anhang-I-Sektoren für wesentlichen Status; 50–249 Beschäftigte oder 10–50 Mio. € Umsatz für wichtigen Status, mit einigen Unterschwellen-Ausnahmen für DNS-Anbieter, TLD-Register und Ähnliches). Jeder Mitgliedstaat setzt sie in nationales Recht um, daher variieren genaue Fristen und Aufsichtsbehörden je Land — diese Seite beschreibt die Richtlinie selbst, keine bestimmte nationale Umsetzung.
Artikel 21(2): die 10 Maßnahmenkategorien
Artikel 21(2) verlangt von Einrichtungen Maßnahmen, die mindestens diese zehn Kategorien abdecken — direkt aus dem Richtlinientext zitiert:
| § | Maßnahme |
|---|---|
| (a) | Konzepte für die Risikoanalyse und für die Sicherheit von Informationssystemen |
| (b) | Bewältigung von Sicherheitsvorfällen |
| (c) | Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement |
| (d) | Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen der Einrichtung und ihren unmittelbaren Anbietern oder Diensteanbietern |
| (e) | Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen |
| (f) | Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen im Bereich der Cybersicherheit |
| (g) | Grundlegende Verfahren im Bereich der Cyberhygiene und Schulungen im Bereich der Cybersicherheit |
| (h) | Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung |
| (i) | Sicherheit des Personals, Konzepte für die Zugriffskontrolle und Management von Anlagen |
| (j) | Verwendung von Multi-Faktor-Authentifizierung oder kontinuierlicher Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gesicherte Notfallkommunikationssysteme |
Hervorgehobene Zeilen sind die zwei Kategorien, für die ein Quellcode-Scan echte Nachweise liefern kann. Die anderen acht sind organisatorische, prozessuale oder Infrastrukturmaßnahmen — kein statisches Analysetool berührt sie.
Wo StaticCodeAudit tatsächlich passt
(e) Management und Offenlegung von Schwachstellen
Ein SARIF-2.1.0-Export ist genau die Art von strukturiertem, maschinenlesbarem Schwachstellen-Nachweis, den diese Kategorie verlangt: ein Scan-Lauf gegen einen bestimmten Commit, mit Regel, Schweregrad, Datei und Zeile jedes Funds — ein Nachweis, dass Schwachstellenmanagement zu einem bestimmten Zeitpunkt im Entwicklungszyklus stattgefunden hat, nicht nur die Behauptung, dass es stattfindet.
./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-high(d) Sicherheit der Lieferkette
Ein CycloneDX-1.5-SBOM listet jede Abhängigkeit auf, die ein Code einbindet — Name, Version, Package URL. Kombiniert mit den SARIF-Funden desselben Scans ist es die Art von Artefakt, auf dem ein Beschaffungs-Reviewer oder Prüfer aufbauen kann, wenn er „die allgemeine Qualität der Produkte und Cybersicherheitspraktiken" eines Anbieters bewertet — eine der Unter-Erwägungen, die NIS2 dieser Kategorie zuordnet.
./staticcodeaudit-linux-x86_64 /path/to/project --sbomEin sekundärer Punkt, der explizit gemacht werden sollte
Artikel 21(2)(d) verlangt von Einrichtungen auch, die Cybersicherheitspraktiken ihrer eigenen Anbieter abzuwägen — einschließlich der Frage, ob die Tools dieser Anbieter neue Datenflüsse einführen. Ein Offline-Scanner, der niemals Quellcode irgendwohin hochlädt, fügt der eigenen Lieferketten-Risikofläche des Codes keine neue SaaS-Abhängigkeit hinzu — anders als ein Cloud-SAST-Anbieter, den ein Sicherheitsteam dann ebenfalls bewerten müsste.
Was das nicht abdeckt — die ehrliche Liste
Acht der zehn Kategorien liegen außerhalb dessen, wofür ein Quellcode-Scanner Nachweise liefern kann, und kein Umfang an Scans ändert das:
- (a) Risikoanalyse und Sicherheitskonzepte — ein organisatorischer Prozess, kein Code-Artefakt.
- (b) Bewältigung von Sicherheitsvorfällen — erfordert einen Reaktionsprozess und ein Team, keinen Scan.
- (c) Betriebsaufrechterhaltung und Notfallwiederherstellung — Infrastruktur und Prozess, ohne Bezug zum Quellcode.
- (f) Konzepte zur Wirksamkeitsbewertung — eine Governance-Aktivität.
- (g) Schulungen zur Cyberhygiene — eine Personen-Aktivität.
- (h) Kryptografie-Konzept — ein schriftliches Konzept; ein Scan kann einen schwachen Algorithmus im Code markieren (Beitrag zu ASVS-Kapitel V11), kann aber das Konzept selbst weder verfassen noch genehmigen.
- (i) Personalsicherheit und Zugriffskontrollkonzept — organisatorisch, nicht auf Code-Ebene.
- (j) MFA und gesicherte Kommunikation — eine Infrastruktur-/Deployment-Entscheidung, keine Quellcode-Eigenschaft.
Häufig gestellte Fragen
Macht die Nutzung von StaticCodeAudit meine Organisation NIS2-konform?
Kein einzelnes Tool tut das. NIS2-Konformität ist eine organisatorische Pflicht, die alle zehn Kategorien von Artikel 21(2) abdeckt, von denen die meisten Konzept und Prozess sind, keine Software. StaticCodeAudit erzeugt für zwei davon — (d) und (e) — nutzbare Nachweise als Teil eines breiteren Compliance-Programms, nicht als dessen Ersatz.
Falle ich überhaupt in den Anwendungsbereich von NIS2?
Der Anwendungsbereich hängt von Ihrem Sektor ab (einer der 18 in Anhang I oder II der Richtlinie gelisteten) und Ihrer Größe (grob 50+ Beschäftigte oder 10 Mio. €+ Umsatz, mit genauen Schwellenwerten und einigen Unterschwellen-Ausnahmen). Das ist eine rechtliche Feststellung, die die Rechtsabteilung oder der Compliance-Beauftragte Ihrer Organisation treffen muss, nicht etwas, das eine Scanner-Ausgabe beantworten kann.
Referenziert die SARIF-/SBOM-Ausgabe NIS2 direkt?
Nein — die Exporte sind Standardformate (OASIS SARIF 2.1.0, OWASP CycloneDX 1.5) ohne NIS2-spezifische Felder. Die Verbindung zu Artikel 21(2) liegt darin, wie der Nachweis von Ihrem Compliance-Prozess genutzt wird, nicht in etwas, das in der Datei selbst kodiert ist.
Wie hängt das mit den ISO-27001- und ASVS-Matrizen auf der Standards-Seite zusammen?
NIS2 schreibt keinen bestimmten technischen Standard vor, aber Mitgliedstaaten und Aufsichtsbehörden verweisen häufig auf ISO/IEC 27001 und ähnliche Frameworks als Nachweis für Maßnahmen „nach dem Stand der Technik". Die von jedem Scan erzeugten Compliance-Matrizen (ISO 27001 Annex A, ASVS, NIST CSF) können als unterstützendes Material in diesem breiteren Gespräch dienen, zu denselben ehrlichen Bedingungen: nur teilweise, im Code sichtbare Abdeckung.
Die echten Nachweise sehen, die ein Scan erzeugt
Öffnen Sie den Live-Demo-Bericht — keine Installation, keine Anmeldung — und sehen Sie sich die SARIF-/SBOM-Exporte und Compliance-Matrizen direkt an.
Live-Bericht öffnen Mehr auf der Seite für regulierte Branchen