Lista de verificación de seguridad de DevSecOps

Aquí hay una lista de verificación de seguridad de DevSecOps de diez pasos que puede ayudar a cualquier equipo a estar en sintonía.

Comprender dónde la seguridad está creando desafíos en el proceso de desarrollo

Nuestra Encuesta Global 2022 de DevSecOps muestra que la brecha entre los desarrolladores y la seguridad se está cerrando, pero aún sigue habiendo algunas fricciones. Un 57 % de los encuestados estuvo de acuerdo en que la seguridad es una métrica de rendimiento para los desarrolladores de su organización, pero el 56 % dijo que era difícil lograr que los desarrolladores priorizaran la corrección de vulnerabilidades del código. Al final, el 59 % dijo que era más probable que el equipo de seguridad encontrara las vulnerabilidades de seguridad después de fusionar el código en un entorno de prueba. Ni siquiera existe un acuerdo sobre quién es realmente responsable de la seguridad: el 43 % de los profesionales de la seguridad afirmaron que ellos son los responsables, pero el 53 % dijo que todos lo son. En resumen: abunda la confusión. El primer paso debe ser comprender qué es lo más desafiante dentro de su pipeline de DevSecOps.

Alinear a todos en torno a un objetivo común

Con tantas suposiciones diferentes sobre la seguridad y la propiedad, ofrecer objetivos claros al equipo proporcionará algo tangible por lo que trabajar. Hacer avanzar la seguridad en el ciclo de vida del software no servirá de nada si su equipo no comprende sus responsabilidades y expectativas. Por ejemplo, alinearse en torno al objetivo de probar más código podría traducirse en versiones más rápidas una vez que las cosas vayan bien. Del mismo modo, establecer el objetivo de mejorar la planificación mediante la incorporación de un defensor de la seguridad desde el principio significa que la seguridad estará involucrada en cada paso del proceso. Por lo tanto, se reducirá la fricción y, en última instancia, se acelerarán los ciclos de lanzamiento. Una práctica exitosa de DevSecOps mejora la responsabilidad incluso entre los miembros del equipo que no se ocupan de la seguridad al crear una cultura en la que la reducción de los riesgos de seguridad es responsabilidad de todos.

Completar una auditoría para identificar dónde están perdiendo el tiempo los equipos

Sin DevSecOps, los equipos de seguridad identifican las vulnerabilidades de seguridad por medio de sus propias herramientas, por lo general al final de un ciclo de desarrollo, y luego las devuelven al equipo de desarrollo para que las corrija. Estas idas y vueltas ponen a los dos equipos en un estado constante de fricción y se desperdicia tiempo con comunicaciones ineficientes. Al comprender cuánto tiempo pierde su equipo al lidiar con las vulnerabilidades después de fusionar el código, es posible que pueda identificar patrones y hacer ajustes para mejorar. Por ejemplo, ¿los equipos de seguridad tienen problemas para rastrear el estado de corrección de las vulnerabilidades críticas, lo que significa que tienen que consultar constantemente con el equipo de desarrollo para conocer las últimas novedades? Esto podría indicar la necesidad de contar con un panel único donde tanto los desarrolladores como los profesionales de la seguridad puedan ver el estado de la corrección de las vulnerabilidades críticas.

Analizar los desafíos y los cuellos de botella

La seguridad puede ser un cuello de botella a la hora de lanzar software rápidamente, pero es importante como para minimizarlo o ignorarlo. DevSecOps promete hacer avanzar la seguridad en el ciclo de vida de desarrollo del software, pero lograrlo no es nada sencillo. Un paso importante es reunir a todos (los equipos de desarrollo, seguridad y operaciones) para debatir con franqueza sobre los desafíos y los cuellos de botella relacionados con la seguridad. Una vez que se hayan expuesto todas las preocupaciones, cree un plan para resolver cada inquietud y ejecútelo. Este debate ayuda a garantizar que se escuche la voz de todos y a identificar los desafíos que podrían no ser evidentes a partir de datos precisos y concretos.

Hacer cambios pequeños e incrementales en el código

En GitLab, iteración es uno de nuestros valores fundamentales, por lo que cuando hacemos cambios, realizamos modificaciones pequeñas y rápidas y luego las desarrollamos. El mismo principio se aplica al cambiar de DevOps a DevSecOps. Los cambios de código más pequeños e incrementales son más fáciles de revisar y proteger, y se pueden lanzar más rápido que los cambios monolíticos del proyecto. La producción de código en pequeños fragmentos o unidades, y luego la ejecución de pruebas automatizadas en esas unidades a medida que se realizan las confirmaciones, permite a los desarrolladores corregir cualquier vulnerabilidad en el acto, en lugar de esperar los comentarios días, semanas o incluso meses después. La ejecución periódica de pruebas ahorra tiempo en el futuro, cuando la aplicación terminada se prueba antes de pasarla a producción.

Automatizar e integrar

La automatización y la integración son fundamentales para DevOps, pero también son lo que hacen de los análisis de seguridad una herramienta poderosa. Si los análisis son ubicuos, se revisarán todos los cambios de código y las vulnerabilidades se encontrarán mucho antes en el proceso. Los análisis deben estar integrados en el flujo de trabajo del desarrollador. La seguridad integrada permite a los desarrolladores encontrar y corregir vulnerabilidades antes de que el código pase a otra etapa. Esto también reduce el volumen de tickets de seguridad que se envían al equipo de seguridad, lo que agiliza su revisión.

Otorgar a los desarrolladores acceso a los resultados de los informes de seguridad

En lugar de mantener los resultados de las pruebas estáticas de seguridad de las aplicaciones (SAST) y las pruebas dinámicas de seguridad de las aplicaciones (DAST) en silos con los equipos de seguridad, asegúrese de que esta información se comparta con todo el equipo, especialmente con los desarrolladores. Si bien esto es importante para la corrección, también es una herramienta valiosa para ayudar a los desarrolladores a establecer los controles de seguridad necesarios en el ciclo de vida de desarrollo del software.

Completar una auditoría de los procesos de seguridad estilo cascada

En el enfoque tradicional de seguridad estilo cascada, las vulnerabilidades suelen encontrarse al final del ciclo de desarrollo. Tómese el tiempo para auditar los flujos de trabajo de seguridad existentes dentro de su ciclo de vida de desarrollo del software. Si encuentra algún proceso de estilo cascada, considere la posibilidad de eliminar o, al menos, reducir en gran medida su dependencia de él. Siempre debe poder cambiar de dirección según surjan las necesidades: Mantenga su organización ágil.

Asegurarse de que el equipo de seguridad tenga visibilidad del estado de la vulnerabilidad

La Encuesta Global 2022 de DevSecOps mostró que el mayor desafío al que se enfrentan los profesionales de la seguridad es priorizar la corrección de vulnerabilidades. Otras preocupaciones incluyeron el volumen de falsos positivos y la dificultad para rastrear el estado de las vulnerabilidaes. Este podría ser uno de los factores que explican las perspectivas de futuro un tanto negativas de los profesionales de la seguridad: solo el 56 % afirmó sentirse «algo» o «muy preparado» para el futuro (casi 20 puntos por debajo que la respuesta media de los departamentos de desarrollo y operaciones). Está claro que los equipos de seguridad necesitan una mejor visibilidad tanto de las vulnerabilidades resueltas como de las no resueltas, dónde residen las vulnerabilidades, quién las creó y en qué estado se encuentran para su corrección.

Optimizar sus herramientas en una sola plataforma de DevOps

Es difícil que todos sean responsables de la seguridad cuando los equipos no cuentan con las herramientas adecuadas. La mejor manera de pasar la seguridad al enfoque Shift left es con una plataforma integral que ayude a los equipos de DevOps a alejarse de los procesos estilo cascada, agilice la comunicación, incluya la automatización y la integración continua y proporcione una fuente única de la verdad para los resultados de los análisis de seguridad y el estado de las vulnerabilidades críticas.