Skip to main content

Esta versión de GitHub Enterprise Server se discontinuó el 2024-09-25. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener rendimiento mejorado, seguridad mejorada y nuevas características, actualice a la versión más reciente de GitHub Enterprise Server. Para obtener ayuda con la actualización, póngase en contacto con el soporte técnico de GitHub Enterprise.

Personalización de la configuración de la acción de revisión de dependencias

Aprenda a agregar una personalización básica a la configuración de revisión de dependencias.

¿Quién puede utilizar esta característica?

Propietarios de repositorios, propietarios de organizaciones, administradores de seguridad y usuarios con el rol de administrador

Introducción

La Acción de revisión de dependencias examina las solicitudes de incorporación de cambios de dependencia y genera un error si las nuevas dependencias tienen vulnerabilidades conocidas. Una vez instalado, si la ejecución del flujo de trabajo está marcada como necesaria, las solicitudes de incorporación de cambios que introducen paquetes vulnerables conocidos se bloquearán de la combinación.

En esta guía se muestra cómo agregar tres personalizaciones muy comunes: compilaciones con errores en función del nivel de gravedad de vulnerabilidad, la licencia de dependencia y el ámbito.

Requisitos previos

En esta guía se da por supuesto que:

Paso 1: Agregar la acción de revisión de dependencias

En este paso, agregaremos el flujo de trabajo de revisión de dependencias al repositorio.

  1. En GitHub, navegue hasta la página principal del repositorio.

  2. En el nombre del repositorio, haz clic en Acciones.

    Captura de pantalla de las pestañas del repositorio "github/docs". La pestaña "Proyectos" aparece resaltada con un contorno naranja.

  3. En "Introducción a GitHub Actions", busque la categoría "Seguridad" y haga clic en Ver todo.

  4. Busque "Revisión de dependencias" y haga clic en Configurar. Como alternativa, busque "Revisión de dependencias" mediante la barra de búsqueda.

  5. Se abrirá el archivo de flujo de trabajo GitHub Actions de la revisión de dependencias, dependency-review.yml. Debe contener lo siguiente:

    YAML
    name: 'Dependency review'
    on:
      pull_request:
        branches: [ "main" ]
    
    permissions:
      contents: read
    
    jobs:
      dependency-review:
        runs-on: ubuntu-latest
        steps:
          - name: 'Checkout repository'
            uses: actions/checkout@v4
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
    

Paso 2: Cambiar la gravedad

Puede bloquear el código que contiene dependencias vulnerables para que no se combinen estableciendo Acción de revisión de dependencias en obligatorio. Sin embargo, vale la pena tener en cuenta que el bloqueo de vulnerabilidades de bajo riesgo puede ser demasiado restrictivo en algunas circunstancias. En este paso, cambiaremos la gravedad de la vulnerabilidad que hará que se produzca un error en una compilación con la opción fail-on-severity.

  1. Agregue la opción fail-on-severity al final del archivo dependency-review.yml:

    YAML
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
            with:
              fail-on-severity: moderate
    

Paso 3: Agregar licencias para bloquear

Las vulnerabilidades no son la única razón por la que es posible que quiera bloquear una dependencia. Si su organización tiene restricciones sobre el tipo de licencias que puede usar, puede usar la revisión de dependencias para aplicar esas directivas con la opción deny-licenses. En este paso, agregaremos una personalización que interrumpirá la compilación si la solicitud de incorporación de cambios introduce una dependencia que contiene la licencia LGPL-2.0 o BSD-2-Clause.

  1. Agregue la opción deny-licenses al final del archivo dependency-review.yml:

    YAML
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
            with:
              fail-on-severity: moderate
              deny-licenses: LGPL-2.0, BSD-2-Clause
    

Paso 4: Agregar ámbitos

Por último, usaremos la opción fail-on-scopes para evitar la combinación de dependencias vulnerables a entornos de implementación específicos, en este caso el entorno de desarrollo.

  1. Agregue la opción fail-on-scopes al final del archivo dependency-review.yml:

    YAML
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
            with:
              fail-on-severity: moderate
              deny-licenses: LGPL-2.0, BSD-2-Clause
              fail-on-scopes: development
    

Paso 5: Comprobación de la configuración

El archivo dependency-review.yml ahora debería presentar un aspecto similar a este:

YAML

name: 'Dependency Review'
on: [pull_request]


permissions:
  contents: read


jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout Repository'
        uses: actions/checkout@v4
      - name: Dependency Review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate
          deny-licenses: LGPL-2.0, BSD-2-Clause
          fail-on-scopes: development

Puede usar esta configuración como plantilla para sus propias configuraciones personalizadas.

Para obtener más información sobre todas las opciones de personalización posibles, consulte el archivo LÉAME en la documentación de la acción de revisión de dependencias.

procedimientos recomendados

Al personalizar la configuración de revisión de dependencias, hay algunos procedimientos recomendados que puede seguir:

  • Elija listas de bloqueados antes que listas permitidas. Es más práctico compilar una lista de las dependencias "realmente incorrectas" que desea bloquear que crear una lista inclusiva de todas las bibliotecas que desea permitir.

  • Elija bloquear licencias en lugar de especificar qué licencias se van a permitir. Hay una amplia variedad de licencias, por lo que suele ser más práctico excluir los que sabe que son incompatibles con las licencias actuales que compilar una lista completa de licencias compatibles.

  • Elija fail-on-severity. El error en función de la gravedad de una vulnerabilidad es una buena manera de equilibrar la necesidad de seguridad con la necesidad de crear experiencias de baja fricción para los desarrolladores.

Información adicional