Uso de la herramienta de escaneo de vulnerabilidades Snyk

Tutoriales
Kubernetes

Introducción

Snyk fue diseñado para servir como una plataforma de seguridad para desarrolladores y con flexibilidad en mente. Su principal objetivo es ayudarte a detectar y solucionar vulnerabilidades en el código fuente de tu aplicación, dependencias de terceros, imágenes de contenedores y archivos de configuración de infraestructura (por ejemplo, Kubernetes, Terraform, etc.).

Snyk se divide en cuatro componentes:

  1. Snyk Code – te ayuda a encontrar y solucionar vulnerabilidades en el código fuente de tu aplicación.
  2. Snyk Open Source – te ayuda a encontrar y solucionar vulnerabilidades en cualquier biblioteca o dependencia de terceros en las que tu aplicación dependa.
  3. Snyk Container – te ayuda a encontrar y solucionar vulnerabilidades en imágenes de contenedores o cargas de trabajo de Kubernetes utilizadas en tu clúster.
  4. Snyk Infrastructure as Code – te ayuda a encontrar y solucionar configuraciones incorrectas en tus manifiestos de Kubernetes (también se admiten Terraform, CloudFormation y Azure).

Snyk se puede ejecutar de diferentes maneras:

  • A través de la interfaz de línea de comandos utilizando Snyk CLI. Esta es la forma preferida de ejecutarlo dentro de scripts y diversas automatizaciones, incluidos los pipelines de CI/CD.
  • En el navegador como Snyk Web UI. Snyk ofrece una plataforma basada en la nube que puedes utilizar para investigar informes de escaneo, recibir sugerencias y tomar las acciones necesarias para solucionar problemas informados, etc. También puedes conectar repositorios de GitHub y realizar escaneos/auditorías desde la interfaz web.
  • A través de complementos para IDE. De esta manera, puedes detectar problemas temprano mientras desarrollas usando tu IDE favorito (por ejemplo, Visual Studio Code).
  • Programáticamente, a través de la API de Snyk. La API de Snyk está disponible para clientes en planes de pago y te permite integrarte con Snyk de forma programática.

¿Es Snyk gratuito?

Sí, las herramientas son gratuitas, excepto la API de Snyk y algunas funciones avanzadas de la interfaz web (como informes avanzados). También hay una limitación en el número de pruebas que puedes realizar por mes.

Consulta los planes de precios para obtener más información.

¿Es Snyk de código abierto?

Sí, las herramientas y el CLI de Snyk lo son. Puedes visitar la página de inicio de GitHub de Snyk para encontrar más detalles sobre la implementación de cada componente. El portal en la nube y todas las características de pago, como la implementación de la API de resto, no son de código abierto.

Otro conjunto importante de conceptos que Snyk utiliza son Objetivos y Proyectos.

Los Objetivos representan un recurso externo que Snyk ha escaneado a través de una integración, la CLI, la interfaz de usuario o la API. Ejemplos de objetivos son un repositorio SCM, una carga de trabajo de Kubernetes, etc.

Por otro lado, los Proyectos definen los elementos que Snyk escanea en un Objetivo dado. Un proyecto incluye:

  • A scannable item external to Snyk.
  • Configuración para definir cómo ejecutar ese escaneo.

Puedes leer más sobre los conceptos fundamentales de Snyk aquí.

En esta guía, utilizarás la CLI de Snyk para realizar un análisis de riesgos para la cadena de suministro de tus aplicaciones Kubernetes (imágenes de contenedores, manifiestos YAML de Kubernetes). Luego, aprenderás cómo tomar la acción apropiada para remediar la situación. Finalmente, aprenderás cómo integrar Snyk en un pipeline de CI/CD para escanear vulnerabilidades en las primeras etapas de desarrollo.

Tabla de Contenidos

Requisitos Previos

Para completar todos los pasos de esta guía, necesitarás:

  1. A working DOKS cluster running Kubernetes version >=1.21 that you have access to. For additional instructions on configuring a DigitalOcean Kubernetes cluster, see: How to Set Up a DigitalOcean Managed Kubernetes Cluster (DOKS).
  2. A DigitalOcean Docker Registry. A free plan is enough to complete this tutorial. Also, make sure it is integrated with your DOKS cluster as explained here.
  3. Kubectl CLI para interacción con Kubernetes. Sigue estas instrucciones para conectarte a tu clúster con kubectl y doctl.
  4. CLI de Snyk para interactuar con el escáner de vulnerabilidades de Snyk.
  5. A free Snyk cloud account account used to periodically publish scan results for your Kubernetes cluster to a nice dashboard. Also, the Snyk web interface helps you with investigations and risk analysis. Please follow How to Create a Snyk Account documentation page.
  6. A Slack workspace you own, and a dedicated Slack app to get notified of vulnerability scan issues reported by Snyk.

Paso 1 – Conociendo la CLI de Snyk

Puede escanear manualmente en busca de vulnerabilidades a través de la interfaz de línea de comandos snyk. La CLI de Snyk está diseñada para ser utilizada en varios scripts y automatizaciones. Un ejemplo práctico es en un pipeline de CI/CD implementado utilizando diversas herramientas como Tekton, Jenkins, GitHub Workflows, etc.

Cuando se invoca la CLI de Snyk, comenzará inmediatamente el proceso de escaneo e informará sobre problemas en un formato específico. De forma predeterminada, imprimirá una tabla resumen utilizando la salida estándar o la consola. Snyk también puede generar informes en otros formatos, como JSON, HTML, SARIF, etc.

Puede optar por enviar los resultados al Portal de la Nube de Snyk (o interfaz web) a través de la bandera --report para almacenar y visualizar los resultados del escaneo más tarde.

Nota:No es obligatorio enviar los resultados del escaneo al portal de la nube de Snyk. La gran ventaja de utilizar el portal de Snyk es la visibilidad, porque le proporciona acceso a un panel agradable donde puede verificar todos los informes de escaneo y ver cuánto impacta la cadena de suministro de Kubernetes. También le ayuda a largo plazo con investigaciones y sugerencias de remedio.

La CLI de Snyk está dividida en varios subcomandos. Cada subcomando está dedicado a una característica específica, como:

Antes de continuar, asegúrese de crear una cuenta gratuita utilizando la interfaz web de Snyk. Además, el CLI de Snyk necesita estar autenticado con su cuenta en la nube también para que algunos comandos/subcomandos funcionen (por ejemplo, snyk code test).

A few examples to try with Snyk CLI:

  1. Exploración de código abierto:
# Escanea el código de tu proyecto desde el directorio actual
snyk test
# Escanea una ruta específica desde el directorio de tu proyecto (asegúrate de reemplazar los marcadores `<>` adecuadamente)
snyk test <path/to/dir>
  1. Exploración de código:
# Escanear el código de tu proyecto desde el directorio actual
snyk code test

# Escanear una ruta específica desde el directorio de tu proyecto (asegúrate de reemplazar los marcadores `<>` adecuadamente)
snyk code test <path/to/dir>
  1. Escaneo de imágenes:
# Escanea la imagen docker de Debian descargándola primero
snyk container debian

# Proporciona más contexto al escáner proporcionando un Dockerfile (asegúrate de reemplazar los marcadores `<>` adecuadamente)
snyk container debian --file=<path/to/dockerfile>
  1. Escaneo de infraestructura como código:
# Escanear el código de tu proyecto desde el directorio actual
snyk iac test

# Escanear una ruta específica desde el directorio de tu proyecto (asegúrate de reemplazar los marcadores `<>` adecuadamente)
snyk iac test <path/to/dir>

# Escanear proyectos basados en Kustomize (primero necesitas renderizar la plantilla final, luego pasarla al escáner)
kustomize build > kubernetes.yaml
snyk iac test kubernetes.yaml

Snyk CLI proporciona páginas de ayuda para todas las opciones disponibles. El siguiente comando puede usarse para imprimir la página de ayuda principal:

snyk --help

La salida se ve similar a:

Output
CLI commands help
  Snyk CLI scans and monitors your projects for security vulnerabilities and license issues.

  For more information visit the Snyk website https://snyk.io

  For details see the CLI documentation https://docs.snyk.io/features/snyk-cli

How to get started
  1. Authenticate by running snyk auth
  2. Test your local project with snyk test
  3. Get alerted for new vulnerabilities with snyk monitor

Available commands
  To learn more about each Snyk CLI command, use the --help option, for example, snyk auth --help or 
  snyk container --help

  snyk auth
    Authenticate Snyk CLI with a Snyk account.

  snyk test
    Test a project for open source vulnerabilities and license issues.

Cada comando (o subcomando) de Snyk CLI tiene una página de ayuda asociada, que se puede acceder mediante snyk [comando] --help.

Por favor, visita la página oficial de documentación de la CLI de Snyk para más ejemplos.

Paso 2 – Conocer la interfaz web de Snyk

Después de registrarte para obtener una cuenta de Snyk, autenticarte e iniciar sesión en Snyk, la interfaz web se abre en el Panel de control, con un asistente para guiarte a través de los pasos de configuración:

  • Identificar dónde se encuentra el código que deseas monitorear en Snyk.
  • Definir qué proyectos dentro de tu código deseas que Snyk escanee.
  • Conectar Snyk a los proyectos relevantes para escanearlos.
  • Revisar los resultados de tu escaneo de Snyk.

Las siguientes funciones están disponibles a través de la interfaz web:

Visite la página de documentación oficial para obtener más información sobre la interfaz de usuario web de Snyk.

Comprender los Niveles de Severidad de Snyk

En cada escaneo, snyk verifica sus recursos en busca de posibles riesgos de seguridad y cómo cada uno afecta su sistema. Se aplica un nivel de severidad a una vulnerabilidad para indicar el riesgo que representa esa vulnerabilidad en una aplicación.

Los niveles de severidad pueden tomar uno de los siguientes valores:

  • Bajo: la aplicación puede exponer algunos datos que permiten el mapeo de vulnerabilidades, que pueden ser utilizados con otras vulnerabilidades para atacar la aplicación.
  • Medio: puede permitir a los atacantes, bajo ciertas condiciones, acceder a datos sensibles en su aplicación.
  • Alto: puede permitir a los atacantes acceder a datos sensibles en su aplicación.
  • Crítico: puede permitir a los atacantes acceder a datos sensibles y ejecutar código en su aplicación.

El Sistema Común de Puntuación de Vulnerabilidades (CVSS) determina el nivel de gravedad de una vulnerabilidad. Snyk utiliza el marco de trabajo CVSS versión 3.1 para comunicar las características y la gravedad de las vulnerabilidades.

La siguiente tabla muestra el mapeo de cada nivel de gravedad:

Severity level CVSS score
Low 0.0 – 3.9
Medium 4.0 – 6.9
High 7.0 – 8.9
Critical 9.0 – 10.10

En esta guía, se utiliza el umbral de nivel medio como valor predeterminado en el ejemplo de canalización CI/CD que se está utilizando. Por lo general, se querrá evaluar primero los problemas de alto y crítico nivel, pero en algunos casos, el nivel medio también requiere atención. En términos de seguridad y como regla general, usualmente se querrá ser muy estricto.

Por favor, visita la página de documentación oficial para aprender más sobre los niveles de gravedad.

Asistencia para la Remediación de Problemas de Seguridad Reportados

Otra característica útil proporcionada por la interfaz web de Snyk es la asistencia para la remediación de problemas de seguridad. Significa que recibes una recomendación sobre cómo solucionar cada problema de seguridad encontrado por el escáner snyk. Esto es muy importante porque simplifica el proceso y cierra el ciclo para cada iteración que necesitas realizar para solucionar cada problema de seguridad reportado.

La siguiente imagen ilustra mejor este proceso:

Para cada problema reportado, hay un botón en el que puedes hacer clic y obtener asistencia para la solución:

El procedimiento principal es el mismo para cada problema reportado. Significa que haces clic en el botón de mostrar detalles, luego sigues los pasos sugeridos para aplicar la corrección.

Paso 3 – Utilizando Snyk para Escanear Vulnerabilidades de Configuración de Kubernetes en un Pipeline de CI/CD

¿Cómo te beneficia incorporar una herramienta de escaneo de cumplimiento de seguridad en tu pipeline de CI/CD y evitar situaciones desagradables en un entorno de producción?

Todo comienza en el nivel de la base, donde comienza el desarrollo de software. En general, querrás usar un entorno dedicado para cada etapa. Entonces, en las primeras etapas de desarrollo cuando el código de la aplicación cambia muy a menudo, deberías usar un entorno de desarrollo dedicado (normalmente llamado entorno inferior). Luego, la aplicación se perfecciona cada vez más en el entorno de QA, donde los equipos de QA realizan pruebas manuales y/o automatizadas. A continuación, si la aplicación recibe la aprobación del equipo de QA, se promueve a los entornos superiores, como la puesta en escena, y finalmente a producción. En este proceso, donde la aplicación se promueve de un entorno a otro, se ejecuta un pipeline dedicado, que escanea continuamente los artefactos de la aplicación y verifica el nivel de gravedad. Si el nivel de gravedad no cumple con un umbral específico, el pipeline falla inmediatamente y la promoción de artefactos de aplicación a producción se detiene en las primeras etapas.

Por lo tanto, la herramienta de escaneo de seguridad (por ejemplo, snyk) actúa como un guardián que detiene los artefactos no deseados de ingresar a tu entorno de producción desde las primeras etapas de desarrollo. De la misma manera, los pipelines de los entornos superiores utilizan snyk para permitir o prohibir que los artefactos de la aplicación ingresen a la etapa de producción final.

Implementación del Flujo de Trabajo de CI/CD de GitHub Actions

En este paso, aprenderás cómo crear y probar un ejemplo de canalización CI/CD con escaneo de vulnerabilidades integrado a través de flujos de trabajo de GitHub. Para aprender los fundamentos de cómo usar Acciones de Github con Kubernetes de DigitalOcean, consulta este tutorial.

La canalización proporcionada en la siguiente sección construye e implementa la aplicación game-2048-example desde el repositorio de kubernetes-sample-apps de DigitalOcean.

En un resumen de alto nivel, el flujo de trabajo CI/CD de game-2048 proporcionado en el repositorio kubernetes-sample-apps se compone de las siguientes etapas:

  1. Etapa de construcción y prueba de la aplicación: construye los artefactos principales de la aplicación y ejecuta pruebas automatizadas.
  2. Etapa de escaneo de imagen de aplicación de Snyk: escanea la imagen docker de la aplicación en busca de vulnerabilidades conocidas. Actúa como un filtro, y el estado final de la canalización (éxito/fallo) depende de este paso. En caso de fallo, se envía una notificación a Slack.
  3. Etapa de construcción y empuje de imagen de aplicación: construye y etiqueta la imagen de la aplicación utilizando el último SHA de confirmación de git. Luego, la imagen se empuja a DOCR.
  4. La etapa de escaneo de infraestructura como código (IAC) de Snyk: escanea vulnerabilidades conocidas en los manifiestos YAML de Kubernetes asociados con la aplicación. Actúa como una barrera, y el estado final del pipeline (aprobado/fallido) depende de este paso. En caso de fallo, también se envía una notificación a Slack.
  5. Etapa de implementación de la aplicación: implementa la aplicación en Kubernetes (DOKS).

El diagrama siguiente ilustra cada tarea del pipeline y los pasos asociados con acciones (solo se muestra la configuración relevante):

Notas:

  • En el caso de proyectos basados en kustomize, es mejor renderizar el manifiesto final para capturar y escanear todo (incluidos los recursos remotos). Por otro lado, puede ser difícil identificar qué recurso de Kubernetes necesita ser parcheado. Esto se debe al hecho de que el archivo de manifiesto resultante está compuesto por todos los recursos que se van a aplicar. Así es como funciona kustomize: reúne todos los fragmentos de configuración de cada capa y los aplica sobre una base para construir el compuesto final.
  • También puedes indicarle a Snyk que escanee toda la carpeta donde guardas tus configuraciones de kustomize. De esta manera, es más fácil identificar qué recurso necesita ser corregido en tu repositorio. Los recursos remotos utilizados por kustomize deben corregirse aguas arriba. Además, los secretos y ConfigMaps de Kubernetes generados mediante kustomize no se capturan.

¿Cómo puedes hacer que el pipeline falle si no se cumple cierto nivel de cumplimiento de seguridad?

La CLI de Snyk proporciona una bandera llamada --severity-threshold para este propósito. Esta bandera se correlaciona con el nivel de gravedad general calculado después de cada escaneo. En el caso de Snyk, el nivel de gravedad toma uno de los siguientes valores: bajo, medio, alto o crítico. Puede fallar o pasar el pipeline basado en el valor del nivel de gravedad y detener el despliegue de la aplicación si no se cumplen las condiciones.

La siguiente imagen ilustra el flujo para el ejemplo del pipeline CI/CD utilizado en esta guía:

Por favor, sigue los siguientes pasos para crear y probar el flujo de trabajo de CI/CD de Snyk proporcionado en el repositorio de GitHub kubernetes-sample-apps:

  1. Bifurca el repositorio de GitHub kubernetes-sample-apps.
  2. Cree los siguientes secretos encriptados de GitHub para su copia de kubernetes-sample-apps (pestaña Configuración -> Secretos -> Acciones):
    • DIGITALOCEAN_ACCESS_TOKEN – contiene el token de su cuenta de DigitalOcean.
    • DOCKER_REGISTRY – contiene el nombre de su registro de Docker de DigitalOcean incluyendo el punto final (por ejemplo, registry.digitalocean.com/sample-apps).
    • DOKS_CLUSTER – contiene el nombre de su clúster DOKS. Puede ejecutar el siguiente comando para obtener el nombre de su clúster DOKS: doctl k8s cluster list --no-header --format Name.
    • SNYK_TOKEN – contiene el ID de su cuenta de usuario de Snyk – ejecute: snyk config get api para obtener el ID. Si eso no funciona, puede recuperar el token desde la página de configuración de su cuenta de usuario.
    • SLACK_WEBHOOK_URL – contiene su URL de webhook entrante de Slack utilizada para notificaciones de escaneo de Snyk.
  3. Navega hasta la pestaña Acciones de tu repositorio bifurcado y selecciona el flujo de trabajo Ejemplo de CI/CD de Snyk para Game 2048:
  4. Haz clic en el botón Ejecutar flujo de trabajo y deja los valores predeterminados:

A new entry should appear in the below list after clicking the Run Workflow green button. Select the running workflow to observe the pipeline progress:

El pipeline fallará y se detendrá cuando se ejecute el trabajo verificación de seguridad del contenedor de snyk. Esto es esperado porque el valor predeterminado del nivel de gravedad utilizado en la entrada del flujo de trabajo, que es medio, no cumple con las expectativas. También deberías recibir una notificación de Slack con detalles sobre la ejecución del flujo de trabajo:

En los siguientes pasos, aprenderás cómo investigar el informe de escaneo de snyk para solucionar los problemas, reducir el nivel de gravedad y pasar el pipeline.

Paso 4 – Investigar los resultados del escaneo de Snyk y solucionar los problemas informados

Cuando el umbral de nivel de gravedad no se cumple, el flujo de trabajo de GitHub game-2048 fallará y se enviará una notificación a Slack con detalles adicionales. También recibirás informes de seguridad publicados en GitHub y accesibles en la pestaña Seguridad de tu repositorio de proyecto.

El flujo de trabajo game-2048 realiza dos controles de seguridad:

  1. Controles de seguridad de la imagen del contenedor: el trabajo snyk-container-security-check se utiliza para este propósito. El comando equivalente de snyk que se utiliza es: snyk container test <GAME-2048-IMAGE>:<TAG> --file=/path/to/game-2048/Dockerfile.
  2. Controles de configuración incorrecta de los manifiestos de Kubernetes: el trabajo snyk-iac-security-check se utiliza para este propósito. El comando equivalente de snyk que se utiliza es: snyk iac test /path/to/project/kubernetes/manifests.

Por lo tanto, reducir el nivel de gravedad y aprobar el flujo de trabajo consiste en:

  1. Investigar y solucionar los problemas informados por el trabajo snyk-container-security-check.
  2. Investigar y solucionar los problemas informados por el trabajo snyk-iac-security-check.

A continuación, aprenderás cómo abordar cada uno de ellos.

Investigación y Corrección de Vulnerabilidades en Imágenes de Contenedores

El pipeline de ejemplo utilizado en esta guía ejecuta controles de seguridad para la imagen del contenedor game-2048 y el Dockerfile asociado a través del trabajo snyk-container-security-check.

El trabajo snyk-container-security-check ejecuta los siguientes pasos:

  1. Construye la imagen Docker de la aplicación game-2048 localmente. Este paso se implementa utilizando la acción de GitHub docker-build-push.
  2. Ejecuta controles de seguridad de Snyk para la imagen del contenedor de la aplicación y el Dockerfile. Este paso se implementa utilizando el comando snyk container test. Los resultados del escaneo se exportan utilizando el formato GitHub SARIF. El umbral de nivel de seguridad se controla mediante el argumento –severity-threshold, que se establece en el parámetro de entrada snyk_fail_threshold si el flujo de trabajo se desencadena manualmente, o en la variable de entorno SNYK_FAIL_THRESHOLD si el flujo de trabajo se ejecuta automáticamente.
  3. Los resultados del escaneo (formato SARIF) se publican en la pestaña de seguridad de tu repositorio de aplicación. Este paso se implementa utilizando la acción de GitHub codeql.

A continuación, se muestra el fragmento principal de la tarea snyk-container-security-check: 

- name: Build App Image for Snyk container scanning
  uses: docker/build-push-action@v3
  with:
    context: ${{ env.PROJECT_DIR }}
    push: false
    tags: "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}"

- name: Check application container vulnerabilities
  run: |
    snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
      --file=Dockerfile \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-container-scan.sarif
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk report SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-container-scan.sarif
    category: snyk-container-scan

–file=Dockerfile \

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

–sarif –sarif-file-output=snyk-container-scan.sarif

Para solucionar los problemas informados, primero debes revisar la pestaña de seguridad de tu repositorio kubernetes-sample-apps bifurcado: 

FROM node:18.6.0-slim AS builder
WORKDIR /usr/src/app
COPY . .
RUN npm install --include=dev
Verás un montón de vulnerabilidades para la imagen de Docker base en este caso. Haz clic en cada una para expandir y ver más detalles: 
Para finalizar las investigaciones y ver las recomendaciones ofrecidas por Snyk, debes inspeccionar la salida de la tarea snyk-container-security-check del flujo de trabajo principal: 
Nota: La prueba de contenedor de Snyk ofrece la posibilidad de exportar resultados en formato SARIF, pero no sabe cómo cargar informes en el portal en la nube de Snyk. Por otro lado, el monitor de contenedor de Snyk ofrece la posibilidad de cargar resultados en el portal en la nube de Snyk, pero no puede exportar SARIF. Por lo tanto, esta guía está utilizando la prueba de contenedor de Snyk con la función de exportación SARIF. Desafortunadamente, algunas recomendaciones no están disponibles en la salida SARIF. Por lo tanto, también debes buscar en la salida de la consola de la tarea para obtener recomendaciones.
El resultado del trabajo snyk-container-security-check muestra que Snyk recomienda actualizar la versión de la imagen base de node:16-slim a node:18.6.0-slim. Este cambio elimina el(s) problema(s) de alto riesgo, y también reduce el número de otras vulnerabilidades reportadas de 70 a 44 - ¡esto es una reducción sustancial de casi 50% !!!
ENV NODE_ENV=development
RUN npm run build

FROM node:18.6.0-slim
RUN npm install http-server -g
RUN mkdir /public
WORKDIR /public
COPY --from=builder /usr/src/app/dist/ ./
EXPOSE 8080
USER 1000
CMD ["http-server"]

Ahora, abre el Dockerfile de la aplicación game-2048 desde tu fork, y cambia las directivas FROM para que apunten a la nueva versión (node:18.6.0-slim en el momento de escribir esto):

#

# El modo de compilación se puede establecer mediante la variable de entorno NODE_ENV (development o production)

# Consulta el package.json y webpack.config.js del proyecto

#

Finalmente, haz commit de los cambios a tu repositorio de GitHub y vuelve a activar el flujo de trabajo (dejando los valores predeterminados). Esta vez, el trabajo snyk-container-security-check debería pasar:

Al ir a la pestaña de seguridad de tu proyecto, no debería haber problemas reportados.

¿Cómo te aseguras de reducir las vulnerabilidades de la imagen base en el futuro?

  1. El mejor enfoque es utilizar una imagen base con un tamaño mínimo: cuanto menos binarios o dependencias tenga la imagen base, mejor. Otra buena práctica es monitorear continuamente tus proyectos, como se explica en la sección Monitorear tus Proyectos de manera Regular de esta guía.
  2. Notarás que el pipeline sigue fallando, pero esta vez en la fase snyk-iac-security-check. Esto es esperado porque hay problemas de seguridad con los manifiestos de Kubernetes utilizados para desplegar la aplicación. En la siguiente sección, aprenderás cómo investigar esta situación y aplicar las recomendaciones de seguridad de Snyk para solucionar los problemas reportados.

Investigación y Solución de Vulnerabilidades en los Manifiestos de Kubernetes

- name: Check for Kubernetes manifests vulnerabilities
  run: |
    snyk iac test \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-iac-scan.sarif \
      --report
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk IAC SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-iac-scan.sarif
    category: snyk-iac-scan

El pipeline sigue fallando y se detiene en el trabajo snyk-iac-security-check. Esto es esperado porque el valor predeterminado del nivel de severidad utilizado en la entrada del flujo de trabajo, que es medio, no cumple con los requisitos de seguridad del proyecto.

  1. El trabajo snyk-iac-security-check verifica las vulnerabilidades (o malconfiguraciones) en los manifiestos de Kubernetes y ejecuta los siguientes pasos:
  2. Snyk realiza controles de seguridad para los manifiestos de Kubernetes desde el directorio del proyecto game-2048-example. Este paso se implementa usando el comando snyk iac test. Los resultados del escaneo se exportan utilizando el formato GitHub SARIF. El umbral de nivel de seguridad se controla mediante el argumento –severity-threshold: se establece en el parámetro de entrada snyk_fail_threshold si el flujo de trabajo se activa manualmente, o en la variable de entorno SNYK_FAIL_THRESHOLD si el flujo de trabajo se ejecuta automáticamente. Finalmente, el argumento –report también se utiliza para enviar los resultados del escaneo al portal de la nube de Snyk.

Los resultados del escaneo (formato SARIF) se publican en la pestaña de seguridad del repositorio de su aplicación. Este paso se implementa utilizando la acción de GitHub codeql.

A continuación, se muestra el fragmento real de la implementación de cada paso del trabajo snyk-iac-security-check:

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: game-2048
spec:
  replicas: 1
  selector:
    matchLabels:
      app: game-2048
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: game-2048
    spec:
      containers:
        - name: backend
          --sarif --sarif-file-output=snyk-iac-scan.sarif \
          image: registry.digitalocean.com/sample-apps/2048-game:latest
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - all

Para solucionar los problemas reportados, tiene dos opciones:

  • Utilice el portal de la nube de Snyk y acceda al proyecto game-2048 para verificar los detalles:
  • Utilice la pestaña de seguridad de su repositorio de la aplicación del juego 2048 para verificar los detalles:
  • De todos modos, recibirá recomendaciones sobre cómo solucionar los problemas informados.
  • Para esta guía, utilizará el portal en la nube de Snyk para investigar los problemas de seguridad informados. Primero, haga clic en la entrada ejemplo-de-juego-2048 de la lista de proyectos, luego seleccione el archivo kustomize/resources/deployment.yaml:

A continuación, marque la casilla de verificación Media en el submenú Severidad a la izquierda para mostrar solo problemas de nivel medio:

Luego, puede inspeccionar cada tarjeta de problema informado y verificar los detalles. Adelante, haga clic en el botón Mostrar más detalles desde la tarjeta El contenedor se está ejecutando sin control de usuario raíz – recibirá más detalles sobre el problema actual e indicaciones importantes sobre cómo solucionarlo:

A few final checks can be performed as well on the Kubernetes side to verify if the reported issues were fixed:

  1. Después de recopilar toda la información de cada tarjeta, puede proceder a editar el archivo deployment.yaml de su repositorio (ubicado en la subcarpeta ejemplo-de-juego-2048/kustomize/resources). Las correcciones ya están implementadas, solo necesita descomentar las últimas líneas del archivo. El archivo deployment.yaml final debería verse así:
  2. readOnlyRootFilesystem – ejecuta la imagen del contenedor en solo lectura (no se pueden modificar archivos mediante kubectl exec en el contenedor).

allowPrivilegeEscalation – establecer allowPrivilegeEscalation en false asegura que ningún proceso hijo de un contenedor pueda obtener más privilegios que su padre.

capabilities.drop – Para hacer los contenedores más seguros, debes proporcionarles la menor cantidad de privilegios que necesiten para ejecutarse. En la práctica, eliminas todo por defecto y luego agregas las capacidades requeridas paso a paso. Puedes obtener más información sobre las capacidades de contenedor aquí.

Finalmente, confirma los cambios para el archivo deployment.yaml y haz push a la rama principal. Después de activar manualmente el flujo de trabajo, debería completarse correctamente esta vez:

También deberías recibir una notificación verde de Slack del trabajo de escaneo de snyk. Ve al enlace del portal de Snyk y verifica si los problemas que solucionaste recientemente han desaparecido; no debería haber problemas de nivel medio reportados.

Verifique si el despliegue del juego 2048 tiene un sistema de archivos de solo lectura (inmutable) escribiendo en el archivo index.html utilizado por la aplicación del juego 2048:

kubectl exec -it deployment/game-2048 -n game-2048 -- /bin/bash -c "echo > /public/index.html"

La salida se parece a:

Salida
/bin/bash: /public/index.html: sistema de archivos de solo lectura
comando terminado con código de salida 1

Verifique si el despliegue del juego 2048 tiene un sistema de archivos de solo lectura (inmutable) escribiendo en el archivo index.html utilizado por la aplicación del juego 2048:

La salida se parece a:

snyk-container-security-check:
    runs-on: ubuntu-latest
    needs: build-and-test-application

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      ...

      - name: Check application container vulnerabilities
        run: |
          snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile \
            --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
            --target-name=${{ env.PROJECT_NAME }} \
            --target-reference=${{ env.ENVIRONMENT }} \
            --sarif-file-output=snyk-container-scan.sarif
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Monitor the application container using Snyk
        run: |
          snyk container monitor "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      
      ...

Compruebe si el contenedor se ejecuta como un usuario no root (debería imprimir un número entero diferente de cero, por ejemplo, 1000):

kubectl exec -it deployment/game-2048 -n game-2048 -- id -u

Compruebe si el contenedor se ejecuta como un usuario no root (debería imprimir un número entero diferente de cero, por ejemplo, 1000):

Si todas las verificaciones pasan, entonces aplicaste las recomendaciones de seguridad requeridas con éxito.

build-and-test-application:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm test
        working-directory: ${{ env.PROJECT_DIR }}

      - name: Snyk code test and monitoring
        run: |
          snyk test ${{ env.PROJECT_DIR }}
          snyk monitor ${{ env.PROJECT_DIR }}
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Monitorea tus proyectos regularmente

La automatización del escaneo de vulnerabilidades que has implementado hasta ahora es un buen punto de partida pero no es perfecto. ¿Por qué?

Un problema con el enfoque actual es que nunca sabes cuándo se informan nuevos problemas para los activos que ya desplegaste en tus entornos. En otras palabras, evaluaste los riesgos de seguridad y tomaste las medidas para solucionar los problemas en un momento específico en el tiempo, cuando se ejecutó tu automatización de CI/CD.

Pero, ¿qué pasa si se reportan nuevos problemas mientras tanto y tu aplicación vuelve a ser vulnerable? Snyk te ayuda a superar esta situación a través de la función de monitoreo. La función de monitoreo de Snyk te ayuda a abordar nuevas vulnerabilidades, que se revelan constantemente. Cuando se combina con la integración de Snyk Slack (explicada en Paso 6 – Habilitar Notificaciones de Slack), puedes tomar acciones inmediatas para solucionar problemas recién revelados que pueden afectar tu aplicación en un entorno de producción.

Para beneficiarte de esta función, todo lo que tienes que hacer es usar el comando snyk monitor antes de cualquier paso de implementación en tu canalización de CI/CD. La sintaxis es muy similar a los comandos snyk test (una de las cosas geniales sobre la interfaz de línea de comandos de snyk es que fue diseñada con uniformidad en mente). El comando snyk monitor enviará una instantánea al portal en la nube de Snyk, y desde allí recibirás notificaciones sobre vulnerabilidades recién reveladas para tu proyecto.

A more efficient approach is where you integrate vulnerability scan tools directly in your favorite IDE (or Integrated Development Environment). This way, you can detect and fix security issues ahead of time in the software development cycle.

En términos de la automatización del flujo de trabajo de GitHub, puedes monitorear tu contenedor de aplicación en el trabajo de verificación de seguridad del contenedor de snyk, después de probar las vulnerabilidades. El siguiente fragmento muestra una implementación práctica para la canalización utilizada en esta guía (algunos pasos se omitieron por claridad):

  1. –file=${{ env.PROJECT_DIR }}/Dockerfile \
  2. –severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
  3. –target-name=${{ env.PROJECT_NAME }} \
  4. –target-reference=${{ env.ENVIRONMENT }} \

–sarif-file-output=snyk-container-scan.sarif

–file=${{ env.PROJECT_DIR }}/Dockerfile

El fragmento anterior muestra un paso adicional llamado Monitorizar el contenedor de la aplicación usando Snyk donde se ejecuta el monitor real del contenedor de Snyk.

Después de que se ejecute el comando de monitorización de Snyk, puedes iniciar sesión en la interfaz web de Snyk para ver la última instantánea e historial de tu proyecto:

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

Puedes probar y monitorizar también el código fuente de tu aplicación en el trabajo construir-y-probar-aplicacion. El fragmento siguiente muestra un ejemplo de implementación para el flujo de trabajo de GitHub utilizado en esta guía:

A continuación, recibirás notificaciones en Slack de manera regular sobre las vulnerabilidades recién reveladas para tu proyecto.

Manejo de Excepciones

Existen situaciones en las que no deseas que el informe final se vea afectado por algunos problemas que tu equipo considera seguros de ignorar. Snyk ofrece una característica integrada para gestionar excepciones y superar esta situación.

Puedes leer más sobre esta característica aquí.

Snyk para IDEs

Snyk ofrece soporte para una variedad de IDEs, como:

el complemento de Eclipse.

el complemento de JetBrains.

  • la extensión de Visual Studio.
  • la extensión de Visual Studio Code.
  • Los complementos mencionados anteriormente te ayudarán a detectar y corregir problemas en las primeras etapas de desarrollo, eliminando así la frustración, los costos y las fallas de seguridad en los sistemas de producción. Además, te ayuda a reducir las iteraciones y el esfuerzo humano a largo plazo. Como ejemplo, por cada problema de seguridad reportado por tu automatización de CI/CD, necesitas volver atrás y corregir el problema en tu código, hacer cambios, esperar la automatización de CI/CD nuevamente, y luego repetir en caso de falla.
  • Desde la documentación oficial, puedes leer más sobre estas características en la página Snyk para IDEs.
  • Paso 5 – Activación Automática del Flujo de Trabajo de Snyk CI/CD
  • Puedes configurar el flujo de trabajo para que se active automáticamente en cada confirmación o PR contra la rama principal descomentando las siguientes líneas en la parte superior del archivo game-2048-snyk.yaml:
  • Después de editar el archivo, confirma los cambios en tu rama principal y deberías estar listo para continuar.
  • Paso 6 – Habilitación de Notificaciones en Slack
  • Puedes configurar Snyk para enviar alertas en Slack sobre nuevas vulnerabilidades descubiertas en tus proyectos y sobre nuevas actualizaciones o parches que estén disponibles.
  • Para configurarlo, necesitarás generar un webhook en Slack. Puedes hacer esto a través de Incoming WebHooks o creando tu propia Aplicación de Slack. Una vez que hayas generado la URL de tu webhook en Slack, ve a la configuración de tu ‘Gestionar organización’, ingresa la URL y haz clic en el botón Conectar:

Source:
https://www.digitalocean.com/community/developer-center/using-the-snyk-vulnerability-scanning-tool