¿Cómo definen los desarrolladores la "codificación segura"?

Una versión de este artículo apareció en TechRepublic. Ha sido actualizado y publicado aquí.

‍

Ha sido una batalla cuesta arriba, aunque esencial, crear un entorno donde los objetivos del equipo de seguridad y los de sus homólogos desarrolladores estén alineados. Nos queda un largo camino por recorrer, pero los obstáculos que impiden la sinergia necesaria para abrir la puerta a una responsabilidad compartida en la seguridad del software son cada vez más evidentes. Las empresas inteligentes quieren evolucionar su estrategia para evitar esos escollos, encontrar un camino productivo hacia adelante y aprovechar el potencial de DevSecOps impulsado por las personas.

Lo que no esperaba es que la percepción de lo que constituye la programación segura fuera un tema de debate. Según una investigación reciente realizada en colaboración con Evans Data, este sentimiento quedó patente. La encuesta State of Developer-Driven Security 2022 profundiza en las perspectivas y experiencias clave de 1200 desarrolladores activos, arrojando luz sobre sus actitudes y desafíos en el ámbito de la seguridad.

Uno de los hallazgos principales fue que solo el 14% de los desarrolladores considera la seguridad una prioridad al programar. Aunque esto demuestra que hay un enorme margen de mejora, confirma lo que ya sabíamos: la creación de funciones es lo primordial en el mundo del desarrollador, y siguen sin estar preparados para integrar la seguridad en su ADN. Sin embargo, cuando se combina con los datos sobre cómo definen los desarrolladores la programación segura, es motivo de preocupación.

Estas percepciones están impulsadas por la experiencia diaria de los desarrolladores y reflejan el entorno de muchas organizaciones, donde los desarrolladores simplemente no son el foco central en la lucha contra las vulnerabilidades comunes. Su capacitación es fundamental, pero mientras tanto, debemos ponernos de acuerdo rápidamente sobre el alcance de la "programación segura" y lo que debemos esperar de un desarrollador con competencias en seguridad.

Necesitamos desmitificar la seguridad en el mundo del desarrollador.

La ciberseguridad es una bestia compleja y difícil de manejar en el mejor de los casos, y aunque la programación segura representa solo una parte del panorama general, es un engranaje complejo en el sistema que requiere atención especializada.

La encuesta reveló que el concepto de trabajar con código seguro estaba bastante aislado para el desarrollador promedio, con un alcance a menudo limitado a una sola categoría en lugar de una visión holística de los fundamentos y más allá. Los desarrolladores indicaron una dependencia del uso de código existente (o preaprobado), en lugar de la práctica de escribir código nuevo libre de vulnerabilidades. Si bien la concienciación sobre la seguridad en componentes de terceros (especialmente en la aplicación de parches, y el desastre de Log4Shell es un gran ejemplo: el 30% de las instancias permanecen sin parches desde diciembre) es muy importante, al igual que probar el código existente, esto por sí solo no alcanza un nivel funcional de capacidad de programación segura.

Las vulnerabilidades a nivel de código son introducidas por desarrolladores que han aprendido patrones de programación deficientes, y la falta de énfasis en escribir código seguro en sus KPI (junto con una cultura de seguridad mediocre) solo refuerza esto como un estándar aceptable.

Los líderes de seguridad pueden avanzar mucho en la mejora de la concienciación inicial y en la identificación de las áreas con mayores lagunas de conocimiento, asegurándose primero de que el grupo de desarrollo vea el panorama completo de lo que implica la programación segura. Probar y escanear código preaprobado es una función, pero la reducción de vulnerabilidades requiere formación práctica en patrones de programación buenos y seguros, en los lenguajes y marcos que se utilizan activamente.

El contexto es vital en la capacitación de los desarrolladores, y deben ser integrados en el proceso cuando se trata de los objetivos de seguridad del negocio.

Muchas organizaciones necesitan actualizar sus programas de seguridad.

Con la explosión de la tecnología impulsada por software que ha dado paso al rápido crecimiento de los incidentes de ciberseguridad en la última década, todos estamos luchando por seguir el ritmo de los actores de amenazas que trabajan las 24 horas del día para descubrir vulnerabilidades en sistemas valiosos.

La metodología DevSecOps se basa en la idea de que todos comparten la responsabilidad de la seguridad, incluidos los desarrolladores, y es una consideración principal desde el principio del ciclo de vida de desarrollo de software (SDLC). El problema es que, especialmente en las grandes empresas, pueden estar muy lejos de implementar DevSecOps como estándar. En 2017, un estudio del Project Management Institute mostró que el 51% de las organizaciones todavía utilizaban Waterfall para su desarrollo de software. Ese estudio tiene ahora cinco años, pero sabiendo lo graduales que pueden ser los cambios en las grandes empresas, es poco probable que haya habido una transición brusca hacia las últimas metodologías orientadas a la seguridad. Estos procesos heredados pueden crear una batalla cuesta arriba para los profesionales de la seguridad que intentan cubrir todos los frentes con una estrategia integral para protegerse contra las ciberamenazas, y adaptar a los desarrolladores y sus necesidades a este panorama es un desafío.

Sin embargo, no podemos usar esto como excusa. Los profesionales de seguridad en la empresa pueden utilizar a los desarrolladores en una estrategia mejorada; solo necesitan familiarizarse con sus necesidades y considerarlos como parte de su plan defensivo. Necesitan una formación integral, y cualquier responsabilidad en materia de seguridad debe implementarse respetando su pila tecnológica y su flujo de trabajo.

¿Programación segura = el cajón de "demasiado difícil"?

La investigación de Evans Data reveló que un asombroso 86% de los desarrolladores considera difícil implementar una codificación segura, y el 92% de los gerentes de desarrollo admite que sus equipos necesitan más formación en marcos de seguridad. Es preocupante que el 48% de los encuestados reconozca que deja vulnerabilidades en su código a sabiendas.

Esto dibuja un panorama muy preocupante. Parece que, en general, los desarrolladores no reciben una formación frecuente y adecuada, ni tienen suficiente exposición a buenas prácticas e higiene de seguridad. Entre líneas, esto refuerza el núcleo del problema: la seguridad simplemente no es una prioridad para los desarrolladores en su trabajo. Además, la formación que reciben no refuerza su confianza ni sus habilidades prácticas, ni les ayuda a comprender el impacto de decidir publicar código vulnerable.

El ataque de ransomware a Colonial Pipeline fue uno de los incidentes de seguridad en la cadena de suministro más disruptivos del último año, provocando el temor de que la mitad del suministro de gas en la costa este de Estados Unidos se cortara por un tiempo indeterminado. Afortunadamente, se recuperaron rápido, pero no sin generar una gran inquietud. Fue uno de esos momentos críticos donde el público general enfrentó la posibilidad de que un ciberincidente afectara gravemente un elemento del mundo físico que no suele considerarse impulsado por software o vulnerable a ciberataques. Todo ese caos fue posible gracias a dos vulnerabilidades antiguas y sin parches, una de ellas la insidiosa y conocida inyección SQL. Si los desarrolladores supieran lo que realmente está en juego al publicar código vulnerable, verían que no existe escenario donde eso sea un riesgo empresarial aceptable.

La funcionalidad de "Personas, Procesos y Tecnología" no depende del desarrollador.

El famoso "triángulo de oro" de Personas, Procesos y Herramientas no se puede lograr sin una estrategia cuidadosamente considerada, y los desarrolladores no están en posición de integrarse a un proceso de seguridad funcional sin considerar sus necesidades y desafíos.

Se requerirá un cambio cultural considerable para potenciar la seguridad impulsada por los desarrolladores, y esto comienza con rutas educativas que brinden mayor claridad tanto a los ingenieros como al equipo de seguridad.