Por qué el código susceptible se envía a sabiendas



La prioridad empresarial de la velocidad de desarrollo e implementación está eclipsando la necesidad de un código seguro.

El impulso para desarrollar e implementar aplicaciones más rápido ha pasado de ser simplemente un objetivo para los desarrolladores a una prioridad a nivel empresarial que afecta los resultados de cada organización. Para cumplir con este objetivo, las empresas han comenzado a deslocalizar el desarrollo, las operaciones y la seguridad, avanzando hacia un modelo DevSecOps para ofrecer mayor agilidad y velocidad en el ciclo de vida del desarrollo de computer software (SDLC).

A menudo se pierde en el caos de este cambio cultural hacia un enfoque SDLC de «necesidad de velocidad» la desalineación entre DevOps y los objetivos de los profesionales de la seguridad. Ambos equipos deben esforzarse por equilibrar sus respectivos objetivos: sacar nuevas funciones y minimizar el riesgo de computer software. Sabemos que esta desalineación contribuye a que el código vulnerable se envíe con más frecuencia de la que debería, pero lo que la mayoría de la gente no se da cuenta es que esto está sucediendo a sabiendas y con bastante frecuencia. Según una reciente ESG Informe de investigación, casi la mitad (48%) de las organizaciones están impulsando códigos vulnerables con regularidad, y lo saben.

La pregunta basic que plantea esta estadística es: ¿por qué? La ciberseguridad sigue siendo una preocupación prioritaria para todas las organizaciones, con una vulnerabilidad que tiene el potencial de disminuir la reputación de una marca, que tardó décadas en construirse, en solo unos segundos. Entonces, ¿por qué los desarrolladores implementan código susceptible a sabiendas?

Los hallazgos del informe ayudan a arrojar algo de luz sobre las razones:

  • El 54% de las organizaciones impulsa el código vulnerable para cumplir con una fecha límite crítica, con planes de corregirlo en una versión posterior.
  • El 49% de las organizaciones impulsa código susceptible porque cree que tiene un riesgo muy bajo.
  • El 45% de las organizaciones publican código vulnerable porque las vulnerabilidades se descubrieron demasiado tarde en el ciclo para resolverlas a tiempo antes de que se implementara el código.

Estos datos nos ayudan a comprender que la prioridad empresarial de la velocidad de desarrollo e implementación eclipsa la necesidad de un código seguro. Las organizaciones están reconociendo varios riesgos con respecto a la seguridad cibernética, la velocidad y los objetivos comerciales, y están dispuestas a asumir algunos de estos riesgos porque las prioridades están en oposición entre sí. Para abordar la frecuencia de publicación consciente de código vulnerable, debemos analizar las causas subyacentes que han provocado que surja una situación tan desafiante.

En primer lugar, los desarrolladores, que en última instancia tienen la responsabilidad de corregir las fallas en el código, no tienen la capacitación ni el acceso a herramientas de seguridad con las integraciones adecuadas para mitigar las vulnerabilidades de manera eficaz. El informe de ESG encontró:

  • El 29% de los desarrolladores carecen de los conocimientos necesarios para mitigar los problemas identificados con las herramientas de prueba actuales.
  • El 26% de los desarrolladores encontraron dificultades o una falta de integración entre las diferentes herramientas de los proveedores de AppSec para generar desafíos.
  • El 26% de los desarrolladores dijo que las herramientas de prueba agregaron fricción o ralentizaron los ciclos de desarrollo.
  • El 35% de las organizaciones dice que menos de la mitad de sus equipos de desarrollo están involucrados en capacitación formal de AppSec.
  • Menos de la mitad de los desarrolladores participan en capacitaciones formales de AppSec más de una vez al año.

Estos desafíos pueden y deben abordarse para ayudar a los desarrolladores a reducir el volumen de código vulnerable que se envía.

A medida que la seguridad continúa pasando a manos de los desarrolladores, las organizaciones deben seguir preparándose para este cambio de cultura modernizando su enfoque de AppSec.

Para los gerentes de AppSec y los CISO que buscan crear un enfoque DevSecOps integrado, algunos elementos comunes de los programas AppSec eficaces incluyen:

  • Los controles de seguridad de las aplicaciones están altamente integrados en la cadena de herramientas de CI / CD.
  • La formación en seguridad de aplicaciones es una parte esencial de la formación que se incluye para los programas de formación en seguridad de desarrollo.
  • Se documentan y comunican las mejores prácticas de seguridad y desarrollo de aplicaciones.
  • Seguimiento de problemas de seguridad y métricas de mejora continua para los equipos de desarrollo.

Depende de los líderes del equipo de seguridad y desarrollo formalizar una estrategia de AppSec que abarque la capacitación, el establecimiento de objetivos, la integración de herramientas y la aplicación de políticas sin introducir demasiada fricción.

Incluso con un programa de seguridad de aplicaciones sólido, las organizaciones seguirán implementando código susceptible. La diferencia es que lo harán con una comprensión profunda y contextual de los riesgos que están tomando en lugar de permitir que los desarrolladores o gerentes de ingeniería, que carecen de experiencia en seguridad, tomen esa decisión. La seguridad de las aplicaciones requiere una clasificación constante de los riesgos potenciales, lo que implica decisiones de priorización que permiten a los equipos de desarrollo mitigar el riesgo sin dejar de cumplir con los plazos clave de entrega.

A medida que la seguridad de las aplicaciones ha madurado, ninguna técnica de prueba ha ayudado a los equipos de desarrollo a mitigar todos los riesgos de seguridad. Los equipos suelen emplear varias herramientas, a menudo de varios proveedores, en varios puntos del SDLC. El uso varía, al igual que las herramientas que las organizaciones consideran más importantes, pero la mayoría de las organizaciones terminan utilizando un conjunto de herramientas para satisfacer sus necesidades de seguridad.

Por último, si bien la mayoría de las organizaciones brindan a los desarrolladores algún nivel de capacitación en seguridad, más del 50% solo lo hace anualmente o con menos frecuencia. Esto simplemente no es lo suficientemente frecuente o completo como para desarrollar hábitos de codificación seguros. Si bien los gerentes de desarrollo a menudo son responsables de esta capacitación, en muchas organizaciones, los analistas de seguridad de aplicaciones cargan con la carga de realizar capacitaciones correctivas para equipos de desarrollo o desarrolladores individuales que tienen un historial de introducir demasiados problemas de seguridad. Las organizaciones deben buscar herramientas de capacitación más prácticas que ofrezcan prácticas de codificación seguras a través de ejercicios interactivos basados ​​en amenazas modernas que los desarrolladores pueden practicar, explotar y parchear. Un enfoque basado en laboratorios para la habilitación del desarrollador puede mejorar el tiempo para resolver fallas y ayudar a los desarrolladores a aprender a evitar las fallas por completo.

Chris Eng es director de investigación de Veracode. A lo largo de su carrera, ha liderado proyectos de ruptura, construcción y defensa de software para algunas de las empresas más grandes del mundo. Es un partidario descarado de la coma de Oxford y la odia cuando se united states la palabra «preguntar» como … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia original