Definición de 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 manera rentable) sin aplicaciones y programas competitivos, o sin acceso las 24 horas a sus sitios web y otra infraestructura.

Sin embargo, estos mismos puntos de contacto suelen ser también la puerta de entrada que los hackers y otros usuarios malintencionados utilizan para robar información, lanzar ataques y dar el salto a otras actividades delictivas, como el fraude y el ransomware. El último Informe de Investigaciones de Filtración de Datos de Verizon destaca que las amenazas contra 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 considerablemente y de que movimientos como DevSecOps están trasladando la seguridad hacia esos desarrolladores que hoy son el alma de los negocios.

Los desarrolladores comprenden la importancia de la seguridad y, en su gran mayoría, desean implementar código seguro y de calidad, pero las vulnerabilidades de software siguen siendo explotadas.

¿Por qué?

Por segundo año consecutivo, Secure Code Warrior realizó la encuesta "El estado de la seguridad impulsada por el desarrollador, 2022" en asociación con Evans Data Corp en diciembre de 2021. Encuestamos a 1200 desarrolladores a nivel mundial para comprender sus habilidades, percepciones y comportamientos en cuanto a las prácticas de codificación segura, así como 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 de un entendimiento sobre lo que constituye un código seguro. Resulta que existe una gran discrepancia entre lo que los desarrolladores consideran código seguro y lo que realmente es.

No fue una sorpresa que escribir código de calidad fuera una prioridad máxima para la comunidad de desarrollo. Pero cuando se les preguntó específicamente sobre el código seguro, solo el 29 % dijo que la práctica activa de escribir código libre de vulnerabilidades era una prioridad. En cambio, los desarrolladores asociaron prácticas menos seguras y mucho menos fiables con la creación de código seguro. Por ejemplo, examinar el código existente (37 %) y confiar en bibliotecas de terceros para obtener código seguro (37 %) fueron las principales prácticas que los desarrolladores asociaron con la codificación segura. Reutilizar código que ya se consideraba 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 % afirmando que esta era una práctica principal en la creación de código seguro. Al profundizar en las preguntas, la falta de tiempo y la ausencia de un enfoque coherente por parte de la dirección se señalaron como las principales barreras para crear código seguro.

La dependencia del código existente es uno de los factores que aumenta el riesgo de que el software se distribuya con vulnerabilidades explotables. Abordar esta desconexión sobre lo que constituye un código seguro es necesario para que los desarrolladores creen código de calidad que, además, sea seguro.

Resulta que existe una gran discrepancia entre lo que los desarrolladores consideran código seguro y lo que realmente es.

¿Qué pueden hacer las organizaciones para solucionar esta situación?

Uno de los mensajes principales de la encuesta fue que la comunidad de desarrolladores en su conjunto está formada por profesionales a quienes les importa su trabajo. Escribir código de la más 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 las mejores prácticas necesarias para producir código seguro y no han invertido suficientes recursos en formación ni 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 fue que el 28 % de los encuestados dijo que su organización consideraba que el código era seguro si no se reportaba ninguna brecha una vez que la aplicación o el programa se implementaba en un entorno de producción o se ponía a disposición del público.

Probablemente no haga falta decirlo, pero en el complejo panorama de amenazas actual, simplemente esperar buenos resultados sin trabajar realmente para conseguirlos probablemente producirá resultados predecibles: aún más brechas de seguridad.

Afortunadamente, esta es una situación en la que es relativamente fácil, al menos, empezar 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 qué consideran código seguro. Y todo lo que quede fuera de esa definición debe considerarse como no seguro.

La codificación segura debe definirse como la práctica de desarrolladores capacitados 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 para alcanzar ese objetivo.

Hacer realidad el objetivo de un código seguro

Una vez definida la seguridad del código, las organizaciones deben estar preparadas para respaldar estos esfuerzos y a los desarrolladores encargados de implementar prácticas de seguridad integral. Este apoyo es fundamental; sin él, la definición de código seguro será poco más que una declaración de intenciones sin efecto real. Para que tengan éxito, las prácticas de programación segura deben contar con el respaldo de la dirección, además de la consideración, autoridad y presupuesto adecuados.

Esto puede requerir nuevos objetivos de evaluación para los desarrolladores, a quienes tradicionalmente se ha medido por la velocidad de su trabajo. De hecho, el 37% de los encuestados admitió dejar vulnerabilidades conocidas en su código debido a plazos ajustados que impedían corregirlas o programar correctamente desde el inicio. Al principio, esto podría significar ampliar los plazos, aunque esa inversión inicial de tiempo se compensará al reducir la necesidad de revisiones, parches y trabajo posterior al despliegue. Eliminar la posibilidad de una brecha tras el lanzamiento puede ahorrar cientos de horas y millones en ingresos perdidos, multas y costes de reparación.

Los desarrolladores también necesitarán formación práctica y relevante, especialmente sobre las vulnerabilidades que suelen encontrar, así como ayuda para aprender a identificarlas y corregirlas. Esto es crucial, dado que el 36% de los encuestados afirmó querer eliminar las vulnerabilidades de su código, pero carecer de las habilidades o conocimientos necesarios para hacerlo.

El 37% de los desarrolladores encuestados admitió dejar vulnerabilidades conocidas en su código porque los plazos ajustados no les permitían corregirlas o programar correctamente desde el principio.

¿Le interesa saber más sobre este tema?

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