La chaîne d'approvisionnement passe par votre build.
L'article 21(2) de la NIS 2 énumère les mesures de gestion des risques cybernétiques que les entités concernées doivent mettre en œuvre, et le point (d) concerne la sécurité de la chaîne d'approvisionnement : la gestion des risques de sécurité dans les relations avec vos fournisseurs et les composants dont vous dépendez. Pour la plupart des équipes, la chaîne d'approvisionnement est concrète et réside dans le code : les dépendances que vous installez, les versions que vous fixez et les scripts en lesquels vous avez confiance lors de la construction.
The shapes the same control failure takes.
La sécurité de la chaîne d'approvisionnement s'affaiblit chaque fois qu'une modification intègre du code tiers avec moins de vérification qu'auparavant. Les formes récurrentes :
Un script distant est transmis à un shell
Une étape de construction ou de configuration récupère un script depuis Internet et l'exécute directement (curl transmis à bash), exécutant ainsi du code distant non vérifié avec les privilèges de la construction.
Une dépendance n'est plus fixée
Une version fixée est modifiée en une plage flottante ou une balise mobile (latest, une branche), de sorte qu'une version future et non vérifiée peut être intégrée silencieusement.
Une vérification d'intégrité est supprimée
Un fichier de verrouillage, une somme de contrôle ou une vérification de signature qui garantissait que vous obteniez l'artefact attendu est supprimé ou contourné pour permettre une installation.
Un nouveau composant arrive sans provenance
Une dépendance ou une image est ajoutée à partir d'une source non vérifiée, sans trace de son origine ou de son mainteneur.
Un miroir ou une liste blanche interne est contourné
Une modification récupère un package directement depuis l'amont au lieu du miroir ou du registre interne vérifié, contournant ainsi les contrôles associés.
Une étape de build qui exécute un script distant.
Un Dockerfile a besoin d'un outil CLI. L'installation la plus rapide est la commande en une ligne du fournisseur, qui télécharge et exécute un script. Cela fonctionne, mais cela signifie que chaque build exécute ce qui se trouve à cette URL, non fixé et non vérifié, avec les privilèges de la construction.
FROM node:22-slim+ RUN curl -fsSL https://get.example-tool.dev/install.sh | bashCOPY . /appTransmettre un script distant à un shell exécute du code tiers non vérifié lors de la construction, et ce que cette URL fournit peut changer à votre insu. L'article 21(2)(d) (sécurité de la chaîne d'approvisionnement) exige que les risques liés à vos dépendances et fournisseurs soient gérés. Fixez l'outil à une version spécifique et vérifiez-le (par une somme de contrôle ou un package connu), plutôt que d'exécuter ce que l'URL retourne aujourd'hui.
Le risque de la chaîne d'approvisionnement est évalué au niveau des dépendances que vous intégrez réellement.
Une inspection dans le cadre de la NIS 2 examine comment une entité gère la sécurité de ses fournisseurs et des composants sur lesquels elle s'appuie : les dépendances sont-elles vérifiées, fixées et suivies, et les entrées de build sont-elles de confiance ? Une modification qui introduit une dépendance non fixée ou exécute un script distant lors de la construction est le risque concret de la chaîne d'approvisionnement derrière cela, et il est visible dans le diff du manifeste, du fichier de verrouillage ou de la configuration de build.
Une revue, pas un programme complet de sécurité de la chaîne d'approvisionnement.
heygrc signale les modifications qui concernent une mesure NIS 2 et cite le point afin que la correction se fasse dans la pull request. Il n'exécute pas votre analyse de composition logicielle ni vos évaluations des risques fournisseurs. Il détecte le moment où une modification intègre du code tiers avec moins de vérification, au niveau du diff.