El ciclo de vida del desarrollo de software (SDLC) parece bastante inocuo; es un proceso, y todos los que trabajamos en el ámbito del software nos unimos para hacer realidad la magia y enviar todos esos productos digitales sin los que la sociedad no puede vivir.

Excepto que... si alguna vez has formado parte de un proyecto de desarrollo de software, sabrás que suele ser un guante, con muchas misiones que conquistar y dragones que matar. Es divertido durante un tiempo, pero el agotamiento es real, y la demanda de software nos hace trabajar a la velocidad de la luz en el mejor de los casos, especialmente al equipo de desarrollo.

Ahora imagina que se les lanza otra tarea imprescindible... la responsabilidad de la seguridad en los elementos del proyecto que tocan. Esto, en el peor de los casos, puede hacer que el castillo de naipes se derrumbe para algunos individuos, pero el escenario más realista es que simplemente no se haga una prioridad, y los asuntos considerados más urgentes para superar la línea tengan prioridad. Y cuando la mayoría de los desarrolladores no están capacitados para codificar de forma segura (especialmente si sus gerentes tampoco dan prioridad a la seguridad), no es de extrañar que veamos frecuentes violaciones de datos, lanzamientos de aplicaciones defectuosas, y una seria rotación entre los profesionales de la seguridad que llegan al punto de ruptura bajo una avalancha de código con errores.

Los desarrolladores necesitan un defensor de la seguridad de las aplicaciones.

Si se tiene en cuenta el escenario anterior, se puede entender por qué la seguridad se pone en la cesta de "demasiado difícil" durante el proceso de codificación, y se deja al equipo de seguridad para que lo solucione. Hay demasiados plazos que compiten entre sí, no hay suficiente formación y no hay ninguna razón real para preocuparse por la seguridad con todo lo demás. Sin embargo, hay demasiada demanda de código para que este statu quo continúe. Y ahí es donde los desarrolladores de superélite pueden destacar entre sus compañeros, aprender nuevas habilidades y, lo que es más importante, construir un código más seguro.

Sin embargo, es importante recordar que la gestión de la seguridad del software no recae exclusivamente en los desarrolladores, sino que sigue siendo competencia del equipo de seguridad de las aplicaciones (que, al trabajar con desarrolladores concienciados en materia de seguridad, tendrán más espacio para respirar en lugar de tener que arreglar los errores comunes una y otra vez). Un proceso DevSecOps que funcione requiere que todos los miembros del equipo tengan el apoyo y las herramientas que necesitan para compartir la responsabilidad de la seguridad, y el tipo correcto de formación es primordial. Equilibrar el conjunto adecuado de herramientas y formación requiere la perspicacia de los profesionales de AppSec dispuestos a trabajar estrechamente con los desarrolladores para inspirarlos e impulsar un cambio positivo.

La formación disruptiva es más molesta que efectiva, y cualquier cosa que repela a los desarrolladores no va a funcionar. Una solución integrada en el IDE o en el gestor de incidencias, centrada en el conocimiento en forma de bocado, es una alternativa que pone a su disposición la información adecuada en el momento en que la necesitan.

Así es como funciona en acción:

Justo a tiempo, no "por si acaso".

Elaprendizaje contextual y práctico es, con mucho, la forma más eficaz de formar, con trozos del tamaño de un bocado entregados justo cuando tienen más sentido. Esto se denomina a veces formación "Just in Time" (JiT), y es muy potente para los desarrolladores que aprenden a codificar de forma segura.

Con orígenes en los principios de fabricación ajustada de Toyota, la formación JiT está diseñada para activarse en función de las necesidades, en contexto, cuando más importa. ¿Un desarrollador acaba de escribir algo que parece tener permisos inadecuados? ¿Y si se ha abierto una pequeña puerta trasera que permite a un atacante ejecutar código de forma remota? Será mucho más memorable si los desarrolladores pueden acceder a los conocimientos cuando los necesiten, en lugar de tener que buscar en la documentación de Confluence o buscar en Google algo que se haya tratado en la formación.

El aprendizaje "justo a tiempo" es la antítesis del aprendizaje "por si acaso"; aunque este último es la forma más común de impartir conocimientos, simplemente no es eficiente. Debemos facilitar que los desarrolladores se comprometan con las mejores prácticas de codificación segura, y que vean el beneficio de actualizarse para su carrera mientras mantienen el enfoque en los objetivos clave en los que están trabajando en este momento.

Deja de hacer que los desarrolladores persigan la formación.

Ya sabemos que hay demasiadas cosas que hacer en un día de trabajo, así que ¿qué incentivo tienen los desarrolladores para desplazarse a un aula, o cambiar de contexto para pasar por cinco pasos para acceder a una formación estática basada en la teoría?

El consenso general es que todo lo que la mayoría de las organizaciones están haciendo no es terriblemente eficaz si la cantidad de vulnerabilidades que causan las violaciones de datos es algo a tener en cuenta. El informe sobre investigaciones de fugas de datos de 2020 de Verizon especificaba que el 43% de las fugas de datos podían atribuirse a vulnerabilidades de la web. Los desarrolladores no están recibiendo una formación eficaz, ni en la educación superior, ni como parte de las medidas de actualización en el lugar de trabajo. Si lo hicieran, las vulnerabilidades más comunes, como la inyección de SQL y el path traversal de la vieja escuela, no se explotarían para obtener datos importantes, y la escasez de habilidades de ciberseguridad no estaría fuera de control.

Entonces, sabiendo que este es el clima actual en el que los desarrolladores reciben formación y se familiarizan con la seguridad, ¿por qué nos sorprende el mal resultado? Podría tener un efecto, positivo, tanto para el desarrollador como para la organización, asegurar una experiencia de formación más fluida, más integrada y menos discordante, donde sea accesible en los espacios en los que realmente trabajan, como Jira, GitHub y en el IDE. La industria simplemente necesita avanzar y hacer que la concienciación sobre la seguridad sea mucho más fácil, en un entorno en el que ya no es un lujo.

¿Listo para asegurar el flujo de trabajo de desarrollo?

Los desarrolladores conscientes de la seguridad son venerados por sus habilidades y por la protección que pueden ofrecer a las organizaciones desde la fase de creación del código. La seguridad ya no es opcional, especialmente con las multas del GDPR, las normas de cumplimiento del PCI-DSS, la gobernanza del NIST... y la posibilidad de ser demandado en una gran acción colectiva multimillonaria, a la manera de Equifax.

Un enfoque integrado podría ser el catalizador para empezar a ganarse a los desarrolladores con un aprendizaje menos disruptivo, y crear algunas vías para profundizar en courses, formar a los campeones de la seguridad y, en general, inspirar esa responsabilidad compartida que necesitamos para mantener los datos del mundo seguros y sanos.

Descargue ahora las herramientas de integración para Jira y GitHub, y díganos lo que piensa.