Avisos de dependencias plantea una pregunta estrecha y comprobable: ¿las versiones de dependencias a las que este repositorio realmente resuelve aparecen en algún aviso de seguridad publicado?
Aporta el 20% de la categoría Seguridad, junto a la postura de seguridad con el 80%.
El peso es deliberadamente modesto. La calibración sobre dieciséis paquetes de uso extendido encontró quince sin ningún aviso conocido: los proyectos bien mantenidos realmente no distribuyen dependencias vulnerables, así que un resultado limpio aquí es la norma, no una distinción.
Qué se mide: lo que instala un consumidor
Para un repositorio que publica un paquete, el conjunto evaluado es el cierre de dependencias en tiempo de ejecución de ese paquete —cada paquete que una instalación arrastra realmente, directo y transitivo— resuelto desde el índice abierto deps.dev. El informe nombra el paquete y la versión exactos evaluados.
Solo cuando un repositorio no publica nada la inspección recurre al grafo de dependencias propio del repositorio. Ese grafo es otra cosa: contiene además fijaciones de desarrollo y prueba que ningún instalador descarga. Los informes en ese ámbito lo indican.
La distinción no es académica. El grafo de Flask contiene versiones antiguas de Werkzeug y Jinja que el proyecto fija deliberadamente para probar; llevan avisos, y ninguna llega a quien instala Flask. El cierre publicado son seis paquetes, ninguno afectado.
Los cierres se resuelven hoy para paquetes de npm, PyPI, crates.io y Maven. Los repositorios que publican en Go, NuGet, RubyGems, Packagist o Hex se evalúan contra su grafo de repositorio hasta que el índice los cubra: es un límite de la fuente de datos, no un juicio sobre esos ecosistemas.
De dónde salen los datos
Cada inspección lee el conjunto resuelto de dependencias del repositorio —las directas más el cierre transitivo bajo ellas— del grafo de dependencias que la plataforma de alojamiento ya calcula a partir de los manifiestos y archivos de bloqueo confirmados.
Ese conjunto se coteja con OSV, la base abierta de avisos mantenida por la Open Source Security Foundation, que agrega los GitHub Security Advisories, PYSEC, RUSTSEC, la base de vulnerabilidades de Go y otras bajo un único esquema. OSV es gratuita, pública y versionada: las mismas propiedades que hacen del Scorecard una base defendible para la postura de seguridad.
La misma consulta devuelve también los paquetes reportados como maliciosos. No son vulnerabilidades y no se cuentan aquí: no llevan gravedad ni versión corregida, y se reportan y se puntúan por separado como dependencias maliciosas. Un paquete que aparece allí no aparece además en los recuentos de esta página.
Qué se informa
Para cada paquete afectado: la versión resuelta, si es una dependencia directa o indirecta, la peor gravedad entre sus avisos, cuántos avisos aplican, sus identificadores y —cuando el aviso la indica— la versión en la que se corrigió el problema.
La gravedad procede de la etiqueta de la propia base de avisos. Los registros que no llevan ninguna, algo común en las entradas PYSEC, se informan como desconocida en lugar de asignarles un valor supuesto.
Cómo puntúa
Tres componentes:
| Componente | Peso |
|---|---|
| Dependencias directas libres de avisos conocidos | 35 |
| Dependencias indirectas libres de avisos conocidos | 25 |
| Sin avisos pendientes | 40 |
Las directas pesan más que las transitivas porque son la elección declarada del propio proyecto; las transitivas llegan con ellas.
La gravedad es la puntuación base CVSS publicada, no una etiqueta gruesa. Cada paquete afectado aporta su puntuación en una escala de 0 a 1. Las etiquetas propias de la base de datos solo se usan cuando un aviso no publica vector CVSS.
En los dos primeros componentes domina el peor hallazgo individual, y el volumen restante pesa progresivamente menos. Una dependencia de gravedad crítica cuesta cerca de tres cuartas partes de su componente; ocho de gravedad baja cuestan cerca de un tercio. Ese orden es deliberado —cien avisos triviales no equivalen a uno crítico— y el término de volumen nunca lleva un componente a cero, de modo que un proyecto con 300 hallazgos sigue puntuando por debajo de uno con 30 en lugar de empatar.
El tercer componente pregunta otra cosa: ¿cuánto tiempo lleva disponible la corrección? Sufrir un aviso publicado la semana pasada es mala suerte. Seguir resolviendo a una versión afectada por uno publicado hace un año es una incapacidad de seguir las dependencias. Un paquete cuenta aquí cuando su aviso más antiguo supera los 90 días. Cuando ningún aviso lleva fecha de publicación, el componente se excluye y su peso se renormaliza, nunca se presume limpio.
Un conjunto sin avisos conocidos obtiene la puntuación completa en los tres.
La cobertura se declara, nunca se presume
Algunas entradas de un grafo de dependencias no llevan versión registrada. Un paquete sin versión no puede cotejarse con un rango de versiones, así que se omite y se cuenta: cada informe indica cuántas dependencias se evaluaron y cuántas no.
Los repositorios cuyo grafo de dependencias no está disponible o está desactivado no son penalizados. La métrica se excluye y el peso restante de Seguridad se renormaliza, exactamente igual que con cualquier otra entrada no disponible; véase el índice de salud.
Qué no afirma
Un aviso aquí significa una cosa precisa: la versión registrada en el grafo de dependencias cae dentro del rango afectado de un aviso.
No significa que la ruta de código vulnerable sea alcanzable desde este proyecto, ni que el proyecto sea explotable. La mayoría de los avisos en un cierre transitivo grande no son explotables en su contexto.
Tampoco distingue lo que un proyecto distribuye de aquello con lo que se construye y se prueba. Un grafo de dependencias incluye fijaciones de desarrollo y prueba, y un repositorio que deliberadamente se prueba contra una versión antigua de una biblioteca mostrará aquí esa versión. La división directa/indirecta es el mejor sustituto disponible y se informa por hallazgo, pero sigue siendo un sustituto.
Léase junto a señales, no garantías: un resultado limpio no es una garantía de seguridad, y un hallazgo es una invitación a mirar, no un veredicto.
Por qué está separada de la postura de seguridad
La propia comprobación de vulnerabilidades de Scorecard consulta esa misma base de avisos y ya contribuye a la postura de seguridad. Puntuar una segunda señal derivada de OSV dentro de esa misma métrica contaría dos veces el mismo cuerpo de pruebas.
Mantenerlas separadas también las mantiene honestas respecto a su distinta granularidad. La postura de seguridad pregunta si un proyecto arrastra dependencias vulnerables conocidas, como una comprobación entre diecinueve. Esta métrica pregunta qué paquetes, con qué gravedad y corregidos en qué versión: la forma que debe tomar una respuesta antes de que alguien pueda actuar sobre ella.