Tradicionalmente el desarrollo de proyectos de software se hacía usando la metodología cascada, un proceso con actividades secuenciales y lineales que entrega un producto final tras largos ciclos. Este enfoque implicaba plazos extensos y un alto riesgo de sobrecostos y retrasos.
Un hito clave en la evolución del desarrollo fue la conferencia de John Allspaw y Paul Hammond de Flickr en 2009, titulada "10+ Deployments per Day: Dev and Ops Cooperation at Flickr", que popularizó la filosofía DevOps. Este cambio cultural permitió a las empresas acelerar sus entregas, reduciendo los plazos de meses a días mediante la implementación de flujos de Integración Continua y Entrega Continua (CI/CD).
Recordemos que un flujo CI/CD consta de las siguientes etapas:
- Fuente (Commit): El código se sube al repositorio, lo que gatilla el flujo.
- Construcción (Build): Se compila el código y se empaquetan los artefactos.
- Pruebas (Test): Se ejecutan chequeos automáticos (unitarias, funcionales, etc.)
- Despliegue (Deploy): Se entrega el artefacto a entornos de prueba o producción.
Sin embargo, a fines de 2012, un nuevo cuello de botella se hizo evidente: las pruebas manuales, especialmente las de seguridad.
Tradicionalmente relegadas al final del proyecto, estas pruebas ralentizaban las entregas y encarecían la solución de vulnerabilidades. Para resolverlo, se adoptó el enfoque de "Shift-Left", moviendo e integrando las pruebas de seguridad de forma temprana y automatizada en el flujo, dando origen a DevSecOps.
Hacia las pruebas continuas de seguridad
El cambio de paradigma significó algunos cambios conceptuales clave:
- Distribución de funciones: El equipo de pruebas ya no es un departamento aislado; la responsabilidad de la calidad y la seguridad se distribuye entre todos los miembros del proyecto.
- Pruebas como diseño: Se pasa de "desarrollar y luego probar" a "definir las pruebas (criterios de aceptación) y luego desarrollar".
- Pruebas tempranas y frecuentes: Se busca probar tempranamente, probar frecuentemente y acortar el tiempo entre la detección de un error y su corrección.
En un flujo DevSecOps, las pruebas de seguridad se materializan en:
- Creación de historias de usuario con criterios de seguridad específicos.
- Desarrollo de pruebas de seguridad unitarias.
- Uso de bibliotecas de pruebas con patrones de seguridad predefinidos.
- Integrar escaneos de vulnerabilidades automatizados al pipeline.
SAST y DAST: Los Pilares de las Pruebas de Seguridad
Las pruebas de seguridad en el flujo CI/CD se dividen principalmente en dos enfoques: SAST y DAST.
Pruebas estáticas de seguridad (SAST o Static Application Security Testing)
Analizan el código fuente sin necesidad de ejecutar la aplicación. Se realizan en la fase de desarrollo (Shift-Left), permitiendo encontrar la línea exacta de código con el error antes de compilar, lo que reduce drásticamente el tiempo de corrección.
Pruebas dinámicas de Seguridad (DAST o Dynamic Application Security Testing)
Atacan la aplicación desde el exterior mientras está en ejecución (prueba de "caja negra"). Se realizan en fases más tardías, generalmente en entornos de prueba o pre-producción, y su objetivo es detectar fallas de configuración y problemas que solo se manifiestan en entornos ya operando.
Herramientas Clave para SAST
Dado que los proyectos suelen combinar múltiples lenguajes, es común optar por herramientas comerciales como Snyk Code, SonarQube o Checkmarx One. Para quienes buscan opciones de software libre, existen herramientas más específicas como Semgrep (compatible con Python, JavaScript, Go, etc.), SonarQube Freemium o Bandit (especializado en Python).
A modo de ejemplo, Semgrep puede incorporarse en Gitlab para analizar el código del proyecto.
Herramientas Clave para DAST
En el ecosistema DAST, OWASP ZAP (Zed Attack Proxy) es el líder indiscutible, permitiendo tanto escaneos automáticos en CI/CD como pruebas manuales de interceptación de tráfico web.
Otras herramientas destacadas son:
- Wapiti: Escáner de "caja negra" que realiza crawling (exploración de páginas) e inyección automática de payloads para detectar vulnerabilidades críticas como Inyección SQL y XSS.
- Nikto: Un clásico enfocado en servidores web, que verifica configuraciones inseguras, software desactualizado y archivos potencialmente peligrosos.
En el ámbito comercial, podemos mencionar Invicti, Acunetix y Burp Suite Enterprise Edition, esta última con un fuerte enfoque en la integración con DevSecOps.
Aunque OWASP ZAP puede incorporarse dentro del flujo CI/CD, es necesario tener acceso a la aplicación ya funcionando en un entorno de staging/QA, al menos para realizar un escaneo rápido.
En conclusión, la industria ha adoptado como estándar el uso de flujos CI/CD para reducir los plazos de entrega. Complementariamente, la adopción de DevSecOps y la implementación de pruebas SAST y DAST se han vuelto imprescindibles para mitigar los riesgos de seguridad. Ignorar estas prácticas no solo implica mayores plazos de desarrollo, sino también la entrega de sistemas inherentemente más inseguros y expuestos a ciberamenazas.
