Auditoría de dependencias y SBOM a partir de su archivo lock
Cargue package-lock.json, yarn.lock, requirements.txt, pom.xml o archivos de Gradle. Vea los avisos de seguridad conocidos con sus versiones corregidas, las clases de licencia y los paquetes obsoletos, y descargue una lista de materiales de software (SBOM) en formato CycloneDX.
Si ya usa Dependabot, Renovate, Snyk, OSV-Scanner o Dependency-Track en su CI, probablemente no lo necesite. Es una comprobación puntual para traspasos de proyecto, due diligence y una primera SBOM.
YuSMP es una empresa de software; la revisión es gratuita y automática. Bajo petición ofrecemos una revisión manual de dependencias y actualizaciones.
1Añada sus archivos de dependencias
Sus archivos se quedan en su navegador. Los archivos lock se analizan localmente. En el siguiente paso verá qué pares paquete@versión se enviarían a nuestro servidor y de ahí a la base de datos pública de vulnerabilidades OSV.dev y a un registro de paquetes; puede excluir los paquetes internos. No guardamos esta lista ni la escribimos en los registros.
Archivos
| Archivo | Formato | Paquetes | Estado |
|---|
2Contexto (opcional)
3Qué se enviará
| Enviar | Paquete | Versión | Ámbito |
|---|
Comprobando
- Buscando vulnerabilidades conocidas
- Comprobando fechas de versión y licencias
- Ordenando las correcciones
Los proyectos grandes tardan hasta un minuto.
Resultados
Corregir primero
Descargar una SBOM CycloneDX
La SBOM se genera en su navegador a partir de los componentes anteriores (los paquetes excluidos y privados quedan fuera y se cuentan en el archivo). Formato: CycloneDX 1.5 JSON.
Qué cubre el archivo (elementos mínimos de la NTIA)
- ✓Nombre, versión e identificador único (purl) del componente
- ◐Relaciones de dependencia: solo raíz → dependencias directas
- ✓Autor de los datos de la SBOM y marca de tiempo
- ✕Nombre del proveedor: no se incluye, los registros no lo ofrecen de forma fiable
- ✕Hashes de los componentes: aún no se incluyen
El CRA espera que los fabricantes documenten los componentes de sus productos, entre otras cosas con una lista de materiales de software (SBOM) en un formato de uso común y legible por máquina que cubra al menos las dependencias de primer nivel (anexo I, parte II, punto 1).
Esta herramienta ayuda a iniciar un inventario de componentes y a ver los avisos conocidos. No es asesoramiento jurídico ni una evaluación de la conformidad.
Recibir el informe en PDF
Un PDF con las prioridades de corrección, el esfuerzo en horas, las tablas de vulnerabilidades, licencias y paquetes obsoletos y el método, por correo electrónico. También vemos que ha realizado la comprobación, para ofrecerle una revisión manual si le resulta útil.
Revisión manual de dependencias y actualizaciones
Un ingeniero revisa su pila: qué es realmente alcanzable, qué actualizaciones son seguras, qué sustituir y un plan que su equipo pueda seguir. Primera llamada gratuita, NDA si lo necesita.
Auditorías de seguridadModernización de softwareCTO fraccional
Qué no hace esta herramienta
- No analiza su código fuente (no es SAST) ni comprueba si realmente se llega a una función vulnerable.
- No analiza imágenes de contenedores, paquetes del sistema operativo ni registros privados.
- No corrige nada ni abre pull requests.
- No guarda sus archivos ni la lista de paquetes.
- No es un certificado, una opinión de auditoría, asesoramiento jurídico ni una evaluación de la conformidad.
Si ya tiene SCA en su CI
Manténgalo. Las herramientas continuas como Dependabot, Renovate, OSV-Scanner o Dependency-Track vigilan cada commit; esta página es para una revisión puntual: el traspaso de un proveedor, una due diligence, una primera SBOM para un cliente o un código que nadie revisa desde hace tiempo.
Cómo funciona
Su navegador lee los archivos y extrae cada paquete con su versión exacta. Los paquetes sin versión exacta (un rango en package.json, un requisito sin fijar, una propiedad de Maven que no se resuelve) aparecen como «versión sin fijar» y no se consultan: un rango no permite dar una respuesta honesta. Añada un archivo lock para obtener un resultado completo.
Los paquetes internos se excluyen automáticamente: file:, link:, workspace:, orígenes git y URL, y todo lo que procede de un registro no público. Puede excluir más a mano antes de enviar nada.
Solo después de pulsar «Comprobar dependencias» la lista paquete@versión va a nuestra función serverless. Esta consulta OSV.dev, la base de datos abierta de vulnerabilidades que reúne los avisos de GitHub, PyPI, npm y otras fuentes, y deps.dev (Open Source Insights) para licencias, fechas de versión y desuso. La gravedad procede del vector CVSS v3 o de la valoración del propio aviso; los duplicados (GHSA, CVE, PYSEC) se fusionan.
Las prioridades ponderan la gravedad según el alcance (dependencia directa de producción, transitiva, de desarrollo) y según exista o no una corrección. El esfuerzo es una cifra orientativa en horas, no un presupuesto. Fije las dependencias y mantenga una SBOM: consulte nuestra lista de comprobación de seguridad para aplicaciones web (en inglés).
Datos de vulnerabilidades: OSV.dev y sus fuentes (CC-BY 4.0). Metadatos de paquetes: deps.dev (Open Source Insights, CC-BY 4.0).
CRA, SBOM y su producto
- El Reglamento de Ciberresiliencia (CRA, Reglamento (UE) 2024/2847) entró en vigor el 10 de diciembre de 2024. La notificación de vulnerabilidades explotadas activamente e incidentes graves se aplica desde el 11 de septiembre de 2026; la mayoría de las demás obligaciones, desde el 11 de diciembre de 2027.
- El CRA espera que los fabricantes documenten los componentes de sus productos, entre otras cosas con una lista de materiales de software (SBOM) en un formato de uso común y legible por máquina que cubra al menos las dependencias de primer nivel (anexo I, parte II, punto 1).
- Las obligaciones se dirigen a los fabricantes de productos con elementos digitales comercializados en la UE. Si se aplican a su producto depende del producto: esta herramienta no lo determina.
Esta herramienta ayuda a iniciar un inventario de componentes y a ver los avisos conocidos. No es asesoramiento jurídico ni una evaluación de la conformidad.
FAQ
¿Se suben mis archivos?
No. Los archivos los lee su navegador y no salen de él. Solo se envía la lista de nombres de paquetes públicos con versiones exactas que usted confirma en la vista previa, y puede excluir cualquier paquete antes.
¿Qué se envía exactamente a servicios externos?
Pares como lodash@4.17.15 con el ecosistema (npm, PyPI, Maven), si el paquete es directo o de desarrollo y la licencia indicada en el archivo lock. Nuestra función reenvía los nombres y versiones a OSV.dev y deps.dev (ambos operados en Estados Unidos). No se envían nombres de archivo, rutas, URL de registros privados ni su código fuente. No guardamos la lista ni la registramos.
¿Qué es una SBOM y quién la necesita?
Una lista de materiales de software (SBOM) es una lista legible por máquina de los componentes de un producto: nombres, versiones, identificadores, licencias. Clientes, inversores y reguladores la piden cada vez más, y el Reglamento de Ciberresiliencia la espera de los fabricantes de productos con elementos digitales.
¿«Vulnerabilidad encontrada» significa que mi producto es explotable?
No. Significa que un aviso publicado afecta a esta versión del paquete. Si su código llama a la función vulnerable, con qué configuración y con qué entradas no se evalúa aquí; para eso está la revisión manual.
¿«No se encontró nada» significa que es seguro?
No. Significa que ningún aviso conocido coincide con las versiones exactas comprobadas. Los paquetes sin fijar, los excluidos y todo lo que queda fuera de los formatos admitidos no se comprobaron, y cada día aparecen avisos nuevos.
¿Es una comprobación de conformidad con el CRA?
No. Ayuda a iniciar un inventario de componentes y a ver los avisos conocidos. No es asesoramiento jurídico ni una evaluación de la conformidad, y que el CRA se aplique depende de su producto.
¿Qué formatos se admiten y qué queda fuera?
npm (package-lock.json, npm-shrinkwrap.json, yarn.lock, package.json), PyPI (requirements*.txt / .in) y Maven/Gradle (pom.xml, build.gradle, build.gradle.kts). Los archivos de Maven y Gradle solo enumeran las dependencias declaradas, sin el árbol transitivo y a menudo sin versiones resueltas. Aún no se admiten: pnpm, Poetry, Pipenv, Go, Rust, Ruby, PHP, .NET, imágenes de contenedores ni registros privados.
¿En qué se diferencia de Dependabot, Snyk u OSV-Scanner?
Esas herramientas funcionan de forma continua en su repositorio y su CI y pueden proponer correcciones. Esta página es una comprobación puntual sin instalar nada: útil para un traspaso, una due diligence o una primera SBOM. Si ya usa una de ellas, manténgala.
Servicios relacionados
Auditorías de seguridad
Pruebas de penetración y revisiones de seguridad, incluida una revisión manual de dependencias y actualizaciones.
Modernización de software
Actualizar frameworks y sustituir paquetes sin mantenimiento sin detener el producto.
CTO fraccional
Supervisión técnica sénior para traspasos, due diligence y decisiones sobre la cadena de suministro.