Mitigar la deuda técnica con seguridad impulsada por el desarrollador

Hablemos de deuda

Casi todo el mundo sabe ya que el cibercrimen se ha convertido en un problema importante para nuestra economía global. En 2022, el coste medio de una brecha de seguridad en Estados Unidos ascendió a 9,44 millones de dólares, frente a los 9,05 millones del año anterior. Es importante no ignorar el coste del código inseguro y su deuda técnica acumulada. Según el informe de 2022 del Consortium for Information and Software Quality: The Cost of Poor Software Quality, se estima que el coste de la mala calidad del software en EE. UU. ha crecido hasta los 2,41 billones de dólares y la deuda técnica de software acumulada ha aumentado a 1,52 billones de dólares.

Los crecientes costes de abordar el código inseguro y su deuda técnica se han convertido en el mayor obstáculo para realizar cambios en las bases de código existentes, dejándolas vulnerables a la explotación y a amenazas externas. El estado de la seguridad del software se enfrenta a una crisis existencial: sabemos que tenemos que mejorar nuestra postura de seguridad y abordar la deuda técnica acumulada, pero las barreras son enormes:

• Se estima que hay 300.000 puestos de trabajo sin cubrir relacionados con el desarrollo de software y la informática en EE. UU., con una tasa de crecimiento proyectada del 15%
• Se prevé que para 2025, el 40% de los presupuestos de TI se destinará simplemente a mantener la deuda técnica
• Un tercio de las horas semanales de los desarrolladores se dedica, de media, a abordar la deuda técnica

Las soluciones rápidas son arriesgadas y cuestan más a largo plazo

¿Qué es la deuda técnica y por qué es tan importante? La deuda técnica se acumula cuando los responsables de la toma de decisiones optan por una solución a corto plazo para un problema de desarrollo de software, en lugar de una solución más exhaustiva y a largo plazo. Esto conlleva un coste oculto sustancial que las organizaciones deben pagar más tarde. Al igual que una tarjeta de crédito al límite, la deuda técnica tiene dos componentes principales:

• Principal: se refiere al coste total de refactorizar o corregir el software para que alcance el nivel deseado de mantenibilidad y seguridad.
• Intereses: el esfuerzo adicional que los desarrolladores dedican a realizar esos cambios para abordar únicamente la deuda técnica, y no a nuevas funcionalidades. Cada minuto dedicado a código que no es del todo correcto añade intereses a la deuda.

Uno puede llegar finalmente a un estado de "quiebra técnica" cuando el coste de las nuevas funciones, las correcciones de errores y el mantenimiento supera el presupuesto del proyecto, hundiendo significativamente el valor de la aplicación de software.

Sin embargo, cierta acumulación de deuda, al igual que en la vida, es normal y, en la mayoría de los casos, algo esperada.

Idealmente, todos los desarrolladores de software deberían reducir los errores tanto como sea posible antes de publicar el código. Sin embargo, se enfrentan a un difícil compromiso: para ser competitiva, una organización puede querer entregar funciones o productos a los clientes rápidamente y al mínimo coste. Como resultado, la calidad de la aplicación se resiente porque los KPI de los desarrolladores se basan en la velocidad de entrega y el coste inicial de construcción. Lo que falta en el panorama son las deficiencias acumuladas y las posibles vulnerabilidades integradas en el código. Esto lo deja expuesto a errores o vulnerabilidades de seguridad en el futuro o, peor aún, a la explotación por parte de actores malintencionados.

Pero ahí reside el dilema: ¿existe una forma diferente de lanzar productos rápidamente sin acumular una enorme cantidad de deuda técnica?

El coste de encontrar y corregir deficiencias y vulnerabilidades es el mayor gasto individual en el ciclo de vida del desarrollo de software. Cuanto antes se detecten los problemas en el ciclo de vida de desarrollo, más rentable será la entrega general.

La deuda técnica puede convertirse en deuda de seguridad

Muchos desarrolladores intentan eludir este compromiso utilizando código abierto para avanzar rápidamente y, idealmente, usar una solución ya verificada. Sin embargo, depender en gran medida del software de código abierto a menudo presenta sus propios riesgos:

• Se descubrió que el 82% de los componentes de código abierto estaban obsoletos (es decir, sin parches o sin un buen soporte)
• El 75% de las bases de código contenían vulnerabilidades (frente al 60% en 2018), y el 49% contenía vulnerabilidades de alto riesgo
• Se identificó una media de 82 vulnerabilidades por base de código

Esto propicia un subconjunto de deuda técnica: la deuda de seguridad. La deuda de seguridad es la acumulación de vulnerabilidades en una aplicación de software que dificulta o incluso imposibilita la protección de datos y sistemas frente a ataques.

Uno de los ejemplos más notorios es Equifax, el gigante de informes crediticios que sufrió una brecha en 2017 por no haber aplicado un parche a una vulnerabilidad conocida en Apache Struts, un popular marco de trabajo de aplicaciones web de código abierto. El parche estaba disponible desde hacía meses, pero la brecha comprometió los datos personales cruciales de más de 147 millones de personas.

Por lo tanto, debe prestarse mayor atención a las prácticas de codificación segura, ya que muchas aplicaciones han alcanzado una masa crítica no solo en su deuda técnica, sino también en la densidad de debilidades y vulnerabilidades de seguridad en la propia aplicación.

Esto puede derivar en enormes pérdidas, que pueden ser tangibles o intangibles:

Daño reputacional: La pérdida de confianza del cliente puede tener un impacto extremadamente negativo a largo plazo. Esto puede incluir daños a la marca, pérdida de ventas y costosos problemas legales como resultado de una brecha.

Impacto normativo y de cumplimiento: Si una brecha de seguridad provoca que una empresa incumpla un plazo o sus obligaciones contractuales. El incumplimiento de un SLA puede meter a una empresa en problemas con los reguladores, lo que resulta en multas significativas.

Costes de remediación: A menudo se requiere trabajo adicional tras un fallo o interrupción para compensar la pérdida de productividad.

Prevención de la deuda técnica y de seguridad en el SDLC

Muchas organizaciones ya están redirigiendo su presupuesto para crear una postura de seguridad más sólida. El año pasado, Google se comprometió a invertir 10.000 millones de dólares en 5 años para financiar un programa destinado a fortalecer la ciberseguridad. La administración Biden también solicitó 2.100 millones de dólares en el presupuesto discrecional de 2022 para la Agencia de Ciberseguridad y Seguridad de Infraestructuras (CISA).

Proporcionar más recursos y formación para ayudar a impulsar el crecimiento profesional y el conocimiento de sus desarrolladores puede ser el primer paso para establecer estándares de calidad para todo el código que se envía a producción.

Los costes de encontrar y corregir una vulnerabilidad o defecto crecen exponencialmente cuanto más tarde se detecte y aborde en el ciclo de desarrollo de software. Y como hemos visto, al dedicar tanto tiempo a abordar la deuda técnica y de seguridad, las organizaciones generan sus propias pérdidas al renunciar a la innovación y al tiempo dedicado a nuevas funciones o productos.

En 2022, la mayoría de los equipos de desarrollo afirmaron que DevOps o DevSecOps era su metodología preferida, y no es de extrañar. DevSecOps integra la seguridad en cada etapa del ciclo de vida de desarrollo de software para ofrecer aplicaciones mejores y más seguras. Los equipos de seguridad y desarrollo siguen trabajando en silos y tienen tensiones, pero está claro que esto debe cambiar para ayudar a las empresas a tener éxito. DevOps es parte de cómo las organizaciones intentan derribar barreras y remodelar la cultura. El objetivo fundamental de DevSecOps es aumentar la colaboración entre AppSec/Seguridad y los desarrolladores desde el principio del ciclo de vida de desarrollo de software.

Implementar una nueva forma de pensar sobre cómo abordar la deuda técnica y la seguridad no tiene por qué ser una hazaña monumental. Establecer una mentalidad proactiva a través de la formación es fundamental al intentar mejorar la concienciación y las habilidades de seguridad de la comunidad de desarrolladores de una organización. Una educación sólida en codificación segura para desarrolladores que garantice un aprendizaje continuo, interactivo, relevante y contextual es una necesidad. Un enfoque verdaderamente holístico debe considerar lo que se necesita para fomentar una cultura de seguridad genuinamente liderada por los desarrolladores. Puede requerir cambiar el enfoque de las formas típicas de gestionar y crear equipos de desarrollo.

Crear un cambio cultural no es fácil, pero Secure Code Warrior le ayuda a identificar a sus campeones de seguridad y a dotar a los desarrolladores y organizaciones de las habilidades adecuadas para afrontar los desafíos de seguridad, en constante cambio, de hoy en día.

Lanzar un programa de código seguro, atractivo y escalable, es una inversión valiosa debido al enfoque preventivo a largo plazo de la seguridad, en lugar del enfoque reactivo del pasado. Esto ayuda en última instancia a mitigar los costosos riesgos de una brecha, educar a los desarrolladores sobre cómo encontrar y corregir vulnerabilidades rápidamente, y facilitar una forma más ágil de centrarse en el desarrollo de productos y acelerar el tiempo de comercialización.