An online vulnerability scanner helps you find security weaknesses without building a full security testing setup from scratch. But the phrase can mean three different things: a scanner for websites, a scanner for software dependencies, or a scanner for servers and networks.
That difference matters. If you want to test a live website for SQL injection, you need a web application scanner. If you want to check whether your npm, Python, Java, PHP, Go, Ruby, Rust, or .NET packages contain known CVEs, you need a dependency vulnerability scanner. If you want to find exposed ports or outdated server software, you need an infrastructure scanner.
This guide explains the main types, when to use each one, what makes a good dependency scanner, and how to run a free dependency scan in 60 seconds using Vulert.
Warning: Choosing the wrong scanner gives you a false sense of security. A web scanner will not fully check your dependency versions, and a dependency scanner will not test your live website for XSS.
The Three Types of Online Vulnerability Scanners
There are three common types of vulnerability scanners: web application scanners, dependency vulnerability scanners, and infrastructure or network scanners. Each one checks a different attack surface. Teams often need more than one, but they should not treat them as interchangeable.
A web scanner tests a running website. A dependency scanner checks third-party packages against CVE databases. An infrastructure scanner checks servers, ports, operating systems, and exposed services. All three can reduce risk, but they answer different questions.
The most common mistake is assuming that one scan covers everything. For example, a web application scanner may detect reflected XSS or insecure headers, but it may not tell you that your Java application uses a vulnerable jackson-databind version. A dependency scanner may show vulnerable npm packages, but it will not crawl your login form for injection payloads. An infrastructure scanner may detect open SSH or outdated OpenSSL on a server, but it will not know whether your package-lock.json contains a vulnerable lodash version.
Type 1 — Web Application Scanners
Web application scanners test a live website or web application by crawling pages, submitting payloads, and checking for common web vulnerabilities. They look for issues such as cross-site scripting, SQL injection, CSRF weaknesses, open redirects, insecure headers, exposed admin paths, and risky HTTP behavior.
These scanners are useful when you want to test a running website from the outside. They simulate some attacker behavior by sending requests to the application and watching how it responds. Tools in this category include OWASP ZAP, Nikto, Burp Suite Community, Detectify, and Pentest-Tools.
The limitation is scope. A web scanner does not fully understand your backend dependency tree. It may not detect a vulnerable package unless the vulnerability is reachable through a testable HTTP behavior. For example, Log4Shell was a dependency vulnerability in server-side Java logging code. A normal website scan alone could not prove every vulnerable package version across a codebase.
Type 2 — Dependency Vulnerability Scanners
Dependency vulnerability scanners check your project’s declared packages against known vulnerability databases. They scan files such as package-lock.json, yarn.lock, requirements.txt, poetry.lock, pom.xml, build.gradle, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, packages.lock.json, or SBOM files.
This is the right scanner type when you want to know whether your third-party packages contain known CVEs. Modern applications depend heavily on open source components. A single application may contain hundreds or thousands of direct and transitive dependencies. If one of those packages has a known CVE, your application can inherit the risk.
Examples include Vulert’s free scanner at vulert.com/abom, npm audit, pip-audit, and limited free versions of SCA tools. A good dependency scanner should show the affected package, vulnerable version, CVE severity, patch availability, and the version to upgrade to.
Type 3 — Infrastructure and Network Scanners
Infrastructure scanners check servers, cloud assets, network ports, operating system packages, exposed services, and configuration weaknesses. They help teams understand what is reachable and whether exposed systems have known issues.
These scanners are useful when you need to assess a server, network range, cloud environment, or external attack surface. Examples include Nmap, OpenVAS, Nessus Essentials, and similar tools. They may find open ports, outdated services, risky protocols, weak TLS configuration, or exposed management interfaces.
The limitation is that infrastructure scanners usually focus on host and service exposure. They may not inspect the exact third-party package versions inside your application repository. That means they are not a replacement for dependency scanning. If your Node.js app includes a vulnerable jsonwebtoken version, a network scan may not find it.
Which Type Do You Actually Need?
The right scanner depends on what you are trying to check. A developer asking “does my Node.js project have vulnerable packages?” needs a dependency scanner. A founder asking “is my website vulnerable to XSS?” needs a web application scanner. A DevOps engineer asking “which ports are open on this server?” needs an infrastructure scanner.
Many teams eventually need all three. But the starting point should match the question. For open source dependency risk, dependency scanning is usually the fastest and most actionable place to begin because it checks exact package versions and maps them to known CVEs.
Dependency scanning is especially important for modern applications because much of the codebase comes from third-party packages. JavaScript projects may include npm dependencies. Python projects may include PyPI packages. Java projects may include Maven dependencies. PHP projects may include Composer packages. Go, Ruby, Rust, Dart, and .NET projects also rely on package ecosystems.
| Your Situation | Recommended Scanner Type | Example Tool |
|---|---|---|
| I want to check Node.js, Python, Java, PHP, Go, or Ruby dependencies for CVEs. | Dependency vulnerability scanner | Vulert ABOM, npm audit, pip-audit
|
| I want to test a live website for XSS, SQL injection, or insecure headers. | Web application scanner | OWASP ZAP, Burp Suite Community, Detectify |
| I want to check servers for open ports and outdated services. | Infrastructure or network scanner | Nmap, OpenVAS, Nessus Essentials |
| I want to check a manifest file or SBOM without installing anything. | Online dependency scanner | vulert.com/abom |
| I want ongoing alerts when new CVEs affect my packages. | Continuous dependency monitoring | Vulert monitoring |
Tip: If your main question is “do my dependencies have known CVEs?”, start with a dependency scanner and upload the lock file or SBOM.
What Makes a Good Online Dependency Vulnerability Scanner
A good online vulnerability scanner for dependencies should be fast, accurate, private, and actionable. It should not only say “you have vulnerabilities.” It should show which package is affected, which version you are using, which CVE applies, whether a patch exists, and what version to upgrade to.
The best scanners use lock files where possible. Lock files contain exact resolved versions, including transitive dependencies. This is more accurate than scanning only top-level manifests because vulnerabilities often appear in indirect packages you did not install directly.
Privacy also matters. Many teams do not want to connect a full private repository just to run a quick check. A manifest-only upload is safer and simpler because it shares dependency metadata, not your entire codebase. Vulert’s scanner is designed around this workflow: upload a supported manifest or SBOM, get results in about 60 seconds, and use the report to fix vulnerable packages.
- No installation required: The scanner should run in a browser and accept file uploads.
-
Lock file support: It should scan files such as
package-lock.json,composer.lock,poetry.lock, andGemfile.lock. - Transitive dependency coverage: It should detect vulnerabilities in indirect packages, not only direct dependencies.
- Fix versions: It should show the safe version or upgrade path, not only the CVE ID.
- Multi-ecosystem support: It should work for npm, Python, Java, PHP, Go, Ruby, Rust, Dart, and .NET projects.
- SBOM support: It should accept CycloneDX and SPDX files for artifact and inventory-based scanning.
- No code access required: It should work without cloning or connecting your repository.
The Best Free Online Dependency Vulnerability Scanners
There are several ways to check dependencies for vulnerabilities. Some are command-line tools for one ecosystem. Some are hosted scanners. Some are broader Software Composition Analysis tools with dashboards and monitoring.
For a quick browser-based check, Vulert’s free scanner is a strong starting point because it accepts many dependency file types and SBOM formats. You can upload a manifest or lock file without installing a command-line tool. This is useful when you are reviewing an old project, checking a client repository, auditing a Lambda package, or scanning a dependency file before release.
Local tools are still useful. npm audit is fast for Node.js. pip-audit works well for Python. govulncheck is useful for Go. The limitation is that every ecosystem has a different workflow. A multi-ecosystem online scanner gives teams one place to check different project types.
| Tool | Ecosystems | Requires Account | Shows Fix Versions | Continuous Monitoring |
|---|---|---|---|---|
| Vulert ABOM | JavaScript, Python, Java, PHP, Go, Ruby, Rust, Dart, .NET, SBOM | No for free scan | Yes | Available with Vulert monitoring |
npm audit |
Node.js | No | Basic fix guidance | No |
pip-audit |
Python | No | Basic fix guidance | No |
govulncheck |
Go | No | Go-specific results | No |
| Snyk Free | Multiple ecosystems | Usually yes | Yes | Limited by plan |
How to Use an Online Dependency Scanner — Step by Step
Using Vulert’s dependency scanner is straightforward. You do not need to install a CLI, connect GitHub, provide source code, or create an account for the free scan. You only need the dependency file that represents your project.
For JavaScript, upload package-lock.json or yarn.lock. For Python, upload requirements.txt, Pipfile.lock, or poetry.lock. For Java, upload pom.xml or build.gradle. For PHP, upload composer.lock. For Go, upload go.sum. For Ruby, Rust, Dart, and .NET, upload Gemfile.lock, Cargo.lock, pubspec.lock, or packages.lock.json. You can also upload CycloneDX or SPDX SBOMs.
-
Open the scanner: Go to
vulert.com/abom. - Choose the right file: Use the lock file where possible because it contains exact resolved dependency versions.
- Upload the file: Drag and drop the file or use the upload button.
- Run the scan: Vulert checks the packages against 458,000+ known CVEs.
- Review severity: Start with Critical and High vulnerabilities.
- Check fix guidance: Review the safe version and command where available.
- Update and rescan: Patch the dependency, rebuild the lock file, and scan again.
# Example npm fix after finding a vulnerable package
npm install package-name@safe-version
# Example Python fix
pip install package-name==safe-version
# Example Go fix
go get module-name@vSafeVersion
Warning: Always rescan after upgrading. The first upgrade may not remove every vulnerable transitive dependency.
The Limitation of One-Time Scanning and What to Do Next
An online vulnerability scanner gives you a snapshot of your security state at one moment. That is useful for quick checks, audits, pull requests, and pre-release reviews. But it does not automatically protect you from new CVEs disclosed after the scan.
This is the core limitation of one-time scanning. A dependency can be clean today and vulnerable tomorrow. New advisories are published continuously. If nobody changes the repository for two months, a CI/CD scan may not run again. If nobody rescans manually, the team may not know that a package in production now has a critical CVE.
Continuous monitoring closes this gap. Vulert monitors dependencies and alerts teams when newly disclosed CVEs affect their specific packages. That means the team does not need to wait for the next commit, next release, next audit, or customer report.
A good workflow has three layers: use a free scanner for quick checks, add dependency scanning to CI/CD for every pull request, and enable continuous monitoring for deployed applications. This gives developers fast feedback and gives security teams ongoing visibility.
A clean one-time scan is useful. Continuous monitoring tells you when that clean result changes.
To build a stronger dependency security workflow, continue with these related Vulert guides:
- Free Online Vulnerability Scanner Guide
- Software Composition Analysis Guide
These guides explain how free scanning, SCA, SBOMs, and continuous monitoring fit together for modern engineering teams.
Key Takeaways
- An online vulnerability scanner can mean a web scanner, dependency scanner, or infrastructure scanner.
- Web application scanners test live websites for issues such as XSS, SQL injection, open redirects, and insecure headers.
- Dependency scanners check package files and SBOMs against CVE databases.
- Infrastructure scanners check servers, ports, services, and network exposure.
- If you want to check open source packages for known CVEs, use a dependency scanner and upload the lock file where possible.
- One-time scans are useful, but continuous monitoring is needed because new CVEs appear after deployment.
Frequently Asked Questions
1. What is the best free online vulnerability scanner?
The best choice depends on what you need to scan. For software dependencies, Vulert’s free scanner at vulert.com/abom lets you upload a manifest file or SBOM and get dependency vulnerability results in about 60 seconds. For live websites, use a web application scanner. For servers and networks, use an infrastructure scanner.
2. What is the difference between a web scanner and a dependency scanner?
A web scanner tests a running website for issues such as XSS, SQL injection, insecure headers, and open redirects. A dependency scanner checks third-party packages, lock files, and SBOMs against known CVEs. They solve different problems and many teams need both.
3. Scan Your Dependencies Free Right Now
If your goal is to check third-party packages for known CVEs, start with a dependency scan. Upload your lock file or SBOM, review the vulnerable packages, apply fixes, and rescan to confirm the results.
Scan your dependencies free at vulert.com/abom — upload your manifest file and see every vulnerability with exact fix commands in 60 seconds. No signup required.
Top comments (0)