Escáner de vulnerabilidades SBOM

Tu lockfile nunca sale de esta página

El análisis se realiza por completo en tu navegador: el archivo que sueltas, o el texto que pegas, se lee localmente y nunca se sube a ningún sitio. Solo los nombres y las versiones extraídos de los paquetes se envían, a la base de datos pública de vulnerabilidades OSV.dev (sin cuenta, sin clave), para que pueda compararlos con vulnerabilidades conocidas. Después, los identificadores CVE de las coincidencias se envían al comprobador propio de este sitio para consultar la lista KEV de CISA. Nada más sale de la página: ni el contenido del archivo, ni rutas, ni nombres de proyectos.

Límites del análisis

Se analizan como máximo 500 paquetes por ejecución; los restantes se enumeran como no analizados. Se obtienen como máximo 200 detalles de vulnerabilidades. Los resultados proceden de la base de datos OSV para las versiones exactas de tu archivo; una versión de paquete que la base de datos nunca ha visto no devuelve coincidencias, lo que no es lo mismo que un certificado de buena salud.

Los límites, con honestidad

“No se encontraron vulnerabilidades” significa que no hay ninguna en la base de datos OSV para estas versiones exactas. No significa que el código sea seguro: las vulnerabilidades que nadie ha notificado todavía, los paquetes maliciosos, los nombres typosquat y las versiones comprometidas son todos invisibles para una comprobación por coincidencia de versión.

Una coincidencia es exacta por versión. Si tu archivo fija un rango en lugar de una versión exacta, se omite y se enumera como tal: el escáner no adivinará qué versión instalaste realmente. Lo mismo se aplica a los paquetes cuyo ecosistema no puede asignar el escáner: se enumeran como omitidos, nunca se descartan en silencio.

Las marcas KEV proceden de una única consulta al comprobador propio de este sitio (datos KEV de CISA, actualizados a diario). Si esa consulta falla o se limita por frecuencia, el análisis se completa igualmente: la columna KEV simplemente dice “desconocido” en lugar de bloquear tus resultados.

Por qué la versión fijada es la superficie de ataque

Un lockfile existe porque “latest” no es una versión. Registra el árbol exacto que instaló tu compilación, para que cada máquina y cada despliegue reciban el mismo código. Esa determinación es también lo que hace que el lockfile se pueda analizar: una base de datos de vulnerabilidades se indexa por paquete y versión exactos, así que una versión fijada se puede juzgar con una sola consulta, mientras que un rango flotante no. El análisis, por tanto, solo es tan bueno como el archivo: confirma el lockfile, mantenlo actualizado y el escáner podrá decirte la verdad sobre lo que envías.

La comprobación en sí es deliberadamente limitada. OSV.dev agrega registros de vulnerabilidades de los avisos de GitHub, el NVD y los ecosistemas de lenguajes, y los compara con tus versiones. Lo que no puede hacer es juzgar el código: un paquete sin CVE conocido puede seguir siendo malicioso, estar abandonado o ser un sosia de un paquete que querías instalar. La coincidencia de versiones es un primer filtro rápido y barato, el que detecta el lodash que olvidaste actualizar, no una auditoría de seguridad.

Por qué una marca KEV pesa más que una puntuación CVSS alta

Una puntuación CVSS mide lo grave que sería una vulnerabilidad si se explotara. El catálogo de vulnerabilidades explotadas conocidas de CISA mide otra cosa: si se está explotando realmente, en la práctica, ahora mismo. Un CVE de gravedad media en la lista KEV merece un parche esta semana; un CVE crítico que nadie ha convertido en arma a menudo puede esperar a la siguiente actualización planificada. Por eso este escáner marca las filas KEV por separado y por eso los resultados se ordenan primero por la peor gravedad, pero la insignia KEV es en la que hay que actuar primero.

Las versiones corregidas conllevan su propio riesgo. La corrección de una vulnerabilidad suele ser una versión menor o de parche, pero “corregido en 4.17.21” también puede significar un cambio de comportamiento que rompe tu compilación, y algunas vulnerabilidades no tienen ninguna versión corregida: el escáner lo dice claramente en lugar de inventar una. Corrige primero los elementos KEV, luego los críticos con una corrección publicada y después programa el resto; fija las nuevas versiones, confirma el lockfile y vuelve a analizar. El mismo ciclo pertenece a CI, donde se ejecuta en cada pull request en lugar de una vez al trimestre.

Licencias en esta SBOM

Las licencias que se muestran aquí proceden solo de los campos de licencia que lleva la propia SBOM. Los lockfiles (package-lock.json, requirements.txt, go.mod) no contienen datos de licencia, así que no se muestra nada para ellos: esta página no busca licencias por paquete, porque ninguna base de datos pública las proporciona de forma fiable.

Términos de lockfile y SBOM, definidos con precisión

Lockfile. Un archivo que registra la versión exacta de cada paquete que instala una compilación: package-lock.json para npm, requirements.txt con fijaciones == para Python, go.mod/go.sum para Go, para que las instalaciones sean reproducibles.

SBOM. Software Bill of Materials: un inventario legible por máquina de cada componente de un programa, normalmente en formato CycloneDX o SPDX. Es el lockfile generalizado a toda la cadena de suministro.

OSV.dev. La base de datos pública de vulnerabilidades de Google, que agrega avisos de GitHub, el NVD y los ecosistemas de lenguajes, y se puede consultar por nombre exacto de paquete, ecosistema y versión.

GHSA. Un identificador de aviso de seguridad de GitHub (GHSA-xxxx-xxxx-xxxx). La mayoría de las vulnerabilidades de npm, PyPI y Go en OSV llevan uno, normalmente junto a un identificador CVE.

CVE. Common Vulnerabilities and Exposures: el sistema de numeración compartido (CVE-YYYY-NNNNN) que permite que todas las bases de datos, escáneres y proveedores hablen de la misma vulnerabilidad.

CVSS. Common Vulnerability Scoring System: una puntuación de 0 a 10 de lo grave que sería una vulnerabilidad si se explotara. 9,0 o más es CRITICAL, 7,0 o más HIGH, 4,0 o más MEDIUM, por debajo de 4,0 LOW.

KEV. El catálogo de vulnerabilidades explotadas conocidas de CISA: vulnerabilidades cuya explotación en la práctica está confirmada, cada una con una fecha límite de corrección. Una marca KEV significa “corrige ahora”, diga lo que diga el CVSS.

Fixed version. La primera versión de un paquete en la que una vulnerabilidad ya no está presente, tomada de los eventos de rango afectado del aviso. Algunas vulnerabilidades aún no tienen ninguna publicada.

Purl. Package URL (pkg:npm/[email protected]): una forma estándar de nombrar un paquete con su ecosistema y versión. Las SBOM llevan purls, y así es como el escáner sabe a qué ecosistema pertenece un componente.

Preguntas frecuentes