Dependency audit and SBOM from your lock file
Upload package-lock.json, yarn.lock, requirements.txt, pom.xml or Gradle files. See known advisories with fix versions, licence classes and stale packages — and download a CycloneDX SBOM.
If you already run Dependabot, Renovate, Snyk, OSV-Scanner or Dependency-Track in CI, you mostly don't need this. It is a one-off check for handovers, due diligence and a first SBOM.
YuSMP is a software company; the review is free and automated. We offer a manual dependency and upgrade review on request.
1Add your dependency files
Your files stay in your browser. Lock files are parsed locally. On the next step you will see which package@version pairs would be sent to our server and on to the public OSV.dev vulnerability database and a package registry; you can exclude internal packages. We do not store this list and do not write it to logs.
Files
| File | Format | Packages | Status |
|---|
2Context (optional)
3What will be sent
| Send | Package | Version | Scope |
|---|
Checking
- Looking up known vulnerabilities
- Checking release dates and licences
- Ranking fixes
Large projects take up to a minute.
Results
Fix first
Download a CycloneDX SBOM
The SBOM is built in your browser from the components above (excluded and private packages are left out and counted in the file). Format: CycloneDX 1.5 JSON.
What the file covers (NTIA minimum elements)
- ✓Component name, version, unique identifier (purl)
- ◐Dependency relationships: root → direct dependencies only
- ✓Author of the SBOM data and timestamp
- ✕Supplier name — not included, registries do not provide it reliably
- ✕Component hashes — not included yet
The CRA expects manufacturers to document the components of their products, including an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies (Annex I, Part II, point 1).
This tool helps you start a component inventory and see known advisories. This is not legal advice and not a conformity assessment.
Get the PDF report
A PDF with the fix-first plan, effort in hours, the vulnerability, licence and stale-package tables and the method — by email. We also see that you ran the check, to offer a manual review if it is useful.
Get a manual dependency & upgrade review
An engineer goes through your stack: what is actually reachable, which upgrades are safe, what to replace, and a plan your team can follow. Free first call, NDA on request.
What this tool does not do
- It does not analyse your source code (no SAST) and does not check whether a vulnerable function is actually reached.
- It does not scan container images, operating-system packages or private registries.
- It does not fix anything or open pull requests.
- It does not store your files or the package list.
- It is not a certificate, an audit opinion, legal advice or a conformity assessment.
If you already have SCA in CI
Keep it. Continuous tools such as Dependabot, Renovate, OSV-Scanner or Dependency-Track watch every commit; this page is for a one-off look: a vendor handover, due diligence, a first SBOM for a customer, or a codebase nobody has checked for a while.
How it works
Your browser reads the files and extracts each package with its exact version. Packages without an exact version (a range in package.json, an unpinned requirement, a Maven property that does not resolve) are listed as “version not pinned” and are not looked up: a range cannot give an honest answer. Add a lock file for a complete result.
Internal packages are excluded automatically: file:, link:, workspace:, git and URL sources, and anything resolved from a non-public registry. You can exclude more by hand before anything is sent.
After you press “Check dependencies”, only the package@version list goes to our serverless function. It asks OSV.dev, the open vulnerability database that aggregates GitHub, PyPI, npm and other advisories, and deps.dev (Open Source Insights) for licences, release dates and deprecation. Severity comes from the CVSS v3 vector or the advisory's own rating; duplicates (GHSA, CVE, PYSEC) are merged.
Priorities weigh severity by reach (direct production dependency, transitive, dev) and by whether a fix exists. Effort is a rough planning figure in hours, not a quote. Pin dependencies and keep an SBOM: see our web app security checklist.
Vulnerability data: OSV.dev and its sources (CC-BY 4.0). Package metadata: deps.dev (Open Source Insights, CC-BY 4.0).
CRA, SBOM and your product
- The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Reporting of actively exploited vulnerabilities and severe incidents applies from 11 September 2026; most other obligations apply from 11 December 2027.
- The CRA expects manufacturers to document the components of their products, including an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies (Annex I, Part II, point 1).
- The obligations apply to manufacturers of products with digital elements placed on the EU market. Whether they apply to your product depends on the product — this tool does not decide that.
This tool helps you start a component inventory and see known advisories. This is not legal advice and not a conformity assessment.
FAQ
Are my files uploaded?
No. The files are read by your browser and never leave it. Only the list of public package names and exact versions you confirm on the preview step is sent, and you can exclude any package before that.
What exactly is sent to external services?
Pairs like lodash@4.17.15 with the ecosystem (npm, PyPI, Maven), whether the package is direct or dev, and the licence string from the lock file. Our function forwards the names and versions to OSV.dev and deps.dev (both operated in the United States). File names, paths, private registry URLs and your source code are not sent. We do not store the list and do not log it.
What is an SBOM and who needs one?
A software bill of materials is a machine-readable list of the components in a product: names, versions, identifiers, licences. Customers, investors and regulators increasingly ask for one, and the EU Cyber Resilience Act expects manufacturers of products with digital elements to keep it.
Does “vulnerability found” mean my product can be exploited?
No. It means a published advisory covers this package version. Whether your code calls the vulnerable function, under which configuration and with which input is not assessed here — that is what a manual review is for.
Does “nothing found” mean it is safe?
No. It means no known advisories matched the exact versions that were checked. Unpinned packages, excluded packages and anything outside the supported formats were not checked, and new advisories appear every day.
Is this a CRA compliance check?
No. It helps you start a component inventory and see known advisories. It is not legal advice and not a conformity assessment, and whether the CRA applies depends on your product.
Which formats are supported and what is not covered?
npm (package-lock.json, npm-shrinkwrap.json, yarn.lock, package.json), PyPI (requirements*.txt / .in) and Maven/Gradle (pom.xml, build.gradle, build.gradle.kts). Maven and Gradle files list only declared dependencies, without the transitive tree and often without resolved versions. Not covered yet: pnpm, Poetry, Pipenv, Go, Rust, Ruby, PHP, .NET, container images and private registries.
How is this different from Dependabot, Snyk or OSV-Scanner?
Those tools run continuously inside your repository and CI and can open fixes. This page is a one-off check without installing anything: useful for a handover, due diligence or a first SBOM. If you already run one of them, keep it.
Related services
Security audits
Penetration tests and security reviews, including a manual dependency & upgrade review.
Software modernization
Upgrade frameworks and replace unmaintained packages without stopping the product.
Fractional CTO
Senior technical oversight for handovers, due diligence and supply-chain decisions.