DevOps y Seguridad, ¿qué esconde esta frase?

Cómo nombramos las cosas puede cambiar nuestra actitud hacia ellas. Es más, conseguir el nombre correcto para un producto, equipo o iniciativa puede ser sustancial en el éxito del mismo.

Pero, ¿qué tiene esto de relevancia para los equipos de seguridad de TI? ¿Por qué debería importarles cómo se llaman las cosas? Simplemente porque cambia la actitud sobre cómo y dónde se gestiona la seguridad de las TI.

DevOps y seguridad: ¿parte del proceso, o infiltrándose en el proceso?

DevOps está cambiando la forma en que los equipos de TI organizan sus actividades. En lugar de separar a los desarrolladores y la gente de operaciones en equipos distintos, como ocurría en el pasado, DevOps se centra en cómo racionalizar los cambios y llevarlos a la producción más rápidamente.

Lo más habitual es que la seguridad se aborde después de los hechos. Para los desarrolladores, la seguridad de TI no está en primer plano cuando se trata de crear o añadir aplicaciones. Según el Global Developer Report de GitLab, sólo el 25% de los desarrolladores calificaron la seguridad de su organización como «buena». En contraste, el 50% estuvo de acuerdo en que las vulnerabilidades de seguridad son descubiertas en su mayoría por el equipo de seguridad después de que el código se fusionara y en un entorno de prueba.

Los equipos de seguridad tienen que estar involucrados en el proceso de desarrollo de software para ayudar a los desarrolladores a producir un código más seguro y evitar que las vulnerabilidades entren en producción. Sin embargo, la forma en que esto se lleva a cabo en la práctica puede marcar una gran diferencia en cuanto a lo fructífero de estos cambios.

Es aquí donde una cosa tan simple como nombrar se vuelve importante. Hay dos términos para la forma en que la seguridad se incorpora en DevOps: DevSecOps y DevOps Security. Dependiendo de tu forma de pensar, puedes elegir cualquiera de ellos, pero es fundamental reconocer que no son intercambiables.

DevSecOps posiciona la función de seguridad como parte del canal de software global: en esto, la seguridad es parte del flujo desde el desarrollo del software hasta la producción. Por otro lado, DevOps Security posiciona la función de seguridad como responsable de la seguridad en todo el proceso, de principio a fin. Dependiendo de tu equipo y de cómo trabajes con otros – estos dos enfoques tendrán diferentes beneficios y desventajas.

Por lo tanto, DevSecOps es más rápido de implementar, integrándose directamente con los desarrolladores en su trabajo. Puede facilitar la implementación de la seguridad en el proceso de desarrollo si no está ahí para empezar. También puede hacer más rápido el acceso a las nuevas construcciones y comprobar que son seguras antes de entrar en producción, pero puede tener un efecto limitador a largo plazo. Si bien el equipo de seguridad puede intervenir rápidamente, se encuentra bloqueado en un momento y un papel específicos en el proceso, en lugar de participar en todo el proceso de desarrollo. Si un problema se desarrolla una vez que el proyecto de software pasa a producción, entonces puede ser más difícil de detener.

Por el contrario, DevOps Security implica examinar todo el proceso y ver cómo la seguridad puede ser incorporada en todas las etapas de desarrollo e implementación del software. En lugar de involucrarse en un punto específico, los equipos de seguridad trabajan para que la seguridad esté disponible y sea utilizada por los desarrolladores como parte de sus flujos de trabajo. Esto implica la integración de cualquier herramienta relacionada con las vulnerabilidades, el escaneo de seguridad o la infraestructura en la forma en que trabajan los desarrolladores.

Pensar a largo plazo en el desarrollo y la seguridad

Mirando a DevOps y la seguridad, es imperativo para nosotros como profesionales de la seguridad entrar en la mentalidad de nuestros usuarios.

Esto es particularmente útil para los desarrolladores, ya que formar parte de su flujo de trabajo y proporcionarles información desde el principio de su trabajo es tan importante como detectar los problemas de seguridad.

Este enfoque implica poner la información en manos de los desarrolladores durante todo el proceso. Implicará más trabajo para hacer las cosas bien, pero proporcionará mucho más valor a los desarrolladores y a la empresa en su conjunto.

Firmado: Raúl Benito, Territory Account Manager de Qualys para España y Portugal