Cómo funcionaba el modelo de impunidad
El problema de fondo nunca fue técnico: fue de caracter normativo. Lanzar software rápido resultaba rentable. Desarrollarlo con controles de seguridad integrados consumía tiempo y presupuesto. Mientras las empresas no asumían los costos de sus fallos, tenían pocos motivos para invertir en prevenirlos. Las licencias as-is institucionalizaron esa lógica durante los años noventa y se mantuvieron prácticamente intactas hasta entrados los 2020.
DevSecOps —el modelo de desarrollo donde la seguridad se integra desde la planificación hasta el despliegue, en lugar de verificarse al final— existía como práctica recomendada desde mediados de la década de 2010. Su adopción era voluntaria y, por tanto, desigual. La regulación que comenzó a consolidarse entre 2023 y 2025 cambió esa ecuación: lo que antes era una buena práctica se convirtió en una obligación con consecuencias legales.
Por qué el modelo anterior era insostenible
Cuando ocurría un incidente de seguridad, determinar responsabilidades era técnicamente complejo. La cadena podía involucrar al desarrollador del código original, al integrador del sistema, al proveedor de infraestructura en la nube o al usuario que no aplicó el parche. Esa opacidad protegía a las empresas y dejaba sin reparación a los afectados.
Tres razones por las que el modelo as-is no podía mantenerse
-
Externalización del riesgoSin consecuencias económicas directas, las empresas trasladaban el costo de los fallos de seguridad hacia usuarios y terceros. El incentivo para invertir en prevención era mínimo.
-
Asimetría de información estructuralEl fabricante era el único que conocía su código en profundidad. El usuario no disponía de medios para evaluar la seguridad de lo que adquiría, lo que hacía inviable cualquier decisión informada de compra basada en criterios de seguridad.
-
Escala del dañoA medida que el software pasó a gestionar infraestructuras críticas —salud, energía, finanzas—, los costos sociales de los fallos dejaron de ser absorbibles por los usuarios individuales y se convirtieron en un problema de orden público.
El giro regulatorio: de la recomendación a la obligación
La Unión Europea aprobó la Cyber Resilience Act (Reglamento UE 2024/2847) en octubre de 2024. Entró en vigor el 12 de noviembre de ese año y sus obligaciones plenas son exigibles desde diciembre de 2027. Por primera vez en el ámbito europeo, el software queda clasificado como un 'producto' sujeto a responsabilidad sin culpa: quien lo comercializa responde por los daños que cause, con independencia de si hubo negligencia demostrable. El reglamento establece tres exigencias concretas.
Requisitos del nuevo marco regulatorio europeo
-
Gestión de vulnerabilidades continuaLos fabricantes deben implementar procesos activos de detección y corrección de vulnerabilidades durante todo el ciclo de vida del software, no únicamente en el momento del lanzamiento.
-
Documentación técnica y SBOMSe exige proveer una lista de componentes de software (Software Bill of Materials): un inventario detallado de qué bibliotecas y dependencias integra el producto, equivalente al listado de ingredientes en un producto alimentario.
-
Seguridad por diseño y por defectoLa seguridad debe estar presente desde la arquitectura inicial, no añadida como capa posterior. Las configuraciones predeterminadas del producto deben ser las más seguras posibles.
En paralelo, la Estrategia Nacional de Ciberseguridad de Estados Unidos de 2023 señaló explícitamente que la responsabilidad por fallos de seguridad debe recaer en los fabricantes, no en los usuarios. El caso SolarWinds aportó un referente judicial: la SEC demandó en octubre de 2023 a la empresa y a su CISO por las revelaciones relacionadas con el ataque a su plataforma Orion. Aunque el tribunal desestimó la mayor parte de los cargos en julio de 2024, el hecho de que un responsable de seguridad fuera llevado a juicio estableció que la exposición personal de los ejecutivos ya forma parte del mapa de riesgos legales en Estados Unidos.
El debate sobre la innovación: un falso dilema que perdió fuerza
El argumento más repetido contra la responsabilidad objetiva fue que destruiría a las startups y reduciría el ritmo de innovación. Ese debate tuvo sentido mientras el marco regulatorio era hipotético. Con la CRA ya aprobada y en período de adaptación, la pregunta dejó de ser 'si debe existir responsabilidad' y pasó a ser 'cómo se estructura para que sea viable'. Los mecanismos diseñados para esa transición muestran que ambos objetivos —responsabilidad e innovación— no son incompatibles.
Mecanismos que hacen viable el nuevo marco para distintos tipos de empresas
-
Puertos segurosLas empresas que sigan marcos reconocidos como el NIST SSDF o las guías de OWASP quedan protegidas de daños punitivos. El cumplimiento del estándar actúa como defensa legal verificable.
-
Daños presuntivos pero rebatiblesTablas de daños predefinidas reducen la incertidumbre para aseguradoras y empresas, y facilitan el desarrollo de un mercado de seguros cibernéticos que opera como regulador privado complementario.
-
Límites para PYMEs y código abiertoEl reglamento establece topes de responsabilidad para empresas pequeñas y excluye el software de código abierto no comercial, preservando la colaboración comunitaria fuera del alcance de las obligaciones comerciales.
DevSecOps como respuesta operativa al nuevo marco
La CRA no prescribe metodologías de desarrollo, pero sus exigencias —gestión continua de vulnerabilidades, SBOM, seguridad por defecto— son incompatibles con modelos donde la seguridad se trata como una fase final. DevSecOps deja de ser una opción cultural para convertirse en la estructura técnica más directa para cumplir con las nuevas obligaciones. Tres prácticas concentran la mayor parte del impacto.
Prácticas clave de DevSecOps para el nuevo marco regulatorio
-
Shift Left: seguridad desde el diseñoDesplazar las actividades de seguridad al inicio del ciclo de desarrollo. Detectar una vulnerabilidad en la fase de diseño cuesta aproximadamente diez veces menos que gestionarla en producción, y es el enfoque más directo para cumplir el requisito de seguridad por diseño de la CRA.
-
Automatización de Quality GatesIntegrar herramientas de SAST (análisis estático de código), DAST (pruebas dinámicas en ejecución) y SCA (auditoría de dependencias de terceros) en los pipelines de CI/CD permite generar evidencia auditable del proceso de verificación, un requisito implícito en la documentación técnica que exige la CRA.
-
Responsabilidad distribuida en toda la organizaciónLa seguridad no puede ser responsabilidad exclusiva del equipo de seguridad si el marco legal alcanza a la dirección. Debe estar presente en las decisiones de los desarrolladores, los product managers y los ejecutivos.
Lo que el cambio regulatorio implica en la práctica
La ventana hasta diciembre de 2027 no es holgada para organizaciones con deuda técnica acumulada. El inventario criptográfico y de componentes —el SBOM— requiere tiempo y herramientas que muchas empresas no tienen desplegadas. La experiencia de organizaciones como Red Hat, que anticiparon estos estándares antes de que fueran obligatorios, muestra que la conformidad temprana genera ventaja competitiva medible: menor costo de respuesta a incidentes y mayor confianza del cliente en procesos de compra donde la seguridad ya aparece como criterio de evaluación. El modelo as-is no desapareció porque la industria decidió ser más responsable. Desapareció porque el marco regulatorio hizo que mantenerlo fuera más costoso que abandonarlo. Ese es, probablemente, el único mecanismo que históricamente ha funcionado para cambiar incentivos a escala industrial.
¿Te gustó este artículo? ¡Compártelo y suscríbete!
