Definir un código seguro

Los desarrolladores que crean el software, las aplicaciones y los programas que impulsan los negocios digitales se han convertido en el alma de muchas organizaciones. La mayoría de las empresas modernas no podrían funcionar (de forma rentable), sin aplicaciones y programas competitivos, o sin acceso las 24 horas del día a sus sitios web y otras infraestructuras.

Sin embargo, estos mismos puntos de contacto suelen ser la puerta de entrada que los hackers y otros usuarios malintencionados emplean para robar información, lanzar ataques y dar paso a otras actividades delictivas como el fraude y el ransomware. El último informe de Verizon sobre investigaciones de fugas de datos destaca que las amenazas que se ciernen sobre las empresas y organizaciones son hoy más peligrosas y costosas que en cualquier otro momento de la historia.

Los ataques exitosos siguen siendo frecuentes, a pesar de que el gasto en ciberseguridad en la mayoría de las organizaciones ha aumentado, y a pesar de que movimientos como DevSecOps están desplazando la seguridad hacia los desarrolladores que son el alma de las empresas hoy en día.

Los desarrolladores comprenden la importancia de la seguridad y desean mayoritariamente desplegar un código seguro y de calidad, pero las vulnerabilidades del software siguen siendo explotadas.

¿Por qué?

Por segundo año, Secure Code Warrior realizó la encuesta The state of developer-driven security, 2022 en colaboración con Evans Data Corp en diciembre de 2021. Encuestamos a 1200 desarrolladores de todo el mundo para conocer las habilidades, percepciones y comportamientos en lo que respecta a las prácticas de codificación segura, así como su impacto y relevancia percibida en el ciclo de vida del desarrollo de software (SDLC).

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

No es de extrañar que la escritura de código de calidad sea una de las principales prioridades de la comunidad de desarrolladores, pero cuando se les preguntó específicamente por el código seguro, sólo 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 fiables a la creación de código seguro. Por ejemplo, el escrutinio del código existente (37%) y la confianza en bibliotecas de origen externo para obtener código seguro (37%) fueron las principales prácticas que los desarrolladores asociaron con la codificación segura. Reutilizar el código que ya se ha considerado seguro (32%) fue otra de las opciones más populares. La práctica activa de escribir código libre de vulnerabilidades ocupó el sexto lugar, con un 29% que declaró que era una práctica principal en la creación de código seguro. Cuando se les preguntó más a fondo, la falta de tiempo y la falta de un enfoque cohesivo por parte de la dirección se declararon como los principales obstáculos para crear código seguro.

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

Resulta que hay una gran discrepancia entre lo que los desarrolladores piensan que es un código seguro, y lo que es realmente un código 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á formada por personas profesionales que se preocupan por lo que hacen. Escribir un código de máxima calidad era abrumadoramente importante para ellos como grupo. El problema es que, en muchos casos, las organizaciones para las que trabajan no han identificado las mejores prácticas necesarias para producir código seguro, y no han dedicado suficientes recursos a la formación o han capacitado a sus desarrolladores para 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 es que el 28% de los encuestados afirmó que su organización consideraba que el código era seguro si no se denunciaba ninguna infracción una vez que la aplicación o el programa se desplegaba 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 actual de las amenazas, limitarse a esperar buenos resultados sin trabajar realmente para conseguirlos probablemente producirá resultados predecibles: aún más violaciones de la seguridad.

Afortunadamente, se trata de una situación en la que es relativamente fácil, al menos, empezar a solucionar el problema y comenzar a trabajar para conseguir el objetivo de un código seguro. El primer paso, y posiblemente el más importante, es que las organizaciones definan lo que consideran código seguro. Y todo lo que esté fuera de esa definición debe ser considerado como no seguro.

La codificación segura debería definirse como la práctica de los desarrolladores cualificados de escribir código libre de vulnerabilidades, desde el inicio del SDLC. Solo una vez definida esta práctica, la comunidad de desarrolladores puede trabajar en pos de ese objetivo.

Hacer realidad el objetivo de un código seguro

Una vez establecida la definición de código seguro, las organizaciones deben estar preparadas para apoyar esos esfuerzos y a sus desarrolladores que llevarán a cabo el objetivo de implementar prácticas de código totalmente seguro. 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 código seguro deben ser respaldadas por la dirección y recibir la consideración, la autoridad y el presupuesto adecuados para que tengan éxito.

Esto puede requerir nuevos objetivos de evaluación comparativa para los desarrolladores, que tradicionalmente se han medido por la velocidad de su codificación. De hecho, el 37% de los desarrolladores que participaron en la encuesta declararon haber dejado vulnerabilidades conocidas dentro de su código porque los plazos ajustados no les permitían disponer del tiempo necesario para solucionarlas, o para 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 ese gasto de tiempo al principio del proceso de codificación probablemente se recuperará más tarde debido a la menor necesidad de revisiones del programa, parches y trabajo posterior a la implantación. Y eliminar la posibilidad de una brecha una vez desplegada puede acabar ahorrando cientos de horas y la posibilidad de millones en pérdidas de ingresos, multas y costes de limpieza.

Los desarrolladores también necesitarán una formación pertinente y práctica, especialmente en lo que respecta a las vulnerabilidades específicas con las que probablemente se encuentren, y ayuda para aprender a identificar y corregir las vulnerabilidades del 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.

El 37% de los desarrolladores que participaron en la encuesta declararon haber dejado vulnerabilidades conocidas dentro de su código porque los plazos ajustados no les permitían disponer del tiempo necesario para solucionarlas, o para codificar correctamente desde el principio.

¿Le interesa saber más sobre este tema?

Libro blanco: Los retos (y las oportunidades) para mejorar la seguridad del software.
Informe: Encuesta sobre el estado de la seguridad impulsada por los desarrolladores, 2022.