---
{
  "title": "Vulnerability scanning",
  "summary": "Identify potential weaknesses while validating the findings and operational context.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    6
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Technical Guide to Information Security Testing and Assessment",
      "url": "https://csrc.nist.gov/pubs/sp/800/115/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

A vulnerability scanner checks systems against known patterns, configurations, or indicators of weaknesses. Authenticated and unauthenticated scans have different visibility. Results require review for false positives, applicability, and business context. Scans may affect fragile systems, so define scope and timing. A scan is one input into vulnerability management, not a guarantee of completeness or a substitute for architectural review and manual assessment.

## In practice

A finding suggests an outdated package. The team verifies the installed component, vendor backports, exposure, and available remediation before prioritizing it.

## A common misunderstanding

A reported version match is not always proof of exploitable vulnerability, and no findings do not prove security.

## Check your understanding

What distinguishes scanning from management?

**Think it through:** Management includes ownership, prioritization, remediation, exceptions, and verification over time.

## Understand what the scanner can observe

Unauthenticated scanning generally evaluates exposed services from outside an account boundary. Authenticated scanning can inspect installed packages, local configuration, or other details available to its supplied identity. Neither mode automatically sees everything. A failed login may silently reduce coverage, while a service hidden behind a different network route may never be reached. Coverage and credential success should therefore be reviewed alongside the finding count.

A scanner's detection can rely on a version banner, a configuration check, a response pattern, or a more direct verification. Those methods provide different confidence. A banner might remain unchanged after a vendor backports a security fix. Conversely, a service that conceals its version can still be vulnerable. Read the evidence and detection logic rather than treating the tool's label as proof.

## Triage a fictional result

Suppose a lab scan flags an old web-server package on a training machine. First confirm the host identity and installed package revision. Check the vendor advisory to determine whether that revision includes the fix. Then establish whether the affected feature is enabled and reachable in the relevant deployment. These checks can turn a noisy version match into either a substantiated issue or a documented false positive.

Do not suppress a result merely because exploitation seems difficult. Record the specific reason it does not apply, or the control that reduces current exposure. Compensating controls may change, and a later reviewer needs enough evidence to revisit the decision.

## Make scanning a repeatable process

Choose timing and intensity with system owners, particularly for fragile equipment and production services. Preserve enough configuration information to interpret changes between runs. A lower finding count could reflect remediation, but it could also mean fewer reachable assets, expired credentials, or a disabled check.

For a beginner lab, compare two authorized scans of the same small environment with different visibility. Record which assets were reached, whether authentication succeeded, and which findings require manual verification. Finally, map confirmed issues to an owner and a retest condition. This connects discovery to remediation without confusing scanner output with completed security work.

## Keep exploring

- [[vulnerability-management]]
- [[penetration-testing]]
- [[service-enumeration]]