Una dependencia vulnerable es un error. Una dependencia maliciosa es un ataque. No son el mismo hallazgo, y este registro no los puntúa del mismo modo.
Dependencias maliciosas plantea una única pregunta: ¿el grafo de dependencias al que resuelve este repositorio contiene algún paquete reportado como malware?
De dónde procede la evidencia
La fuente es el corpus malicious-packages de OpenSSF: un registro de licencia abierta, mantenido por la comunidad, de paquetes hallados maliciosos en los registros públicos —typosquats, tomas de control de cuentas, ataques de confusión de dependencias y paquetes que distribuyen binarios maliciosos precompilados.
OSV.dev incorpora ese corpus y lo sirve bajo identificadores MAL- junto a los avisos de seguridad ordinarios. Como este registro ya consulta OSV para los avisos de dependencias, los paquetes maliciosos llegan en una consulta que ya se estaba haciendo. El hallazgo no cuesta ninguna petición adicional, ninguna espera adicional ni ninguna dependencia adicional de un tercero.
Por qué se puntúa aparte de los avisos
Hasta la metodología v1.10.0 estos reportes se contaban como avisos ordinarios, y eso era incorrecto de una manera que conviene enunciar con claridad.
El reporte de un paquete malicioso no lleva vector CVSS ni etiqueta de gravedad: no hay nada que puntuar, porque el malware no tiene gravedad, solo un estado. Puntuado como aviso, caía en la gravedad unknown, que se pondera como una vulnerabilidad moderada. Un paquete del que se había comprobado que roba credenciales contaba algo menos que un CVE medio.
Las tres propiedades que hacen puntuable una vulnerabilidad están todas ausentes:
- No hay versión corregida. No existe una publicación corregida del mismo artefacto a la que actualizar. El remedio es la eliminación, o abandonar el nombre comprometido.
- No hay exposición parcial. Una vulnerabilidad puede residir en una ruta de código inalcanzable. Una carga útil de instalación se ejecuta cuando el paquete se instala.
- No hay grados. Un paquete está reportado como malicioso o no lo está.
Así, una dependencia maliciosa se retira por completo de los hallazgos de avisos y se trata como una señal de alerta: un multiplicador y un límite en lugar de puntos de menos. Aplica un multiplicador del 35% a la puntuación de la postura de seguridad y al índice de salud ponderado, y limita ambos a 29, el techo de la banda Crítico. Eso es una banda más estricto que el límite de 49 de las jurisdicciones de alto riesgo, porque aquí hay un compromiso confirmado del software y no una exposición a un riesgo.
Un paquete que lleva a la vez un reporte malicioso y CVE ordinarios aparece únicamente bajo este hallazgo. Sus vulnerabilidades son irrelevantes.
Los artefactos retirados se reportan, no se puntúan
Un registro que elimina un paquete malicioso zanja la cuestión: no queda nada instalable, y un repositorio que resuelve a él no está distribuyendo malware hoy. Por eso cada hallazgo comprueba si el registro sigue sirviendo esa versión resuelta exacta. Cuando no lo hace, el hallazgo permanece en el informe —el proyecto depende de un nombre que fue comprometido, y eso merece verse—, pero no levanta ninguna señal de alerta ni cuesta puntos.
La comprobación pregunta deliberadamente por la versión resuelta y no por la última del paquete. Tras una retirada, npm deja una publicación de relleno, marcada -security, como la última del paquete. Eso protege a todo el que resuelve un rango de versiones, y a nadie que fijara exactamente la versión mala. Leer la última versión habría exculpado al primer repositorio en el que este hallazgo se activó, que fija el paquete comprometido en la versión precisa que el registro sigue sirviendo.
Cuando la pregunta no admite respuesta —un ecosistema que la comprobación no cubre, o un registro que no respondió— el hallazgo se puntúa como si el paquete siguiera vivo. No alcanzar un registro no es evidencia de que el malware fuera retirado.
Las directas y las indirectas cuentan igual
Casi toda la puntuación de dependencias de este registro distingue una dependencia directa declarada de una arrastrada de forma transitiva, porque un mantenedor eligió la primera y heredó la segunda.
Esa distinción no se aplica aquí. El script de instalación de un paquete se ejecuta a la profundidad que ocupe en el grafo resuelto; un ladrón de credenciales cuatro niveles más abajo compromete la máquina exactamente igual de a fondo que uno nombrado en el manifiesto. Ambos se reportan, ambos se puntúan, y el informe indica cuál es cuál para que se vea por dónde entró el paquete.
Qué no afirma este hallazgo
No es una acusación contra los mantenedores. El reporte se refiere al paquete tal como fue publicado, por quien lo publicara. Un repositorio resuelve a miles de paquetes que nunca inspeccionó; heredar uno comprometido es la forma normal en que esto ocurre, y no dice nada sobre la intención ni la competencia de quienes mantienen el repositorio inspeccionado.
No es una afirmación de que el código se ejecutara. El hallazgo dice que el grafo de dependencias resuelto contiene el paquete. Si alguien instaló ese grafo exacto, y qué hizo la carga útil en tal caso, queda fuera de lo que un registro público puede observar.
No es una determinación nuestra. La clasificación es la del corpus de OpenSSF, alcanzada por su propio proceso y sus propias fuentes, y este registro la reporta en lugar de reproducirla. Un reporte retirado aguas arriba desaparece en la siguiente inspección.
Con qué frecuencia se activa
Rara vez, por diseño y por medición. Antes de publicar esta métrica se ejecutó sobre una muestra de 300 repositorios que cubría 46.889 dependencias resueltas, y no encontró nada.
Ese es el resultado esperado, y no es señal de que la comprobación sea inútil. Los registros retiran los paquetes maliciosos en cuestión de horas o días desde su descubrimiento, así que un archivo de bloqueo que aún resuelve a uno es algo inusual. El valor de este hallazgo no está en que se active a menudo; está en que, cuando se activa, es el hecho más importante del informe, y ya no quedará promediado dentro de una puntuación de vulnerabilidades.
Cuándo no se evalúa
Como los avisos de dependencias, esta métrica se excluye —no se puntúa con cero— siempre que el grafo de dependencias o la consulta a OSV no estuvieran disponibles. Un repositorio nunca es penalizado por tener desactivado el grafo de dependencias de GitHub: el informe dice que la comprobación no se ejecutó en lugar de dar a entender un resultado limpio.