Un cliente que está sujeto a la obligación de diligencia debida de la NIS2 debe ser capaz de demostrar que conoce los riesgos en su propia cadena de suministro. El software que desarrolla para ese cliente forma parte de esa cadena. En la práctica, esto se traduce en requisitos contractuales que actúan simultáneamente en dos aspectos: el producto que entrega y la forma en que lo produce. Ambos aparecen en el texto del contrato, a menudo como anexo del contrato de compra.
El núcleo es simple de recordar: el cliente no solo pregunta si el software funciona, sino también si puede demostrar cómo se mantiene seguro, quién puede acceder a él y qué ocurre si algo va mal. Esto supone un cambio respecto a antes, cuando la funcionalidad y el plazo de entrega eran a menudo los únicos puntos de discusión.
Requisitos del producto que entrega
El requisito contractual más común se refiere a la composición del propio software. Los clientes solicitan cada vez más un inventario de las bibliotecas utilizadas y los componentes de código abierto, lo que se denomina lista de materiales de software. El motivo es que una vulnerabilidad en un componente subyacente es un riesgo tan importante como un error en su propio código, y un cliente quiere poder identificar esos riesgos sin tener que leer el código fuente.
Además, se incluyen requisitos sobre cómo se detectan y corrigen las vulnerabilidades en el software y en qué plazo. Esto puede incluir análisis automatizados de puntos débiles conocidos, un procedimiento fijo para parches, o la cuestión de quién puede reportar una vulnerabilidad y dónde se envía. Para software existente, a veces también se pregunta por el período de soporte: cuánto tiempo sigue recibiendo actualizaciones de seguridad una versión.
Requisitos para su propia infraestructura de desarrollo
Un segundo grupo de requisitos no se centra en el producto, sino en el proceso mediante el cual se elabora: la infraestructura de desarrollo. Piense en quién tiene acceso al código fuente y al entorno en el que se construye y prueba, cómo se revisan los cambios antes de ser implementados en producción, y si existe separación entre un entorno de prueba, uno de aceptación y uno de producción. El uso de verificación multifactor para desarrolladores que tienen acceso al código fuente o a los sistemas de compilación también aparece en los contratos, así como la cuestión de quién gestiona las claves y credenciales de acceso asociadas al despliegue de software.
Algunos clientes también preguntarán sobre el origen del software que usted utiliza para construir: el compilador, las herramientas de compilación, los paquetes que se descargan durante la compilación. Esto se alinea con una comprensión más amplia de que un ataque no solo puede llegar a través del producto final, sino también a través de la fábrica en la que se fabrica.
Por qué estos requisitos se formulan de esta manera específica
La obligación de diligencia debida que subyace a todo esto requiere que una organización sujeta a obligaciones demuestre que evalúa y controla los riesgos en su propia cadena de suministro. La forma exacta en que esto se implementa varía según el país en la ley nacional basada en la directiva europea, y según el sector en el que opera el cliente. Lo que es un requisito firme en un contrato, puede aparecer como una pregunta sin compromiso en otro. Si desea saber cómo se estructura esa obligación en esencia, leer la explicación de cada obligación en nuestra base de conocimientos.
Importante recordar: es el cliente quien establece estos requisitos porque está sujeto a supervisión, no porque las empresas de software estén sujetas a la directiva como tales. Si y con qué rigor se aplique en su caso depende del sector y el tamaño de ese cliente específico. Para su situación particular, el texto de la ley nacional o el asesoramiento jurídico es el punto de partida adecuado, no una estimación general.
Qué significa esto para su preparación
La mayoría de estos requisitos se pueden responder adecuadamente con algo de preparación previa, y la respuesta que usted elabora una vez puede reutilizarla repetidamente con cada cliente siguiente. Un inventario de componentes utilizados, una breve descripción de su control de acceso y un procedimiento fijo para parches no son documentos que tenga que reinventar para cada contrato.
¿Desea ver primero si y cómo esto afecta a su empresa? Entonces la verificación que en unas pocas preguntas determina su posición en la cadena de suministro le ofrece una primera orientación, sin necesidad de que tenga una cuenta. Para las preguntas que los clientes plantean de manera concreta y la forma en que le ayudamos, lea más en la página de preguntas frecuentes o vea cómo resaldamos la información en la plataforma.
El banco de conocimientos gratuito y la verificación le dan una primera idea sin obligaciones. Si posteriormente desea transformar los requisitos contractuales en un expediente operativo con pruebas documentales y respuestas listas para usar a cuestionarios, ese es el momento para ver qué añade una suscripción.