Lograr DevSecOps requiere cortar la jerga



Establecer una cultura donde la seguridad pueda funcionar fácilmente con los desarrolladores comienza por asegurarse de que al menos puedan hablar el mismo idioma.

Cuando se trata de equipos de desarrolladores y seguridad, la palabra del día es fricción. Por un lado, los desarrolladores se centran en crear y moverse lo más rápido posible. Por otro lado, los equipos de seguridad generalmente se inyectan en el proceso en momentos inoportunos para corregir las vulnerabilidades del computer software.

Esta dinámica incohesiva interrumpe el flujo y la velocidad que a los desarrolladores les gusta operar, lo que hace que los desarrolladores vean la seguridad como un obstáculo en lugar de un grupo con el que deberían trabajar de la mano.

Los líderes empresariales entienden la importancia general de establecer una cultura de «DevSecOps» dentro de su entorno, donde los desarrolladores y la seguridad trabajan a la perfección para lograr un objetivo común. Pero ponerlos en la misma página es un desafío cada vez mayor. Ambas han sido áreas de negocios tradicionalmente fragmentadas y trabajan en entornos profundamente técnicos con agendas completamente diferentes.

Como con cualquier departamento, los desarrolladores tienen una jerga que usan que es ajena a aquellos que no están profundamente involucrados en las complejidades del desarrollo de software package. Establecer una cultura donde la seguridad pueda funcionar fácilmente con los desarrolladores comienza por asegurarse de que puedan al menos hablar el mismo idioma

Para ayudar a cerrar la brecha, desglosé algunas de las iniciativas y términos comunes que los desarrolladores usan y los profesionales de seguridad deben conocer para ayudarlos a estar en la misma página e integrar mejor la seguridad en sus procesos.

• «Desplazar a la izquierda»: Esto realmente debería llamarse «expandir a la izquierda» (pero ese es un punto y argumento para otro día). Desplazar a la izquierda simplemente significa que las pruebas de computer software y sistemas deben realizarse temprano en el ciclo de vida para detectar defectos y errores rápidamente. Con los desarrolladores centrados en la velocidad y la innovación, encontrar errores al remaining del proceso de desarrollo de application los ralentiza demasiado. El desplazamiento hacia la izquierda apunta a evitar errores que impidan el desarrollo.

Esto es importante desde el punto de vista de la seguridad por varias razones. Con ciclos DevOps cada vez más rápidos, los desarrolladores inevitablemente tienen una mayor responsabilidad de asegurar el código porque la seguridad exige su atención con mayor frecuencia. Las puertas de seguridad tradicionales simplemente no son suficientes para mantener este ritmo rápido, lo que dificulta no solo la velocidad sino también la innovación. Los profesionales de seguridad también tienen que desplazarse a la izquierda para ayudar a integrar la seguridad en los procesos de desarrollo. Cuando esto sucede, una organización pasa de una cultura DevOps a una cultura DevSecOps, donde ambos equipos aportan un valor significativo al trabajar en conjunto.

• «Integración continua»: La integración continua (CI) significa que los cambios de código se integran automáticamente desde múltiples contribuyentes para una pieza de software package. Para los desarrolladores, este proceso es increíblemente interactivo y rápido. Cuando escuchas a los desarrolladores hablar sobre CI, significan que los cambios que se realizan en sus equipos se implementan automáticamente para mejorar el software program en desarrollo como un esfuerzo de colaboración.

Por seguridad, es valioso saberlo debido a la oportunidad serious de aplicar prácticas de codificación seguras y evaluaciones de vulnerabilidad en esta etapa. Por ejemplo, el análisis de código estático al principio del ciclo de vida del desarrollo de software package puede ayudar a identificar errores que normalmente afectarían la producción. Cuando se eliminan las vulnerabilidades antes de la producción, es una victoria no solo para la gente de seguridad sino también para los desarrolladores porque no tienen que reescribir el código más adelante (o deshacer nada).

• «Pruebas de regresión»: Las pruebas de regresión son bastante simples. Es la prueba de principio a fin de una aplicación nueva o actualizada para asegurarse de que las actualizaciones o modificaciones no afecten negativamente el funcionamiento de la aplicación para los usuarios finales. Y es un proceso donde la seguridad definitivamente debería estar involucrada.

Durante las pruebas de regresión, la seguridad debería aprovechar la oportunidad de colaboración. Del mismo modo que los desarrolladores quieren probar el producto en busca de problemas de funcionalidad, la seguridad debe examinar la aplicación para identificar las debilidades que podrían ser explotables. De esta manera, se pueden establecer puertas de seguridad adecuadas para mitigar las vulnerabilidades antes de la producción.

Cuando la seguridad está involucrada en el proceso de prueba de regresión, el motor se prueba desde el punto de vista de la funcionalidad y la vulnerabilidad antes de implementarse, lo que resulta en un software program de alto rendimiento y más seguro.

• «Despliegue de Canarias» y «falla»: Estos dos prácticamente van de la mano. Un lanzamiento canario es cuando los desarrolladores lanzan una versión de computer software nueva o actualizada a un pequeño subconjunto de usuarios para evaluar qué tan bien funciona antes de un lanzamiento masivo. Fallar hacia adelante es cuando los desarrolladores encuentran un problema durante un lanzamiento canario y hacen ajustes sobre la marcha en lugar de retroceder a una versión anterior o impedir el desarrollo.

Del mismo modo que los desarrolladores prueban los problemas de rendimiento en un entorno más pequeño durante una implementación canaria, la seguridad también puede estar involucrada en el proceso al monitorear un pequeño subconjunto de usuarios dentro de un entorno de menor riesgo. Es casi como una prueba de manejo para ver qué tan bien le irá al producto remaining una vez que se desate en la naturaleza.

Logrando DevSecOps
Obviamente, se necesita más que aprender nuevos términos e iniciativas para integrar la seguridad en los procesos de los desarrolladores, pero uno de los primeros pasos más importantes que pueden tomar los equipos de seguridad es colaborar estrechamente con los desarrolladores para comprender dónde debe estar involucrada la seguridad para agregar valor actual.

Es comprensible que los equipos de desarrollo quieran innovar lo más rápido posible, y los equipos de seguridad deberían ser empáticos con eso. También es comprensible que los equipos de seguridad quieran que los desarrolladores ayuden a garantizar que sus innovaciones no ignoren la seguridad adecuada, y los equipos de desarrollo deben ser empáticos con eso.

La clave y el único camino a seguir es un enfoque combinado en el que ambas partes trabajen juntas para lograr el objetivo común de impulsar rápidamente un computer software innovador que también sea lo más seguro posible. Sin embargo, hasta que ocurra ese cambio de mentalidad, ambas partes continuarán señalando a la otra como un obstáculo para el progreso.

Contenido relacionado:

Mario DiNatale se desempeña como jefe de seguridad de la plataforma en ZeroNorth. Anteriormente, era CTO en Kyber Security y CIO de la ciudad de Hamden. Además, Mario actúa como mentor y asesor de numerosas nuevas empresas. Incluso mientras actúa en una capacidad ejecutiva, él permanece regularmente … Ver biografía completa

Más concepts





Enlace a la noticia original