Creo que a día de hoy, todo el mundo está familiarizado con el término DevOps (Por qué el que trabaja en ello, es como el que deja de fumar, te recordará lo malo que es no ser "Ágiles" constantemente). Si bien significa diferentes cosas para diferentes personas, creo que el mejor resumen de una línea que he leído lo describe como "Desarrollo y Operación de la forma más rápida posible".
Este aparentemente obvio cambio cultural de los equipos que rompen las barreras y los silos, combinado con tecnología habilitadora como Chef y Docker (Despliegue de software), que impulsa la automatización, la reutilización y la agilidad, agrega valor a todos los departamentos de TI.
Entonces, ¿estamos ante el fin de la innovación en este ámbito? ¿Hemos logrado el nirvana de la entrega de código? Rotundamente NO, hemos estado perdiendo un componente clave ante esta Agilidad o rapidez, hemos pasado por alto la seguridad (Pero no importa, somos Ágiles)
Todo ello, nos da pie a que hablemos de un término algo menos familiar: DevSecOps (también conocido como SecDevOps por algunas personas).
El concepto, como podéis recoger del nombre, es algo similar al de DevOps. Con DevOps, el objetivo era traer el equipo de Ops (Operaciones) al equipo de desarrollo para que no fuera sólo un acople final de los proyectos. Lo mismo ocurre con DevSecOps: necesitamos garantizar que la seguridad ya no sea una idea tardía para un departamento aislado que se preocupa de estos inseguros desarrollos Ágiles, sino que se integre en todas las etapas de un proyecto y vistas a futuro.
¿Cómo podríamos hacer todo esto? Bueno, comprometeríamos a un recurso de seguridad en todos los proyectos para intentar obtener una configuración automatizada tan pronto como sea posible. Podríamos ejecutar pruebas de seguridad contra el código, pruebas en el proceso de liberación, incrustar herramientas, en definitiva, intentar registrar todo esto de una manera auditable.
Para hacer las cosas de una forma aún más simple, es necesario integrar los procesos de seguridad (¡tal vez crearlos en algunos casos!). El cambio fundamental aquí es no sólo considerar la seguridad en cada etapa, sino ver la seguridad como algo que no ralentiza el trabajo y la productividad.
Si se piensa con honestidad, la prisa por obtener un nuevo producto en el mercado es a menudo el principal conductor de la vulnerabilidad de la seguridad. En realidad, ¿cuál es la peor consecuencia que podría suceder con su nuevo producto encantador / una nueva aplicación / Web ? Una violación de seguridad. Empecemos a hacer algo al respecto. Pasemos de reparar el código roto o vulnerable, protegiéndonos a medida que el código es construido, probado y entregado.
Hay algunos ejemplos más detallados de cómo integrar la seguridad en el ciclo de vida en la creación de software, pero no lo voy a repetir, sino que voy a volver a enfatizar la necesidad de ir pensando en conseguir equipos de seguridad involucrados en los procesos DevOps actuales. Nuestros equipos deben estar entusiasmados con esta premisa, ya que los chicos de seguridad pueden aprender sobre DevOps, y los chicos de DevOps pueden aprender sobre seguridad. Y si no conseguimos equipos lo suficientemente entusiasmados con esta oportunidad de aprender, entonces, debemos preguntarnos si tenemos los equipos adecuados para este DevOps y esta agilidad que tanto nos gusta.
La seguridad a pasado, o debe pasar de ser un simple departamento o gerencia, a involucrarse en el ciclo de vida de los procesos ágiles, rompiendo la premisa de la ralentización. Sacar aplicaciones inseguras o vulnerables, será mucho menos ágil y productivo, debido a que la misma se tendrá que desarrollar 2 veces.
