Cómo Snyk está priorizando la experiencia de los desarrolladores

Cambiar de contexto puede ser el peor enemigo de la seguridad. Las prácticas de seguridad actuales requieren el apoyo de los desarrolladores, y cuando los equipos de seguridad les piden que se desvíen de sus flujos de trabajo habituales para resolver problemas, es mucho menos probable que adopten esas prácticas.

Para que los desarrolladores puedan encontrar y corregir vulnerabilidades en su código, los equipos de seguridad deben llevar la seguridad aún más a la izquierda. No basta con ofrecer herramientas fáciles de usar y capacitaciones sobre cómo utilizarlas. Si la herramienta sigue obligando a los desarrolladores a interrumpir su flujo de trabajo para realizar tareas relacionadas con la seguridad, aumenta su carga cognitiva. A menudo, los desarrolladores no tienen el tiempo ni los recursos para agregar otra tarea a una agenda que ya está llena.

Para enfrentar estos desafíos, Snyk lanza nuevas funciones que mejoran nuestras soluciones centradas en los desarrolladores y permiten que los equipos de seguridad sigan adaptándose a las nuevas realidades de los ciclos de desarrollo actuales. Hace poco, mostramos a nuestros usuarios un adelanto de estas funciones en la edición más reciente de SnykLaunch, ahora disponible a pedido. En esta publicación, repasaremos los nuevos lanzamientos que mejoran directamente la experiencia de los desarrolladores y explicaremos por qué son importantes para los equipos de hoy. 

El costo de cambiar de contexto

Los desarrolladores pasan buena parte de su tiempo en tres lugares: sus IDE, la CLI y el SCM. Aunque podría parecer sencillo que un desarrollador reciba una alerta de seguridad sobre un proyecto en curso y vaya a otra plataforma para resolver el problema, a menudo no lo es. Ese cambio de contexto no solo saca a los desarrolladores de sus flujos de trabajo habituales, sino que agrega pasos al desarrollo de software, interrumpe su productividad y los obliga a ir y venir entre varios sistemas para realizar tareas relacionadas con la seguridad. 

Los desarrolladores escriben la mayor parte de su código en sus IDE, ya sea código escrito a mano, código creado con IA generativa o una combinación de ambos. Crean ramas o bifurcaciones del código, lo envían de forma incremental a su SCM y, cuando está listo, crean un «pull request» (PR). Un pull request está diseñado para facilitar la colaboración y la revisión de código. Interrumpir este proceso y obligar a los desarrolladores a salir del flujo de trabajo del SCM para resolver problemas de seguridad agrega una tarea inesperada y rompe su ritmo, lo que frustra el propósito de un flujo de trabajo de PR eficiente. Es como descubrir una tarea sorpresa en tu lista de pendientes cuando creías que ya casi habías terminado.

Esta desconexión entre los equipos de desarrollo y seguridad perjudica los esfuerzos de DevSecOps. A menudo, los equipos de seguridad se preguntan por qué más desarrolladores no adoptan sus herramientas, mientras que los desarrolladores pueden resistirse a las interrupciones de su flujo de trabajo que provoca una tarea inesperada. Es una situación en la que todos pierden.

Dos pilares de la experiencia de los desarrolladores

En lugar de pedirles a los desarrolladores que interrumpan su concentración para resolver problemas de seguridad, los equipos de seguridad deben integrarse en las herramientas que ya utilizan. Dos ideas fundamentales pueden ayudarles a lograrlo:

1. Dar a los desarrolladores información contextual en su entorno de trabajo

Los desarrolladores necesitan cierta información de contexto para corregir con éxito los problemas de seguridad en su código. Esta información puede incluir por qué se marcó una línea específica como vulnerable y cómo modificarla para mitigar la vulnerabilidad. Sin embargo, los equipos de seguridad no pueden esperar que los desarrolladores revisen documentación genérica o consulten tutoriales en una plataforma de seguridad para resolver el problema. Deben ofrecer recursos educativos breves y concretos que proporcionen a los desarrolladores información básica y recomendaciones para corregirlo, ni más ni menos. 

2. Reducir la fricción y minimizar las interrupciones en los flujos de trabajo

Snyk ya ayuda a los desarrolladores a encontrar y corregir vulnerabilidades de seguridad directamente en sus IDE. Como los desarrolladores también pasan mucho tiempo trabajando en su SCM, Snyk amplía sus herramientas centradas en los desarrolladores e integra información de seguridad en los flujos de trabajo de PR del SCM. Así, los desarrolladores reciben comentarios de seguridad sin complicaciones y dentro de las herramientas que usan a diario.

Nuevas funciones de PR de Snyk para mejorar la experiencia de los desarrolladores 

Por nuestra experiencia trabajando directamente con equipos de desarrollo y ayudando a los desarrolladores a integrar la seguridad en sus IDE, sabemos que el mejor lugar para incluir la seguridad son las herramientas que ya utilizan. Ahora, cuando un desarrollador hace clic en el botón «crear PR», las comprobaciones de PR de Snyk (disponibles de forma general para Snyk Open Souce y con acceso anticipado para Snyk Code) pueden realizar una revisión de seguridad del código directamente en los flujos de trabajo estándar de PR.

Al terminar el análisis de PR Check, nuestra nueva función de «resumen de problemas» publica un comentario en el SCM con un resumen de los hallazgos de seguridad, directamente en el flujo de trabajo de PR de los desarrolladores. Estos datos resumen los hallazgos según su nivel de gravedad y ofrecen enlaces directos para que los desarrolladores revisen y resuelvan los problemas.

Además, ahora ofrecemos plantillas de PR personalizables, que permiten a los equipos personalizar los PR que genera Snyk. Las nuevas plantillas de PR personalizables de Snyk adaptan los pull requests generados por Snyk a los estándares, las prácticas y las preferencias de comunicación específicas de tu organización. Puedes especificar el título y la descripción, qué detalles de seguridad compartir e incluso la información de los tickets de JIRA, para que coincidan con lo que tus desarrolladores esperan ver en sus PR. Al adaptar nuestras funciones a las necesidades específicas de tu organización, puedes integrar el flujo de trabajo en los procesos existentes de los desarrolladores de forma aún más fluida. 

Para obtener más información sobre estas nuevas funciones de pull request, no te pierdas nuestra presentación más reciente de SnykLaunch.