A vulnerability scanner can finish successfully while part of the environment remains untested. A newly provisioned VM may never enter the scanner target set. A host may have a scan record that is months old. An external scan may show that a service is unreachable from the internet while saying nothing about whether it is reachable from a peered VPC.
The 2026 Verizon Data Breach Investigations Report found that exploitation of vulnerabilities accounted for 31% of breaches, making it the leading initial access vector in its dataset.
In this article, we break down how vulnerability testing works in practice, the main testing types and methods, and seven practices our security team uses to evaluate test quality. With technical input from Anna Maeva, Vulnerability Management Expert at Cloudaware, we also show how to measure coverage, identify stale or missing scan evidence, and verify that a vulnerability was actually re-tested after a change.
Key insights
- A successful scan does not prove complete vulnerability testing coverage. Teams need to compare scan evidence with the current in-scope asset inventory and account for assets that were never tested or whose results are no longer current.
- The testing method determines what a result can actually prove. Network scans, authenticated host checks, cloud workload testing, container analysis, and application testing answer different security questions and should not be treated as interchangeable.
- Test location changes the meaning of a result. A service that is unreachable externally may still be exposed from a peered VPC, VPN, management subnet, or another internal network path.
- Coverage quality depends on both completeness and freshness. Scanner job status, asset coverage, and Last Scan Date are separate signals, and combining them gives a more accurate view of whether testing evidence is still usable.
- Multiple vulnerability sources can create both gaps and duplication. The useful question is not how many scanners are connected, but which assets and conditions each source actually covers.
- Remediation should end with a technical re-test. Closing a ticket or applying a fix does not confirm that the original vulnerable condition is gone; the relevant test needs to be repeated after the change.
What is vulnerability testing?
Vulnerability testing is the use of technical checks to identify or confirm security weaknesses within a defined system, network, infrastructure, or software scope. Depending on the target, security vulnerability testing may use automated vulnerability scanning, authenticated host inspection, network probing, configuration checks, application-specific testing, or a combination of methods.
The terminology overlaps across security disciplines. NIST SP 800-115 uses the broader category of technical information security testing and assessment and covers techniques such as vulnerability scanning and penetration testing, each with different objectives, strengths, and limitations.
For this article, we will use this distinction:
| Term | Question it primarily answers | Role here |
|---|---|---|
| Vulnerability scanning | What known weaknesses can this automated source detect? | One technique used in vulnerability testing |
| Vulnerability testing | What weaknesses can we identify or confirm in this defined technical scope? | Main topic |
| Vulnerability assessment | What weaknesses exist, and what do the results mean for the assessed scope? | Adjacent activity |
| Penetration testing | Can controlled exploitation demonstrate impact or an attack path? | Separate testing discipline |
| Vulnerability management | How are findings prioritized, assigned, remediated, excepted, and tracked over time? | Broader operating process |
Remediation SLAs, ownership models, exception governance, and program metrics belong to vulnerability management best practices. Vulnerability testing stays focused on the technical evidence needed to determine whether a weakness exists.
Vulnerability testing scopes and methods
Vulnerability testing takes different forms because the evidence needed to confirm a weakness depends on what is being tested. A host-level check can verify installed packages and patch state, a network test can establish which services are reachable, while application testing can expose weaknesses that infrastructure-level methods cannot observe.
For enterprise environments, the main testing scopes are systems, network infrastructure, cloud workloads and containers, and applications.
System vulnerability testing
System vulnerability testing checks hosts and operating systems for weaknesses in installed software, patch state, running services, and local configuration. In IT vulnerability testing, this scope is most useful when the security question depends on what is actually present on the machine.
Typical checks include:
- Installed packages and software versions
- Missing security updates
- Unsupported operating systems or software
- Running services
- Host-level security configuration
The depth of the evidence matters. A remote test may identify an SSH service and infer its version, while an authenticated or agent-based check can confirm the installed package, patch level, and operating-system state.
Network and infrastructure vulnerability testing
Network and infrastructure vulnerability testing checks which systems, ports, protocols, and services are reachable from a particular network position.
It can be used to identify:
- Reachable hosts
- Open ports
- Exposed services
- Protocol and service versions
- Internet-facing interfaces
- Internal network exposure
The test location is part of the result. A service that cannot be reached from the public internet may still be accessible from a peered VPC, internal subnet, VPN, or administrative network.
For that reason, "not reachable" should always be read as not reachable from the vantage point used for the test. If the security question concerns internal exposure, an external scan alone cannot answer it.
Cloud workload and container vulnerability testing
Cloud workload vulnerability testing checks the software and components running in cloud compute, virtual machines, container images, and deployed workloads.
The challenge is that the asset being tested may change quickly. A VM can be replaced, an image can be redeployed, or a workload can move while older scan evidence still exists.
Useful evidence can include:
- Operating-system and package vulnerabilities on cloud VMs
- Vulnerable components in container images
- Software versions in running workloads
- The image or artifact from which a workload was deployed
- The current asset associated with the scan result
For example, an image scan may show that a vulnerable package exists in an artifact. Runtime or host-level evidence answers a different question: whether the affected component is actually present in the deployed workload being investigated.
This is also why cloud inventory matters to vulnerability testing. A finding tied to a terminated instance says little about the state of the workload that replaced it.
Application vulnerability testing
Application vulnerability testing looks for weaknesses in application code, dependencies, APIs, and runtime behavior that host and network testing cannot fully observe.
Methods can include static application security testing (SAST), dynamic application security testing (DAST), software composition analysis (SCA), API testing, and targeted manual testing.
The practical distinction between the four scopes is the question each one can answer:
| If you need to verify | Start with |
|---|---|
| Installed software, package, or patch state | System vulnerability testing |
| Network reachability or exposed services | Network and infrastructure vulnerability testing |
| Vulnerable components in a VM, image, or deployed workload | Cloud workload and container vulnerability testing |
| Application behavior, code, dependencies, or API weaknesses | Application and API testing |
How vulnerability testing works
A reliable vulnerability testing process starts with the security question, not with the scanner**.** The testing method should be chosen after the team knows what it is trying to prove and which assets are expected to be covered.
A practical process has six steps:
- Define the question. Determine whether you need to prove that a package is installed, a service is externally reachable, a workload contains an affected component, or another specific condition exists
- Establish the scope. Identify the current systems, workloads, accounts, subscriptions, applications, or endpoints expected to be tested
- Choose the method. Select authenticated, unauthenticated, agent-based, network, API-based, application-specific, or other testing capable of producing the required evidence
- Execute and preserve context. Keep the affected asset, source, method, timestamp, and result associated with the observation
- Validate ambiguous results. Determine whether a positive finding has sufficient evidence and whether an absent finding means "not vulnerable" or "not currently tested"
- Re-test after change. Repeat a method capable of observing the original condition after the relevant system state changes
NIST SP 800-115 takes the same underlying approach: technical testing techniques have different capabilities and limitations, so the method should follow the assessment objective rather than be treated as universally sufficient.
Once a weakness has been confirmed, teams may need a deeper vulnerability analysis to determine applicability, exploitability, business context, and treatment. That is a downstream decision from the testing question itself.
7 vulnerability testing practices from our security team
For this article, we checked these practices in October 2026 against NIST SP 800-115, CIS Controls v8.1, PCI DSS vulnerability-scanning requirements, and the 2026 Verizon Data Breach Investigations Report. Cloudaware product screenshots and workflow examples were also reviewed against the current product UI and documentation.
Technical review: Anna Maeva, Vulnerability Management Expert at Cloudaware
1. Build the test scope from current inventory, not the scanner's target list
Start with the assets that should be tested, then verify which of them actually have current testing evidence.
A scanner only reports on assets it knows about. A VM created after scanner enrollment, an account added through a different provisioning path, or infrastructure covered by another scanner can remain outside its target population even when every configured scan completes successfully.
Cloudaware's SecOps workflow demonstrates this problem in multi-cloud and hybrid environments, where customers may use multiple cloud providers, on-premises infrastructure, and different vulnerability scanners. In one demo environment, coverage is checked across AWS, Azure, and vCenter rather than inferred from any individual scanner.
Illustrative Cloudaware scan coverage view showing where infrastructure assets have scan evidence and where coverage is missing across operating systems, environments, accounts, applications, and platforms.
The approach also matches CIS Controls v8.1. CIS Control 1 requires an inventory of enterprise assets, including cloud assets, while Safeguard 7.5 uses the enterprise asset inventory as an input for internal vulnerability scanning.
For testing teams, the implication is concrete: calculate coverage against the current in-scope asset population, not only against the targets already configured in the scanner.
2. Define the security question before choosing the test
Choose a vulnerability testing method based on the condition you need to confirm, not on whichever scanner is already available.
"Is this workload vulnerable?" is usually too broad to define a useful test. The real question may be whether a particular package is installed, whether a service is externally reachable, whether a container contains an affected component, or whether a previous vulnerability is still present after remediation.
Different questions require different evidence:
| Security question | Evidence that can answer it |
|---|---|
| Is the service reachable from the internet? | Testing from the relevant external vantage point |
| Is the vulnerable package installed? | Authenticated or host-level package evidence |
| Does this workload have current testing coverage? | Current asset record, expected source, and recent scan evidence |
| Did remediation remove the vulnerable condition? | A fresh test capable of observing the original condition |
This is consistent with NIST SP 800-115 in principle, although the more useful next step for a confirmed finding is Cloudaware's guide to vulnerability analysis. NIST's technical guidance emphasizes choosing testing techniques according to the assessment objective and understanding the capabilities and limitations of each method.
3. Use authenticated or host-level testing when network evidence is not enough
Remote vulnerability testing can show what a system exposes, but it cannot always confirm what is installed or configured on the host.
A network scan may identify an SSH service, observe an open port, or infer a software version. That may be sufficient when the security question concerns exposure. It is weaker evidence when the decision depends on installed packages, patch state, operating-system details, or software that does not expose a reliable network signature.
Authenticated or agent-based testing can inspect that host-level state directly. This does not make authenticated testing universally better. If the question is whether TCP/443 is reachable from the internet, host credentials cannot substitute for an external network test.
CIS Safeguard 7.5 explicitly requires both authenticated and unauthenticated vulnerability scans for internal enterprise assets. PCI DSS Requirement 11.3.1.2 likewise requires authenticated internal vulnerability scanning, with sufficient privileges to access the system resources needed for a thorough scan, where the target supports credentials.
The testing depth should therefore increase when the decision requires evidence that a network-level observation cannot provide.
4. Test from the vantage point that matches the security question
A negative result only tells you what was not observable from the position where the test ran. A service that cannot be reached from the public internet may still be accessible from a peered VPC, a VPN, an administrative subnet, or another internal network segment. Network controls between the scanner and target can change the result without changing the state of the target itself.
NIST distinguishes external and internal testing for this reason. Its technical testing guidance notes that individual techniques provide different views of the environment and that firewalls and other network controls can affect what a scanner can observe.
This distinction becomes more important as cloud network paths span accounts, VPCs, transit gateways, routing rules, and security controls. Cloudaware's SRE workflow demonstrates how Cloudaware MCP can use CMDB relationship data to trace how an AWS instance reaches the internet through its surrounding network infrastructure.
That context does not replace an external or internal vulnerability test, but it helps establish the access path and testing vantage point that matter for the question being investigated.
Cloudaware MCP uses CMDB relationship data to trace an AWS instance's egress path through its VPC route table and NAT gateway.
For vulnerability testing, define the access path that matters first. Then run the test from a location capable of observing that path.
5. Measure asset coverage and scan freshness, not scanner job success
A successful scanner job is an execution result. It is not proof that the current environment has complete vulnerability testing coverage. Coverage has two separate questions: whether the intended asset was tested and whether the available evidence is recent enough to support the current decision.
This distinction matters because scan evidence ages independently of scanner health. A scanner may be operating normally while a newly provisioned workload has never been tested, or while the latest evidence for another asset predates a material configuration change.
Treat these signals separately:
| Signal | What it tells you | What it does not prove |
|---|---|---|
| Scanner job status | Whether the scheduled scan executed successfully | Whether every current in-scope asset was included |
| Asset coverage | Whether an in-scope asset has testing evidence from the expected source | Whether that evidence is still current |
| Last scan date | How recently the asset was tested | Whether the selected method was capable of detecting the condition in question |
CIS uses the same asset-centered logic. Safeguard 7.6 starts with the enterprise asset inventory, identifies externally exposed assets, and then distinguishes assets covered by vulnerability scanning software from those that are not covered. Scanner configuration is evaluated separately from actual asset coverage.
Cloudaware ties vulnerability scan evidence and Last Scan Date to the individual CI, making scan freshness visible at the asset level.
6. Use complementary sources, then check where they overlap and where they leave gaps
Multiple vulnerability sources are useful when they cover different assets or provide different evidence. Simply adding another scanner does not guarantee broader testing coverage.
This is a recurring pattern in Cloudaware environments. A company may use cloud-native vulnerability data for part of AWS, a third-party scanner for another infrastructure segment, and different tooling for on-premises systems. Cloudaware normalizes findings from multiple sources and relates them to CMDB assets, making it possible to evaluate coverage across sources rather than reviewing each scanner independently.
For teams operating several scanners, the useful question is not how many sources are connected. It is which assets and security conditions each source can actually cover.
7. Re-test the original condition after a fix or significant change
Closing a remediation ticket does not verify that the vulnerable condition disappeared. The relevant technical test needs to be repeated against the changed system.
If a finding identified a vulnerable package on a host, the re-test should establish whether that host, or the workload that replaced it, still presents the same vulnerable condition. If the issue involved network exposure, verification should repeat a test capable of observing that exposure.
Cloudaware supports on-demand scanning when a team needs fresh verification before the next scheduled scan cycle.
The Cloudaware scan request action lets teams trigger a fresh scan for a selected asset after remediation or another significant change.
PCI DSS Requirement 11.3.1.3 requires internal vulnerability scans after significant changes, resolution of high-risk and critical vulnerabilities, and rescans as needed. CIS Safeguard 7.7 similarly compares current and previous scan results to determine whether previously detected vulnerabilities remain present.
Recent industry data shows why technical verification still matters. The 2026 Verizon DBIR, using aggregated vulnerability-management data from more than 13,000 organizations, found that only 26% of CISA Known Exploited Vulnerabilities were fully remediated in 2025, down from 38% the previous year. Median time to full remediation increased from 32 to 43 days.
How to know whether vulnerability testing coverage is complete
Vulnerability testing coverage is complete only relative to a defined scope and evidence requirement. "No vulnerabilities found" is not a useful conclusion if the team cannot establish whether the expected assets were tested recently enough, with methods capable of observing the conditions that mattered.
Review coverage across these dimensions:
| Coverage check | Question to answer |
|---|---|
| Scope coverage | Does every in-scope asset have an expected testing source? |
| Current coverage | Does every current asset have test evidence? |
| Freshness | Is the latest evidence recent enough for the decision being made? |
| Method coverage | Can the selected method observe the condition being tested? |
| Vantage-point coverage | Was the test performed from the network or system context relevant to the question? |
| Source overlap | Are multiple sources covering the same assets while another part of the environment remains uncovered? |
| Re-test evidence | Was the affected condition tested again after the relevant change? |
This is where Cloudaware fits into vulnerability testing without replacing specialist testing tools. Cloudaware correlates vulnerability-source data with current CMDB inventory so security teams can identify where testing evidence exists, where it is stale or missing, and where scanner coverage overlaps.
Once the problem moves from evidence coverage into prioritization, ownership, remediation, and reporting, it becomes part of the broader cloud vulnerability management workflow.