Una versión de este artículo apareció en TechRepublic. Se ha actualizado y sindicado aquí.

‍

La creación de un entorno en el que los objetivos del equipo de seguridad y sus homólogos de desarrollo estén alineados ha sido una batalla ardua, aunque esencial. Nos queda un largo camino por recorrer, pero los obstáculos que se interponen en el camino de la sinergia necesaria para abrir la puerta a la responsabilidad compartida de la seguridad del software son cada vez más claros. Las empresas inteligentes quieren evolucionar su estrategia para evitar esos escollos, encontrar un camino productivo hacia adelante y utilizar DevSecOps en todo su potencial.

Lo que no había previsto es que la percepción de lo que constituye el acto de codificación segura es objeto de debate. Según una nueva investigación realizada en colaboración con Evans Data, este sentimiento se puso en blanco y negro. La encuesta State of Developer-Driven Security 2022 profundiza en las ideas y experiencias clave de 1.200 desarrolladores activos, iluminando sus actitudes y desafíos en el ámbito de la seguridad.

Una de las conclusiones más destacadas fue que sólo el 14% de los desarrolladores consideran la seguridad una prioridad a la hora de codificar. Si bien esto demuestra que hay un enorme margen de mejora, confirma lo que ya sabíamos: la creación de características es el rey en el mundo de los desarrolladores, y siguen estando mal equipados para hacer de la seguridad parte de su ADN. Sin embargo, cuando se combina con los datos sobre las definiciones de los desarrolladores de lo que significa para ellos la codificación segura, es motivo de preocupación.

Estas percepciones son impulsadas por la experiencia de los desarrolladores en su día a día, y habla del entorno de muchas organizaciones, que es que los desarrolladores simplemente no son un punto focal en la lucha contra las vulnerabilidades comunes. Su habilitación es fundamental, pero mientras tanto, debemos ponernos rápidamente de acuerdo con el alcance de la "codificación segura", y lo que debemos esperar de un desarrollador con conocimientos de seguridad. 

Tenemos que desmitificar la seguridad en el mundo de los desarrolladores.

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

La encuesta reveló que el concepto de trabajar con código seguro estaba bastante aislado para el desarrollador medio, y que su alcance se limitaba a menudo a una sola categoría, en contraposición a una visión holística de los fundamentos y más allá. Los desarrolladores indicaron una dependencia en el uso de código existente (o pre-aprobado), en lugar de la práctica de escribir nuevo código que esté libre de vulnerabilidades. Mientras que la concienciación sobre la seguridad en relación con los componentes de terceros (especialmente la aplicación de parches, y la debacle de Log4Shell es un gran ejemplo: El 30% de las instancias siguen sin parchear desde diciembre) es muy importante, al igual que probar el código existente, éstos por sí solos no cumplen con un nivel funcional de capacidad de codificación segura. 

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

Los responsables de la seguridad pueden contribuir en gran medida a mejorar la concienciación inicial y a identificar las áreas con mayores lagunas de conocimiento, asegurándose en primer lugar de que se muestra a la cohorte de desarrollo la imagen completa de lo que implica la codificación segura. Probar y escanear el código preaprobado es una función, pero la reducción de las vulnerabilidades requiere una formación práctica en patrones de codificació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 es necesario que se les haga partícipes del viaje cuando se trata de los objetivos de seguridad de la empresa.

Muchas organizaciones necesitan actualizar sus programas de seguridad.

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

La metodología DevSecOps se basa en la idea de que todo el mundo comparte la responsabilidad de la seguridad, incluidos los desarrolladores, y es una consideración principal desde el principio del SDLC. El problema es que, especialmente en las grandes empresas, pueden estar muy lejos de implementar DevSecOps como un estándar. En 2017, un estudio del Project Management Institute mostraba que el 51% de las organizaciones seguían utilizando Waterfall para su desarrollo de software. Ese estudio tiene ahora cinco años, pero conociendo lo graduales que pueden ser los cambios en las grandes empresas, es poco probable que haya habido una transición brusca a las últimas metodologías orientadas a la seguridad. Estos procesos heredados pueden suponer una ardua batalla para los profesionales de la seguridad que intentan cubrir todas las bases con una estrategia integral de protección contra las ciberamenazas, y adaptar a los desarrolladores y sus necesidades a este panorama es todo un reto. 

Sin embargo, no podemos utilizar esto como excusa. Los profesionales de la seguridad en la empresa pueden utilizar a los desarrolladores en una estrategia mejorada; sólo tienen que familiarizarse con sus necesidades y considerarlos como parte de su juego defensivo. Necesitan una formación exhaustiva, y cualquier responsabilidad en materia de seguridad debe aplicarse con respecto a su pila tecnológica y su flujo de trabajo. 

Codificación segura = la cesta "demasiado difícil"?

La investigación de Evans Data sacó a la luz que un asombroso 86% de los desarrolladores encuentran difícil practicar la codificación segura, y el 92% de los directores de desarrollo también admitieron que sus equipos necesitaban más formación en marcos de seguridad. Lo más preocupante es que el 48% de los encuestados admite que deja a sabiendas vulnerabilidades en su código. 

Esto dibuja un panorama muy preocupante. Parece que, en general, los desarrolladores no reciben una formación frecuente y adecuada, ni están suficientemente expuestos a las buenas prácticas de seguridad e higiene. Al leer entre líneas, se refuerza el quid de la cuestión: simplemente no es una prioridad para los desarrolladores tener en cuenta la seguridad en su trabajo. Eso, y que la formación que reciben no fomenta su confianza ni sus habilidades prácticas, ni les ayuda a entender el impacto de su decisión de enviar código vulnerable. 

El ataque al ransomware de Colonial Pipeline fue uno de los incidentes de seguridad de la cadena de suministro más perturbadores del año pasado, y desató el temor de que la mitad del suministro de gas en la costa este de Estados Unidos quedara cortado durante un periodo indeterminado. Afortunadamente, volvieron a funcionar rápidamente, pero no sin una gran aprensión en la comunidad. Fue uno de esos momentos cruciales en los que el público en general se enfrentó a la posibilidad de que un incidente cibernético afectara gravemente a un elemento del mundo físico que no se considera necesariamente como impulsado por el software, o un riesgo para un ciberataque. Y todo ese caos fue posible gracias a dos antiguas vulnerabilidades sin parchear, una de las cuales era la insidiosa, aunque ampliamente conocida, inyección SQL. Si los desarrolladores supieran lo que realmente está en juego cuando deciden enviar código vulnerable, verían rápidamente que no hay ningún escenario en el que eso sea un riesgo comercial aceptable.

El "P-P-T" funcional no depende del promotor.

El famoso "triángulo de oro" formado por las personas, los procesos y las herramientas no es posible sin una estrategia cuidadosamente estudiada, y los desarrolladores no están en condiciones de asimilarse a un proceso de seguridad que funcione sin tener en cuenta sus necesidades y desafíos.

Se necesitará un cambio de cultura considerable para mejorar la seguridad impulsada por los desarrolladores, y esto comienza con vías educativas que lleven tanto a los ingenieros como al equipo de seguridad a una mayor claridad.