The main types of vulnerability assessments are network, host, application, database, wireless, and cloud, and each one examines a different layer of your environment for a different class of weakness. Running the wrong type against a given risk is a common and expensive mistake: a network scan will not find a SQL injection flaw, and an application scan will not tell you a server is running an unpatched kernel. Matching the assessment to the asset is the whole game.
A vulnerability assessment is a systematic review of security weaknesses in a system. It rates them, prioritizes them, and recommends remediation — but assessment is not exploitation. Unlike a penetration test, it identifies and classifies weaknesses rather than proving they can be chained into a breach.
Network-based assessments
A network vulnerability assessment scans hosts reachable across the network for open ports, exposed services, and known service-level flaws. It is the classic sweep: enumerate what is listening, fingerprint versions, and match against advisory data.
This type finds exposed management interfaces, services running with default credentials, unpatched daemons, and unnecessary open ports. It is your first line of defense against the "we did not know that box was on the internet" problem. Tools in this category probe from either outside the perimeter (external) or inside it (internal), and the two views differ enough that you want both.
# Illustrative service/version discovery, the input to a network assessment
nmap -sV -p- --open target-host
The limit: a network scan sees services, not the logic running inside them. It tells you Apache 2.4.x is exposed, not that the app behind it has a broken authorization check.
Host-based assessments
Where network scans look from the outside in, host-based assessments look from the inside of a single machine out. An agent or credentialed scan inspects the operating system, installed packages, patch levels, configuration files, running processes, and local user accounts.
This is the assessment that finds the missing kernel patch, the world-readable secrets file, the account with a weak password policy, and the misconfigured service that a network scan cannot see because it is not exposed externally. Host-based assessments are essential for servers holding sensitive data and for meeting configuration-hardening benchmarks like the CIS Benchmarks.
Application vulnerability assessments
Application assessments target the software layer: web apps, APIs, and mobile backends. They look for the flaws in the OWASP Top 10 — injection, broken access control, security misconfiguration, cryptographic failures, and the rest.
This category splits into static analysis (SAST), which reads source code, and dynamic analysis (DAST), which probes a running app from the outside. You want both, because they catch different things: SAST sees the vulnerable code path even if it is not currently reachable, while DAST confirms what is actually exploitable at runtime. Neither one reliably finds business-logic flaws, which is why deeper manual testing still has a role.
Database assessments
Databases deserve their own assessment type because they hold the crown jewels and have their own failure modes. A database vulnerability assessment checks for default or weak credentials, excessive privileges, unencrypted data at rest, unpatched database engine versions, and dangerous configuration like publicly bound listeners.
The most common real-world finding here is not an exotic CVE but a database exposed to the network with weak or no authentication. That single misconfiguration has caused more data leaks than most software bugs. If a datastore is reachable and under-authenticated, treat it as a live incident, not a low-priority finding.
Wireless and physical-layer assessments
A wireless assessment examines Wi-Fi networks and the devices attached to them: rogue access points, weak encryption (anything still on WEP or misconfigured WPA), default router credentials, and networks that bridge guest and corporate segments they should not.
This type matters most for organizations with physical offices and IoT deployments. It is easy to forget because it does not show up in a code scan, but a rogue access point is a direct path into an otherwise well-defended network.
Cloud and container assessments
Cloud assessments have become their own major category because the failure modes are distinct. Instead of unpatched servers, the top risks are misconfigured storage buckets, over-permissive IAM roles, exposed management APIs, and unencrypted volumes. The shared-responsibility model means the provider secures the infrastructure and you secure your configuration of it — and configuration is where almost all cloud incidents originate.
Container and image assessments sit alongside this: scanning container images for vulnerable OS packages and application dependencies, checking that images are not running as root, and verifying that base images are current. Software composition analysis overlaps here, since a container inherits every CVE in the packages it bundles. An SCA tool such as our platform can map those transitively so you see inherited risk, not just what you installed directly.
Choosing and sequencing them
You do not run all six types with equal frequency. Match cadence to change rate and risk:
- Network and host: continuously or weekly, since the internet-facing surface changes and new CVEs land daily.
- Application: on every build for automated SAST and SCA, plus scheduled DAST against staging.
- Database: on provisioning and after any config change, then periodically.
- Cloud: continuously through posture-management tooling, because a single console click can open a hole.
- Wireless: periodically and after office or network changes.
The mistake to avoid is assessing one layer thoroughly and ignoring the rest. Attackers do not respect your org chart; they take the easiest path, which is usually the layer you were not watching. For a structured program that covers these layers without overwhelming your team, the Academy has planning material.
FAQ
What is the difference between a vulnerability assessment and a penetration test?
A vulnerability assessment identifies and classifies weaknesses; a penetration test attempts to exploit them to prove real impact and chain them together. Assessments are broad and frequent; pen tests are deep and periodic. They complement each other.
How many types of vulnerability assessment do I actually need?
Cover every layer where you hold real assets: at minimum network, host, and application, plus cloud if you run in a public cloud and database if you store sensitive data. Skipping a layer means an attacker gets a free, unwatched path.
Are authenticated scans better than unauthenticated ones?
For host and database assessments, authenticated (credentialed) scans are far more accurate because they inspect internal state rather than guessing from the outside. Unauthenticated scans still matter — they show what an external attacker sees without credentials.
How often should I run a vulnerability assessment?
Continuous or weekly for network, host, and cloud; per-build for automated application scanning; and after any significant configuration change for databases. New CVEs are published daily, so infrequent scanning leaves long exposure windows.