3 consejos para capacitar eficazmente a los desarrolladores en seguridad

«Esta es la era dorada de la seguridad de las aplicaciones», afirma Jim Manico, fundador de Manicode Security y capacitador en programación segura, en el episodio 26 de The Secure Developer podcast.

Hace diez años, dice Manico, la capacitación en seguridad era «algo peculiar que hacer, algo que se hacía de vez en cuando». Ahora, las herramientas de evaluación son maduras, la buena literatura sobre evaluación facilita el acceso al conocimiento y muchas personas talentosas están creando aplicaciones seguras.

Vivir en la era dorada no significa que el problema de la seguridad esté resuelto; significa que sabemos qué hay que aprender y contamos con los recursos y la voluntad para impartir esa formación.

En este artículo, analizaremos tres consejos para mejorar tu programa de educación en seguridad para desarrolladores y aprovechar al máximo la era dorada de la seguridad de las aplicaciones.

1. Facilita el aprendizaje con requisitos de seguridad claros

La educación en seguridad para desarrolladores es imposible sin una comprensión clara y compartida de lo que es la seguridad de las aplicaciones.

Por eso, según Manico, establecer requisitos de seguridad claros es una de las medidas más importantes que pueden tomar las empresas para capacitar a sus desarrolladores. «Quiero una definición clara de los requisitos de seguridad», dice Manico, «para que todos entendamos lo mismo cuando hablamos de seguridad de las aplicaciones».

Aunque muchos recurrirían instintivamente al OWASP Top 10, Manico recomienda evitarlo. En su lugar, recomienda el estándar de verificación de seguridad de aplicaciones de OWASP, que incluye más de 200 requisitos. Lo mejor de usar este estándar, dice Manico, es que resulta útil sin importar qué tan bien lo implemente el equipo.

«A grandes rasgos», dice Manico, «tenemos los requisitos establecidos y hemos traducido cada uno de ellos para identificar dónde está contemplado en el framework, dónde debemos implementarlo manualmente y dónde contamos con herramientas de terceros que nos ayudan».

Pero incluso si los equipos no llegan a ese nivel de profundidad, aún pueden obtener beneficios. «He visto a personas establecer requisitos, nunca leerlos y, aun así, encontrar útil el proceso, porque los líderes técnicos pudieron influir en los desarrolladores líderes durante cuatro o cinco horas, simplemente hablando sobre lo que es importante para la seguridad», dice Manico.

Por lo tanto, trabajar con los requisitos de seguridad permite llegar a un consenso útil sobre lo que los desarrolladores y los equipos de seguridad deben hacer para alcanzar cierto nivel de seguridad de las aplicaciones. Aunque los equipos no lleguen tan lejos como podrían, llegar a un consenso puede ser de gran ayuda.

«Sin importar cómo los implementes, serán útiles de alguna manera», dice Manico.

2. Ayuda a los equipos de desarrollo a valerse por sí mismos con un security champion

En cada graduación de secundaria y universidad hay lágrimas, a pesar de que graduarse es el objetivo. Al final, aunque sea emotivo, todos los educadores quieren que sus estudiantes sean independientes, autónomos y exitosos.

Lo mismo ocurre con la educación en seguridad para desarrolladores. Las empresas hacen bien en contratar consultores y educadores externos de seguridad, pero deberían elegir a quienes piensan de forma proactiva en cómo funcionarán los equipos cuando el educador ya no esté.

Nick Vinson, líder de DevSecOps en Pearson, hace precisamente eso. Según Vinson, en el episodio 84 de The Secure Developer podcast, el objetivo principal de su trabajo es «darle al equipo las herramientas y los conocimientos que necesita para valerse por sí mismo».

Para lograrlo, el equipo de Vinson integra ingenieros expertos en seguridad en los equipos con los que trabaja. Los ingenieros integrados participan plenamente en el equipo y pueden realizar, probar e implementar cambios en producción.

Mientras forman parte del equipo, estos expertos realizan modelado de amenazas para identificar riesgos y vulnerabilidades de seguridad. También implementan capacidades automatizadas de pruebas de seguridad en el SDLC y, al mismo tiempo, se aseguran, como dice Vinson, de que «los equipos sepan qué hacer en lugar de limitarse a marcar casillas».

Para que esos nuevos conocimientos perduren, el experto integrado capacita a un security champion interno, además de aportar trabajo y asesoramiento. «Esa es nuestra principal responsabilidad», dice Vinson.

Al integrar a un ingeniero de seguridad, Vinson logra dos objetivos a la vez: fortalecer más rápidamente la seguridad de las aplicaciones y capacitar a un security champion que ayude a mantener esas prácticas de programación segura.

3. Gánate la credibilidad de los desarrolladores para generar confianza

A menudo, la gente es escéptica respecto al potencial de educar a los desarrolladores sobre seguridad. ¿Acaso los desarrolladores no tratarán la seguridad como un requisito que hay que marcar, una distracción de su trabajo principal?

Jet Anderson, ingeniero de seguridad en Amazon, responde sin rodeos en el episodio 98 de The Secure Developer podcast: «Eso es una tontería; no creo que sea cierto en absoluto».

En contra de esas suposiciones, Anderson encuentra en los desarrolladores una verdadera pasión por la seguridad. «Veo que a los desarrolladores les importa mucho la calidad y quieren hacer lo correcto», dice Anderson. Y la seguridad es una parte fundamental de hacer lo correcto.

Según Anderson, la brecha entre los desarrolladores y los ingenieros de seguridad no se debe a la apatía de los desarrolladores, sino a la falta de entendimiento mutuo.

«No es que a los desarrolladores no les importe», dice Anderson. «Es que quienes trabajan en seguridad de la información no necesariamente tienen un conocimiento profundo del desarrollo de software, así que quizá les falte credibilidad o incluso el lenguaje para explicar con precisión el riesgo o la falla».

Como ejemplo, Anderson usa el término «vulnerabilidad». Entre quienes trabajan en seguridad de la información, es un término común que se usa en distintos contextos, pero quizá los desarrolladores entiendan mejor otros términos. Anderson dice que lo que suelen encontrar los profesionales de seguridad se describe mejor como defectos, y que un defecto solo debería describirse como vulnerabilidad si se encuentra una forma de explotarlo.

«Ese pequeño detalle forma parte del cambio cultural», dice Anderson. Aunque parezcan cambios menores, las modificaciones del lenguaje, repetidas en muchos contextos distintos, pueden generar muchas más oportunidades para que los ingenieros de seguridad y los desarrolladores se entiendan. Una vez que existe un entendimiento compartido, la educación de los desarrolladores puede tener mucho más éxito.

Desplazar la seguridad a la izquierda, hasta llegar a la mente de los desarrolladores

Desplazar la seguridad a la izquierda se refiere a tomar las tareas de seguridad, que tradicionalmente se realizan al final del SDLC, y adelantarlas, hacia el comienzo del SDLC. Pero, según Anderson, se puede ir aún más a la izquierda, más allá de la primera etapa del SDLC. «No se me ocurre nada anterior en el SLDC que la mente de un desarrollador», dice Anderson.

Las organizaciones que quieren desplazar la seguridad a la izquierda e integrarla en el diseño fundamental de las aplicaciones deben tener presentes tanto lo que está en juego como el punto de partida. Muchos desarrolladores pueden graduarse de la universidad u obtener una certificación sin aprender nada sobre seguridad. Si quieres desplazar la seguridad a la izquierda, la educación en seguridad para desarrolladores es esencial.

Suscríbete hoy al podcast The Secure Developer para recibir más consejos de expertos en seguridad.