“¿Está hecho el SAST? ¿DAST también? Genial, ¡tenemos DevSecOps!”
He escuchado esta afirmación recientemente más de lo que esperaba.
Pasar a un enfoque DevSecOps es más que solo hacer un análisis de código, incluso si se hace en las primeras etapas. Según un estudio de CSA, el 30% de las empresas ya están en proceso de implementar DevSecOps en su organización, lo que refleja la relevancia que tiene en aras de la seguridad en la nube.
DevSecOps está muy centrado en el ser humano y debe ser claro en toda la organización. Los procesos y la cultura son la base sólida sobre la que se debe construir DevSecOps. Dicho esto, hablemos de la cadena de herramientas. Cuando pensamos en los controles de seguridad dentro de DevOps, necesitamos una visión amplia de lo que debe protegerse. Implica cómo se realiza la automatización, cómo se aprueba la construcción, cuántos riesgos se implementan en producción, etc.
El desplazamiento a la izquierda se ha vuelto popular en los equipos de DevOps, y cada vez más personas lo incluyen en sus proyectos. Tener visibilidad sobre lo que están desarrollando tus compañeros es necesario para poder actuar en consecuencia. Muchas herramientas de prueba pueden descubrir brechas de seguridad en las fases del código, con SAST/DAST como referencias en ese asunto. Pero cambiar a la izquierda significa que mantienes la conciencia en tu lado derecho.
En un flujo de tres pasos muy simple de código-construcción-implementación, DevSecOps generalmente se adjunta solo en el primer paso. Cada paso tiene sus propios desafíos. Comenzando con la gestión del código fuente (SCM), ¿sabemos cuántas vulnerabilidades tiene nuestro repositorio fuente? ¿Podemos rastrear cada uno de ellos hasta su paquete fuente? ¿Cómo los controlamos/vigilamos? Estas son algunas de las preguntas que surgen en este paso. Si bien algunos SAST ayudan, otros no. Y siempre tenga en cuenta que la cadena de herramientas tiene procesos sólidos y complementarios.
Luego pasamos al siguiente paso: construir. Cualquiera que sea el producto innovador que se esté creando en su repositorio, saltará a un repositorio de artefactos, probablemente un registro, la casa de las imágenes de contenedores. ¿Cómo podemos estar seguros de que esos artefactos pasaron con el mismo estado? Si se aceptó algún riesgo, por ejemplo, un paquete sin solución disponible pero que es imperativo para que la aplicación funcione, o todas las vulnerabilidades se han corregido, el artefacto debe permanecer con el mismo estado. ¿Hay alguna forma de saber si algo malo llegó a la imagen del contenedor?
Todas esas preguntas surgen sin tener en cuenta que el proceso de compilación en sí también debe monitorearse debido a los riesgos de seguridad de CI/CD asociados con un control de IAM débil, el uso inadecuado de herramientas de terceros y más.
Todos los pasos anteriores nos llevan a: desplegar. Todo un nuevo mundo de posibilidades depende de la arquitectura fundamental de la aplicación. ¿Es sin servidor? ¿Quizás un enfoque de microservicios encaja mejor? ¿Vamos a utilizar los servicios administrados de CSP para nuestros contenedores y/u orquestación? Es importante conocer estas características de antemano porque una vez que se implementa la aplicación, una cadena de herramientas adecuada debe estar lista para mantener la seguridad en un cierto nivel.
Cada opción que mencioné tiene sus propias restricciones y consideraciones; por ejemplo, si nuestra solución está basada en agentes, es posible que tengamos problemas con la arquitectura PaaS. Es posible que estemos en lo más profundo del viaje y que el barco del código ya haya zarpado, pero es necesario implementar nuevos controles y procesos.
DevSecOps es DevOps en torno a la seguridad. El equilibrio entre la agilidad y la protección adecuada es el objetivo. DevSecOps no se trata solo del código, sino de su viaje. Además del flujo de tres pasos que usé como ejemplo, habrá riesgos adicionales que deben abordarse de acuerdo con la canalización y la aplicación que estamos tratando: qué sucederá con el monitoreo de seguridad durante la producción y qué haremos con la identidad. durante todo el proceso de DevOps?
El monitoreo continuo y la confianza cero también entran en escena en el marco DevSecOps, que va mucho más allá de analizar lo que sucede en nuestro código.
Este es un viaje duro, no hay duda al respecto. Pero es necesario considerar todos estos elementos desde el principio. Desde los profesionales de la seguridad hasta los arquitectos de seguridad, es imperativo que nuestros colegas y clientes sepan que cuando hablamos de DevSecOps, nos enfrentamos a un desafío de varias fases que comienza desde el principio de DevOps (incluso en la fase de diseño, que omití intencionalmente), e implica un viaje sin fin porque siempre se necesitarán nuevas características, surgirán nuevas tendencias tecnológicas en el mercado, etc.
Cuanto más claro sea comprender lo que implica DevSecOps, mejor manejaremos estos desafíos.
Alejandro Bernal es arquitecto de seguridad y miembro del Grupo de Trabajo de Tendencias Emergentes de ISACA
