Security mantiene un inventario de cada paquete que instala cada proyecto y lo compara con las advertencias publicadas, de modo que se detecta una versión vulnerable cuando llega a un pull request, y nuevamente cuando una nueva advertencia nombra una versión que ya se ejecuta.
El inventario
En cada nueva cabecera de la rama predeterminada, y al menos una vez al día, Coroid lee los archivos de bloqueo del proyecto con OSV-Scanner, vinculado a una versión específica y verificado contra su suma de comprobación publicada. El escáner solo recibe los archivos de dependencias, una configuración que genera Coroid, y no tiene acceso a la red ni credenciales. Un osv-scanner.toml propio del repositorio no tiene efecto.
Seguridad → Dependencias muestra el inventario de cada proyecto: los paquetes y sus versiones instaladas, qué manifiesto declara cada uno, cuáles son vulnerables, la cobertura de cada archivo y cuándo se leyeron por última vez los datos de las advertencias. Exportar CycloneDX descarga el inventario como un archivo CycloneDX 1.5. Solo enumera las vulnerabilidades para los hallazgos que ya son públicos. Ver Divulgación.
Qué lee Coroid por completo
La cobertura es por archivo de bloqueo, no por repositorio. En un monorepositorio, cada archivo de bloqueo forma su propio grupo con su propia cobertura, de modo que los resultados de un archivo de bloqueo completo son válidos incluso cuando otro manifiesto está incompleto.
| Archivo | Ecosistema | Versiones exactas | Dependencias transitivas completas | Cobertura |
|---|---|---|---|---|
package-lock.json | npm | Sí | Sí | Completo |
npm-shrinkwrap.json | npm | Sí | Sí | Completo |
pnpm-lock.yaml | npm | Sí | Sí | Completo |
yarn.lock | npm | Sí | Sí | Completo |
requirements.txt | PyPI | Sí | No | Parcial |
go.mod | Go | Sí | No | Parcial |
Esta tabla se genera a partir de los fixtures de las pruebas propias de Coroid ejecutadas mediante el escáner, por lo que solo cambia cuando lo hacen las pruebas.
- Espacios de trabajo de npm, pnpm y Yarn: un
package.jsonsin su propio archivo de bloqueo queda cubierto por el archivo de bloqueo raíz. Unpackage.jsonque ya no coincida con su archivo de bloqueo será parcial hasta que se regenere el archivo de bloqueo. - Archivos de bloqueo de npm deben ser de versión 2 o 3. Las entradas de pnpm y Yarn que provienen de git, un archivo local o un parche son parciales.
requirements.txtcubre solo las versiones vinculadas con==.- Otros archivos de dependencias (
package.jsonsin archivo de bloqueo,pyproject.toml,poetry.lock,Pipfile,Cargo.lock,Gemfile.lock,pom.xml, Gradle, Composer, NuGet y otros) se detectan y muestran como parciales, indicando el archivo, de modo que un proyecto nunca se considere cubierto cuando no lo esté.
Advertencias
Coroid lee las advertencias de OSV, que también incluye las advertencias de GitHub, para cada ecosistema que usen sus proyectos. Cada hora lee lo nuevo o modificado desde la última lectura, y una vez al día lee todo. La comparación utiliza los inventarios almacenados, por lo que no necesita acceso a su repositorio.
El objetivo de Coroid es hacer coincidir el 95 % de las nuevas advertencias con cada inventario en menos de 60 minutos después de que aparezcan en los datos de advertencias que lee, y mide cuánto tiempo tardó cada coincidencia. No puede prometer un tiempo desde la divulgación original de una vulnerabilidad: eso depende de cuándo se publique una advertencia.
Si los datos de las advertencias tienen más de 90 minutos de retraso, o si la última lectura falló, Resumen y Dependencias mostrarán "Fuente de advertencias retrasada desde…", y la cobertura de ningún proyecto se considerará completa mientras dure.
Cuando se retira una advertencia, Coroid recalcula qué sigue aplicándose de las advertencias restantes para la misma vulnerabilidad. Un hallazgo se cierra como "Ya no aplica" solo cuando ninguna lo hace, nunca como solucionado.
En las solicitudes de extracción
La comprobación Coroid Security analiza los archivos de bloqueo que modifica pull request, tanto en su base como en su cabecera, y cuenta solo las versiones vulnerables que introduce el cambio:
- Observar: la comprobación aprueba o informa de forma neutra indicando lo que encontró.
- Aplicar: Un cambio que introduzca una versión con vulnerabilidades conocidas de gravedad igual o superior al nivel seleccionado (por defecto, alta) hará que la comprobación falle. También fallará si la cobertura parcial del archivo lockfile que se ve afectado por el cambio no es suficiente; en estos casos se indicará el motivo y cómo volver a ejecutar la comprobación.
La misma comprobación se ejecuta en las solicitudes de extracción de correcciones y funcionalidades propias de Coroid antes de que se abran. Para saber cómo se comporta esta comprobación, cómo exigir su cumplimiento y cómo volver a ejecutarla, consulte Permisos de GitHub y la comprobación de Seguridad de Coroid.
Notificaciones
El primer inventario completo de un repositorio constituye una línea base silenciosa: sus resultados aparecen en la sección de Seguridad y no se envía ninguna notificación. Después de eso, cualquier hallazgo de dependencia crítica notificará una vez a los propietarios y administradores de la organización mediante el sistema de notificaciones, por correo electrónico si está habilitado, y en Slack si está conectado. En el caso de una advertencia pública, el sistema de notificaciones indicará el nombre del paquete y la advertencia; para los casos que aún no sean públicos, solo se informará que existe un hallazgo crítico que requiere atención. Consulte Divulgación.