De supply chain loopt door je build.
Art. 21(2) van NIS 2 somt de cybersecurity risicobeheermaatregelen op die entiteiten binnen de scope moeten nemen, en punt (d) is supply-chain security: het beheersen van de beveiligingsrisico's in de relaties met je leveranciers en de componenten waar je van afhankelijk bent. Voor de meeste teams is de supply chain concreet en leeft in code: de afhankelijkheden die je installeert, de versies die je vastpint en de scripts die je vertrouwt tijdens de build.
The shapes the same control failure takes.
Supply-chain security verzwakt telkens een wijziging code van derden binnenhaalt met minder verificatie dan voorheen. De terugkerende patronen:
Een extern script wordt doorgestuurd naar een shell
Een build- of instapstap haalt een script van internet en voert het direct uit (curl doorgestuurd naar bash), waardoor onverifieerde externe code wordt uitgevoerd met de rechten van de build.
Een afhankelijkheid is niet vastgepind
Een vastgepinde versie wordt gewijzigd in een zwevend bereik of een bewegend tag (latest, een branch), zodat een toekomstige, onverifieerde versie stilletjes kan worden binnen gehaald.
Een integriteitscontrole wordt verwijderd
Een lockfile, checksum of handtekeningsverificatie die ervoor zorgde dat je het verwachte artefact ontving, wordt verwijderd of omzeild om een installatie mogelijk te maken.
Een nieuwe component arriveert zonder herkomst
Een afhankelijkheid of image wordt toegevoegd vanaf een niet-gecontroleerde bron, zonder registratie van waar het vandaan komt of wie het onderhoudt.
Een interne mirror of allowlist wordt omzeild
Een wijziging haalt een pakket direct van upstream in plaats van de gecontroleerde interne mirror of registry, waardoor de controles daarop worden omzeild.
Een buildstap die een extern script uitvoert.
Een Dockerfile heeft een CLI-tool nodig. De snelste installatie is de éénregelige opdracht van de leverancier die een script downloadt en uitvoert. Het werkt, en betekent dat elke build uitvoert wat er op die URL staat, niet vastgepind en onverifieerd, met de rechten van de build.
FROM node:22-slim+ RUN curl -fsSL https://get.example-tool.dev/install.sh | bashCOPY . /appHet doorsturen van een extern script naar een shell voert onverifieerde code van derden uit tijdens de build, en wat die URL serveert kan veranderen zonder dat je het weet. Art. 21(2)(d) (supply chain security) verwacht dat de risico's in je afhankelijkheden en leveranciers worden beheerst. Pin de tool aan een specifieke versie en verifieer deze (een checksum of een bekend pakket), in plaats van uit te voeren wat de URL vandaag retourneert.
Supply-chain risico wordt beoordeeld op basis van de afhankelijkheden die je daadwerkelijk binnenhaalt.
Een inspectie onder NIS 2 kijkt naar hoe een entiteit de beveiliging van haar leveranciers en de componenten waar ze van afhankelijk is, beheert: worden afhankelijkheden gecontroleerd, vastgepind en bijgehouden, en worden build-inputs vertrouwd. Een wijziging die een niet-vastgepinde afhankelijkheid introduceert of een extern script tijdens de build uitvoert, is het concrete supply-chain risico daarachter, en dit is zichtbaar in de diff van het manifest, lockfile of buildconfig.
Een review, geen volledig supply-chain programma.
heygrc markeert wijzigingen die een NIS 2-maatregel raken en citeert het artikel, zodat de oplossing in de pull request plaatsvindt. Het voert geen software-composition analyse of leveranciersrisicobeoordelingen uit. Het vangt het moment op waarop een wijziging code van derden binnenhaalt met minder verificatie, in de diff.