El 45% del código generado por herramientas de Inteligencia Artificial contiene vulnerabilidades críticas según el Top 10 de OWASP —la lista de los fallos de seguridad más peligrosos y frecuentes en software. Detrás de ese número hay brechas de datos, pérdidas de miles de millones de dólares y daños a infraestructuras críticas. Y sin embargo, casi ninguna empresa de software paga consecuencias reales por ello. Este artículo argumenta que eso debe cambiar, y que ya está comenzando a cambiar.
La cultura de DevSecOps
El problema de fondo no es técnico: es de incentivos. Lanzar software rápido es rentable. Hacerlo seguro cuesta tiempo y dinero. Mientras las empresas no asuman los costos de sus fallos de seguridad, seguirán externalizando ese riesgo hacia los usuarios finales, que son los menos equipados para defenderse.
La solución tiene dos patas: un marco regulatorio que haga a las empresas responsables de los daños que causa su software, y una cultura de DevSecOps —un modelo de desarrollo donde la seguridad no se revisa al final, sino que se integra en cada etapa del proceso, desde la planificación hasta el despliegue en producción. Una sin la otra no funciona: la regulación sin práctica técnica es papel mojado; la práctica técnica sin regulación es voluntaria y minoritaria.
La inoperancia de la negligencia y la lógica de la responsabilidad objetiva
Cuando ocurre un incidente de seguridad, determinar quién tiene la culpa es casi imposible. ¿Fue el desarrollador del código original? ¿El integrador del sistema? ¿El proveedor de la nube? ¿El usuario que no aplicó el parche? Esa opacidad técnica protege a las empresas y deja sin reparación a los afectados.
La responsabilidad objetiva propone aplicar al software la misma lógica que ya existe para los productos físicos defectuosos: quien pone el producto en el mercado es responsable de los daños que cause, independientemente de si hubo intención de ser negligente. Como cuando un fabricante de automóviles responde por un fallo de frenos, aunque el error haya sido de un proveedor de componentes.
✓ Por qué la lógica técnica respalda este modelo
-
Internalización de externalidadesSi las empresas saben que pagarán por cada brecha de seguridad, tienen un incentivo económico real para invertir en prevención. Hoy ese incentivo no existe.
-
Asimetría de la informaciónEl fabricante es el único que conoce su código. El usuario no puede evaluar la seguridad de lo que compra. No tiene sentido que sea el usuario quien asuma el riesgo.
-
Seguridad como métrica de calidadBajo este modelo, la seguridad deja de ser un costo opcional que se recorta bajo presión y se convierte en una condición básica para operar en el mercado.
Evidencia histórica y el giro regulatorio en Europa
Este camino ya lo recorrieron otras industrias. El caso Greenman v. Yuba Power Products estableció en Estados Unidos que los costos de las lesiones causadas por productos defectuosos deben recaer sobre los fabricantes, no sobre los ciudadanos. La industria automotriz lo asumió, mejoró y sobrevivió.
En Europa, ese cambio ya está ocurriendo para el software. La UE clasificó explícitamente al software como un "producto" sujeto a responsabilidad sin culpa. El nuevo marco exige a los fabricantes tres cosas concretas:
✓ Requisitos del nuevo marco regulatorio europeo
-
Gestión de vulnerabilidades continuaLas empresas deben implementar procesos activos de detección y corrección de vulnerabilidades durante todo el ciclo de vida del software, no solo al lanzarlo.
-
Documentación técnica y SBOMSe exige proveer una lista de componentes de software (Software Bill of Materials), el equivalente a los ingredientes de un producto alimentario: saber exactamente qué hay dentro.
-
Seguridad por diseño y por defectoLa seguridad debe estar integrada desde la arquitectura inicial, no añadida como capa posterior. Las configuraciones predeterminadas deben ser las más seguras posibles.
La experiencia de empresas como Red Hat demuestra que adaptarse proactivamente a estos estándares no solo es viable, sino rentable: la conformidad con marcos de seguridad auditables aumenta la confianza del cliente y reduce los costos de respuesta a incidentes.
¿Matará la responsabilidad a la innovación?
El argumento más repetido contra este modelo es que aplastará a las startups y frenará la innovación. Es una preocupación legítima, pero parte de un falso dilema: o seguridad o velocidad. Un marco regulatorio bien diseñado no busca software perfecto —eso es imposible— sino software desarrollado con diligencia demostrable.
✓ Mecanismos para proteger la innovación dentro del nuevo marco
-
Puertos segurosLas empresas que sigan marcos reconocidos como el NIST SSDF o las guías de OWASP quedarían protegidas de daños punitivos. Cumplir el estándar es la defensa.
-
Daños presuntivos pero rebatiblesTablas de daños predefinidas reducen la incertidumbre para aseguradoras y empresas, facilitando un mercado de seguros cibernéticos que actúe como regulador privado complementario.
-
Límites para PYMEs y código abiertoLa ley puede establecer topes de responsabilidad para pequeñas empresas y excluir el software de código abierto no comercial, protegiendo la colaboración comunitaria.
El resultado real de este marco no sería menos innovación: sería la salida del mercado de quienes compiten ignorando la seguridad, dejando espacio a quienes la tratan como una ventaja competitiva.
Del código reactivo a la cultura resiliente
Adoptar DevSecOps no es instalar una herramienta: es cambiar cómo piensa una organización sobre la seguridad. Tres prácticas concretas marcan la diferencia:
✓ Prácticas clave para construir una cultura DevSecOps
-
Shift Left: seguridad desde el primer díaMover las actividades de seguridad al inicio del ciclo de desarrollo. Encontrar una vulnerabilidad en la fase de diseño cuesta diez veces menos que encontrarla en producción.
-
Automatizar los 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. El software vulnerable se detiene antes de llegar al usuario.
-
Responsabilidad compartida en toda la organizaciónLa seguridad no es tarea exclusiva del equipo de seguridad. Debe estar presente en las decisiones de los desarrolladores, los product managers y la dirección.
Hacia una nueva ética del desarrollo de software
Quote_Output"El software de calidad no nace de la inspiración casual, sino de un proceso disciplinado, repetible y responsable."
La unión de responsabilidad objetiva, seguros cibernéticos y DevSecOps —lo que algunos llaman Cyberensuring Security— no es solo una propuesta técnica o legal. Es una posición ética: en una sociedad que depende de sus sistemas digitales para funcionar, producir software inseguro sin consecuencias es tan irresponsable como vender un coche sin frenos. La era de lanzar rápido y pedir disculpas después tiene los días contados. Quienes empiecen a construir con esa mentalidad hoy tendrán una ventaja difícil de alcanzar mañana.
Etiquetas
¿Te gustó este artículo? ¡Compártelo y suscríbete!
