Examen de dependencias
El examen de dependencias en GitHub Advanced Security para Azure DevOps detecta los componentes de código abierto que se usan en el código fuente y detecta si hay alguna vulnerabilidad asociada. Las vulnerabilidades encontradas de componentes de código abierto se marcan como una alerta.
GitHub Advanced Security para Azure DevOps funciona con Azure Repos. Si quiere usar GitHub Advanced Security con repositorios de GitHub, vea GitHub Advanced Security.
Acerca del examen de dependencias
El examen de dependencias genera una alerta para cualquier componente de código abierto, directo o transitivo, que se encuentre vulnerable y del que dependa el código. Las vulnerabilidades directas son las bibliotecas que usa el código directamente. Las dependencias transitivas son las bibliotecas u otro software que dirigen el uso de dependencias.
Acerca de la detección del examen de dependencias
Una nueva instantánea de los componentes se almacena cada vez que el gráfico de dependencias de un repositorio cambia y, después, se ejecuta una canalización que contiene la tarea de examen de dependencias que crea código nuevo.
Para cada componente vulnerable detectado en uso, el componente y la vulnerabilidad se muestran en el registro de compilación y se muestran como una alerta en la pestaña Seguridad avanzada. Solo los avisos revisados por GitHub y agregados a la base de datos de asesoría de GitHub crean una alerta de examen de dependencias. El registro de compilación incluye un vínculo a la alerta individual para una investigación más detallada. Para obtener más información sobre los detalles de la alerta, consulte Corrección de alertas de examen de dependencias.
El registro de compilación también contiene información básica sobre cada vulnerabilidad detectada. Estos detalles incluyen la gravedad, el componente afectado, el título de la vulnerabilidad y el CVE asociado.
Ecosistemas de paquetes compatibles
El análisis de dependencias admite dependencias directas y transitivas para todos los ecosistemas de paquetes admitidos.
| Administrador de paquetes | Idiomas | Formatos compatibles |
|---|---|---|
| Cargo | Rust | Cargo.toml, Cargo.lock |
| CocoaPods | Swift | Podfile.lock |
| Módulos de Go | Go | go.mod, go.sum |
| Gradle | Java | *.lockfile |
| Maven | Java | pom.xml |
| npm | JavaScript | package-lock.json, package.json, npm-shrinkwrap.json, lerna.json |
| NuGet | C# | *.packages.config, *.project.assets, *.csproj |
| pip | Python | setup.py, requirements.txt |
| pnpm | JavaScript | package.json |
| RubyGems | Ruby | Gemfile.lock |
| Yarn | JavaScript | package.json |
Acerca de las alertas de examen de dependencias
La pestaña Seguridad avanzada de Repos en Azure DevOps es la ubicación central para ver las alertas de seguridad, que de forma predeterminada muestra las alertas de examen de dependencias. Puede filtrar por rama, canalización, paquete y gravedad. Puede seleccionar una alerta para obtener más detalles, incluida la guía de corrección. En este momento, el centro de alertas no muestra alertas para el examen completado en las ramas de PR.
Cuando se detecta un paquete vulnerable en el repositorio, la corrección de alertas de examen de dependencias normalmente implica actualizar a una versión de paquete superior o quitar el paquete que causa el problema. Este consejo es válido para las dependencias directas y transitivas (o indirectas). La vista predeterminada de la pestaña Seguridad avanzada muestra las alertas activas para la rama predeterminada del repositorio.
No hay ningún efecto en los resultados si se cambia el nombre de las canalizaciones o ramas; puede tardar hasta 24 horas antes de que se muestre el nuevo nombre.
El estado de una alerta se actualiza automáticamente a Closed cuando el componente vulnerable ya no se detecta en la compilación más reciente para las canalizaciones en las que se instala la tarea de examen de dependencias. Para ver las alertas resueltas, use el filtro State en la barra de herramientas principal y seleccione Closed.
Si desactiva la Seguridad avanzada para el repositorio, perderá el acceso a los resultados en la pestaña Seguridad avanzada y la tarea de compilación. No se producirá un error en la tarea de compilación, pero los resultados de las compilaciones que se han ejecutado con la tarea mientras la Seguridad avanzada está deshabilitada se ocultan y no se conservan.
Detalles de alertas
También puede profundizar en los detalles de una alerta si hace clic en una alerta específica y en una guía de corrección.
| Sección | Explicación |
|---|---|
| Recomendación | El texto de la recomendación procede directamente de nuestro proveedor de datos de vulnerabilidades, la base de datos de asesoría de GitHub. Normalmente, las instrucciones sugieren actualizar el componente identificado a una versión que no sea vulnerable. |
| Location | En la sección Ubicaciones se detallan las rutas en las que la tarea de examen de dependencias ha detectado el componente vulnerable en uso. Si el archivo se puede resolver desde el examen de compilación subyacente a un archivo confirmado en el origen, la tarjeta Ubicaciones aparece como un vínculo en el que se puede hacer clic. Si se generó un archivo como parte de una compilación (por ejemplo, un artefacto de compilación), no se puede hacer clic en el vínculo. Revise los registros de compilación para comprender mejor cómo se ha incorporado el componente a la compilación. |
| Descripción | La descripción la proporciona la asesoría de GitHub. |
Detecciones
Las canalizaciones que aparecen en la pestaña Detecciones son las canalizaciones donde se encontró el componente vulnerable. Cada fila detalla la compilación más reciente de la canalización afectada y la fecha en que se introdujo por primera vez el paquete. Si el paquete vulnerable se ha corregido en algunas canalizaciones, pero no en todas, verá filas parcialmente corregidas.
Una vez resuelta una alerta, la alerta pasa automáticamente al estado Closed y la canalización de ejecución más reciente en la pestaña Detecciones muestra una marca de verificación verde, lo que significa que el código que contiene el componente actualizado se ejecutó en esa canalización:
severity
La base de datos de asesoría de GitHub proporciona una puntuación de CVSS, que luego se traduce en una gravedad baja, media, alta o crítica para una alerta mediante las siguientes directrices:
| Puntuación de CVSS | severity |
|---|---|
| 1.0 < Puntuación < 4.0 | Bajo |
| 4.0 < Puntuación < 7.0 | Media |
| 7.0 < Puntuación < 9.0 | Alto |
| Puntuación > = 9.0 | Crítico |
Búsqueda de detalles
Normalmente se encuentran dos secciones en Búsqueda de detalles: paquete vulnerable y dependencia raíz. El paquete vulnerable es el componente potencialmente vulnerable. La sección de dependencia raíz contiene componentes de nivel superior que son responsables de la cadena de dependencias que da lugar a una vulnerabilidad.
Si solo se hace referencia al paquete vulnerable como una dependencia directa, solo verá la sección "Paquete vulnerable".
Si se hace referencia al paquete vulnerable como una dependencia directa y transitiva, el paquete se muestra tanto en la sección "paquete vulnerable" como en la sección "dependencia raíz".
Si solo se hace referencia al paquete vulnerable como una dependencia transitiva, el paquete se muestra en la sección "paquete vulnerable" y las dependencias raíz que hacen referencia al paquete vulnerable se muestran en la sección "dependencia raíz".
Administración de alertas de examen de dependencias
Visualizar las alertas para un repositorio
Cualquier usuario con permisos de colaborador para un repositorio puede ver un resumen de todas las alertas de un repositorio en Repositorios>Seguridad avanzada.
De forma predeterminada, la página de alertas muestra los resultados del examen de dependencias de la rama predeterminada del repositorio.
El estado de una alerta refleja el estado de la rama predeterminada y la canalización de ejecución más reciente, incluso si la alerta existe en otras ramas y canalizaciones.
Corrección de alertas de examen de dependencias
Una dependencia directa es un componente que se encuentra en el repositorio. Una dependencia transitiva o indirecta es un componente al que usa una dependencia directa. El proyecto sigue siendo vulnerable independientemente de si la vulnerabilidad se encuentra en una dependencia directa o transitiva.
La corrección de una dependencia transitiva vulnerable suele implicar invalidar explícitamente la versión del componente vulnerable que se usa para cada dependencia directa identificada. Una vez que las dependencias raíz han actualizado su uso del componente vulnerable a una versión segura, puede actualizar cada dependencia raíz en lugar de varias invalidaciones individuales.
Actualización de dependencias para Yarn/Npm
Hipotéticamente, supongamos que este paquete tiene dos vulnerabilidades. Una es para axios, una dependencia directa y otra para acorn, una dependencia transitiva (también conocida como dependencia indirecta o dependencia de dependencia).
{
"name": "my-package",
"version": "1.0.0",
"dependencies": {
"axios": "0.18.0",
"eslint": "5.16.0",
}
}
La versión actual de axios tiene una vulnerabilidad de ataque por denegación de servicio (DoS) con una recomendación para actualizar a la versión 0.18.1 o a una más reciente. Dado que es una dependencia directa, tiene control sobre la versión de axios que usa; todo lo que debe hacer es actualizar la versión de axios que usted incorpora. La actualización package.json tiene un aspecto similar al siguiente:
{
"name": "my-package",
"version": "1.0.0",
"dependencies": {
"axios": "0.19.2",
"eslint": "5.16.0",
}
}
Ahora, la versión de eslint en la actualización package.json que se muestra depende de una versión de acorn que es una expresión regular de una vulnerabilidad de denegación de servicio (ReDoS) con una recomendación para actualizar a la versión 5.7.4, 6.4.1, 7.1.1 o superior. Si recibe una alerta de la herramienta de examen de dependencias, debe indicarle la dependencia raíz que requiere la dependencia vulnerable.
Yarn
Si usa Yarn, puede usar "yarn why" para encontrar la cadena de dependencias completa.
> $ yarn why acorn
yarn why v1.22.4
[1/4] Why do we have the module "acorn"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "acorn@6.4.0"
info Reasons this module exists
- "eslint#espree" depends on it
- Hoisted from "eslint#espree#acorn"
info Disk size without dependencies: "1.09MB"
info Disk size with unique dependencies: "1.09MB"
info Disk size with transitive dependencies: "1.09MB"
info Number of shared dependencies: 0
Done in 0.30s.
La cadena de dependencias completa es eslint>espree>acorn. Una vez que conozca la cadena de dependencias, puede usar otra característica de Yarn, las resoluciones de dependencia selectivas, para invalidar la versión de acorn que se usa.
Use el campo de resoluciones de package.json para definir una invalidación de versión. Se muestran tres métodos diferentes para invalidar un paquete, en orden de peor a mejor:
{
"name": "yarn-resolutions",
"version": "1.0.0",
"license": "MIT",
"dependencies": {
"axios": "0.19.2",
"eslint": "5.16.0"
},
"resolutions": {
// DO NOT USE!
"**/acorn": "6.4.1",
// BETTER
"eslint/**/acorn": "6.4.1",
// BEST
"eslint/espree/acorn": "6.4.1"
}
}
El uso del patrón **/acorn invalida todos los usos del paquete acorn en todas las dependencias. Es peligroso y se interrumpe en tiempo de ejecución. Como resultado, se ha quitado en Yarn v2.
El uso del patrón eslint/**/acorn invalida todos los usos del paquete acorn en el paquete eslint y, en los paquetes de los que depende. Es más seguro que invalidar el paquete para todas las dependencias, pero sigue teniendo algunos riesgos si el gráfico de dependencias de un paquete es grande. Este patrón se recomienda cuando hay muchos subpaquetes que usan un paquete vulnerable y la definición de invalidaciones para subpaquetes individuales sería algo poco práctico.
El uso del patrón eslint/espree/acorn invalida solo el uso de acorn en el paquete espree del paquete eslint. Tiene como destino específicamente la cadena de dependencias vulnerable y es la manera recomendada de invalidar las versiones del paquete.
npm
Si usa npm 8.3 o superior, puede usar el campo overrides en package.json
Agregue una invalidación si necesita realizar cambios específicos en las dependencias transitivas. Por ejemplo, puede que tenga que agregar una invalidación para reemplazar la versión de una dependencia con un problema de seguridad conocido, reemplazar una dependencia existente por una bifurcación o asegurarse de que la misma versión de un paquete se usa en todas partes.
{
"name": "npm-overrides",
"version": "1.0.0",
"license": "MIT",
"dependencies": {
"axios": "0.19.2",
"eslint": "5.16.0"
},
"overrides":{
"eslint": {
"espree": {
"acorn": "6.4.1"
}
}
}
}
En el ejemplo de invalidación se muestra la manera que npm tiene de decir "invalidar solo el uso de acorn en el paquete espree en el paquete eslint". Tiene como destino específicamente la cadena de dependencias vulnerable y es la manera recomendada de invalidar las versiones del paquete. Las invalidaciones son una característica nativa de npm. Proporciona una manera de reemplazar un paquete en el árbol de dependencias por otra versión u otro paquete por completo.
Después de establecer las invalidaciones, debe eliminar package-lock.json y node_modules volver a ejecutar npm install.
No es posible establecer una invalidación para un paquete del que dependa directamente, a menos que la dependencia y la propia invalidación compartan exactamente la misma especificación. Por ejemplo, supongamos que axios: "0.18.0" es vulnerable y buscamos actualizar a axios: "0.19.2". Cambie directamente la versión de dependencia en lugar de usar la invalidación.
{
"name": "npm-overrides",
"version": "1.0.0",
"license": "MIT",
"dependencies": {
"axios": "0.18.0"
},
"overrides": {
// BAD, will throw an EOVERRIDE error
// "axios": "0.19.2",
}
}
Actualice la versión de la dependencia sin establecer una invalidación:
{
"name": "npm-overrides",
"version": "1.0.0",
"license": "MIT",
"dependencies": {
"axios": "0.19.2"
}
}
Actualización de dependencias para Maven
El mecanismo de resolución de dependencias no es tan sofisticado como el que se usa en Yarn. Como resultado, solo puede tener una sola versión de una dependencia en un proyecto. Para resolver este problema, Maven usa un algoritmo de "coincidencias próximas". Es decir, usa la versión de la dependencia más cercana al proyecto en el árbol de dependencias.
Por ejemplo, tiene el siguiente gráfico de dependencias:
your-project --- A:1.0.0 --- B:2.0.0
\
\__ B:1.0.0
your-project depende de A:1.0.0, que a su vez depende de B:2.0.0, pero el proyecto también tiene una dependencia directa de B:1.0.0. Por lo tanto, tiene dos versiones diferentes de la dependencia B en el gráfico de dependencias, pero la versión 1.0.0 de la dependencia B gana, ya que es la "más próxima" al proyecto.
En algunos casos, este escenario podría funcionar si las versiones son compatibles. Sin embargo, si A:1.0.0 depende de alguna característica de B que solo esté disponible en la versión 2.0.0, este comportamiento no funciona. En el peor de los casos, este proyecto puede que siga compilándose, pero se produce un error en tiempo de ejecución.
Echemos un vistazo a un ejemplo real.
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.microsoft.customer360</groupId>
<artifactId>maven-dependencies</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>maven-dependencies</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>com.fasterxml.jackson.jaxrs</groupId>
<artifactId>jackson-jaxrs-json-provider</artifactId>
<version>2.10.3</version>
</dependency>
</project>
Supongamos que la versión de com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider de la que usted depende, depende a su vez de una versión de com.fasterxml.jackson.core:jackson-databind que tiene una vulnerabilidad de deserialización de datos que no son de confianza.
Puede comprobar esta dependencia mediante el complemento de dependencia de Maven. En este caso, ejecutaría mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind y obtendrá la siguiente salida:
> $ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
[INFO] Scanning for projects...
[INFO]
[INFO] ------------< com.microsoft.customer360:maven-dependencies >------------
[INFO] Building maven-dependencies 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-dependencies ---
[INFO] com.microsoft.customer360:maven-dependencies:jar:1.0-SNAPSHOT
[INFO] \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.10.3:compile
[INFO] \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.10.3:compile
[INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.10.3:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.928 s
[INFO] Finished at: 2020-04-27T14:30:55+02:00
[INFO] ------------------------------------------------------------------------
En primer lugar, compruebe si hay una nueva versión de com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider que no depende de una versión vulnerable de com.fasterxml.jackson.core:jackson-databind. Si es así, puede actualizar com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider y eso sería suficiente. Si no es así, invalide la versión de com.fasterxml.jackson.core:jackson-databind.
Como se muestra en el fragmento de código, Maven usa el algoritmo de "coincidencias próximas", por lo que la resolución es agregar una dependencia directa a com.fasterxml.jackson.core:jackson-databind que corrija la vulnerabilidad.
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.microsoft.customer360</groupId>
<artifactId>maven-dependencies</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>maven-dependencies</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>com.fasterxml.jackson.jaxrs</groupId>
<artifactId>jackson-jaxrs-json-provider</artifactId>
<version>2.10.3</version>
</dependency>
<!-- Dependency resolutions -->
<!-- jackson-jaxrs-json-provider -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.9.10.4</version>
</dependency>
</dependencies>
</project>
Para comprobar que la resolución funciona, vuelva a ejecutar mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind.
$ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
[INFO] Scanning for projects...
[INFO]
[INFO] ------------< com.microsoft.customer360:maven-dependencies >------------
[INFO] Building maven-dependencies 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-dependencies ---
[INFO] com.microsoft.customer360:maven-dependencies:jar:1.0-SNAPSHOT
[INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.9.10.4:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.827 s
[INFO] Finished at: 2020-04-27T14:32:42+02:00
[INFO] ------------------------------------------------------------------------
Se recomienda agregar un comentario cerca de la resolución de dependencias para que cualquier persona que venga más adelante sepa por qué la dependencia está ahí. Se puede quitar una vez que la dependencia raíz usa la nueva versión; de lo contrario, se acumulan dependencias.
En un proyecto real, agregue la dependencia lo más alta posible en la cadena. Por ejemplo, podría agregar la resolución en el archivo POM primario, en lugar de individualmente en cada archivo POM del proyecto.
Actualización de dependencias para NuGet
El algoritmo de resolución de dependencias que se usa en NuGet es similar a Maven, en el sentido de que solo se puede usar una única versión de una dependencia. Sin embargo, NuGet no ancla las versiones de dependencia.
Por ejemplo, si tiene una dependencia <PackageReference Include="A" Version="1.2.3" />, podría esperar que este paquete sea equivalente a = 1.2.3, pero realmente significa >= 1.2.3. Para anclar una versión exacta, debe usar Version="[1.2.3]". Para obtener más información, consulte la documentación de intervalos de versiones de NuGet.
Además del comportamiento de intervalo predeterminado, NuGet restaura la versión aplicable más baja para satisfacer un intervalo. Este comportamiento significa que, en muchos casos, tiene que definir un intervalo.
Echemos un vistazo a este proyecto de ejemplo, que tiene una dependencia de Microsoft.AspNetCore.App:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<RootNamespace>NuGet.Dependencies</RootNamespace>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.14" />
</ItemGroup>
</Project>
Depende de una versión de Microsoft.AspNetCore.Http.Connections que es vulnerable a una vulnerabilidad de ejecución remota de código (RCE).
En primer lugar, debe comprobar si hay una versión actualizada de Microsoft.AspNetCore.App que depende de una versión más reciente de Microsoft.AspNetCore.Http.Connections. Si es así, puede actualizar Microsoft.AspNetCore.App y eso sería suficiente. Si no es así, debe invalidar la versión de Microsoft.AspNetCore.Http.Connections de la que depende.
NuGet no tiene un equivalente integrado de yarn why o mvn dependency:tree, por lo que la manera más fácil de ver el árbol de dependencias suele ser visitar nuget.org. Si visita la página NuGet para Microsoft.AspNetCore.App, verá que depende de Microsoft.AspNetCore.Http.Connectionsversion >= 1.0.4 && < 1.1.0. O bien, en un intervalo de versiones de NuGet, la sintaxis representativa es [1.0.4,1.1.0).
La vulnerabilidad de RCE en Microsoft.AspNetCore.Http.Connections se corrigió en la versión 1.0.15, por lo que debe invalidar el intervalo de versiones para que sea [1.0.15, 1.1.0).
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<RootNamespace>NuGet.Dependencies</RootNamespace>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.8" />
</ItemGroup>
<ItemGroup Label="Dependency Resolutions">
<!-- Microsoft.AspNetCore.App -->
<PackageReference Include="Microsoft.AspNetCore.Http.Connections" Version="[1.0.15,1.1.0)" />
</ItemGroup>
</Project>
Se recomienda agregar un comentario cerca de la resolución de dependencias para que cualquier persona que venga más adelante sepa por qué la dependencia está ahí. Se puede quitar una vez que la dependencia raíz use la nueva versión. De lo contrario, se acumulan dependencias.
¿Qué ocurre si no hay ninguna corrección disponible?
Cuando no hay ninguna corrección conocida disponible, las siguientes opciones están disponibles como otros métodos de corrección hasta que haya disponible un componente actualizado:
- Dejar de usar el componente y quítelo del código: esta eliminación se detectará en la siguiente compilación con la tarea de examen de dependencias instalada
- Contribuya con una corrección al propio componente. Si su organización tiene directrices específicas sobre las contribuciones de código abierto, siga esas directrices.
- Descartar la alerta. Sin embargo, las alertas sin ninguna corrección conocida siguen pudiendo suponer una amenaza de seguridad para su organización. Se recomienda no descartar una alerta solo porque no hay ninguna corrección conocida.
Descarte de alertas de examen de dependencias
Para descartar alertas en Advanced Security, necesita los permisos adecuados. De forma predeterminada, solo se proporciona a los administradores de proyectos con la capacidad de descartar alertas de seguridad avanzada.
Para descartar una alerta:
- Vaya a la alerta que quiera cerrar y selecciónela
- Seleccione el menú desplegable Cerrar alerta
- Si aún no está seleccionado, seleccione Riesgo aceptado o Falso positivo como motivo del cierre
- Agregue un comentario opcional en el cuadro de texto Comentario
- Seleccione Cerrar para enviar y cerrar la alerta
- El estado de la alerta cambia de Abierto a Cerrado y muestra el motivo del cierre
Esta acción solo descarta la alerta de la rama seleccionada. Otras ramas que pueden contener la misma vulnerabilidad permanecen activas hasta que se actúe en ellas. Cualquier alerta que se haya cerrado anteriormente se puede volver a abrir de forma manual.
Solución de problemas de examen de dependencias
Análisis de dependencias sin identificar ningún componente
Si la tarea de análisis de dependencias se está completando sin marcar ningún componente y sin generar alertas de componentes con vulnerabilidades conocidas, asegúrese de incluir un paso de restauración de paquetes antes de la tarea AdvancedSecurity-Dependency-Scanning@1.
Tiempo de espera de la tarea de examen de dependencias
La hora predeterminada en la que se ejecuta la tarea de análisis de dependencias antes de que se agote el tiempo de espera es de 300 segundos (5 minutos). Si la tarea agota el tiempo de espera antes de la finalización, puede establecer una variable de canalización DependencyScanning.Timeout, que espera un entero que represente segundos, como DependencyScanning.Timeout: 600. Todo lo que esté bajo el tiempo de espera predeterminado de 300 segundos no tiene ningún efecto.
Para usar esta variable, agregue DependencyScanning.Timeout como una variable de canalización:
- task: AdvancedSecurity-Dependency-Scanning@1
- env:
DependencyScanning.Timeout: 600
Escenario de emergencia para la tarea de compilación
Si la tarea de compilación de examen de dependencias bloquea una ejecución correcta de la canalización y usted necesita omitir urgentemente la tarea de compilación, puede establecer una variable de canalización DependencyScanning.Skip: true.
Permisos de tarea de examen de dependencias
La tarea de compilación de análisis de dependencias usa la identidad de canalización para llamar a las API de REST de Advanced Security. De forma predeterminada, las canalizaciones del mismo proyecto tienen acceso para capturar alertas. Si quita esos permisos de la cuenta de servicio de compilación o si tiene una configuración personalizada (por ejemplo, una canalización hospedada en un proyecto diferente al repositorio), debe conceder estos permisos manualmente.
Conceda el permiso Advanced Security: View Alerts a la cuenta de servicio de compilación que se usa en la canalización, que para las canalizaciones con ámbito de proyecto, es [Project Name] Build Service ([Organization Name])y, para las canalizaciones con ámbito de recopilación, es Project Collection Build Service ([Organization Name]).
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de