Die Lieferkette verläuft durch Ihren Build-Prozess.
Art. 21(2) von NIS 2 listet die Maßnahmen zum Cybersecurity-Risikomanagement auf, die betroffene Organisationen ergreifen müssen, und Punkt (d) betrifft die Lieferketten-Sicherheit: das Management der Sicherheitsrisiken in den Beziehungen zu Ihren Lieferanten und den Komponenten, von denen Sie abhängig sind. Für die meisten Teams ist die Lieferkette konkret und im Code verankert: die Abhängigkeiten, die Sie installieren, die Versionen, die Sie festlegen, und die Skripte, denen Sie während des Builds vertrauen.
The shapes the same control failure takes.
Die Lieferketten-Sicherheit wird geschwächt, wenn eine Änderung Code von Dritten mit weniger Überprüfung als zuvor einbindet. Die wiederkehrenden Muster:
Ein Remote-Skript wird an eine Shell weitergeleitet
Ein Build- oder Setup-Schritt lädt ein Skript aus dem Internet herunter und führt es direkt aus (z. B. curl an bash weitergeleitet), wodurch unverifizierter Remote-Code mit den Berechtigungen des Builds ausgeführt wird.
Eine Abhängigkeit wird nicht mehr festgepinnt
Eine festgelegte Version wird in einen variablen Bereich oder ein bewegliches Tag (z. B. latest, ein Branch) geändert, sodass eine zukünftige, unverifizierte Version stillschweigend eingebunden werden kann.
Eine Integritätsprüfung wird entfernt
Eine Lock-Datei, Prüfsumme oder Signaturüberprüfung, die sicherstellte, dass das erwartete Artefakt erhalten wurde, wird entfernt oder umgangen, um eine Installation zu ermöglichen.
Eine neue Komponente ohne Herkunftsnachweis wird hinzugefügt
Eine Abhängigkeit oder ein Image wird von einer nicht geprüften Quelle hinzugefügt, ohne Aufzeichnung, woher es stammt oder wer es verwaltet.
Ein interner Mirror oder eine Allowlist wird umgangen
Eine Änderung lädt ein Paket direkt von der ursprünglichen Quelle herunter, anstatt vom geprüften internen Mirror oder Registry, und umgeht so die damit verbundenen Kontrollen.
Ein Build-Schritt, der ein Remote-Skript ausführt.
Eine Dockerfile benötigt ein CLI-Tool. Die schnellste Installationsmethode ist der Einzeiler des Anbieters, der ein Skript herunterlädt und ausführt. Es funktioniert, bedeutet aber, dass bei jedem Build der Code an dieser URL, unverifiziert und nicht festgepinnt, mit den Berechtigungen des Builds ausgeführt wird.
FROM node:22-slim+ RUN curl -fsSL https://get.example-tool.dev/install.sh | bashCOPY . /appDas Weiterleiten eines Remote-Skripts an eine Shell führt zur Ausführung von unverifiziertem Code Dritter während des Builds, und der Inhalt dieser URL kann sich ohne Ihr Wissen ändern. Art. 21(2)(d) (Lieferketten-Sicherheit) verlangt, dass die Risiken in Ihren Abhängigkeiten und Lieferanten verwaltet werden. Pinnen Sie das Tool auf eine spezifische Version und überprüfen Sie es (z. B. durch eine Prüfsumme oder ein bekanntes Paket), anstatt auszuführen, was die URL heute zurückgibt.
Lieferketten-Risiken werden an den tatsächlich eingebundenen Abhängigkeiten bewertet.
Eine Prüfung nach NIS 2 untersucht, wie eine Organisation die Sicherheit ihrer Lieferanten und der Komponenten, auf die sie sich verlässt, verwaltet: Werden Abhängigkeiten geprüft, festgepinnt und nachverfolgt, und sind Build-Eingaben vertrauenswürdig? Eine Änderung, die eine nicht festgepinnte Abhängigkeit einführt oder ein Remote-Skript während des Builds ausführt, ist das konkrete Lieferketten-Risiko dahinter, und es ist im Diff der Manifest-, Lock- oder Build-Konfigurationsdatei sichtbar.
Eine Prüfung, kein vollständiges Lieferketten-Programm.
heygrc markiert Änderungen, die eine NIS 2-Maßnahme betreffen, und verweist auf den entsprechenden Punkt, sodass die Korrektur im Pull Request erfolgt. Es führt keine Software-Zusammensetzungsanalyse oder Lieferantenrisikobewertungen durch. Es erkennt den Moment, in dem eine Änderung Code von Dritten mit weniger Überprüfung einbindet, im Diff.