NIS 2 (Richtlinie (EU) 2022/2555) nennt in Art. 21(2) zehn Maßnahmen zum Cybersecurity-Risikomanagement, und die meisten Compliance-Beschreibungen behandeln diese als Politik und Prozess: eine Informationssicherheitsrichtlinie, ein Vorfallbehandlungsverfahren, ein Business-Continuity-Plan. Das ist für den Großteil der Liste korrekt. Für eine Maßnahme, die durch das tatsächlich ausgelieferte Produkt einer Mannschaft entschieden wird, ist dies unvollständig: Art. 21(2)(e), Sicherheit bei der Beschaffung, Entwicklung und Wartung von Netzwerk- und Informationssystemen, einschließlich Schwachstellenbehandlung und -offenlegung.
Dieser Leitfaden richtet sich an Entwickler, deren Organisation im Anwendungsbereich von NIS 2 liegt, also eine wesentliche oder wichtige Einrichtung nach der Richtlinie oder ein Zulieferer, der eine solche beliefert, und die wissen möchten, welcher Teil dieser Maßnahme durch eine Pull-Request-Überprüfung tatsächlich erfasst werden kann, unabhängig von den Lieferketten- und Cyber-Hygiene-Maßnahmen, die die Framework-Zentrale bereits abdeckt.
Für wen dies gilt und die Größenklassenregel
NIS 2 gilt für mittlere und große Einrichtungen nach der Größenklassenregel (im Allgemeinen 50 oder mehr Mitarbeiter oder Jahresumsatz und Jahresbilanzsumme jeweils über 10 Millionen EUR), die in den in Anhang I und Anhang II der Richtlinie genannten Sektoren tätig sind: Energie, Verkehr, Bankwesen, Gesundheit und digitale Infrastruktur unter anderem in Anhang I; Postdienste, Chemie, Lebensmittel und verarbeitendes Gewerbe unter anderem in Anhang II. Allein der Sektor entscheidet nicht über die Einstufung als wesentlich oder wichtig: Innerhalb von Anhang I wird eine große Einrichtung, die die Größenklassenregel erfüllt, in der Regel als 'wesentlich' eingestuft, eine mittlere Einrichtung in der Regel als 'wichtig'; eine Einrichtung aus Anhang II, die die Größenklassenregel erfüllt, wird unabhängig von der Größe in der Regel als 'wichtig' eingestuft, die Größe führt hier nicht zu einer weiteren Unterteilung wie in Anhang I; und eine kleinere Gruppe von Einrichtungen (bestimmte Anbieter digitaler Infrastruktur, öffentliche Verwaltung und einige andere Sonderkategorien) wird unabhängig von der Größe, nach Name und nicht nach der Größenklassenregel, in den Anwendungsbereich einbezogen und manchmal als wesentlich eingestuft. Ob Ihre Organisation oder der Kunde, für den Sie Software entwickeln, als wesentlich, wichtig oder außerhalb des Anwendungsbereichs eingestuft wird, ist eine rechtliche Klassifizierungsfrage für Ihr Compliance- oder Rechtsteam und keine Entscheidung, die durch eine Code-Überprüfung getroffen wird. Wenn diese Diskussion noch nicht stattgefunden hat, führen Sie sie, bevor Sie diesen Leitfaden als Compliance-Programm behandeln.
Dieser Leitfaden geht davon aus, dass die Klassifizierungsfrage bereits geklärt ist und die Organisation im Anwendungsbereich liegt. Er ist kein Ersatz für das Risikomanagement-Framework, das die Richtlinie verlangt, die Vorfallbehandlung nach Art. 21(2)(b) und die Vorfallmeldung nach Art. 23 erfordern, oder die Verantwortung der Leitungsorgane nach Art. 20 zuweist. Er behandelt die eine Maßnahme aus Art. 21(2), die in einem Diff sichtbar wird.
Die Maßnahme, die tatsächlich in einem Diff sichtbar wird: Art. 21(2)(e)
Zwei der zehn Maßnahmen aus Art. 21(2) haben bereits eigene Seiten für Kontrollen im Code auf dieser Website: Lieferketten-Sicherheit (Art. 21(2)(d), eine nicht fixierte oder nicht überprüfte Abhängigkeit) und grundlegende Cyber-Hygiene (Art. 21(2)(g), eine bekannte Schwachstelle, die nicht gepatcht wurde). Punkt (e), Sicherheit bei der Beschaffung, Entwicklung und Wartung von Netzwerk- und Informationssystemen, ist ein anderer Ausschnitt: Er betrifft, wie Software entwickelt wird und wie darin enthaltene Schwachstellen gefunden und offen gelegt werden, nicht welche Abhängigkeiten Sie einbinden oder welche Patches Sie anschließend anwenden.
In der Praxis lässt sich dies auf zwei technische Gewohnheiten abbilden. Erstens: die Sicherheitstests, die ein Entwicklungsprozess vor dem Ausliefern einer Änderung durchläuft: ein statisches Analyse-Gate, ein erforderlicher Sicherheitsüberprüfungsschritt, eine Abhängigkeits- oder Fuzz-Prüfung, die bestanden werden muss. Zweitens: ein funktionierender Weg zur Offenlegung von Schwachstellen für die Software, sobald sie läuft: ein Sicherheitskontakt, eine veröffentlichte Annahmestelle für externe Meldungen, ein Weg für jemanden, der eine Schwachstelle findet, um Sie darüber zu informieren. Beide können in einem einzigen Pull Request untergraben werden: Ein Gate wird deaktiviert, um eine Veröffentlichung zu ermöglichen, oder eine neue extern erreichbare Oberfläche wird ohne zugehörigen Offenlegungsweg ausgeliefert.
Praktisches Beispiel: Das Gate wird deaktiviert, um eine Frist einzuhalten
Ein Team steht unter Zeitdruck, um einen neuen öffentlich zugänglichen API-Endpunkt auszuliefern, die erste kundenorientierte Oberfläche des Unternehmens, die aus dem offenen Internet erreichbar ist. Der Pull Request, der den Endpunkt hinzufügt, enthält auch eine nicht zusammenhängende einzeilige Änderung: Das erforderliche statische Analyse-Sicherheitsgate des Repositorys, das normalerweise vor dem Merge bestanden werden muss, wird als nicht blockierend markiert, mit einem Kommentar, der auf ein Follow-up-Ticket verweist. Der Endpunkt selbst ist gut gebaut, mit Eingabevalidierung und Auth-Prüfungen, die eine manuelle Überprüfung bestehen. Das im Kommentar referenzierte Follow-up-Ticket existiert nicht, und nichts im PR stellt das Gate nach dem Ausliefern der Version wieder als blockierend her. Separat davon hat das Unternehmen keinen Sicherheitskontakt, keine security.txt oder keine veröffentlichte Annahmestelle für Schwachstellenmeldungen: Bisher waren nur interne Tools exponiert, daher hat niemand eine benötigt.
Wird dieser PR nur als Feature überprüft, ist er in Ordnung: Der Endpunkt funktioniert, die Tests bestehen, die Frist wird eingehalten. Wird er jedoch gegen Art. 21(2)(e) überprüft, ist er gleichzeitig zwei Dinge. Er schwächt die Sicherheitstests, die der Entwicklungsprozess vor dem Ausliefern des Codes durchführen soll, ohne eine definierte Ausnahme oder einen Wiederherstellungspfad, was genau die Hälfte der Maßnahme zur Beschaffung und Entwicklung betrifft. Und es ist der Moment, in dem der fehlende Offenlegungsweg des Unternehmens aufhört, eine theoretische Lücke zu sein, und zu einer realen wird: Es gibt nun eine aktive, extern erreichbare Oberfläche, aber keinen Weg für jemanden, der eine Schwachstelle darin findet, um das Unternehmen darüber zu informieren, was die Offenlegungshälfte betrifft. Keines der Probleme betrifft die Frage, ob der Code des Endpunkts korrekt ist. Beide betreffen die Frage, ob der Prozess und die Organisation die Maßnahme noch erfüllen, die davon ausging, dass das Gate aktiv bleibt und irgendwo ein Offenlegungsweg existiert.
Ein Befund, der Art. 21(2)(e) zitiert, entscheidet nicht, ob das Gate aus einem triftigen Grund deaktiviert werden sollte, den Offenlegungsprozess entwirft oder den Sicherheitstest selbst durchführt. Er macht die Änderung sichtbar, während der PR noch offen ist, sodass der Autor oder ein Prüfer entweder das Gate mit einer nachverfolgbaren Ausnahme wiederherstellen und markieren kann, dass die Organisation vor dem Ausliefern dieses Endpunkts einen Offenlegungskanal benötigt, da dieser sonst die erste Anlaufstelle für eine Meldung ohne Ziel wäre. Wenn bereits ein Offenlegungsweg auf Organisationsebene existiert, trifft der zweite Teil nicht zu: Die Lücke ist nur dann real, wenn keiner existiert.
Worauf man bei der Überprüfung achten sollte, ohne zum NIS-2-Juristen zu werden
Wenn ein Pull Request die CI-Konfiguration berührt, fragen Sie, ob er einen erforderlichen Sicherheitstest-Schritt deaktiviert, schwächt oder umgeht und, falls ja, ob derselbe PR (oder ein verlinkter) dokumentiert, warum und wann er wieder aktiviert wird. Ein Gate, das ohne Wiederherstellungspfad deaktiviert wird, ist der Hinweis auf Art. 21(2)(e). Wenn ein Pull Request einen neuen extern erreichbaren Endpunkt, Dienst oder eine Integration hinzufügt, fragen Sie, ob bereits ein Offenlegungsweg für Schwachstellen auf Organisationsebene existiert. Falls ja, erbt die neue Oberfläche diesen, und es ist nichts Weiteres erforderlich. Falls nein, ist dies eine Lücke, die es wert ist, angesprochen zu werden, auch wenn es sich um eine einmalige organisatorische Korrektur handelt und nicht um eine pro-PR-Korrektur.
Dies ist eine engere Anforderung als die gesamte Maßnahme. Sie deckt nicht ab, ob Ihre Entwicklungslebenszyklus-Dokumentation vollständig ist oder ob Ihr Schwachstellenbehandlungsprozess alle Elemente erfüllt, die die Richtlinie beschreibt. Das sind Prozessfragen für diejenigen, die Ihr NIS-2-Programm verantworten. Sie betrifft die beiden Stellen, an denen ein Pull Request stillschweigend die Arbeit untergraben kann, die dieses Programm bereits geleistet hat.
Wo heygrc ins Spiel kommt und die Ehrlichkeitsgrenze
heygrc ist darauf ausgelegt, jeden Pull Request gegen die von Ihnen ausgewählten Frameworks zu prüfen, einschließlich NIS 2, wenn aktiviert, und den Punkt zu benennen, den eine Änderung scheinbar berührt, z. B. Art. 21(2)(e) bei einem deaktivierten Sicherheitsgate oder einem neuen Endpunkt ohne sichtbaren Offenlegungsweg, Art. 21(2)(d) bei einer nicht fixierten Abhängigkeit, Art. 21(2)(g) bei einem zurückgehaltenen Patch. Der Befund ist ein Review-Kommentar mit der angehängten Klausel, sodass Autor und Prüfer mit vollständigen Informationen entscheiden können. Es zertifiziert keine NIS-2-Compliance, schreibt keine Offenlegungsrichtlinie für Schwachstellen, führt keine Sicherheitstests durch, klassifiziert keine Einrichtung oder reicht die in Art. 23 geforderten Vorfallmeldungen ein. Diese bleiben menschliche und organisatorische Pflichten.
Wenn Ihr Team bereits ein SAST- oder Code-Qualitäts-Tool für denselben Pull Request ausführt, behalten Sie es bei. Dieses Tool prüft, ob der Code selbst korrekt und sicher ist. Art. 21(2)(e) prüft, ob der Prozess um den Code herum, das Gate, das hätte laufen sollen, und der Weg, den jemand nutzt, um eine Schwachstelle zu melden, noch Bestand hat. Der oben genannte Endpunkt kann alle Qualitätsprüfungen bestehen und die Maßnahme dennoch schwächen. Führen Sie beide Ebenen aus, keine ersetzt die andere.