¿Qué es DevSecOps, de verdad? La seguridad como propiedad del proceso

DevSecOps es una de esas palabras que se estiran hasta que no significan nada: se le pega a un producto, a un puesto de trabajo o a un único escáner en un pipeline. Sin el marketing, describe algo sencillo y realmente valioso: integrar la seguridad en la forma de hacer software, en lugar de tratarla como una barrera al final.

El problema que resuelve

El modelo tradicional es una revisión de seguridad justo antes del lanzamiento: un especialista prueba la aplicación terminada, entrega un montón de hallazgos y el equipo corre para corregirlos con la presión de la fecha encima. Encuentra problemas reales, pero en el peor momento posible: cuando más cuesta arreglarlos y más probable es que retrasen el lanzamiento. Peor aún, es una foto fija. Al día siguiente de la prueba, el código nuevo empieza a acumular riesgos nuevos que nadie vigila.

DevSecOps desplaza los controles a la izquierda, es decir, antes en el proceso, a la pull request y al pipeline, para que los problemas se detecten en cuanto se introducen, cuando arreglarlos es barato y el autor aún los tiene frescos.

Cómo es en la práctica

En concreto, en un proyecto llevado así, la seguridad aparece en varios puntos, y ninguno frena al equipo:

• Análisis estático (SAST) en cada cambio, ajustado para que la señal sea real y no un muro de falsos positivos que todo el mundo aprende a ignorar.
• Análisis de dependencias y de la cadena de suministro, con versiones fijadas, para que una biblioteca con una vulnerabilidad conocida se señale antes de publicarse, no después de salir en las noticias.
• Detección de secretos en el código y en la CI, para que una clave de API o una contraseña nunca lleguen a confirmarse en el repositorio.
• Pipelines de compilación reforzados, con pasos de mínimo privilegio, dependencias verificadas y artefactos firmados, para que el propio pipeline no sea el eslabón débil.
• Modelado de amenazas para las nuevas funciones, de modo que los riesgos de diseño se detecten antes de construirse.
• Una prueba de penetración específica antes de cada versión importante, que se apoya en todo lo anterior en lugar de cargar sola con todo el peso.

Lo difícil no son las herramientas

Cualquier equipo puede atornillar un escáner a la CI. La diferencia entre un DevSecOps que funciona y un DevSecOps de fachada está en el ajuste y en la cultura. Un pipeline que inunda a los desarrolladores de falsos positivos enseña a todos a saltarse el paso de seguridad, y eso es peor que no tenerlo, porque ahora hay una falsa sensación de seguridad. La clave está en configurar las herramientas para que sus hallazgos sean fiables, ejecutar los controles rápidos en línea y los lentos por separado, y tratar la mayoría de los resultados como información para el autor más que como un bloqueo estricto.

La seguridad deja de ser una revisión puntual y se convierte en una propiedad del proceso. Categorías enteras de problemas se detectan al fusionar, antes de que nadie tenga que pensar en ellas.

¿Sustituye a las pruebas de penetración?

No: cambia su propósito. Cuando los problemas rutinarios ya se detectan de forma continua, una prueba de penetración deja de ser una caza frenética de errores y pasa a ser lo que debería: una persona experta buscando fallos de lógica de negocio, huecos en el control de acceso y cadenas creativas que ningún escáner encuentra. Ambas cosas se refuerzan. Los controles continuos aportan amplitud; la persona, profundidad.

Por dónde empezar

No hace falta adoptarlo todo de golpe, y no conviene. Empieza por lo que más rinde con menos fricción: la detección de secretos, para que las credenciales dejen de filtrarse, y el análisis de dependencias, para saber qué bibliotecas vulnerables estás publicando. Añade SAST cuando lo tengas ajustado. Incorpora el modelado de amenazas al trabajo nuevo. Lo importante es la dirección, no un despliegue de golpe: cada control que adelantas es un riesgo detectado a menor coste.

Ese es el enfoque que aplicamos en los proyectos que entregamos. Si quieres que la seguridad sea algo que tu proceso produce por defecto y no algo que se añade a última hora con la fecha encima, ese es el trabajo, y estaremos encantados de ayudarte a ponerlo en marcha.