Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- La CRA, FedRAMP, NIS 2 y PCI DSS plantean las mismas dos preguntas sobre tus componentes de código abierto: qué es lo que distribuyes y qué ocurre cuando se detecta una vulnerabilidad.
- Se diferencian en cuanto al plazo (el PCI DSS cuenta a partir de la publicación del parche, FedRAMP a partir de la evaluación, mientras que la CRA y la NIS 2 no establecen ningún plazo específico), en quién revisa el registro y en cuánto tiempo hay que conservarlo (solo la CRA especifica un plazo: al menos 10 años).
- Ninguna de ellas explica cómo determinar la procedencia de un componente, ni quién se encarga de proporcionar la solución una vez que sus responsables dejan de ocuparse de él.
- SecureChain da respuesta a ambas cuestiones: los paquetes se someten a un proceso de verificación, se recompilan a partir del código fuente, se actualizan con parches en el marco de un SLA y se entregan con información sobre su procedencia, una SBOM y declaraciones VEX.
La Ley de Resiliencia Cibernética (CRA), el Programa Federal de Gestión de Riesgos y Autorizaciones (FedRAMP), la norma NIS 2 y la Norma de Seguridad de Datos del Sector de Tarjetas de Pago (PCI DSS) abarcan, cada una de ellas, mucho más que las pruebas de cumplimiento de la cadena de suministro de software, y cada una plantea cuestiones que pueden llegar a afectar a los paquetes de código abierto incluidos en su producto. Una de esas cuestiones ya tiene una fecha concreta: la norma PCI DSS exige un inventario de componentes de terceros a partir del 31 de marzo de 2025.
Imaginemos una empresa hipotética que vende en la UE, presta servicios a una entidad sujeta a la Directiva NIS 2, gestiona un servicio federal en la nube y maneja datos de titulares de tarjetas. Un paquete de código abierto podría suscitar preguntas por parte de una autoridad de vigilancia del mercado, del cliente sujeto a la Directiva NIS 2, de una agencia federal y de un evaluador de pagos. ¿De dónde procede y quién se encargará de aplicar los parches cuando sus responsables dejen de hacerlo?
Los cuatro documentos se solapan en cuanto a contenido y difieren en quién muestra qué, a quién y durante cuánto tiempo. El registro al que se refiere el título es SecureChain, de TuxCare, que distribuye paquetes de código abierto a través de un repositorio seleccionado.
A quién va dirigido cada documento
Cada documento utiliza su propio término para referirse a la parte a la que va dirigido, y estos términos no son intercambiables. La CRA se dirige al fabricante, que el artículo 3(13) define como una persona que desarrolla o fabrica productos con elementos digitales, o encarga su fabricación, y los comercializa bajo su propio nombre o marca comercial. El «Playbook» de FedRAMP atribuye la responsabilidad principal de los controles de seguridad al proveedor de servicios en la nube, y las normas de 2026 se refieren al «proveedor». El Manual describe el proceso de la Rev. 5; FedRAMP lo aloja en su sitio web heredado a modo de referencia mientras se realiza la transición a las normas de 2026. La NIS 2 abarca las entidades esenciales e importantes, que los artículos 2 y 3 definen principalmente por sector y tamaño. La norma PCI DSS se aplica a las entidades que almacenan, procesan o transmiten datos de titulares de tarjetas o que podrían afectar a su seguridad. Esto incluye a los proveedores de servicios, que son entidades distintas de las marcas de pago que procesan, almacenan o transmiten datos de titulares de tarjetas en nombre de otra entidad, o que prestan servicios que podrían afectar a la seguridad del entorno de datos de los titulares de tarjetas.
| Documento | Naturaleza jurídica | Dirigido a | Situación a 28 de octubre de 2026 | Fundamentos |
|---|---|---|---|---|
| CRA, Reglamento (UE) 2024/2847 | Reglamento, vinculante en su totalidad y de aplicación directa | Fabricante (art. 3, apartado 13) | Entrará en vigor el 11 de diciembre de 2027. El artículo 14 entrará en vigor el 11 de septiembre de 2026. | Texto de encuadernación |
| Manual de supervisión continua de FedRAMP, versión 1.0 (17 de noviembre de 2025) y Normativa consolidada para 2026 | Orientaciones del programa (Manual) y normas del programa | Proveedor de servicios en la nube (Playbook), proveedor (normas de 2026) | Conjuntos de normas sobre detección y respuesta ante vulnerabilidades (VDR) y evaluación e información sobre vulnerabilidades (VER): certificación inicial y continua a partir del 7 de diciembre de 2026. El periodo de gracia finaliza el 7 de marzo de 2027. | Guía (Manual). Las normas marcadas como obligatorias. |
| NIS 2, Directiva (UE) 2022/2555 | Directiva, transpuesta a la legislación nacional de cada Estado miembro | Entidades esenciales e importantes (artículos 2 y 3) | Las medidas de los Estados miembros debían presentarse antes del 17 de octubre de 2024 y son de aplicación a partir del 18 de octubre de 2024 (art. 41, apartado 1). | Vinculante para los Estados miembros |
| PCI DSS v4.0.1 (junio de 2024) | Estándar del sector | Entidades que almacenan, tratan o transmiten datos de los titulares de tarjetas (artículo 2) | Versión 4.0.1, junio de 2024. El requisito 6.3.2 es obligatorio desde el 31 de marzo de 2025. | Estándar del sector |
Una empresa puede desempeñar más de una de estas funciones a la vez, como por ejemplo la de fabricante según la CRA y la de proveedor de servicios en la nube según FedRAMP, por lo que su función determina qué preguntas del documento le son aplicables. Lo que se debe presentar como prueba del cumplimiento de la cadena de suministro de software recibe un nombre diferente en cada documento. La CRA solicita documentación técnica; el «Playbook» de FedRAMP exige entregables y pruebas justificativas; la NIS 2 exige pruebas de implementación; y la norma PCI DSS exige que un evaluador examine la documentación.
Nota: La norma PCI DSS v4.0.1 deja en manos de las marcas de pago, los adquirentes y otras organizaciones que gestionan programas de cumplimiento la decisión de quién debe cumplir con la norma o validar dicho cumplimiento (Sección 2).
Lo que cada uno pregunta sobre los componentes de terceros
El contenido de tu software recibe un nombre diferente en cada documento. La CRA denomina directamente a los componentes de código abierto. La norma NIS 2 habla de proveedores directos y proveedores de servicios. El Manual de FedRAMP, que no menciona el código abierto ni las listas de materiales de software, aborda el inventario y las vulnerabilidades, mientras que la norma PCI DSS identifica los componentes de terceros dentro del software a medida y personalizado.
| Documento (naturaleza) | Qué se pregunta sobre los componentes | Qué muestras y a quién | Retención declarada | Fundamentos |
|---|---|---|---|---|
| CRA (normativa) | Diligencia debida respecto a los componentes de terceros (art. 13, apartado 5). Notificar las vulnerabilidades de los componentes al responsable del mantenimiento y subsanarlas (art. 13, apartado 6). Identificar y documentar los componentes, mediante una lista de materiales de software que incluya, como mínimo, las dependencias de nivel superior (anexo I, parte II, apartado 1). | Documentación técnica (anexo VII), que deberá estar a disposición de las autoridades de vigilancia del mercado (art. 13, apartado 13). Lista de componentes del software, previa solicitud motivada de la autoridad (anexo VII, punto 8). | Documentación técnica: al menos 10 años después de la comercialización del producto, o durante el periodo de asistencia técnica si este fuera más largo (art. 13, apartado 13) | Texto de encuadernación |
| FedRAMP (orientaciones y normas del programa) | Realizar un inventario al menos una vez al mes (Manual, sección 2). Cada vulnerabilidad específica se registra como un elemento independiente del plan de acción y los hitos (POA&M) (sección 3). La supervisión de la cadena de suministro figura como técnica de detección (VDR-CSO-DET). | Envío mensual de POA&M y del inventario al repositorio seguro para su revisión por parte de la agencia (Playbook). Informe mensual sobre la actividad relacionada con las vulnerabilidades a todas las partes pertinentes (VER-TFR-MHR). | No se especifica ni en el «Playbook» ni en el reglamento de VER. | Guía (Manual). Las reglas marcadas son obligatorias. |
| NIS 2 (directiva) | Seguridad de la cadena de suministro, incluidas las relaciones con los proveedores directos (art. 21, apartado 2, letra d)). Gestión y divulgación de vulnerabilidades (art. 21, apartado 2, letra e)). Evaluar las vulnerabilidades, la calidad de los productos y las prácticas de ciberseguridad de cada proveedor directo, incluidos los procedimientos de desarrollo seguro (art. 21, apartado 3). | Previa solicitud, presentación ante la autoridad competente de pruebas que demuestren la aplicación de las políticas de ciberseguridad (art. 32, apartado 2, letra g), para las entidades esenciales; art. 33, apartado 2, letra f), para las entidades importantes). | No se menciona en los artículos 21, 32 ni 33 | Vinculante para los Estados miembros |
| PCI DSS v4.0.1 (norma del sector) | Inventario del software a medida y personalizado, así como de sus componentes de terceros (6.3.2). Los parches para vulnerabilidades críticas se instalan en el plazo de un mes desde su publicación (6.3.3). Inventario de los componentes del sistema incluidos en el ámbito de aplicación (12.5.1). | Documentación y entrevistas examinadas por un evaluador (6.3.2.a, 6.3.2.b). | No se indica nada en los apartados 6.3.2, 6.3.3 ni 12.5.1 | Estándar del sector |
Nota: El apartado 5 del artículo 13 establece la obligación de diligencia debida respecto a los componentes de código libre y de código abierto, incluso cuando no se hayan puesto a disposición en el marco de una actividad comercial.
En qué aspectos se solapan las pruebas de cumplimiento de la cadena de suministro de software y en cuáles no
La coincidencia radica en el contenido de ambas preguntas. Una se refiere a los componentes que se suministran. Tanto la CRA como el Playbook y la norma PCI DSS exigen, cada uno a su manera, algún tipo de inventario. La NIS 2 incluye la gestión de activos entre las medidas del artículo 21, apartado 2, letra i), y pregunta por los proveedores, mientras que el artículo 21 no menciona ninguna lista de componentes. La otra cuestión es qué ocurre una vez que se detecta una vulnerabilidad, y los cuatro documentos abordan este tema. Según la CRA, la corrección debe realizarse sin demora (Anexo I, Parte II, apartado 2). La NIS 2 incluye la gestión y divulgación de vulnerabilidades (artículo 21, apartado 2, letra e)). La norma PCI DSS establece un plazo de un mes desde su publicación para los parches de vulnerabilidades críticas (6.3.3), y las normas de FedRAMP para 2026 asignan la etiqueta de «vulnerabilidad aceptada» a cualquier vulnerabilidad que siga abierta 192 días después de la evaluación (VER-TFR-MAV).
Las diferencias comienzan por los plazos. La norma PCI DSS cuenta a partir de la publicación del parche; FedRAMP, a partir de la evaluación; y la CRA y la NIS 2 no indican ningún plazo en las disposiciones citadas aquí. También difieren en cuanto a cuándo y a quién se debe presentar la documentación. Una autoridad de vigilancia del mercado tiene a su disposición la documentación técnica de la CRA; las agencias revisan los informes mensuales de FedRAMP; una autoridad competente puede solicitar pruebas a una entidad sujeta a la NIS 2; y un evaluador de la norma PCI DSS comprueba la documentación de la entidad. No debe darse por sentado que un registro elaborado en función del plazo y del destinatario de un documento se ajuste al de otro.
Lo que los documentos dejan a tu criterio
Los cuatro documentos plantean la cuestión y dejan abierta gran parte de la metodología. La CRA exige a los fabricantes que documenten los aspectos de ciberseguridad del producto de manera proporcionada al riesgo (artículo 13, apartado 7), y la NIS 2 exige medidas adecuadas y proporcionadas (artículo 21, apartado 1). La norma PCI DSS deja que sea la propia entidad la que, mediante su evaluación de riesgos, determine el momento de aplicación de otros parches pertinentes, es decir, aquellos que no se refieren a vulnerabilidades críticas (6.3.3), y la norma de detección de FedRAMP exige el uso de técnicas adecuadas (VDR-CSO-DET).
Quedan dos cuestiones pendientes en las disposiciones citadas hasta ahora. La primera es la procedencia de un componente. El artículo 13, apartado 5, de la CRA exige la debida diligencia para que los componentes de terceros no pongan en riesgo el producto, y el artículo 21, apartado 3, de la NIS 2 exige a las entidades que evalúen los procedimientos de desarrollo seguro de los proveedores. El considerando 85 de la Directiva NIS 2, que no tiene carácter vinculante, describe cómo los atacantes comprometen a las entidades aprovechando vulnerabilidades en productos y servicios de terceros. Ninguno de los dos artículos explica cómo verificar que un componente se corresponda con la fuente de la que afirma proceder o que no contenga código malicioso.
El segundo aspecto es de dónde procede la corrección. La norma PCI DSS 6.3.3 cuenta un mes a partir del lanzamiento de un parche, por lo que da por hecho que alguien lo ha publicado. La CRA atribuye al fabricante la obligación de proporcionar actualizaciones de seguridad (Anexo I, Parte II(2)), y el artículo 13(8) mantiene las vulnerabilidades en los componentes de un producto dentro del ámbito de aplicación durante todo el periodo de soporte de la CRA. En el ciclo de supervisión continua de la Rev. 5 de FedRAMP, un hallazgo sin solución por parte del proveedor se mantiene en el POA&M mensual como una dependencia del proveedor. Para los proveedores con más de un cliente de agencia, el Manual de estrategias centra la reunión colaborativa mensual en los elementos vencidos y las dependencias de los proveedores (Sección 7). Ninguna de esas disposiciones especifica de dónde procede la corrección en sí una vez que los responsables del mantenimiento han dejado de publicarlas.
El papel de SecureChain en el ámbito del software de código abierto
SecureChain, de TuxCare, analiza el código fuente de los paquetes de código abierto en busca de malware oculto y los recompila en un entorno aislado a partir de ese código analizado. Los paquetes que no superan la inspección se bloquean antes de que lleguen al entorno del cliente, y el resto se distribuyen a través de un repositorio supervisado.
Cada paquete se distribuye con información sobre su procedencia (un registro firmado de cómo se ha compilado, conforme al nivel 3 de la SLSA), una SBOM, declaraciones VEX y registros sobre el origen y el estado de las correcciones que se solicitan en los documentos mencionados anteriormente.
SecureChain aplica parches a los componentes activos en el marco de un acuerdo de nivel de servicio y, en el caso de las versiones que ya no reciben mantenimiento por parte del desarrollador original, el servicio Endless Lifecycle Support (ELS) adapta las correcciones para vulnerabilidades de riesgo crítico, alto, medio y bajo a las versiones en uso, siguiendo un calendario comprometido. SecureChain cubre paquetes de código abierto en JavaScript, Python, Java, Go y PHP.
Si todavía no sabes de dónde procede un componente, o quién se encarga de actualizarlo una vez que el desarrollador original deja de hacerlo, descubre cómo aborda SecureChain para software de código abierto ambas cuestiones.
PREGUNTAS FRECUENTES
¿Cómo utilizan el término «prueba» la CRA, FedRAMP, NIS 2 y PCI DSS?
Las cuatro la utilizan, en diferentes sentidos. El anexo VII de la Ley de Resiliencia Cibernética enumera las pruebas de la existencia de una dirección de contacto para la notificación de vulnerabilidades dentro de la documentación técnica. Los artículos 32 y 33 de la Directiva NIS 2 permiten a las autoridades solicitar pruebas de la implementación. El Manual del Programa Federal de Gestión de Riesgos y Autorizaciones (FRAP) menciona las pruebas justificativas, y la Norma de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) establece que los evaluadores examinen la documentación y entrevisten al personal (6.3.2.a, 6.3.2.b).
¿Durante cuánto tiempo debe conservarse la documentación técnica de la CRA?
En virtud del artículo 13, apartado 13, de la Ley de Resiliencia Cibernética (CRA), los fabricantes están obligados a mantener la documentación técnica a disposición de las autoridades de vigilancia del mercado durante al menos 10 años tras la comercialización del producto, o durante el periodo de asistencia técnica si este fuera más largo. El anexo VII enumera los contenidos, incluida una lista de componentes de software, cuando proceda.
¿Qué multas establecen la CRA y la NIS 2?
El artículo 64, apartado 2, de la Ley de Resiliencia Cibernética establece multas de hasta 15 000 000 EUR o el 2,5 % de la cifra de negocios anual total a nivel mundial del ejercicio financiero anterior por incumplimientos del anexo I y de los artículos 13 y 14. El artículo 34 de la Directiva NIS 2 exige a los Estados miembros que establezcan límites máximos de al menos 10 000 000 de euros o el 2 % de la facturación para las entidades esenciales, y de 7 000 000 de euros o el 1,4 % de la facturación para las entidades importantes. En todos los casos, se aplicará el importe más elevado.
¿Cómo llega la NIS 2 a un proveedor de software?
La Directiva NIS 2 impone sus obligaciones a las entidades esenciales e importantes, por lo que, por lo general, se contacta con un proveedor a través de un cliente. El artículo 21, apartado 2, letra d), y el artículo 21, apartado 3, exigen que la entidad evalúe las vulnerabilidades de cada proveedor directo y garantice la elaboración de procedimientos de desarrollo. Un proveedor que sea a su vez una entidad esencial o importante queda sujeto a la Directiva por derecho propio, en virtud de la legislación de los Estados miembros.
¿En qué casos exige la norma PCI DSS un inventario de componentes de terceros?
El requisito 6.3.2 de la Norma de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) v4.0.1, una norma del sector, se refiere a los componentes de terceros incorporados en software a medida y personalizado. Hasta el 31 de marzo de 2025 se consideraba una buena práctica, y a partir de esa fecha será obligatorio. La decisión de si una entidad debe realizar la validación corresponde a las marcas de pago, los adquirentes y otras organizaciones que gestionan programas de cumplimiento.
