Los desarrolladores que crean el software, las aplicaciones y los programas que impulsan el negocio digital se han convertido en el alma de muchas organizaciones. La mayoría de las empresas modernas no podrían funcionar (rentablemente) sin aplicaciones y programas competitivos, o sin acceso las 24 horas a sus sitios web y otra infraestructura.

Y, sin embargo, estos mismos puntos de contacto también suelen ser la puerta de entrada que emplean los delincuentes informáticos para robar información, lanzar ataques y ser un trampolín para otras actividades delictivas, como el fraude y el ransomware.

Los ataques exitosos siguen siendo frecuentes, a pesar de que el gasto en seguridad en la mayoría de las organizaciones está aumentando, y aunque movimientos como DevSecOps están cambiando la seguridad hacia aquellos desarrolladores que son el alma de los negocios en la actualidad. Los desarrolladores comprenden la importancia de la seguridad y, en su gran mayoría, desean implementar un código seguro y de calidad, pero las vulnerabilidades del software continúan siendo explotadas.

¿Por qué?

Secure Code Warrior realizó una encuesta sobre el estado de la seguridad impulsada por los desarrolladores [PDF] y encuestó a 1.200 desarrolladores en todo el mundo para comprender las habilidades, percepciones y comportamientos en lo que respecta a las prácticas de codificación segura. y su impacto y relevancia percibida en el Ciclo de Vida de Desarrollo de Software (SDLC).

La encuesta identificó la ausencia de una definición clara o una comprensión de lo que constituye un código seguro. Resulta que existe una gran discrepancia entre lo que los desarrolladores creen que es un código seguro y lo que realmente es un código seguro.

No fue sorprendente que escribir código de calidad fuera una prioridad principal para la comunidad de desarrollo. Pero cuando se les preguntó específicamente sobre el código seguro, solo el 29% dijo que se priorizaba la práctica activa de escribir código libre de vulnerabilidades.

En cambio, los desarrolladores asociaron prácticas menos seguras y mucho menos confiables con la creación de código seguro. Por ejemplo, examinar el código existente (37%) y confiar en bibliotecas de fuentes externas para obtener un código seguro (37%) fueron las principales prácticas que los desarrolladores asociaron con la codificación segura.

La reutilización de código que ya se había considerado seguro (32%) fue otra opción popular. La práctica activa de escribir código libre de vulnerabilidades ocupó el sexto lugar con un 29% que afirmó que esta era una de las principales prácticas en la creación de código seguro.

La falta de tiempo y la falta de un enfoque cohesivo por parte de la gerencia se señalaron como las principales barreras para crear un código seguro.

La confianza en el código existente es uno de los factores que aumenta el riesgo de que el software se envíe con vulnerabilidades explotables. Abordar esta desconexión de lo que constituye un código seguro es necesario para que los desarrolladores creen un código de calidad que también sea seguro.

¿Qué pueden hacer las organizaciones para arreglar la situación?

Uno de los mensajes predominantes de la encuesta fue que la comunidad de desarrolladores en su conjunto está llena de profesionales que se preocupan por lo que hacen. Escribir código de alta calidad era abrumadoramente importante para ellos como grupo. El problema es que, en muchos casos, las organizaciones para las que trabajan no han identificado qué mejores prácticas se requieren para producir código seguro y no han destinado suficientes recursos a la capacitación ni han permitido a sus desarrolladores alcanzar esos objetivos.

De hecho, la mayoría de los desarrolladores afirmaron que sus organizaciones ni siquiera tenían una definición clara de lo que constituye un código seguro. Uno de los ejemplos más preocupantes de esto fue que el 28% de los encuestados dijeron que su organización consideraba que el código era seguro si no se informaba de una infracción una vez que una aplicación o programa se implementaba en un entorno de producción o se ponía a disposición del público.

Probablemente no hace falta decirlo, pero en el complejo panorama de amenazas actual, el simple hecho de esperar buenos resultados sin trabajar realmente para lograrlos probablemente producirá resultados predecibles: incluso más violaciones de seguridad.

Afortunadamente, esta es una situación en la que es relativamente fácil al menos comenzar a solucionar el problema y luego comenzar a trabajar hacia el objetivo de un código seguro. El primer paso, y posiblemente el más importante, es que las organizaciones definan lo que consideran un código seguro. Y todo lo que está fuera de esa definición debe considerarse no seguro.

La codificación segura debe definirse como la práctica de desarrolladores expertos que escriben código libre de vulnerabilidades, desde el inicio del SDLC. Solo una vez que se define esta práctica, la comunidad de desarrolladores puede trabajar hacia ese objetivo.

Hacer realidad el objetivo del código seguro

Una vez que se establece la definición de código seguro, las organizaciones deben estar listas para respaldar esos esfuerzos y a sus desarrolladores, quienes llevarán a cabo el objetivo de implementar prácticas de código seguro total. Ese apoyo es fundamental. Sin él, la definición de código seguro dentro de su organización, aunque importante, será poco más que un tigre de papel. Las prácticas de codificación segura deben ser respaldadas por la gerencia y recibir la debida consideración, autoridad y presupuesto para tener éxito.

Esto puede requerir nuevos objetivos de evaluación comparativa para los desarrolladores, que tradicionalmente han sido medidos por la velocidad de su codificación. De hecho, el 37% de los desarrolladores en la encuesta informaron que dejaron vulnerabilidades conocidas dentro de su código porque los plazos ajustados no permitían el tiempo necesario para corregirlos o codificar correctamente desde el principio.

Al principio, esto puede significar aumentar los plazos para dar a los desarrolladores más tiempo para codificar correctamente, aunque es probable que ese gasto de tiempo al comienzo del proceso de codificación se compense más tarde debido a la menor necesidad de revisiones del programa, parches y posteriores a la implementación. trabaja. Y eliminar la posibilidad de una brecha que se implemente puede terminar ahorrando cientos de horas y posiblemente millones en pérdida de ingresos, multas y costos de limpieza.

Los desarrolladores también requerirán capacitación práctica relevante, especialmente en lo que se refiere a vulnerabilidades específicas que es probable que encuentren, y ayuda para aprender a identificar y corregir vulnerabilidades de código. Esto es especialmente cierto a la luz del 36% de los encuestados que dijeron que querían eliminar las vulnerabilidades de su código, pero no tenían las habilidades o el conocimiento para hacerlo.

¿Quiere leer más información obtenida de la encuesta de Secure Code Warriors a 1200 desarrolladores de todo el mundo? Puede acceder a ellos aquí: State of Developer Driven Security 2022

Fuente: THN