Skip to main content

Integración del análisis de seguridad de C/C++ de Snyk Open Source en pipelines de CI

Escrito por
Headshot of Michal Brutvan

Michal Brutvan

blog feature oss cpp

8 de septiembre de 2022

0 minutos de lectura

Snyk Open Source admite el análisis de dependencias open source vendorizadas de C y C++ mediante la CLI, y nos complace compartir que ahora también está disponible a través de nuestros plugins de CI. Esta guía te explicará cómo integrar el análisis de seguridad de C/C++ en pipelines para que los desarrolladores reciban directamente información sobre vulnerabilidades y recomendaciones para corregirlas. Ten en cuenta que, en esta guía, nos referiremos a “C/C++” simplemente como “C++”

Opción 1: Usar plugins de CI

Snyk se integra con muchas plataformas de CI/CD, como Jenkins, Azure DevOps y GitHub Actions. Todos estos plugins tienen algo en común: incorporan la CLI de Snyk y otras herramientas para facilitar la configuración y el uso. Esto también significa que su configuración es la misma y que todos estos plugins te permiten especificar un argumento adicional de línea de comandos para pasarlo a la CLI de Snyk.

Para analizar un proyecto de C++, solo tienes que agregar --unmanaged como argumento adicional. Aquí tienes un ejemplo de configuración del plugin Snyk Security para Jenkins:

Formulario de configuración de Jenkins que muestra el nombre del proyecto “cpp-goof”, la instalación de Snyk “snyk@latest” y el argumento adicional “--unmanaged”.

Después de la compilación, encontrarás un elemento Snyk Security Report en la página de detalles de la compilación:

Informe de pruebas de Snyk en Jenkins que muestra 58 vulnerabilidades conocidas en 14 dependencias de C/C++, incluido un problema crítico de lectura fuera de los límites

El informe de seguridad enumera las vulnerabilidades detectadas según las dependencias open source identificadas. Cada vulnerabilidad incluye información sobre su gravedad, la dependencia afectada y la versión del proyecto open source que corrige la vulnerabilidad.

Aviso de seguridad que detalla un desbordamiento de búfer en el heap de alta gravedad en el paquete dnsmasq y recomienda actualizar a la versión 2.83 o posterior.

Opción 2: Usar un script

Los dos comandos de la CLI que se usan para analizar proyectos de C++ son snyk test y snyk monitor, ambos con la opción de línea de comandos --unmanaged. Los dos analizan el código para detectar dependencias open source y sus vulnerabilidades, pero cada uno tiene un propósito distinto.

snyk test

El comando snyk test --unmanaged es el comando básico para generar la lista de vulnerabilidades. Identifica las dependencias open source en tu código y consulta la Snyk Vulnerability Database para encontrar vulnerabilidades conocidas. Está diseñado para funcionar en pipelines de CI (admite resultados en formato JSON) y devuelve un código de salida distinto de cero cuando detecta un problema. Si almacenas tus dependencias open source como archivos comprimidos, la CLI de Snyk también puede inspeccionarlos.

snyk monitor

A diferencia del comando anterior, el comando snyk monitor --unmanaged delega el informe de problemas en la interfaz de Snyk. Está diseñado para tomar una instantánea de las dependencias y vulnerabilidades detectadas en ese momento e importarlas a tu panel de Snyk. Desde allí, se supervisan las dependencias identificadas para detectar nuevas vulnerabilidades y recibirás una alerta cuando se agregue una nueva vulnerabilidad a Snyk Vulnerability Database. Este comando no devuelve un código de salida cuando detecta un problema.

Vale la pena mencionar que este comando realmente toma una instantánea de las dependencias detectadas en ese momento. Snyk solo almacena las firmas en sus servidores durante un breve periodo para solucionar problemas. A medida que evoluciona nuestra base de datos open source, Snyk puede detectar nuevas bibliotecas y sus vulnerabilidades, por lo que es buena idea ejecutar el comando snyk monitor --unmanaged con regularidad.

snyk-to-html

snyk-to-html es una herramienta independiente que convierte los resultados JSON de snyk test --json en un documento HTML legible. Un uso típico con el comando snyk test para dependencias no administradas sería así:

snyk test --unmanaged --json | snyk-to-html -o snyk_results.html

En conjunto

La supervisión periódica es importante para mantener una postura de seguridad sólida. La mejor manera de proteger el código es importar al panel de Snyk la instantánea de las dependencias identificadas y dejar que el proceso de supervisión nocturno te avise sobre nuevas vulnerabilidades. Ejecutar snyk monitor --unmanaged con regularidad garantizará que la instantánea de dependencias esté actualizada con los datos de vulnerabilidades más recientes y que recibas alertas sobre nuevas vulnerabilidades en cuanto aparezcan en nuestra base de datos de vulnerabilidades.

Si quieres probar commits o ramas individuales y hacer que el pipeline falle cuando haya vulnerabilidades, ejecuta solo el comando snyk test --unmanaged. Encadenar el comando test con snyk monitor --unmanaged también importará los resultados a tu panel de inmediato. La instantánea de dependencias se actualizará solo si la prueba se completa correctamente:

$ snyk test --unmanaged && snyk monitor --unmanaged

También puedes usar otras opciones, como severity-threshold=high, para que Snyk interrumpa la compilación solo si introduces vulnerabilidades con gravedad high o superior. Consulta la documentación de Snyk para C/C++ para ver la lista completa de opciones de línea de comandos compatibles.

Ejemplo de definición de pipeline de Gitlab CI/CD

dependency_scanning:
  image: node:latest  # we need npm to install Snyk CLI and we don't need any C++ tooling to run the scan
  stage: test
  script:
    # Install npm, snyk, and snyk-to-html
    - npm install -g npm@latest
    - npm install -g snyk
    - npm install snyk-to-html -g
    # Run snyk help, snyk auth, snyk monitor, snyk test to break build and out report
    - snyk --help
    - snyk auth $SNYK_TOKEN
    - snyk monitor --unmanaged --project-name=cpp-goof-gitlab
    - snyk test --unmanaged --json | snyk-to-html -o snyk_results.html

  # Save report to artifacts
  artifacts:
    when: always
    paths: 
      - snyk_results.html

Corrección de problemas

Para corregir un problema, debes reemplazar el código fuente del paquete open source con la vulnerabilidad detectada por la versión más reciente recomendada. Sigue las recomendaciones disponibles en la URL del problema para saber en qué versión de tu dependencia se corrigió la vulnerabilidad.

$ snyk test --unmanaged
Testing c-example...

Issues:

 ✗ [Low] Race Condition
    Introduced through: https://curl.se|curl@7.58.0
    URL: https://security.snyk.io/vuln/SNYK-UNMANAGED-CURL-2317489
Página de Snyk Vulnerability Database que muestra una condición de carrera de curl que afecta las versiones 7.10.4 y 7.77.0, con recomendaciones para actualizar.

Después de actualizar el código fuente, pueden ocurrir dos cosas:

  1. El problema desaparece y listo.

  2. El problema sigue detectándose porque la dependencia open source no se identificó correctamente.

En cuanto al caso 2, esto se debe a que actualizamos mensualmente nuestra base de datos open source con nuevas versiones, así que es posible que la versión más reciente del paquete que acabas de incluir en tu código aún no se haya agregado. Para verificar si Snyk identificó correctamente la dependencia y su versión, ejecuta el comando test con la opción --print-deps:

$ snyk test --unmanaged --print-deps
Testing c-example...

Dependencies:

  https://curl.se|curl@7.58.0
  confidence: 0.800

Issues:

 ✗ [Low] Race Condition
    Introduced through: https://curl.se|curl@7.58.0
    URL: https://security.snyk.io/vuln/SNYK-UNMANAGED-CURL-2317489

Ten en cuenta que la métrica confidence mide el nivel de confianza de Snyk en la coincidencia.

¿Qué nivel de confianza es adecuado?

La respuesta es: depende. El nivel de confianza es la proporción de archivos locales que coinciden con una versión publicada del proyecto open source. Por ejemplo, si una versión específica publicada de un proyecto open source (el paquete con el código fuente) contiene 1000 archivos y tu proyecto local contiene 900 de ellos, mientras que los demás no coinciden porque se modificaron, el nivel de confianza es 900/1000 = 0.9. Sin embargo, el nivel de confianza es el mismo para un proyecto open source con 10 archivos y 9 archivos locales coincidentes, un caso bastante distinto del ejemplo anterior. Tú decides qué nivel de confianza es suficiente y qué identificaciones de dependencias vas a omitir.

Si la identificación no es correcta, puedes usar el comando snyk ignore para ignorar temporalmente la dependencia:

$ snyk ignore --file-path='./deps/curl-7.60.0/*' --expiry='2022-05-20' --reason='patched the release and waiting for Snyk OS database to update'

El futuro del análisis de seguridad de C/C++

Estamos trabajando para mejorar la precisión de nuestros análisis, centrándonos más en la selección de proyectos open source y mejorando nuestros algoritmos de coincidencia para tener en cuenta proyectos con código ligeramente modificado (o con pruebas y documentación eliminadas). Esto incluye actualizar con mayor frecuencia nuestra base de datos de código fuente o agregar proyectos que no tienen versiones publicadas.

Como alternativa a la detección no administrada (basada en firmas) de componentes de C++, estamos desarrollando una API que te permitirá consultar directamente nuestra base de datos de vulnerabilidades. ¿Tienes comentarios o te interesa conocer la nueva API? Escríbenos a ccpp@snyk.io.

Empieza con los desafíos de Capture the Flag

Aprende a resolver desafíos de captura la bandera con nuestro taller virtual introductorio a pedido.