La supply chain passa attraverso il tuo build.
L'Art. 21(2) della NIS 2 elenca le misure di gestione del rischio informatico che le entità in ambito devono adottare, e il punto (d) riguarda la sicurezza della supply chain: gestire i rischi di sicurezza nelle relazioni con i fornitori e nei componenti da cui si dipende. Per la maggior parte dei team, la supply chain è concreta e risiede nel codice: le dipendenze che si installano, le versioni che si fissano e gli script di cui ci si fida durante il build.
The shapes the same control failure takes.
La sicurezza della supply chain si indebolisce ogni volta che una modifica introduce codice di terze parti con una verifica inferiore rispetto a prima. Le forme ricorrenti:
Uno script remoto viene passato a una shell
Un passaggio di build o setup recupera uno script da internet e lo esegue direttamente (curl passato a bash), eseguendo codice remoto non verificato con i privilegi del build.
Una dipendenza non è fissata
Una versione fissata viene modificata in un intervallo fluttuante o un tag mobile (latest, un branch), così una versione futura e non verificata può essere integrata silenziosamente.
Un controllo di integrità viene rimosso
Un lockfile, un checksum o una verifica della firma che garantiva di ottenere l'artefatto atteso viene rimosso o bypassato per far funzionare l'installazione.
Un nuovo componente arriva senza provenienza
Una dipendenza o un'immagine viene aggiunta da una fonte non verificata, senza traccia di provenienza o di chi la mantiene.
Un mirror o una allowlist interna viene bypassato
Una modifica recupera un pacchetto direttamente dall'upstream invece che dal mirror o registry interno verificato, eludendo i controlli su di esso.
Un passaggio di build che esegue uno script remoto.
Un Dockerfile richiede uno strumento CLI. L'installazione più rapida è il comando one-liner del fornitore che scarica ed esegue uno script. Funziona, ma significa che ogni build esegue qualsiasi cosa si trovi a quell'URL, non fissato e non verificato, con i privilegi del build.
FROM node:22-slim+ RUN curl -fsSL https://get.example-tool.dev/install.sh | bashCOPY . /appPassare uno script remoto a una shell esegue codice di terze parti non verificato durante il build, e ciò che quel URL fornisce può cambiare senza che tu lo sappia. L'Art. 21(2)(d) (sicurezza della supply chain) richiede che i rischi nelle dipendenze e nei fornitori siano gestiti. Fissa lo strumento a una versione specifica e verificalo (un checksum o un pacchetto noto), invece di eseguire qualsiasi cosa l'URL restituisca oggi.
Il rischio della supply chain viene valutato sulle dipendenze effettivamente integrate.
Un controllo ai sensi della NIS 2 esamina come un'entità gestisce la sicurezza dei propri fornitori e dei componenti da cui dipende: le dipendenze sono verificate, fissate e tracciate, e gli input di build sono affidabili. Una modifica che introduce una dipendenza non fissata o esegue uno script remoto durante il build rappresenta il rischio concreto della supply chain dietro questo, ed è visibile nel diff del manifest, lockfile o configurazione di build.
Una revisione, non un programma completo di supply chain.
heygrc segnalerà le modifiche che interessano una misura NIS 2 e citerà il punto in modo che la correzione avvenga nella pull request. Non esegue l'analisi della composizione del software né le valutazioni del rischio dei fornitori. Rileva il momento in cui una modifica introduce codice di terze parti con una verifica inferiore, nel diff.