La cadena de suministro pasa por tu proceso de compilación.
El Art. 21(2) de NIS 2 enumera las medidas de gestión de riesgos de ciberseguridad que las entidades en el ámbito de aplicación deben adoptar, y el punto (d) es la seguridad de la cadena de suministro: gestionar los riesgos de seguridad en las relaciones con tus proveedores y los componentes de los que dependes. Para la mayoría de los equipos, la cadena de suministro es concreta y reside en el código: las dependencias que instalas, las versiones que fijas y los scripts en los que confías durante la compilación.
The shapes the same control failure takes.
La seguridad de la cadena de suministro se debilita cada vez que un cambio incorpora código de terceros con menos verificación que antes. Las formas recurrentes:
Un script remoto se canaliza a un shell
Un paso de compilación o configuración recupera un script de internet y lo ejecuta directamente (curl canalizado a bash), ejecutando código remoto no verificado con los privilegios que tenga el proceso de compilación.
Una dependencia no está fijada
Una versión fijada se cambia a un rango flotante o una etiqueta móvil (latest, una rama), de modo que una versión futura no verificada pueda incorporarse silenciosamente.
Se elimina una verificación de integridad
Se elimina o se omite un archivo de bloqueo, una suma de comprobación o una verificación de firma que garantizaba que se obtenía el artefacto esperado.
Llega un nuevo componente sin procedencia
Se añade una dependencia o imagen de una fuente no evaluada, sin registro de su origen o de quién la mantiene.
Se omite un espejo interno o una lista de permitidos
Un cambio recupera un paquete directamente de la fuente original en lugar del espejo o registro interno evaluado, eludiendo los controles aplicados a este.
Un paso de compilación que ejecuta un script remoto.
Un Dockerfile necesita una herramienta de CLI. La instalación más rápida es el comando de una línea del proveedor, que descarga y ejecuta un script. Funciona, pero significa que cada compilación ejecuta lo que haya en esa URL, sin fijar versión ni verificar, con los privilegios del proceso de compilación.
FROM node:22-slim+ RUN curl -fsSL https://get.example-tool.dev/install.sh | bashCOPY . /appCanalizar un script remoto a un shell ejecuta código de terceros no verificado en tiempo de compilación, y lo que sirva esa URL puede cambiar sin que lo sepas. El Art. 21(2)(d) (seguridad de la cadena de suministro) exige que los riesgos en tus dependencias y proveedores se gestionen. Fija la herramienta a una versión específica y verifícala (con una suma de comprobación o un paquete conocido), en lugar de ejecutar lo que la URL devuelva hoy.
El riesgo de la cadena de suministro se evalúa en las dependencias que realmente incorporas.
Una inspección bajo NIS 2 examina cómo una entidad gestiona la seguridad de sus proveedores y los componentes en los que se basa: ¿se evalúan, fijan y rastrean las dependencias y se confía en las entradas de compilación? Un cambio que introduzca una dependencia no fijada o ejecute un script remoto en la compilación es el riesgo concreto de la cadena de suministro detrás de esto, y es visible en el diff del manifiesto, el archivo de bloqueo o la configuración de compilación.
Una revisión, no un programa completo de cadena de suministro.
heygrc marca los cambios que afectan a una medida de NIS 2 y cita el punto para que la corrección se realice en la solicitud de extracción. No ejecuta tu análisis de composición de software ni tus evaluaciones de riesgo de proveedores. Detecta el momento en que un cambio incorpora código de terceros con menos verificación, en el diff.