La Ley de Resiliencia Cibernética europea entra en vigor mañana con plazos de notificación que obligan a repensar cómo se rastrea el software en producción.
El 11 de septiembre entra en vigencia la Ley de Resiliencia Cibernética de la Unión Europea (EU Cyber Resilience Act, CRA), un marco regulatorio que establece plazos de reporte de vulnerabilidades sin precedentes en jurisdicciones mayores: los proveedores de software que operan en el mercado europeo tendrán tan poco como 24 horas para notificar fallas activamente explotadas desde el momento en que toman conocimiento de ellas. El requisito no distingue entre proveedores con sede en Europa y aquellos fuera del bloque — alcanza a cualquier empresa que distribuya productos de software a usuarios o infraestructura en territorio de la UE. La pregunta operativa que plantea ActiveState, proveedor de herramientas de gestión de dependencias, es directa: ¿sabés exactamente qué versión de qué componente enviaste a producción, y cuándo te enteraste de que tenía una vulnerabilidad?
Por qué 24 horas es un plazo que rompe flujos de trabajo actuales
El plazo de 24 horas para reportar vulnerabilidades bajo explotación activa no es una recomendación — es un requisito legal con potencial de sanciones. Para cumplirlo, un proveedor necesita tres capacidades operativas simultáneas: detectar que una vulnerabilidad existe en su código o dependencias, confirmar que está siendo explotada en la práctica, y tener un registro preciso de qué clientes o despliegues están corriendo la versión afectada. La mayoría de las organizaciones de software no tiene los tres elementos integrados en tiempo real.
El problema no es técnico en el sentido de que las herramientas existan — sistemas de gestión de inventario de software (SBOM, Software Bill of Materials), feeds de inteligencia de amenazas y plataformas de gestión de vulnerabilidades están disponibles comercialmente. El problema es que esos sistemas rara vez están conectados entre sí de manera que permita responder la pregunta «¿qué enviamos y cuándo supimos?» en menos de un día. En la práctica habitual de desarrollo, el descubrimiento de una CVE (identificador de vulnerabilidad) puede tardar días en llegar al equipo correcto, y el mapeo de qué versiones de producto la incluyen puede requerir auditorías manuales de repositorios y registros de compilación.
ActiveState señala que el cumplimiento de la CRA depende de tener visibilidad granular sobre la cadena de suministro de software — no solo qué bibliotecas de terceros se usan, sino en qué versión exacta, en qué build, desplegada cuándo y dónde. Esa trazabilidad es estándar en industrias reguladas como dispositivos médicos o aviación, pero no en la mayoría del software comercial o de código abierto.
Qué significa «activamente explotada» y quién lo determina
La CRA no define un umbral técnico preciso para considerar que una vulnerabilidad está «activamente explotada». En la práctica, los proveedores tendrán que basarse en fuentes de inteligencia de amenazas — feeds de CISA (Agencia de Seguridad de Infraestructura y Ciberseguridad de EE.UU.), reportes de investigadores, telemetría de honeypots, análisis de tráfico de CDN (redes de distribución de contenido) — para hacer esa determinación. El problema es que esas fuentes no siempre coinciden en tiempo real, y una explotación puede estar ocurriendo en un segmento de infraestructura sin que sea visible en otros.
El riesgo legal está en el momento en que el proveedor «toma conocimiento» de la explotación. Si un investigador publica un proof-of-concept funcional en GitHub y el equipo de seguridad de la empresa lo ve, el reloj de 24 horas empieza a correr — independientemente de si el equipo de producto ya mapeó qué versiones están afectadas o si el equipo legal ya redactó la notificación. La CRA traslada la carga de la prueba al proveedor: tendrá que demostrar que actuó dentro del plazo, lo que implica registros auditables de cuándo se detectó la amenaza y qué acciones se tomaron.
El impacto en América Latina: proveedores regionales bajo regulación extraterritorial
Aunque la CRA es una ley europea, su alcance es extraterritorial en la práctica. Cualquier empresa de software en América Latina que tenga clientes en la UE — ya sea a través de ventas directas, distribución en marketplaces europeos, o servicios cloud con presencia en datacenters del bloque — queda sujeta a los mismos requisitos de reporte que un proveedor con sede en Berlín o París. Esto incluye desde startups de fintech argentinas que operan en España hasta integradores brasileños que revenden soluciones de terceros a subsidiarias europeas de multinacionales.
El desafío para proveedores en la región es doble. Primero, muchos no tienen procesos formales de gestión de vulnerabilidades más allá de aplicar parches cuando los vendors upstream los publican — la idea de reportar proactivamente a una autoridad europea en 24 horas no está en el radar operativo. Segundo, la dependencia de componentes de código abierto sin SBOM automatizado es alta en el ecosistema de desarrollo latinoamericano, lo que hace difícil rastrear qué versión de qué biblioteca está en producción sin auditorías manuales que pueden llevar semanas. Un proveedor mexicano de software de gestión hospitalaria que use una biblioteca de procesamiento de imágenes con una CVE recién explotada tendrá que notificar a clientes en la UE en el mismo plazo que un gigante de software europeo — sin necesariamente tener la infraestructura de compliance que ese gigante ya construyó.
Nuestro análisis
La CRA marca un punto de inflexión en cómo se regula el software a nivel global, no por la novedad de exigir reporte de vulnerabilidades — eso ya existe en sectores como finanzas o salud — sino por aplicar plazos de respuesta de infraestructura crítica a todo el software comercial que toque el mercado europeo. El plazo de 24 horas no es técnicamente imposible de cumplir, pero requiere una inversión en trazabilidad y automatización que la mayoría de los proveedores todavía no hizo. Lo que ActiveState plantea es correcto: el cumplimiento depende de saber qué se envió y cuándo se supo, y eso no se resuelve con un proceso de última hora — requiere SBOM en cada build, integración de feeds de amenazas con inventarios de producto, y procesos de notificación preconfigurados.
El patrón que se repite en regulaciones extraterritoriales como GDPR (Reglamento General de Protección de Datos) o ahora la CRA es que las empresas fuera de Europa terminan adaptándose a los estándares europeos porque el costo de mantener dos flujos de trabajo separados (uno para la UE, otro para el resto del mundo) es mayor que el de adoptar el estándar más estricto globalmente. Es probable que veamos lo mismo con la CRA: proveedores en América Latina, Asia o EE.UU. que implementen SBOM y reporte en 24 horas no solo para clientes europeos, sino como práctica general. La pregunta que queda abierta es cuántos proveedores van a descubrir que no cumplen los requisitos recién cuando reciban la primera notificación de una autoridad europea — y si para ese momento el daño reputacional o legal ya va a ser irreversible.