Detrás del software program que impulsa nuestro mundo y nuestras economías hay desarrolladores de software program que diseñan, desarrollan e implementan código. Los desarrolladores de software program ejercen una influencia significativa en la calidad, confiabilidad y seguridad del software program producido. Alternativamente, los atacantes simplemente buscan un error de codificación inocente, una dependencia susceptible, un secreto filtrado, una función con privilegios excesivos o un depósito de almacenamiento mal configurado que pueda explotarse para infiltrarse en una empresa. Esto eleva la seguridad de las aplicaciones al papel más essential de su equipo de desarrollo.
Ya deberíamos ser mejores en esto.
El concepto de DevSecOps, que integra personas, procesos y tecnología con el objetivo de incorporar seguridad a lo largo del ciclo de vida de una aplicación, no es nuevo. Forrester presentó Los siete hábitos de Rugged DevOps, una de las primeras versiones de DevSecOps, en 2015. Sin embargo, la transformación lleva tiempo y numerosos factores, como las regulaciones de la industria, la tolerancia al riesgo, el código heredado y la cultura empresarial, pueden facilitar o impedir la adopción por una organización o equipos individuales. Gracias a los asistentes de codificación de los desarrolladores, las implementaciones en la nube y las canalizaciones CI/CD automatizadas, el código se publica a una velocidad ridícula, pero sin la seguridad de la aplicación, ese código tiene el potencial de introducir un riesgo negativo significativo para la organización.
Veamos dónde nos encontramos este año en lo que respecta a la seguridad de las aplicaciones.
Los exploits de aplicaciones net continúan persistiendo. El veintidós por ciento de los tomadores de decisiones de seguridad que informaron violaciones a través de ataques externos identificaron vulnerabilidades de aplicaciones net como el punto de entrada. Nos referimos a fallas de seguridad comunes como XSS (Cross-Website Scripting) y SQL injection (SQLi), que los atacantes aprovecharon para comprometer a las organizaciones. Las herramientas diseñadas para identificar este tipo de fallas, como las pruebas de seguridad de aplicaciones estáticas (SAST) y las pruebas de seguridad de aplicaciones dinámicas (DAST), han estado disponibles durante décadas. Entonces, ¿por qué estos problemas siguen prevaleciendo? En primer lugar, para que estas herramientas sean efectivas, los equipos deben usarlas en las primeras etapas del ciclo de vida de desarrollo, pero a menudo no lo hacen. En segundo lugar, los ataques dirigidos a interfaces de programación de aplicaciones (API) han aumentado en los últimos años, y las organizaciones están luchando por inventariar con éxito las API y mucho menos aplicarles las mejores prácticas de seguridad de las aplicaciones. Los ataques a la cadena de suministro de software program están aumentando. Una forma particularmente insidiosa de estos ataques involucra a malos actores que comprometen bibliotecas de código abierto. Las organizaciones, sin saberlo, descargan e incorporan estas bibliotecas comprometidas en las aplicaciones de los clientes. El veintisiete por ciento de los tomadores de decisiones de seguridad que informaron violaciones a través de ataques externos identificaron vulnerabilidades de software program como el vector. Otro consejo básico de higiene: mantenga actualizadas sus bibliotecas de código abierto y de terceros. Cuando se revelan y parchean nuevas vulnerabilidades críticas, para obtener una solución a menudo es necesario actualizar a las últimas versiones. Si su aplicación tiene varias versiones atrasadas, esto podría requerir actualizaciones dolorosas solo para aplicar una solución de seguridad, lo que retrasaría su capacidad de respuesta. La deuda de seguridad no desaparecerá mágicamente. En el mundo de la seguridad del software program, esto es related a la deuda técnica, que se acumula cuando se toman atajos, se omiten las pruebas o se realizan revisiones de código superficialmente para acelerar los lanzamientos de productos. Cada equipo de desarrollo de software program ha experimentado la carga de la deuda técnica. Los síntomas incluyen quejas de los clientes sobre una interfaz de usuario lenta, la corrección de un defecto en un área del código que genera consecuencias no deseadas en otra o una acumulación de defectos cada vez mayor. La deuda de seguridad es related.
Pero no todo son advertencias nefastas y oportunidades perdidas para mantenerse al día con lo básico. Hemos observado algunas tendencias prometedoras en los equipos que realizan la transición a DevSecOps, que representa un enfoque de seguridad más preventivo. ¿Interesado en descubrir más? Profundice en nuestro informe completo, El estado de la seguridad de las aplicaciones, 2024, para ver cómo se compara su programa.
