Free Online Vulnerability Scanner — How to Check Your Dependencies in 60 Seconds

A free online vulnerability scanner lets you check your application dependencies for known CVEs without installing software, creating an account, or connecting your source code repository. You upload a dependency file, run a scan, and see which packages are vulnerable.

This is useful when you need a quick answer: “Does my project contain vulnerable open source packages?” Instead of setting up a local scanner, configuring CI/CD, or connecting GitHub, you can upload a manifest, lock file, or SBOM and get results in under 60 seconds.

Vulert’s free scanner at vulert.com/abom is built for this exact use case. It checks dependency files against 458,000+ known CVEs and shows affected packages, severity, available fixes, and upgrade guidance.

What it does: A dependency vulnerability scanner checks your third-party packages for known CVEs. It is different from web scanners, infrastructure scanners, and SAST tools.

What a Free Online Vulnerability Scanner Does

A free online vulnerability scanner for dependencies checks the packages your application uses against a database of known security vulnerabilities. Instead of scanning your running website, server, or custom source code, it focuses on third-party packages such as npm modules, Python packages, Maven dependencies, Composer packages, Go modules, Ruby gems, Rust crates, and SBOM components.

This distinction matters. A web application scanner tests a live website for issues such as SQL injection, cross-site scripting, exposed headers, or insecure forms. An infrastructure scanner checks servers, ports, operating systems, and network services. A SAST tool analyzes your own source code for insecure patterns. A dependency scanner checks the open source components your application imports.

For example, if your Node.js application uses lodash, axios, or jsonwebtoken, the scanner checks whether the exact versions in your lock file are affected by known CVEs. If your Python project uses requests, urllib3, cryptography, or PyJWT, it does the same. If your Java project uses jackson-databind or Spring packages, it checks those dependency versions too.

A dependency scanner answers one direct question: which third-party packages in this project are affected by known CVEs?

What File to Upload — Supported Formats

The file you upload determines how accurate the scan will be. The best file is usually the lock file because it contains exact resolved package versions, including transitive dependencies. Transitive dependencies are packages that your direct dependencies pull in automatically.

For example, package.json may show only the packages you added manually, but package-lock.json contains the full resolved dependency tree. The same idea applies to composer.lock, poetry.lock, Pipfile.lock, Gemfile.lock, Cargo.lock, and pubspec.lock. Scanning the lock file gives a better picture of what your application actually runs.

Vulert supports many common dependency files and SBOM formats, so you can use one scanner across multiple ecosystems instead of switching tools for every language.

Language or Platform	File to Upload	Why This File
JavaScript / Node.js	package-lock.json	Contains exact npm dependency versions and transitive packages.
JavaScript / Yarn	yarn.lock	Contains resolved Yarn dependency versions.
Java / Maven	pom.xml	Defines Maven dependencies and versions.
Java / Gradle	build.gradle	Defines Gradle dependencies used by the project.
Python / pip	requirements.txt	Lists Python packages used by the application.
Python / Pipenv	Pipfile.lock	Contains exact resolved Pipenv dependency versions.
Python / Poetry	poetry.lock	Contains exact resolved Poetry dependency versions.
PHP / Composer	composer.lock	More accurate than composer.json because it includes resolved versions.
Go	go.sum	Tracks Go module dependency versions.
Ruby	Gemfile.lock	Contains exact resolved Ruby gem versions.
Rust	Cargo.lock	Contains exact Rust crate versions.
.NET / C#	packages.lock.json	Tracks resolved NuGet package versions.
Dart / Flutter	pubspec.lock	Contains exact Dart and Flutter package versions.
SBOM	CycloneDX or SPDX	Useful when scanning built artifacts or exported component inventories.

Tip: Always upload the lock file where one exists. Upload package-lock.json instead of package.json, and composer.lock instead of composer.json.

How to Use Vulert’s Free Online Scanner — Step by Step

Using Vulert’s scanner is simple because it does not require installation, repository access, or a credit card. You only need the dependency file from your project. This makes it useful for developers, security teams, freelancers, agencies, and product teams who want a quick dependency health check before deployment.

The process works for a single project, a client project, an old repository, a Lambda function, a backend service, a frontend application, or any app where you can access the dependency file. You do not need to upload your full source code. The scanner only needs the manifest, lock file, or SBOM to identify packages and match them against known CVEs.

1. Go to the scanner: Open vulert.com/abom.
2. Find your dependency file: Choose the correct file, such as package-lock.json, requirements.txt, pom.xml, composer.lock, go.sum, or an SBOM.
3. Upload the file: Drag and drop it onto the upload area or click Browse.
4. Enter your email: The full report is sent to your inbox.
5. Click Scan: The scanner checks your dependencies against known CVEs.
6. Review results: Results appear on screen in under 60 seconds, and the full report is emailed to you.

No account creation is required. No software installation is required. No repository connection is required. You do not need to share your private source code.

Warning: Do not upload random source code archives when a lock file is enough. For dependency scanning, the lock file or SBOM is the correct input.

How to Read Your Scan Results

After the scan finishes, you need to understand what the results mean. A vulnerability report is only useful if it helps you decide what to fix first. The best reports do not just list CVEs; they show severity, affected package, vulnerable version, patch availability, and remediation guidance.

Vulert groups results by severity and package so teams can focus on the changes that reduce the most risk. This is better than staring at a long list of CVEs with no clear priority. If one package upgrade removes several vulnerabilities, that package should usually move to the top of the remediation list.

The Risk Level

Risk level shows the highest severity vulnerability found in your dependency file. Common levels include Critical, High, Medium, and Low. A project with one Critical CVE should receive immediate attention, especially if the vulnerable package is reachable from user input, authentication logic, file parsing, payment flows, or external network requests.

The Vulnerability Table

Vulnerability table entries usually include the CVE ID, title, package name, affected version, severity, patch status, and disclosure date. For example, the table may show that your project uses an old lodash version affected by prototype pollution, a vulnerable jsonwebtoken version, or a jackson-databind version with a known deserialization issue.

Patch Available — Yes vs No

Patch available tells you whether a fixed version exists. If a patch is available, upgrade to the safe version and rescan. If no patch is available, read the workaround section, check whether the vulnerable feature is used, consider configuration-level mitigations, and track the package closely until a fixed version is released.

Result Field	Meaning	Action
Severity	How serious the CVE is.	Start with Critical and High issues.
Package	The dependency affected by the CVE.	Find where it appears in your dependency tree.
Current Version	The vulnerable version you are using.	Compare it with the fixed version.
Patch Available	Whether a safe version exists.	Upgrade when possible.
Disclosure Date	When the vulnerability became public.	Prioritize older known issues that remain unfixed.

How to Fix What the Scanner Finds

A vulnerability scan is the start of remediation, not the end. Once the scanner shows a vulnerable package, check the affected version, safe version, exploitability, and whether your application actually uses the vulnerable code path. Then upgrade, test, and rescan.

For patched vulnerabilities, the normal fix is to upgrade the affected package. The exact command depends on your ecosystem. After upgrading, run your tests and rescan the dependency file to confirm the CVE is gone. Do not assume the issue is fixed until the scanner confirms the new resolved version is safe.

# npm
npm install package-name@safe-version

# Example
npm install lodash@4.17.21

# pip
pip install package-name==safe-version

# Example
pip install PyJWT==2.4.0

# Composer
composer require package/name:safe-version

<!-- Maven: update the version in pom.xml -->
<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>safe-version</version>
</dependency>

# Go
go get module-name@vSafeVersion

# Example
go get golang.org/x/crypto@v0.31.0

For large projects, fix packages in batches. Start with Critical and High CVEs that have patches. Then fix packages where one upgrade removes many vulnerabilities. Vulert’s Dependency Health view helps by grouping CVEs by package, so teams can see which upgrades reduce the most risk.

What to Do When There Is No Patch

Not every vulnerability has a fixed version on disclosure day. Some maintainers take time to release patches. Some packages are abandoned. Some vulnerabilities require configuration changes rather than package upgrades. When the scanner shows “Patch Available: No,” do not ignore it.

Start by reading the vulnerability detail. Look for workarounds, affected functions, vulnerable configuration, exploit requirements, and whether authentication or user interaction is required. Then decide whether the vulnerable package is reachable in your application. A package used only in a build script may carry different risk than one processing public HTTP requests.

• Check for a workaround: Some CVEs can be mitigated by disabling a feature or changing configuration.
• Limit exposure: Restrict access to endpoints that use the vulnerable package.
• Replace the package: If the project is abandoned, consider a maintained alternative.
• Add monitoring: Watch for exploitation signals, crashes, or suspicious input patterns.
• Track the CVE: Recheck regularly until a fixed version becomes available.

Tip: A missing patch does not mean there is nothing to do. Workarounds, exposure reduction, and package replacement can still reduce risk.

The Limitation of One-Time Scanning

A one-time scan shows the security state of your dependencies at one moment. That is useful, but it is not enough for long-term protection. New CVEs are disclosed continuously, and a package that looks safe today may become vulnerable tomorrow.

This is one of the biggest gaps in manual dependency checks. A developer may scan before release, get a clean report, and then forget the project. Two weeks later, a critical CVE may be disclosed in a transitive dependency. Without monitoring, the team may not know until an audit, customer report, incident, or exploit attempt.

Continuous monitoring solves this by checking your dependency set against new CVEs after the initial scan. Vulert monitors dependencies and alerts teams when newly disclosed vulnerabilities affect their specific packages. Each alert includes the affected package, severity, CVE detail, and fix guidance.

A clean scan today does not guarantee a safe dependency tree tomorrow.

The best workflow is simple: use a vulnerability scanner online for quick checks, add scanning to CI/CD for pull requests, and enable continuous monitoring for deployed applications.

Comparing Free Scanning Options

Several ecosystems include free local audit tools. npm has npm audit. Python has pip-audit. PHP has Composer audit options. Go has govulncheck. These tools are useful and should be part of developer workflows.

The limitation is fragmentation. Each tool works differently, supports one ecosystem, requires local setup, and may produce output in a different format. That becomes harder for teams managing JavaScript, Python, Java, PHP, Go, Ruby, Rust, Dart, and .NET projects at the same time.

Vulert’s online scanner gives one upload flow across many ecosystems. It also supports SBOM files, which is useful when you want to scan exported dependency inventories instead of native package files.

Tool	Ecosystems	Continuous Monitoring	Fix Guidance	No Install Needed
npm audit	Node.js	No	Basic	No
pip-audit	Python	No	Basic	No
composer audit	PHP	No	Basic	No
govulncheck	Go	No	Go-specific	No
Vulert ABOM	Multiple ecosystems + SBOM	Available with Vulert monitoring	Exact versions and fix commands	Yes

Key Takeaways

• A free online vulnerability scanner helps developers check dependency files for known CVEs without installing anything.
• Dependency scanners are different from web application scanners, infrastructure scanners, and SAST tools.
• Upload lock files such as package-lock.json, composer.lock, poetry.lock, Gemfile.lock, or SBOM files where possible.
• Scan results should show severity, affected package, vulnerable version, patch availability, and disclosure date.
• Fix patched vulnerabilities by upgrading to the safe version, then rescan to confirm the CVE is gone.
• One-time scans are useful, but continuous monitoring is needed because new CVEs are disclosed after deployment.

Frequently Asked Questions

1. Is there a free online vulnerability scanner with no signup?

Yes. Vulert’s scanner at vulert.com/abom lets you upload a manifest file or SBOM and see dependency vulnerabilities in about 60 seconds. No account creation, credit card, software installation, or repository connection is required.

2. What file do I upload to scan my dependencies?

Upload the lock file where possible. For Node.js, use package-lock.json or yarn.lock. For PHP, use composer.lock. For Python, use requirements.txt, Pipfile.lock, or poetry.lock. SBOM files in CycloneDX or SPDX format are also supported.

3. What is the difference between a one-time scan and continuous monitoring?

A one-time scan checks your dependencies at one moment. Continuous monitoring keeps checking after the scan and alerts you when new CVEs are disclosed for packages you already use. This matters because dependencies can become vulnerable after release.