Due diligence de software para departamentos de Compliance

El software moderno no se escribe desde cero. Cada aplicación empresarial incorpora cientos o miles de componentes de código abierto y librerías de terceros. Para quienes trabajamos en Compliance, esto plantea un desafío que no podemos seguir ignorando: ¿cómo evaluamos y documentamos los riesgos de una cadena de suministro de software que no controlamos directamente?

Durante años, esta pregunta se respondía con un encogimiento de hombros. "Eso es cosa de IT", decíamos. Pero el nuevo marco regulatorio europeo ha cambiado las reglas del juego. El CRA y NIS2 han trasladado la responsabilidad de evaluar la seguridad del software directamente a nuestros departamentos, con consecuencias legales y económicas muy reales para quienes no cumplan.

Este artículo está escrito desde la trinchera del Compliance. No es una guía técnica sobre cómo escribir código seguro, sino una guía práctica sobre qué debemos exigir, qué documentación necesitamos y cómo estructurar nuestros procesos de due diligence para cumplir con las nuevas obligaciones.

El nuevo paradigma: software como riesgo regulatorio

Tradicionalmente, los departamentos de Compliance nos centrábamos en riesgos financieros, legales y de privacidad. El software era responsabilidad exclusiva de IT, y nuestra interacción con él se limitaba a verificar que los contratos de licencia estuvieran en orden. Esta separación de responsabilidades, que funcionó durante décadas, ya no es viable.

El cambio no es arbitrario. Los reguladores europeos han observado que los incidentes de ciberseguridad más graves de los últimos años han tenido su origen en vulnerabilidades de componentes de software de terceros. SolarWinds, Log4Shell, y decenas de casos menos mediáticos han demostrado que la cadena de suministro de software es un vector de ataque crítico que no estaba siendo adecuadamente gestionado.

Por qué el software es ahora un riesgo de Compliance

Las obligaciones legales ya no son ambiguas. El Artículo 8 del CRA y el Artículo 21 de NIS2 exigen expresamente que las organizaciones realicen due diligence de su cadena de suministro de software. No es una recomendación ni una buena práctica: es un requisito legal con sanciones que pueden alcanzar los 15 millones de euros bajo el CRA o los 10 millones bajo NIS2.

Pero las sanciones económicas no son lo único que debería preocuparnos. NIS2 introduce la posibilidad de suspender a directivos por incumplimientos graves de seguridad. Esto significa que el Compliance Officer que ignore sistemáticamente los riesgos de software no solo pone en peligro a la organización, sino potencialmente su propia carrera profesional.

Los reguladores exigen además evidencia documentada de nuestros procesos de evaluación. Ya no basta con afirmar que "hacemos due diligence": debemos poder demostrarlo con registros, informes y trazabilidad completa de nuestras decisiones.

El riesgo de las dependencias transitivas

Uno de los conceptos que más nos cuesta asimilar a quienes venimos del Compliance tradicional es el de las dependencias transitivas. Cuando nuestros desarrolladores incluyen una librería en un proyecto, esa librería a su vez incluye otras librerías, que a su vez incluyen otras. El resultado es una cadena de dependencias que crece exponencialmente.

Un estudio reciente reveló que el proyecto de software medio tiene 847 dependencias transitivas, es decir, componentes que se incluyen indirectamente a través de otras librerías. Cada una de estas dependencias puede contener vulnerabilidades de seguridad conocidas, tener licencias incompatibles con uso comercial, estar abandonada y sin mantenimiento, o proceder de orígenes no verificables.

El caso de Log4Shell ilustra perfectamente este riesgo. Log4j era una dependencia transitiva invisible en innumerables proyectos. Cuando se descubrió la vulnerabilidad crítica, la mayoría de empresas afectadas ni siquiera sabían que usaban este componente. Sus equipos de IT tuvieron que rastrear manualmente todas las aplicaciones para determinar cuáles estaban afectadas, un proceso que en algunas organizaciones llevó semanas.

CRA Artículo 8: obligaciones de due diligence

El Artículo 8 del Cyber Resilience Act establece obligaciones específicas de due diligence que debemos entender en detalle. No se trata de requisitos vagos que podamos interpretar a conveniencia, sino de obligaciones concretas que los Organismos Notificados verificarán.

Requisitos del CRA Art. 8

La siguiente tabla resume las obligaciones principales y la evidencia que debemos mantener. Es importante entender que cada una de estas obligaciones requiere un proceso documentado y evidencia verificable.

La identificación de componentes mediante SBOM (Software Bill of Materials) es el punto de partida de todo el proceso. Sin un inventario completo y actualizado de qué software incluyen nuestros productos, es imposible cumplir con las demás obligaciones. El SBOM debe incluir no solo los componentes que nuestros desarrolladores añaden directamente, sino también todas las dependencias transitivas.

La evaluación de seguridad implica verificar activamente que los componentes que utilizamos no tienen vulnerabilidades conocidas graves, o que si las tienen, existe un plan de remediación. No podemos simplemente asumir que "si está en un repositorio público, será seguro". Debemos documentar nuestro análisis y las decisiones que tomamos basándonos en él.

Qué significa "ejercer la diligencia debida"

El CRA especifica que los fabricantes deben seleccionar componentes con cuidado, considerando su historial de seguridad. Esto significa que antes de incorporar una nueva librería a nuestro producto, debemos evaluar si ha tenido vulnerabilidades graves en el pasado y cómo fueron gestionadas por sus mantenedores.

Debemos verificar la procedencia de los componentes integrados. ¿Quién los desarrolla? ¿Es una organización conocida o un desarrollador individual? ¿Podemos confiar en que no se ha introducido código malicioso en algún momento de la cadena?

La evaluación del mantenimiento activo es crucial. Un componente que lleva dos años sin actualizaciones es un riesgo latente: si se descubre una vulnerabilidad, probablemente no habrá nadie que publique un parche. Debemos identificar estos componentes "zombi" y planificar su sustitución.

Finalmente, todo el proceso de evaluación y selección debe estar documentado. Cuando un auditor nos pregunte "¿por qué eligieron este componente?", debemos poder responder con evidencia escrita, no con recuerdos vagos.

NIS2 Artículo 21: gestión de cadena de suministro

La Directiva NIS2 complementa el CRA con obligaciones organizacionales de seguridad en la cadena de suministro. Mientras el CRA se centra en los productos, NIS2 se centra en las organizaciones que los utilizan.

NIS2 Art. 21(2)(d): Seguridad de la cadena de suministro

Las entidades cubiertas por NIS2 deben implementar políticas de seguridad para relaciones con proveedores directos. Esto incluye no solo a nuestros proveedores de software comercial, sino también a los proyectos de código abierto que utilizamos, aunque la relación con estos últimos sea muy diferente.

La evaluación de riesgos de la cadena de suministro debe ser sistemática y documentada. No podemos limitarnos a confiar en que nuestros proveedores "saben lo que hacen". Debemos establecer criterios de evaluación, aplicarlos consistentemente y documentar los resultados.

Los requisitos contractuales de seguridad con proveedores son ahora obligatorios. Cuando adquirimos software comercial, debemos incluir cláusulas que nos garanticen acceso a información de seguridad, notificación de vulnerabilidades y actualizaciones durante un período razonable.

La monitorización continua del cumplimiento de proveedores cierra el ciclo. No basta con evaluar a un proveedor una vez y olvidarnos: debemos verificar periódicamente que sigue cumpliendo nuestros requisitos de seguridad.

Qué evaluar: las cuatro dimensiones del due diligence de software

Un proceso completo de due diligence de software debe cubrir cuatro dimensiones fundamentales. Cada una aborda un tipo diferente de riesgo, y descuidar cualquiera de ellas puede dejarnos expuestos a sanciones o incidentes.

1. Vulnerabilidades de seguridad

La evaluación de vulnerabilidades es probablemente la dimensión más intuitiva para quienes venimos del Compliance tradicional. Buscamos defectos conocidos en el software que podrían ser explotados por atacantes.

Debemos buscar CVEs (Common Vulnerabilities and Exposures) conocidos en el componente y todas sus dependencias. La severidad según CVSS (Common Vulnerability Scoring System) nos ayuda a priorizar: las vulnerabilidades Critical y High requieren atención inmediata, mientras que las Medium y Low pueden gestionarse de forma planificada.

Es importante verificar la disponibilidad de parches o versiones corregidas. Una vulnerabilidad conocida pero ya corregida es un riesgo muy diferente a una vulnerabilidad sin solución disponible. El historial de vulnerabilidades del componente también es relevante: un proyecto que ha tenido múltiples vulnerabilidades críticas en poco tiempo puede indicar problemas sistémicos de calidad de código.

Las fuentes de datos principales para esta evaluación incluyen el National Vulnerability Database (NVD), GitHub Advisory Database, OSV (Open Source Vulnerabilities) y las bases de datos específicas de proveedores comerciales.

2. Licencias de software

La evaluación de licencias es donde Compliance se siente más en su territorio natural, pero el mundo de las licencias de software tiene peculiaridades que debemos entender.

Debemos identificar el tipo de licencia de cada componente: permisiva, copyleft o propietaria. Las licencias permisivas como MIT, Apache 2.0 o BSD generalmente permiten uso comercial sin restricciones significativas. Las licencias copyleft como GPL pueden obligarnos a publicar nuestro propio código fuente si no tenemos cuidado con cómo integramos el componente.

La categorización del Blue Oak Council es una herramienta útil para clasificar licencias. Las categorías Platinum y Gold indican licencias permisivas sin restricciones problemáticas. Silver indica licencias permisivas con algunas condiciones que debemos revisar. Bronze corresponde a licencias copyleft débiles como LGPL o MPL, que requieren precaución pero suelen ser manejables. Lead indica licencias copyleft fuertes como GPL, que requieren análisis específico por parte de nuestro equipo legal.

No debemos olvidar las obligaciones de atribución. Muchas licencias permisivas requieren que incluyamos un aviso de copyright en nuestro producto. El archivo NOTICE.txt es el mecanismo estándar para cumplir con estas obligaciones.

3. Salud del proyecto

La salud del proyecto es una dimensión que a menudo se descuida pero que tiene implicaciones importantes para el riesgo a largo plazo.

Debemos evaluar la actividad reciente de desarrollo. Un proyecto activo con commits regulares, releases periódicas y respuesta rápida a issues es mucho menos arriesgado que un proyecto aparentemente abandonado. La regla general es que si el último commit tiene más de 12 meses, debemos considerar el componente como potencialmente abandonado.

El tamaño y diversidad de la comunidad de mantenedores importa. Un proyecto mantenido por un solo desarrollador tiene un "bus factor" de uno: si esa persona pierde interés o capacidad de mantener el proyecto, no habrá nadie que publique parches de seguridad. Los proyectos con múltiples mantenedores activos de diferentes organizaciones son significativamente más resilientes.

El tiempo de respuesta a issues de seguridad es un indicador crítico. ¿Cuánto tardaron en responder a la última vulnerabilidad reportada? ¿Publicaron un parche rápidamente o ignoraron el problema durante meses? Esta información nos dice mucho sobre cómo se gestionará la próxima vulnerabilidad que se descubra.

4. Procedencia y confianza

La evaluación de procedencia busca verificar que el software que estamos utilizando es realmente lo que creemos que es, y que no ha sido manipulado en ningún punto de la cadena de suministro.

Debemos verificar el origen del código fuente. ¿El componente procede de un repositorio oficial conocido? ¿Podemos rastrear su historial de desarrollo? Los ataques de "typosquatting" (publicar paquetes con nombres similares a proyectos populares) son cada vez más frecuentes.

La integridad de los artefactos es fundamental. Cuando descargamos un componente, ¿podemos verificar que no ha sido modificado? Los checksums y las firmas digitales proporcionan esta garantía, pero solo si los verificamos activamente.

El historial del mantenedor o la organización detrás del proyecto también es relevante. ¿Es una entidad conocida y reputada? ¿Ha habido incidentes de seguridad relacionados con sus otros proyectos? La presencia en registros de paquetes oficiales (npm, PyPI, Maven Central) proporciona cierta capa de verificación, aunque no es garantía absoluta.

Documentación para Organismos Notificados

Los productos con elementos digitales de Clase I y II requieren evaluación por Organismos Notificados. Como departamento de Compliance, somos responsables de preparar y mantener la documentación que estos organismos examinarán.

El SBOM completo en formato estándar (SPDX 2.3 o CycloneDX 1.5) es el documento central. Debe incluir todos los componentes, sus versiones exactas, sus licencias y sus dependencias. Un SBOM incompleto o desactualizado es una señal de alarma para cualquier auditor.

El informe de vulnerabilidades debe documentar todos los CVEs identificados en nuestros componentes, junto con el estado de remediación de cada uno. Si hemos decidido aceptar el riesgo de una vulnerabilidad sin corregirla, esa decisión debe estar documentada y justificada.

El análisis de licencias debe demostrar que hemos verificado la compatibilidad de todas las licencias de nuestros componentes con nuestro modelo de negocio y distribución. Cualquier conflicto de licencias identificado debe tener una resolución documentada.

La evaluación de riesgos de componentes de terceros debe seguir una metodología consistente y documentada. No podemos evaluar cada componente de forma diferente según quién haga el análisis o qué día de la semana sea.

El procedimiento documentado de selección y evaluación de componentes demuestra que tenemos un proceso sistemático, no decisiones puntuales basadas en intuición. Los registros de monitorización de vulnerabilidades prueban que no solo evaluamos componentes al inicio, sino que mantenemos vigilancia continua.

Plantillas NIS2: alertas 24h, notificación 72h, informe 1 mes

NIS2 establece un proceso de notificación de incidentes en tres fases con plazos estrictos. Como Compliance, debemos tener preparadas las plantillas y los procesos para cumplir estos plazos cuando ocurra un incidente.

Fase 1: Alerta temprana (24 horas)

La alerta temprana debe enviarse dentro de las 24 horas siguientes a tener conocimiento de un incidente significativo. El contenido mínimo incluye fecha y hora de detección, descripción preliminar del incidente, evaluación inicial de impacto, indicación de si se sospecha origen malicioso y medidas de contención iniciales adoptadas.

No esperemos a tener toda la información para enviar la alerta. El propósito de esta primera comunicación es avisar a las autoridades de que algo ha ocurrido, no proporcionar un análisis completo.

Fase 2: Notificación de incidente (72 horas)

A las 72 horas debemos proporcionar una actualización más detallada. Esta notificación debe incluir una actualización de la alerta temprana con nueva información disponible, evaluación detallada del impacto, indicadores de compromiso (IoCs) identificados que puedan ayudar a otras organizaciones, medidas de remediación en curso y evaluación del impacto transfronterizo si aplica.

Fase 3: Informe final (1 mes)

El informe final, que debe presentarse en el plazo de un mes, es un documento completo que incluye descripción detallada del incidente desde su detección hasta su resolución, causa raíz identificada tras el análisis forense, medidas de remediación implementadas, lecciones aprendidas y plan de mejora para prevenir recurrencia.

Requisitos de retención documental

CRA: 10 años de retención

El Artículo 31(13) del CRA exige conservar la documentación técnica durante 10 años desde la comercialización del producto. Esta obligación tiene implicaciones prácticas significativas para nuestros sistemas de archivo y gestión documental.

La documentación sujeta a esta retención incluye el SBOM de cada versión del producto (no solo la actual, sino todas las versiones históricas), informes de análisis de vulnerabilidades generados durante la vida del producto, registros de decisiones de remediación que documenten por qué se tomaron determinadas acciones y documentación de evaluación de componentes.

Para cumplir con la retención de 10 años, debemos implementar un sistema de archivo con garantías de integridad que asegure que los documentos no se alteran con el tiempo. Las políticas de versionado de documentación deben ser claras para poder recuperar el estado exacto de la documentación en cualquier momento del pasado. Las responsabilidades de custodia documental deben estar asignadas explícitamente, y debemos verificar periódicamente la recuperabilidad de los documentos archivados. Los formatos de largo plazo como PDF/A o texto plano son preferibles a formatos propietarios que podrían no ser legibles dentro de una década.

Cómo EMETHRA ayuda a los departamentos de Compliance

EMETHRA proporciona las herramientas que los equipos de Compliance necesitamos para gestionar el due diligence de software de forma eficiente, sin depender completamente de los equipos técnicos para cada análisis.

Nuestro due diligence automatizado permite obtener un análisis de dependencias transitivas completo con un solo clic. Identificamos CVEs en todas las capas de dependencias, categorizamos licencias según Blue Oak Council y evaluamos la salud de proyectos de código abierto, todo de forma automática y actualizable.

La documentación generada está lista para auditoría. Producimos SBOM en formatos estándar (SPDX ISO 5962:2021, CycloneDX 1.5) aceptados por reguladores y Organismos Notificados. Los informes de vulnerabilidades incluyen priorización CVSS, el análisis de licencias indica claramente la compatibilidad comercial y generamos automáticamente el archivo NOTICE.txt para cumplimiento de atribución.

Para la evidencia ante reguladores, generamos documentación técnica alineada con Anexo VII, mantenemos historial de análisis para demostrar monitorización continua, exportamos informes en PDF para auditorías y cumplimos los requisitos de retención del CRA.

Lista de verificación para Compliance Officers

Utiliza esta lista para evaluar el estado actual de tu programa de due diligence de software y planificar las mejoras necesarias.

Políticas y procedimientos:

• Política de evaluación de componentes de terceros documentada
• Criterios de aceptación de riesgos definidos
• Proceso de aprobación de nuevos componentes establecido
• Responsabilidades de due diligence asignadas

Capacidades técnicas:

• Herramienta de generación de SBOM implementada
• Análisis de vulnerabilidades automatizado
• Verificación de licencias integrada
• Monitorización continua de nuevas vulnerabilidades

Documentación:

• SBOM actualizado para todos los productos
• Registro de decisiones de remediación
• Evidencia de evaluaciones periódicas
• Sistema de archivo para retención 10 años

Respuesta a incidentes:

• Plantillas NIS2 (24h/72h/1mes) preparadas
• Canal de comunicación con CSIRT establecido
• Proceso de escalado definido
• Simulacros de notificación realizados

---

Referencias normativas:

• CRA Artículo 8 - Due diligence
• NIS2 Artículo 21 - Medidas de gestión de riesgos
• Blue Oak Council - License List
• SPDX ISO 5962:2021