DevSecOps puede reducir drásticamente el riesgo cibernético para las organizaciones, en particular aquellas que dependen del desarrollo interno para obtener una ventaja competitiva.
Sin embargo, para ser un término que ha existido durante años, la terminología de DevSecOps aún no se comprende bien.
En este artículo, explicare qué es DevSecOps, en qué se diferencia de DevOps y qué controles de seguridad debería incorporar.
¿Cuál es la diferencia entre DevOps y DevSecOps?
La forma más sencilla de explicar la diferencia entre DevOps y DecSecOps es comparar sus definiciones.
DevOps es una combinación de desarrollo y operaciones destinada a permitir que los equipos de ingeniería desarrollen software de manera más rápida y eficiente.
El objetivo final es crear un ciclo de vida de desarrollo más ágil que permita a las organizaciones crear y actualizar rápidamente aplicaciones y activos de software, brindando una mejor experiencia al cliente y una ventaja competitiva significativa.
DevSecOps es una combinación de desarrollo, operaciones y seguridad. Su objetivo es integrar completamente los componentes de seguridad en las canalizaciones de DevOps, manteniendo la velocidad y la agilidad al tiempo que garantiza que el software sea resistente a las ciberamenazas.
El equipo de seguridad generalmente admite agregar el “Sec” en DevSecOps, pero los equipos de ingeniería asumen la responsabilidad final de garantizar que el código que producen sea seguro.
Tanto las canalizaciones de DevOps como DevSecOps suelen incluir un alto grado de automatización para permitir un desarrollo rápido y preciso que respalde los objetivos comerciales sin sacrificar la calidad del software.
Existe un argumento de que DevOps y DevSecOps son lo mismo. El renombrado orador de DevSecOps, Larry Maccherone, a menudo ha descrito la seguridad como un componente imprescindible en la calidad del software.
En otras palabras, si un activo de software no es seguro, debe considerarse igualmente importante que si un activo no funciona
Si bien, este argumento tiene una lógica clara, en la práctica, la mayoría de las personas consideran que DevSecOps es el término adecuado para una canalización de DevOps que incluye seguridad integrada.
¿Por qué es importante DevSecOps?
Hoy en día, las organizaciones confían en una matriz compleja de infraestructura local, en la nube e híbrida para habilitar sus operaciones.
Esta complejidad se ve agravada por la creación continua de aplicaciones de software, microservicios y contenedores en la nube nuevos y actualizados para organizaciones que desarrollan software internamente.
Cada vez que se crea o cambia un activo o componente orientado a Internet, existe el riesgo de que una vulnerabilidad o una configuración incorrecta lo deje vulnerable a un ataque.
Acelerar el desarrollo, automatizar los componentes de la entrega de aplicaciones y otras complejidades, como dividir el software en microservicios, solamente agravan este riesgo.
Es fácil cometer errores menores durante el proceso de desarrollo, lo que deja un activo completamente expuesto a ciberataques básicos.
De manera similar, los equipos de ingeniería modernos utilizan varias herramientas para automatizar tareas relacionadas, como la configuración y el mantenimiento de servidores, contenedores, repositorios de códigos o registros de imágenes, que también pueden quedar vulnerables.
En última instancia, las canalizaciones de DevOps brindan un valor comercial claro, pero también son una fuente importante de riesgo.
Es por ello que el “Sec” en DevSecOps es tan importante.
Con tanto en juego, proteger el software y la arquitectura de desarrollo no puede ser un apartado más y sin demasiada importancia; debe ser integrado en el proceso del desarrollo, como un apartado vital más.
¿Qué es la seguridad DevOps?
Es fácil decir, “incorpora seguridad en la canalización de DevOps”. Pero, ¿Qué significa eso exactamente?
Bien, eso significa integrar completamente varias prácticas de seguridad en el proceso de desarrollo para detectar defectos de seguridad antes de que el código se envíe a producción.
Defectos como:
- Vulnerabilidades (p. ej., debilidad ante las 10 amenazas principales de OWASP).
- Credenciales y secretos implementados de forma insegura.
- Controles de acceso mal configurados.
10 Principales riesgos de seguridad de las aplicaciones web (by OWASP)
No todas las prácticas de seguridad se pueden integrar con éxito en una canalización de desarrollo sin ralentizar significativamente las cosas.
Sin embargo, una canalización de DevSecOps puede incorporar muchos procesos, herramientas y servicios de seguridad.
Pero, ¿Cómo se construyen procesos más lentos como pentesting en una tubería de desarrollo sin afectar el tiempo de comercialización?
La respuesta es: Separando las prácticas de seguridad en “dentro de banda” y “fuera de banda”.
Prácticas en banda
Las prácticas en banda se pueden integrar fácilmente en la canalización sin causar retrasos significativos. Esto incluye controles como:
Prácticas de codificación seguras
Estos son cruciales para minimizar la presencia de vulnerabilidades en el código escrito. Si bien las vulnerabilidades se pueden encontrar más tarde, la capacidad del equipo para impulsar el código rápidamente depende de poder escribir código que en *su mayoría esté* libre de problemas desde el principio.
Escáneres automáticos de códigos
Los escáneres SAST, DAST e IAST descubren vulnerabilidades en el código fuente y las aplicaciones compiladas.
Revisión del código de pares
Esto requiere mucha mano de obra pero es importante para encontrar vulnerabilidades que pueden no ser evidentes para una máquina, por ejemplo, aquellas causadas por problemas lógicos.
Por lo general, se puede completar una revisión del código entre pares antes de los lanzamientos de productos y actualizaciones importantes, pero no necesariamente para cada inserción de código.
Análisis de composición de software (SCA)
Estas herramientas de escaneo buscan vulnerabilidades en dependencias como bibliotecas de software y proyectos de código abierto.
Las prácticas fuera de banda son más lentas y ocurren junto con la canalización de desarrollo sin retrasar los impulsos de código.
Cuando los resultados de las prácticas fuera de banda están disponibles, se retroalimentan a la canalización para eliminar las vulnerabilidades de seguridad de versiones futuras.
Prácticas fuera de banda
Las prácticas fuera de banda incluyen:
Pentests y evaluaciones de seguridad
Estos pueden tardar días o semanas en completarse, pero son cruciales para garantizar la seguridad de una aplicación o activo de software.
Programas de divulgación de vulnerabilidades y recompensas por errores (VDP)
Estas son fuentes continuas de información de seguridad que pueden alimentar fácilmente nuevos impulsos de código.
Las prácticas de seguridad combinadas en banda y fuera de banda reducen sustancialmente el riesgo de enviar código vulnerable, lo que a su vez puede reducir significativamente el riesgo cibernético de una organización.