Adopta un enfoque shift-left responsable con los controles de seguridad mejorados de Snyk para pull requests

Nos complace anunciar que mejoramos las pruebas de seguridad y licencias de Snyk para pull requests, a fin de brindar un mejor soporte a la seguridad shift-left y a los flujos de trabajo de desarrollo seguro.

Los pull requests —la base de los flujos de trabajo de desarrollo en GitHub— facilitan la colaboración en los proyectos. Cada colaborador puede compartir los cambios que subió a una rama de un repositorio, debatirlos con otros colaboradores y, posteriormente, confirmarlos e integrarlos en la rama base.

Snyk está diseñado para que los desarrolladores y los equipos de seguridad integren las pruebas de seguridad en estos flujos de trabajo, lo antes posible en el SDLC. Snyk prueba automáticamente los cambios incluidos en los pull requests para detectar vulnerabilidades de seguridad y problemas de licencias. Si se identifica un problema, la prueba de Snyk falla y se notifica al desarrollador mediante una comprobación de estado correspondiente. Para evitar que las pruebas de seguridad de Snyk para pull requests interfieran con los pipelines de desarrollo, los usuarios pueden decidir exactamente cuándo deben fallar las comprobaciones de estado; por ejemplo, solo ante problemas de gravedad alta o cuando haya una corrección disponible.

Las últimas mejoras en las pruebas de seguridad de Snyk para pull requests llevan esto un paso más allá. Para evitar aún más interrupciones innecesarias en los pipelines de desarrollo y brindar a los desarrolladores visibilidad total sobre los resultados de las pruebas de seguridad de Snyk, ahora pueden consultar todos los detalles sobre el motivo por el que falló su pull request y, luego, solicitar al administrador que omita la prueba y apruebe el pull request de todos modos.

Veamos cómo funciona con algunos ejemplos sencillos.

Comprobaciones de estado de Snyk para pull requests

Una vez que GitHub termina de comprobar si hay conflictos y ejecuta las comprobaciones en los archivos de manifiesto del proyecto (por ejemplo, package.json / package.lock, requirements.txt o Gemfile.lock / Gemfile), Snyk realiza las pruebas de seguridad. Si los cambios no introducen vulnerabilidades, la prueba se supera sin problemas:

Por otro lado, si los cambios introducen vulnerabilidades, las comprobaciones de estado de Snyk hacen que falle el pull request. En el siguiente ejemplo, la inclusión de una dependencia provocó que fallaran las pruebas de seguridad de Snyk:

Sin importar cuántos proyectos (y archivos de manifiesto relacionados) haya en un repositorio, solo se muestran dos comprobaciones de estado de Snyk: una para las pruebas de seguridad y otra para las comprobaciones de licencias. Esto resulta especialmente útil en los monorepos, ya que reduce la cantidad de comprobaciones de estado que Snyk genera para los proyectos integrados.

Los administradores pueden configurar las pruebas de seguridad de Snyk para pull requests para que sean más estrictas o flexibles. Por ejemplo, se puede configurar que las pruebas fallen si el repositorio tiene vulnerabilidades existentes o solo cuando se introduzcan vulnerabilidades de gravedad alta.

Omitir las pruebas de seguridad fallidas

Ver comprobaciones de estado fallidas en los pull requests puede ser frustrante para los desarrolladores, sobre todo cuando no incluyen información contextual sobre el motivo del fallo. Snyk ofrece visibilidad sobre las vulnerabilidades y los problemas de licencias detectados durante las pruebas, además de la posibilidad de omitir la prueba fallida y aprobarla de todos modos.

Si un pull request no supera las pruebas de Snyk, los usuarios pueden consultar los motivos haciendo clic en el enlace Detalles que aparece junto al estado de la comprobación fallida. Esto los lleva a la aplicación de Snyk, donde se muestra toda la información sobre el motivo del fallo en la página Estado combinado:

Se muestran todas las comprobaciones pertinentes realizadas para el proyecto, junto con información sobre los resultados y su estado: «Error» para las pruebas que no se pudieron completar, «Fallida» para las pruebas que fallaron debido a problemas detectados, «En curso» para las pruebas que aún se están ejecutando y «Correcta» para las pruebas superadas.

Los usuarios identificados como colaboradores pueden solicitar a un administrador de Snyk que apruebe una o varias de las pruebas que se muestran en esta página.

Los administradores pueden hacer clic en el botón Marcar como correcto en SCM para aprobar la solicitud. El estado se actualiza automáticamente en GitHub.

Cada acción de omisión realizada para aprobar una prueba de seguridad fallida queda registrada para futuras consultas, junto con información de auditoría sobre quién la realizó y cuándo, además de un enlace a la página Estado combinado.

Un enfoque shift-left supervisado

Desplazar la seguridad hacia la izquierda es una piedra angular para implementar con éxito una estrategia DevSecOps, pero debe hacerse de manera responsable. Para lograrlo, hay que ayudar a los desarrolladores a integrar la seguridad en los flujos de trabajo de desarrollo existentes de manera fluida y sin obstáculos, con el nivel adecuado de supervisión.

Las pruebas de seguridad mejoradas de Snyk para pull requests brindan a los desarrolladores visibilidad temprana y completa sobre las pruebas de seguridad automatizadas que se ejecutan en sus pull requests, además de la posibilidad de solicitar que se aprueben las pruebas fallidas. Además, los equipos de seguridad tienen el control necesario para eliminar los bloqueos de forma segura.

¿Quieres probar estas funciones? Están disponibles en todos los planes de Snyk, incluido el plan Free.