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:
- El gráfico de dependencias está habilitado para el repositorio. El gráfico de dependencias está habilitado de forma predeterminada para repositorios públicos y puede optar por habilitarlo para repositorios privados. Para obtener más información, vea "Configuración del gráfico de dependencias".
- Se ha habilitado GitHub Actions para el repositorio. Para obtener más información, consulta "Administrar los ajustes de las GitHub Actions de un repositorio".
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.
-
En GitHub, navegue hasta la página principal del repositorio.
-
En el nombre del repositorio, haz clic en Acciones.
-
En "Introducción a GitHub Actions", busque la categoría "Seguridad" y haga clic en Ver todo.
-
Busque "Revisión de dependencias" y haga clic en Configurar. Como alternativa, busque "Revisión de dependencias" mediante la barra de búsqueda.
-
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
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
.
-
Agregue la opción
fail-on-severity
al final del archivodependency-review.yml
:YAML - name: 'Dependency Review' uses: actions/dependency-review-action@v4 with: fail-on-severity: moderate
- 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.
-
Agregue la opción
deny-licenses
al final del archivodependency-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
- 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.
-
Agregue la opción
fail-on-scopes
al final del archivodependency-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
- 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:
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
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.