7 obstáculos sorprendentes en el camino hacia la madurez de DevSecOps

Como parte de la reciente formulación y el lanzamiento del Marco de madurez de DevSecOps, Snyk realizó una amplia investigación de la industria sobre el estado actual de la seguridad de los desarrolladores en las empresas centradas en software. Más de 300 organizaciones proporcionaron datos para ayudarnos a comprender cómo evalúan su propia madurez en DevOps, seguridad de aplicaciones, gestión de vulnerabilidades, priorización, adopción por parte de los desarrolladores y gobernanza de programas.

En general, nuestros hallazgos muestran que la mayoría de las empresas entiende el valor de las prácticas maduras de DevSecOps y trabaja activamente para construir una cultura de seguridad moderna y un programa de seguridad de aplicaciones orientado a la mejora continua. Sin embargo, no todas están abordando este proceso de la misma manera. De hecho, dentro del amplio objetivo de aumentar la madurez, observamos bastante diversidad en la forma en que las organizaciones describen aspectos clave de sus prácticas de seguridad, lo que evidencia brechas importantes que aún persisten en el camino hacia una meta común: la madurez de DevSecOps. Veamos algunos hallazgos que destacan posibles áreas de mejora.

La reducción de riesgos y la fatiga de seguridad son los KPI que los equipos de seguridad tienen menos probabilidades de medir, aunque se encuentran entre los cinco indicadores que más desean medir.

De todas las métricas de seguridad que registraban los equipos que investigamos, las dos que tenían menos probabilidades de medirse eran “Reducción de riesgos gracias a las acciones de los desarrolladores” y “Reducción de la fatiga de seguridad (tiempo dedicado a la clasificación manual, compilaciones fallidas y retrabajo de seguridad)”. Sin embargo, cuando preguntamos a los mismos encuestados qué métricas desearían informar idealmente si dispusieran de todos los datos pertinentes, estos dos KPI también ocuparon los primeros puestos de la lista. 

Es evidente que todavía existe una gran desconexión entre los datos que las herramientas de seguridad pueden informar fácilmente —como la cantidad de vulnerabilidades detectadas y corregidas, las puntuaciones CVSS, el tiempo de corrección, etc.— y las preguntas que los profesionales de seguridad quieren plantear, como “¿Cuánto riesgo se reduce con un tipo específico de acción?”, que determinan la eficacia y el ROI de sus programas. Esto resalta la importancia de agregar y correlacionar datos de vulnerabilidades de distintas fuentes para eliminar los silos y comprender el riesgo de forma integral, con base en una visión completa del contexto de la aplicación, el negocio y las vulnerabilidades. Las herramientas de gestión de la postura de seguridad de las aplicaciones (ASPM), como Snyk AppRisk, pueden ayudar al funcionar como centro interno y fuente única de información confiable para obtener insights de seguridad basados en riesgos. 

Por otro lado, de todos los perfiles incluidos en el estudio, los desarrolladores de software fueron quienes expresaron mayor interés en medir la fatiga de seguridad, también conocida como trabajo tedioso. Esta amplia categoría busca medir el costo de adoptar un enfoque de seguridad desde el inicio, en términos de la productividad perdida por los desarrolladores, que deben dedicar tiempo a tareas de seguridad que no se pueden automatizar fácilmente. Como la mayoría de las herramientas de análisis de vulnerabilidades están diseñadas para el público de seguridad, suelen pasar por alto el impacto que tienen en los desarrolladores, lo que hace imposible saber cuánta ineficiencia existe en los procesos de detección y corrección integrados en el SDLC. Esta incapacidad para medir el trabajo tedioso de seguridad contribuye en parte a los altos niveles de fricción entre los equipos de desarrollo y seguridad, que seguimos observando incluso en organizaciones con un alto nivel de madurez de DevSecOps.

Medir con precisión la postura de seguridad en función del riesgo es el objetivo número uno de DevSecOps, tanto para los equipos de seguridad como para los de ingeniería.

En seguridad de aplicaciones persiste el mito de que a los desarrolladores no les importa el riesgo del software. La realidad vuelve a quedar en evidencia: la principal prioridad de DevSecOps para los desarrolladores era comprender con precisión la postura de seguridad basada en riesgos, igual que para sus colegas de seguridad de aplicaciones (los grupos de ingeniería de plataformas la señalaron como su segundo objetivo). En otras palabras, los desarrolladores quieren contribuir a reducir los riesgos de la organización, pero sienten que les faltan los datos necesarios para tomar mejores decisiones de priorización.

Esta discrepancia se debe a la complejidad de calcular el riesgo de las aplicaciones, lo cual requiere contexto adicional (impacto en el negocio, reachability, madurez de la explotación y presencia de controles compensatorios, entre otros aspectos), más allá de un simple recuento de problemas y sus niveles de gravedad. El software moderno es muy complejo y los presupuestos para corregir problemas siempre son limitados. Por eso, el tiempo de corrección no debe asignarse únicamente según las vulnerabilidades de mayor gravedad (que pueden ser explotables o no y, aunque lo sean, podrían tener o no un impacto significativo en el negocio si se explotan), sino mediante un sistema de puntuación personalizado y basado en riesgos, que considere fuentes de contexto diversas a lo largo del SDLC.

La incapacidad de acordar un esquema de priorización basado en riesgos es una de las principales causas de fricción entre los equipos de ingeniería y seguridad, y puede hacer fracasar las iniciativas de DevSecOps debido a la persistente falta de confianza. Los desarrolladores suelen sentir que se ven obligados a dedicar tiempo a corregir los problemas “equivocados” (es decir, los de menor riesgo real). Los profesionales de seguridad suelen sentir que demasiados riesgos reales llegan a los entornos de producción porque no hay un mecanismo compartido y confiable de puntuación de riesgos al que puedan acceder ambos perfiles desde sus flujos de trabajo. Por eso, es evidente que medir el riesgo con precisión es la principal prioridad compartida, pero la mayoría de las herramientas de seguridad todavía está evolucionando para satisfacer esta necesidad.

Solo el 50 % de las organizaciones afirma invertir en capacitación de seguridad para desarrolladores justo cuando la necesitan y en programas de Security Champions dentro de los equipos de desarrollo.

La formación en seguridad, especialmente para los desarrolladores de software, es un componente fundamental de las prácticas maduras de DevSecOps. Para ser eficaz, debe ser pertinente, práctica, continua y estar estrechamente integrada en los procesos y las formas de trabajo de los equipos. Sin embargo, la mayoría de las capacitaciones de seguridad tradicionales no cumple estos objetivos, lo que genera una brecha constante en la comprensión que tienen los desarrolladores de los riesgos de seguridad de las aplicaciones y las prácticas de codificación segura asociadas.

Esta brecha se debe a la forma de aprendizaje que prefieren los ingenieros, basada en la resolución de problemas del mundo real. La gran complejidad de las técnicas modernas de desarrollo de software dificulta enseñar todo lo que un ingeniero necesita saber con métodos tradicionales y verticales. En cambio, los desarrolladores aprenden haciendo: encuentran un problema y deben hallar una solución antes de continuar. Se ha demostrado que este tipo de aprendizaje “justo cuando se necesita” es mucho más efectivo. Sin embargo, la mayoría de los programas de capacitación en seguridad adoptan el enfoque contrario, que no es eficaz. Se ha demostrado que invertir en educación de seguridad justo cuando se necesita —que permite a los desarrolladores tomar una microlección para comprender los riesgos de una vulnerabilidad específica y aprender a corregirla, por ejemplo, al solucionar un problema encontrado en su propio código— mejora los resultados de seguridad. Snyk Learn es un ejemplo de este enfoque. Sin embargo, solo alrededor de la mitad de las organizaciones que estudiamos lo utiliza.

Asimismo, las investigaciones han demostrado sistemáticamente la eficacia de los programas de Security Champions, que buscan integrar directamente los conocimientos de seguridad en los equipos de ingeniería de software. Para ello, se capacita a fondo a un desarrollador de cada equipo y se le proporcionan recursos específicos para que actúe como enlace entre sus colegas desarrolladores y el equipo de seguridad de aplicaciones. Como los ingenieros prefieren aprender de otros ingenieros y sus colegas pueden traducir con mayor eficacia los requisitos de seguridad a las formas de trabajo de sus equipos, se ha demostrado que los Security Champions reducen la fricción con el equipo de seguridad de aplicaciones y mejoran los resultados. La mitad de las organizaciones que aún no ha implementado un programa de Champions podría seguir enfrentando obstáculos en sus iniciativas de seguridad para desarrolladores sin este elemento fundamental de la cultura.

Menos de la mitad (46 %) de las organizaciones afirma que puede identificar con precisión sus aplicaciones críticas para el negocio.

Por lo general, el riesgo se calcula multiplicando la probabilidad por el impacto. Aunque las herramientas de análisis de vulnerabilidades pueden medir con más o menos precisión la probabilidad de explotación (sobre todo si incluyen contexto adicional, como reachability y madurez de la explotación), por definición, solo el negocio puede evaluar el impacto. Un escáner de seguridad no puede distinguir entre un problema de gravedad alta en una aplicación crítica para el negocio y la misma vulnerabilidad en un servicio sin uso que da soporte a un sitio web promocional obsoleto. Sin embargo, los riesgos asociados a estos dos problemas no podrían ser más distintos.

La madurez de DevSecOps exige que las organizaciones comprendan el impacto en el negocio de sus activos de software e integren estas evaluaciones en la puntuación de riesgos para priorizar los problemas. A menudo se utilizan herramientas como las bases de datos de gestión de configuración (CMDB) para mantener un inventario actualizado de repositorios de código, imágenes de contenedores, implementaciones y otros artefactos. También pueden ser la fuente confiable para determinar la criticidad para el negocio; luego, las plataformas de orquestación de seguridad, especialmente las soluciones ASPM como Snyk AppRisk, pueden incorporar esos datos e integrarlos en algoritmos de priorización basados en riesgos.

La mayoría de las organizaciones encuestadas que tienen dificultades para identificar su software crítico para el negocio enfrenta un problema doble: podrían estar dejando que llegue demasiado riesgo a producción en estas aplicaciones clave, cuya explotación tendría un impacto considerable en el negocio. También sufren procesos de corrección ineficientes en general, porque no pueden restar prioridad fácilmente a las correcciones de aplicaciones con puntuaciones de impacto muy bajas. La madurez de DevSecOps requiere herramientas y procesos que consideren el impacto en el negocio como un factor fundamental en cualquier cálculo de riesgos.

Solo el 31 % de las organizaciones aplica automáticamente requisitos de seguridad en varias etapas del SDLC antes de llegar a producción.

Nuestra investigación reveló que la mayoría de las organizaciones tiene perfiles de riesgo de software completamente documentados y que se pueden aplicar automáticamente. Sin embargo, en el grupo más numeroso (40 %), esta aplicación ocurre únicamente en el entorno de producción o ejecución. Un número comparativamente menor de organizaciones toma la iniciativa de aplicar políticas en varios puntos del SDLC, en entornos previos a la producción. Y lo más importante es que, incluso en las culturas maduras de DevSecOps, esto significa que se están perdiendo la mayoría de los beneficios de corregir los problemas de seguridad pronto y con rapidez.

Desde hace mucho, en seguridad se considera una verdad incuestionable que el costo de corregir problemas aumenta a medida que el software avanza por el SDLC. Si solo se implementa un subconjunto de las políticas de seguridad antes de la producción (por ejemplo, en los pipelines de CI/CD, las revisiones de solicitudes de cambios o los entornos de prueba), la mayoría de los problemas requerirá el proceso de corrección más costoso posible.

Existe un equilibrio entre el costo de corrección y la precisión de la detección. Detectar los problemas antes en el SDLC agiliza y hace más eficiente su corrección, porque los ciclos de retroalimentación con los flujos de trabajo de los desarrolladores son más cortos. Sin embargo, a medida que el software se acerca a producción —cuando se compila, empaqueta e implementa en entornos de prueba cada vez más similares a producción—, resulta más fácil comprender el riesgo y los análisis de seguridad son más precisos. No hay un lugar “correcto” para implementar las pruebas de seguridad en un SDLC orientado a DevSecOps. En cambio, el mejor equilibrio entre precisión y eficiencia se logra mediante varios puntos de control de seguridad ligeros que aplican políticas en cada etapa, según los cambios realizados en el software. Las organizaciones que solo aplican seguridad en una etapa deben sacrificar la precisión o la eficiencia de las correcciones, lo que en última instancia limita su avance hacia la madurez de DevSecOps. 

Solo el 25 % afirma que las alertas de seguridad se envían únicamente a las partes interesadas pertinentes e incluyen todo el contexto necesario para actuar.

La fatiga por alertas es una de las principales causas de fricción en seguridad. Demasiadas alertas o notificaciones, en especial las que parecen irrelevantes o requieren un esfuerzo adicional para interpretarlas, se ignoran con facilidad. Con el tiempo, esto puede generar desconfianza en la herramienta de seguridad que produce tanto ruido, incluso si las alertas futuras son más precisas. Por eso, evitar la fatiga por alertas es fundamental para madurar las prácticas de DevSecOps.

Tres de cada cuatro organizaciones reciben notificaciones que no pueden atender adecuadamente. A menudo, les falta el contexto necesario, no se envían a las personas indicadas o no incluyen pasos claros y confiables para resolver el problema. Este caos de alertas puede ser un efecto secundario de varias herramientas de seguridad aisladas que compiten por la atención de las mismas partes interesadas y reducen la capacidad para atender las notificaciones que sí requieren acción.

Respuesta y corrección es uno de los seis pilares del Marco de madurez de DevSecOps de Snyk. Sin embargo, toda estrategia de respuesta repetible debe comenzar con un flujo de alertas capaz de impulsar de forma rápida y confiable acciones decisivas por parte de las personas adecuadas. Las organizaciones que no logren resolver la fatiga por alertas pronto descubrirán que su capacidad para implementar ciclos de corrección confiables, que mejoran con el tiempo, es limitada.

Solo el 37 % describe su programa de DevSecOps como «transparente y de autoservicio desde la perspectiva de ingeniería, lo que facilita protegerse y dificulta introducir riesgos en el software». 

Quizás la mayor desconexión en el camino hacia la madurez de DevSecOps sea comprender la experiencia de los desarrolladores. Al principio, la promesa de DevOps (antes de agregar «Sec») buscaba facilitarles la vida a los desarrolladores al darles herramientas para realizar tareas que requerían la ayuda de equipos de TI centralizados. Empaquetar software, implementar aplicaciones o configurar infraestructura eran tareas que los propios desarrolladores podían gestionar con solo escribir código. Este cambio hacia el autoservicio mediante procesos automatizados y repetibles se convirtió en un pilar del desarrollo de software moderno y permitió reducir considerablemente el tiempo de comercialización.

Sin embargo, en materia de seguridad, el progreso no ha avanzado al mismo ritmo. La idea de «DevSecOps» existe desde hace más de una década, pero suele depender de herramientas y procesos heredados de seguridad de aplicaciones que no se adaptan a las prácticas actuales de desarrollo de software. Esta falta de correspondencia genera una experiencia poco satisfactoria para los desarrolladores. Aunque los ingenieros pueden gestionar fácilmente sus propios contenedores, pruebas automatizadas y servicios en la nube, a menudo tienen que esperar a que se ejecuten análisis de seguridad por separado, lo que encarece la corrección y genera una tensión constante con los equipos de seguridad de aplicaciones.

Esta falta de transparencia y autoservicio dificulta que los desarrolladores gestionen eficazmente los riesgos del software. En lugar de prevenir los problemas desde el principio, a menudo tienen que adivinar cuál es la opción segura y corregirlos más adelante, cuando hacerlo es más costoso. En otras palabras, es fácil introducir riesgos y difícil protegerse. DevSecOps debe romper este ciclo con principios de «seguridad desde el diseño» que ofrezcan caminos predefinidos a los desarrolladores, les permitan gestionar los riesgos por su cuenta y les den la confianza de que la opción predeterminada también es la más segura.

DevSecOps ha evolucionado mucho desde sus inicios. Nuestra investigación muestra que la mayoría de las organizaciones avanzan con firmeza hacia la madurez, pero aún hay mucho por hacer para cumplir la promesa de prácticas de seguridad confiables, automatizadas y centradas en los desarrolladores.

¿Te interesa hacer avanzar tu programa de DevSecOps? Descarga el ebook hoy.