Existe una necesidad por parte de las compañías de ir más allá del DevOps y adoptar el DevSecOps. Además, garantizar la seguridad no debe ser un plan de última hora, sino que debe ser algo integrado en todas las diferentes fases de desarrollo de un proyecto.

DevOps se refiere a la integración de desarrollo, operaciones TI, seguridad y garantía de calidad bajo un mismo paraguas en el desarrollo de un negocio. En resumen, es el cruce de diferentes negocios a la hora de desarrollar software, con ciclos más cortos, tiempos de prueba más rápidos, más automatismo y un código mejorado y seguro.

DevOps busca establecer bucles continuos en los que los diferentes equipos de un negocio planeen, programen código, construyan, implementen, gestionen y monitoricen de forma conjunta. Al hacer esto el desarrollo de código se vuelve más flexible y eficiente, además de mejorar el acabado de los productos.

Son muchos los beneficios de los DevOps: desde mejorar la calidad del software y el time to market, a reducir el riesgo de cumplimiento. Aun así, la gran pregunta sobre el rol de la seguridad de la información en el proceso se mantiene ahí: ha habido un gran intento por parte de las compañías de ir más allá del DevOps y adoptar el DevSecOps, el proceso de envolver información de seguridad en todas las partes del desarrollo de aplicaciones.

El problema es que esto no es fácil de conseguir: hay una relación complicada entre los equipos de seguridad y los de TI, sin contar además con que DevOps y DevSecOps tienen una diferencia importante de modelos operativos y de objetivos.

Con DevOps,  el fin es traer los equipos de desarrollo a los equipos de seguridad, de manera que no sea simplemente la última parte del proyecto por añadir, como viene sucediendo hasta ahora. Lo mismo se aplica DevSecOps, hay una necesidad de garantizar que la seguridad no es un plan de última hora, si no que se trata de algo integrado en todas las fases de un proyecto.

Google y Amazon ya lo predijeron
La mayoría de las compañías que han adoptado un modelo DevOps han disfrutado desde el principio de sus beneficios: un estudio reciente ha señalado que las empresas que lo han integrado han aumentado su time to market en un 20%, un 22% en las relaciones con los clientes y un 19% en ingresos.

Otro informe señaló que el 52% de las compañías que han adoptado el método DevOps aumentan la satisfacción de sus clientes y la tasas de conversión, con un 38% de aumento en ventas.

Google y Facebook son probablemente los dos pioneros de este modelo, ya que empezaron a ponerlo en práctica e innovar en sus productos cloud nuevos y viejos; lo mismo se aplica también a Amazon con su plataforma AWS.

Netflix ha creado el Simian Armu, una gama de herramientas automatizadas para probar las infraestructuras de la empresa de streaming; esto permitirá a la compañía identificar proactivamente los problemas de seguridad antes de que se conviertan en un problema serio para los clientes.

Otras firmas, tanto pequeñas como grandes, han empleado métodos DevOps para acortar el tiempo de desarrollo software de días a horas, y parece que otras empresas continuarán con esta tendencia a lo largo del año. Gartner predijo que un cuarto de las empresas globales habrá adoptado este modelo para finales del 2016, haciendo del DevOps una estrategia mainstream.

Puntos extras en seguridad
A pesar de estos ejemplos, son muchas las dudas planteadas alrededor de si este método puede mejorar la seguridad de la compañía, especialmente con equipos demandando visibilidad completa del entorno de cómputo; a esto se une además una regulación muy estricta de los procesos.

La mayoría de los expertos creen que la seguridad puede beneficiarse de los DevOps, diseñando la seguridad desde el principio, y manteniendo siempre un equilibrio con los objetivos de la compañía.

Además, el automatizar la seguridad y los test regulatorios del cumplimiento durante los ciclos de desarrollo, implementación y producción puede suponer alcanzar niveles de seguridad nunca vistos.

“DevOps es en realidad un impulso para los expertos en seguridad, que podrán mediante la correcta automatización de las herramientas, inocular la seguridad desde el comienzo del proceso; también supondría el aumento de la seguridad del código que afecta directamente a la producción”, explicó James D. Brown, director de Jump Cloud, en un artículo en Wired.

¿Adiós a los agujeros de seguridad?
Andy Chakraborty, consultor de DevOps y de seguridad y actual manager global de la oficina de Tony Blair, explicó en una entrevista que “gracias al método DevOps hay una relación mucho más estrecha entre la gente que desarrolla las aplicaciones y los encargados de los sistemas de la infraestructura en los que la aplicación se basa”.

“Esto permite un entendimiento más profundo de lo que la aplicación hace y dónde puede ser más débil ante amenazas de seguridad. Con la proliferación de las brechas de seguridad (como Heartbleed o Shellschok) este entendimiento del desarrollo de aplicaciones permite tomar decisiones más informados”.

“Como experto en seguridad, percibo mucho rechazo hacia el movimiento DevOps”, comentó al respecto en un blog el experto en seguridad Jay Shculman. “Yo sugiero lo contrario, ya que este método permite una integración de la infraestructura y desarrollo, causando un gran impacto en el entorno de seguridad”.

Sin embargo, no todo el mundo cree que sea un matrimonio tan armonioso. Algunos expertos alegan que puede causar problemas a los equipos de seguridad, especialmente haciendo más difícil comprender los peligros a los que se enfrenta la organización. Con el TI tradicional, el tiempo de desarrollo e implementación es más largo, lo cual implica que el equipo de seguridad tiene tiempo y recursos para revisar el código y reforzar la seguridad al final del ciclo.

Con el DevOps, en cambio, no hay tiempo para revisar esos agujeros antes del lanzamiento del producto, además de tener menos tiempo para reforzar la seguridad. Junto con esto, existe la posibilidad de que el método DevOps automatice el proceso erróneo y desencadene una serie de riesgos para la compañía.

Los desafíos de la adopción
Para empezar, las juntas ejecutivas suelen intentar definir un ROI antes de seguir adelante con cualquier proyecto, mientras que también está la importante tarea de desplegar un programa de sensibilización para poder hacer una fácil transición.

Estas dos razones están disuadiendo a algunas compañías de implementar este modelo de negocio. En un estudio promocionado por CA Technologies se descubrió que solo el 20% están adoptando el método DevOps, ya que la mayoría de organizaciones no entienden bien los requisitos clave para el crecimiento de ventas. Por ello, aún quedan algunos obstáculos por superar antes de que este modelo se convierta en una estrategia convencional.

En última instancia, de todas formas, es difícil no coincidir con el CEO de Microsoft, Satya Nadella, quien destacó que “en el futuro todas las empresas se convertirán en un negocio basado en el software con el método DevOps con un rol fundamental siempre y cuando la seguridad esté integrada”.

-IDG.es