Mesa redonda de Snyk e Intuit: romper silos y conectar con las comunidades de seguridad y desarrollo

Hace poco participé en una mesa redonda de Snyk con Intuit. La sesión fue tan buena que quise escribir esta publicación para compartir algunas de las ideas y conclusiones más interesantes, empezando con esta excelente ilustración artística de la sesión. En resumen, estas son mis principales conclusiones:

• Presenta las tareas de seguridad a los desarrolladores como una forma de ayudarlos a hacer su trabajo, por ejemplo, evitando tener que rehacerlo.

• Procura que corregir el problema sea el camino que ofrezca menos resistencia para el desarrollador, con herramientas que quiera usar.

• No intentes convertir a todos los desarrolladores en expertos en seguridad; enfócate en quienes quieren aprender más.

• La participación en un programa de security champions debe ser voluntaria; las recompensas, el reconocimiento y los beneficios deben impulsar el crecimiento orgánico de la comunidad.

• Mide los logros, no la ausencia de infracciones.

• Comparte historias de éxito de equipos que hacen un buen trabajo para inspirar más logros.

¿De verdad les importa la seguridad a los desarrolladores?

La discusión comenzó con una afirmación contundente: a la mayoría de los desarrolladores no les importa mucho la seguridad. A menudo se percibe como más trabajo, sin el reconocimiento que podrían obtener, por ejemplo, al lanzar una funcionalidad. Por supuesto, esto no significa que los desarrolladores no quieran hacer lo correcto; la mayoría de las veces, sí quieren. Pero ¿cómo podemos hacer que la seguridad les resulte más atractiva?

Otro factor que agrava el problema y aleja a los desarrolladores de la seguridad es la terminología que se usa. Cuando se emplean términos poco conocidos, como SCA, SAST, DAST y RASP —que el desarrollador promedio probablemente nunca ha escuchado—, la vida de los desarrolladores puede volverse más difícil y confusa. Es importante explicar estas siglas de tres y cuatro letras que tienen sentido para el equipo de seguridad y hacer que sean más fáciles de entender para los desarrolladores.

Entonces, ¿cómo podemos hacer que la seguridad les resulte atractiva a los desarrolladores?

Estas fueron algunas sugerencias para mejorar la seguridad de los desarrolladores:

• Preséntala de una forma que ayude a los desarrolladores, por ejemplo, evitando que tengan que rehacer su trabajo.

• Procura que corregir el problema sea el camino que ofrezca menos resistencia.

• Elige herramientas que los desarrolladores quieran usar.

Evita rehacer el trabajo

Una sugerencia que tuvo buena recepción entre quienes estaban en la mesa fue presentar la seguridad de una forma que conecte con los desarrolladores. A ningún desarrollador le gusta tener que rehacer su trabajo. Si la seguridad ayuda a prevenir que esto ocurra, dejamos de hablar de seguridad y empezamos a hablar de realizar ciertas actividades con anticipación para evitar tener que dedicar mucho tiempo después a corregir esos problemas de seguridad.

Haz que la seguridad sea el camino que ofrezca menos resistencia

Por supuesto, es muy importante prevenir los problemas de seguridad. No solo es costoso resolverlos, sino que también dejan una marca negativa en un proyecto que los desarrolladores no quieren ver. Para evitar esta reacción, es fundamental ofrecer políticas claras y visibilidad dentro de un ciclo natural de retroalimentación sobre seguridad, que facilite a los desarrolladores evitar errores. Ofréceles un camino que ofrezca menos resistencia y los anime a corregir los problemas, en lugar de evitarlos.

Herramientas pensadas primero para los desarrolladores

Por supuesto, las herramientas también influyen en cómo los desarrolladores encuentran y corrigen los problemas de seguridad. Vlad Nikolov, de Intuit, planteó un punto importante: cómo anima a los desarrolladores a elegir sus propias herramientas de seguridad. Las personas quieren sentir que contribuyen y que son dueñas de lo que hacen. Vlad contó cómo Snyk llegó a Intuit: el equipo de desarrollo se lo presentó al equipo de seguridad como la herramienta que quería usar.

¿Cómo podemos capacitar mejor a los desarrolladores?

Estas son algunas ideas iniciales importantes que vale la pena tener presentes:

• La seguridad no forma parte de la enseñanza del desarrollo de software en las instituciones educativas, así que representa un obstáculo desde el principio.

• No intentes convertir a todos los desarrolladores en expertos; enfócate en quienes quieren aprender más.

Capacitación en seguridad

Para que la seguridad forme parte del día a día de los desarrolladores, debe integrarse de forma natural en sus procesos y en su comprensión del desarrollo de software. Se observó que, durante sus estudios universitarios, los desarrolladores muchas veces ni siquiera conocen OWASP Top Ten, ni aprenden sobre desarrollo seguro y principios de diseño seguro al mismo tiempo que sobre desarrollo de software. Para integrar realmente la seguridad en el proceso de desarrollo de software, debe enseñarse junto con el desarrollo de software en las instituciones educativas, para que los ingenieros asocien la programación segura con el desarrollo de software en general.

Los equipos necesitan conocimientos amplios de seguridad, no expertos individuales

Pero ¿no empezamos esta mesa redonda diciendo que a los desarrolladores no les importa mucho la seguridad? ¿Cómo nos aseguramos de que los equipos de desarrollo conozcan bien las prácticas de seguridad si no siempre las tienen presentes ni quieren aprender sobre ellas? Aquí es importante distinguir el nivel de conocimientos de seguridad que necesitan los equipos de desarrollo. Los desarrolladores no necesitan ser expertos en seguridad, pero deberían tener conocimientos en varias áreas; un buen ejemplo es el modelado de amenazas. Si los desarrolladores se plantean preguntas del tipo «¿qué pasaría si...?», podrán pensar en los flujos adecuados para reducir los riesgos de seguridad.

Fomenta la curiosidad con un programa de security champions

Para mí, este tema dejó dos grandes conclusiones:

• Dedica tiempo a los desarrolladores que sienten curiosidad de forma natural y quieren aprender más sobre seguridad.

• La participación en un programa de security champions debe ser voluntaria; las recompensas, el reconocimiento y los beneficios deben impulsar el crecimiento orgánico de la comunidad.

Convierte la curiosidad en experiencia

Debemos reconocer que hay distintos tipos de desarrolladores: quienes sienten curiosidad por la seguridad y con quienes queremos colaborar estrechamente, y quienes se ocupan de la seguridad porque es necesario. Estos últimos harán lo mínimo necesario para completar sus tareas. Por eso, el umbral de lo que deben hacer debe ser bajo y el proceso de seguridad, sencillo. En cambio, debemos fomentar la curiosidad de quienes quieren aprender sobre seguridad y aprovecharla, por ejemplo, mediante un programa de security champions.

Los security champions deben participar como voluntarios

El grupo estuvo de acuerdo en que la participación en un programa de security champions debe ser voluntaria. Desde la perspectiva del equipo de seguridad, este tipo de programa es una excelente manera de reunir a quienes apoyan la seguridad en equipos de desarrollo distribuidos y quieren participar. Si se gestiona bien, permitirá que más personas se sumen con el tiempo, también de forma voluntaria, al ver los beneficios, las recompensas y el reconocimiento que reciben quienes ya forman parte del programa.

Celebra y recompensa los logros

Celebrar los logros y recompensar a quienes contribuyen fue un tema importante en el que todos estuvieron de acuerdo. Estas son algunas ideas para lograrlo:

• Mide los logros, no la ausencia de infracciones.

• Comparte historias de éxito de equipos que hacen un buen trabajo para inspirar más logros.

• Ve más allá de las métricas operativas y celebra logros como la adopción de procesos y prácticas de seguridad.

Es cierto que la mayoría de las organizaciones mide la seguridad de sus proyectos según las infracciones de seguridad, en lugar de fijarse en los logros. En gran medida, esto se debe a que es más fácil hacer un seguimiento constante de esa métrica en los distintos equipos de desarrollo. Sin embargo, este enfoque se centra en lo que está mal en los proyectos y no en lo que se hizo bien. Cuando todo funciona correctamente, hay poco que compartir con las comunidades de desarrollo más amplias, aparte de que hay menos problemas.

En cambio, lo que realmente queremos destacar es cuántas veces un desarrollador encontró y corrigió una vulnerabilidad antes de que se convirtiera en una infracción. Esta es una medida real del éxito de un programa de seguridad, cuyo KPI se centra en acciones que mejoran la seguridad. Además, estas actividades deberían recompensarse y convertirse en dinámicas de juego, para reconocer el gran trabajo que hacen los desarrolladores y los equipos para mejorar su nivel de seguridad y animar a otros a hacer lo mismo.

Es más fácil decirlo que hacerlo. Aunque fue alentador saber que todos compartían esta opinión, fue más difícil encontrar ejemplos concretos de que esto ya esté ocurriendo. Algunas personas en la mesa sí querían dar ciertos pasos, como cambiar el lenguaje para que la terminología fuera más accesible para los desarrolladores. También propusieron ofrecer más estímulos y reconocimiento con historias concretas, y destacar a los desarrolladores que hacen un gran trabajo al corregir vulnerabilidades, con la esperanza de que otros sigan su ejemplo y adopten una mentalidad más enfocada en la seguridad.

Un logro no siempre tiene que relacionarse con una métrica operativa; por ejemplo, puede vincularse más directamente con la seguridad en tu pipeline o en tus procesos. Una idea que se mencionó fue crear un sistema de calificación que muestre el nivel actual de seguridad tuyo y de tu equipo, así como un plan o rumbo para los cambios y las mejoras que quieren implementar. Esto también permite ver el camino recorrido por las personas y los equipos, incluido su progreso.

¿Cómo puedes medir la ausencia de problemas de seguridad?

Es fácil complicar demasiado los KPI y las mediciones. Una métrica importante que queremos poder obtener es la ausencia de problemas de seguridad. Para evitar tener que rehacer el trabajo de desarrollo, necesitamos entender qué se hizo para evitarlo. Medir los hábitos de seguridad es una buena forma de saber cómo se detectan los problemas. Por ejemplo, ¿los equipos identifican por sí mismos dónde existen amenazas de seguridad, quizá gracias a buenas prácticas de modelado de amenazas?

Una buena forma de pensar en el efecto de shift left es empezar por la derecha. En última instancia, queremos que nuestro entorno de producción sea más seguro, con menos riesgos y vulnerabilidades. Si implementamos procesos y hábitos a la izquierda, veremos que las métricas y cifras de la derecha disminuyen. Esto mostrará el impacto y el éxito de las actividades que se implementaron a la izquierda. Así que revisa tus métricas de seguridad, implementa seguridad shift left (primero para los desarrolladores) y vuelve a revisar tus métricas.Visita https://snyk.io/events/ para saber dónde estaremos próximamente. Si quieres recibir invitaciones a futuras mesas redondas interactivas, comunícate con tu representante de Snyk para obtener más información.