Vulnerability Scanning: Network, App, Container, Cloud
A federal contractor deploys a new microservice on a Friday afternoon. By Monday morning, the Citrix Bleed vulnerability (CVE-2023-4966) in their load balancer has been exploited, session tokens exfiltrated, and an attacker is laterally moving through systems that last week's scan marked clean. The scan was not wrong at the time it ran. The environment changed, and the scanning cadence did not keep up.
Vulnerability scanning is the systematic identification of known security weaknesses across your infrastructure. It is also the single most frequently mandated security control across compliance frameworks -- and the one most frequently done badly.
Why This Matters Now
Three forces converged in 2025-2026 that changed vulnerability scanning from a quarterly checkbox into a continuous operational requirement:
CISA BOD 26-04 mandates risk-based remediation timelines tied to exploitation evidence, not just CVSS severity. You cannot remediate what you have not detected, and you cannot prioritize by exploitation probability if your scanner only runs monthly.
The NVD April 2026 policy change shifted enrichment responsibilities toward CNAs, fragmenting the single source of truth that scanners historically relied on for plugin development. Scanners with independent vulnerability research teams now outpace those waiting for NVD-published CPE data.
The MOVEit breach wave (CVE-2023-34362, 2,500+ organizations compromised) demonstrated that mass exploitation of a single vulnerability can outrun monthly scanning cadences. Organizations scanning weekly or continuously detected and patched before the exploitation campaign reached them. Organizations scanning monthly did not.
Scanning Types Across Your Environment
Network Vulnerability Scanning
The foundational layer. Network scanning probes hosts, services, and devices accessible over the network -- servers, workstations, routers, switches, firewalls, printers, IoT devices.
What it detects:
- Missing operating system and application patches
- Misconfigured services (default credentials, unnecessary services enabled)
- SSL/TLS weaknesses (expired certificates, deprecated protocols, weak cipher suites)
- Network device firmware vulnerabilities
- End-of-life software still in production
- Open ports exposing unnecessary attack surface
Scanning modes:
- Unauthenticated -- external perspective, tests what an attacker can see without credentials. Useful for perimeter assessment but structurally limited in detection depth.
- Authenticated -- logs into targets using service accounts, queries package managers, reads configurations. Dramatically higher accuracy and coverage. PCI DSS v4.0 now mandates authenticated internal scanning.
Cadence: Weekly minimum for internet-facing assets. Monthly is the compliance floor for internal assets under most frameworks. Continuous or daily for environments under CISA BOD 26-04.
Web Application Scanning (DAST)
Dynamic Application Security Testing sends crafted HTTP requests to running web applications and analyzes responses for vulnerability indicators. Unlike SAST (which reads source code), DAST operates against the deployed application the way an attacker would.
What it detects:
- SQL injection and NoSQL injection
- Cross-site scripting (reflected, stored, DOM-based)
- Authentication and session management flaws
- Server-side request forgery (SSRF)
- Insecure direct object references
- Security header misconfigurations
- API endpoint vulnerabilities
Why it matters separately: Network scanners detect infrastructure vulnerabilities. DAST detects application-layer vulnerabilities that only manifest in the context of your custom code. A server can be fully patched at the OS level while the application running on it is trivially exploitable. The MOVEit vulnerability was an application-layer SQL injection -- no amount of OS patching would have prevented it.
Cadence: Before every production deployment (integrated into CI/CD pipeline) and quarterly comprehensive scans for compliance evidence.
Container Image Scanning
Containers introduce a fundamentally different vulnerability lifecycle. A vulnerable base image propagates to every container instance launched from it, and ephemeral workloads may exist for seconds -- too briefly for traditional scanning approaches.
What it detects:
- OS package vulnerabilities in base images (Alpine, Debian, Ubuntu layers)
- Application dependency vulnerabilities (npm, pip, Maven, Go modules)
- Hard-coded secrets (API keys, private keys, credentials baked into layers)
- Misconfigured base images (running as root, unnecessary packages installed)
- Known-malicious layers from compromised public registries
Where scanning occurs:
- Build time -- in CI/CD pipeline before image push (shift-left, cheapest to fix)
- Registry -- on push to container registry (gate before deployment)
- Runtime -- continuous scanning of running containers for newly disclosed CVEs affecting deployed images
See our dedicated container security guide for Kubernetes-specific hardening.
Cadence: Every build (pipeline-integrated), continuous registry rescanning, and runtime admission control blocking unscanned or Critical-finding images.
Cloud Security Posture Management (CSPM)
Cloud infrastructure is not servers you scan -- it is configuration you audit. CSPM evaluates your cloud resource configurations against security benchmarks and best practices.
What it detects:
- Overly permissive IAM policies (wildcard actions, cross-account trust)
- Public-facing storage buckets or databases
- Unencrypted data stores (S3, RDS, Cosmos DB)
- Missing logging and monitoring configurations
- Network security groups allowing unrestricted inbound traffic
- Resources deployed outside approved regions
- Drift from infrastructure-as-code templates
Why it matters: Misconfigured cloud resources are the leading cause of data breaches in cloud environments -- not unpatched software, but permissive IAM policies and exposed storage. Traditional network scanning does not detect these issues because they are configuration state, not network-accessible vulnerabilities.
Cadence: Continuous. Cloud configurations change constantly through console access, IaC deployments, and API automation. Point-in-time scanning misses the configuration that was permissive for 47 minutes before someone caught it.
Static Application Security Testing (SAST)
Analyzes source code or compiled binaries for security flaws without executing the application. Finds vulnerabilities that DAST cannot reach -- dead code paths, race conditions, cryptographic weaknesses. For a detailed comparison, see SAST vs DAST vs SCA.
Authenticated vs. Unauthenticated: The False Economy
Here is the contrarian opinion: organizations that run only unauthenticated scans are spending budget to feel safe while remaining structurally blind.
Unauthenticated scanning sees what an external attacker sees -- useful for perimeter assessment, but limited to banner-based version guessing and service probing. It cannot verify actual patch levels, cannot assess configurations, and cannot reach the majority of the scanner plugin library that requires system-level access.
The numbers are stark:
| Metric | Unauthenticated | Authenticated |
|---|---|---|
| Plugin coverage | 20-30% of scanner library | 85-95% of scanner library |
| Version accuracy | Banner-inferred (often wrong) | Package-manager confirmed |
| Configuration audit | Not possible | Full capability |
| False positive rate | 15-40% (version guessing) | 2-5% (confirmed state) |
| Compliance acceptance | Shrinking (PCI DSS v4 rejected it) | Universal |
The operational cost of authenticated scanning is credential management -- maintaining service accounts with read access to targets. That is a solvable problem. The operational cost of unauthenticated scanning is invisible vulnerabilities and wasted analyst time triaging false positives. That is an unsolvable problem without changing the scanning approach.
Compliance Framework Requirements
Virtually every compliance framework mandates vulnerability scanning. The differences are in cadence, scope, and remediation timelines:
| Framework | Scanning Requirement | Remediation Timeline |
|---|---|---|
| NIST 800-171 | 3.11.2: Periodic and event-driven scans | Risk-based |
| FedRAMP | RA-5: Monthly OS/infra, web app, and database scans | 30/90/180 days by severity |
| PCI DSS v4.0 | 11.3: Quarterly + after changes (authenticated) | 30 days Critical/High |
| CMMC Level 2 | Mirrors 800-171 3.11.2 (RA.L2-3.11.2) | Defined by organization |
| HIPAA | 164.308(a)(8): Periodic technical evaluation | Risk-based |
| CISA BOD 26-04 | Risk-based continuous | By exploitation evidence |
Note: "monthly" is the compliance floor, not the security recommendation. Organizations experiencing active threats or managing internet-facing infrastructure should scan weekly or continuously.
Prioritization Beyond CVSS
Raw CVSS scores are a starting point, not an answer. A CVSS 9.8 vulnerability on an air-gapped test server is less urgent than a CVSS 7.5 vulnerability on your internet-facing production database. Effective prioritization layers multiple signals:
- EPSS score -- statistical probability of exploitation in the next 30 days
- CISA KEV status -- confirmed active exploitation (immediate priority regardless of CVSS)
- Asset criticality -- business impact rating of the affected system
- Network exposure -- internet-facing versus internal-only versus air-gapped
- Compensating controls -- existing mitigations that reduce exploitability (WAF, network segmentation, EDR)
- Data sensitivity -- what the attacker gains if exploitation succeeds
This multi-factor approach is what risk-based prioritization means in practice. It is also what CISA BOD 26-04 demands -- remediation priority driven by exploitation likelihood and impact, not CVSS alone.
Operationalizing Scan Results
Detection without remediation is surveillance without defense. The operational model that makes scanning useful:
- Ingest -- scan results flow into a centralized platform (not spreadsheets, not email)
- Deduplicate -- the same vulnerability found by multiple scanners appears once, not three times
- Prioritize -- multi-factor scoring ranks findings by actual risk
- Assign -- findings route to system owners with context and remediation guidance
- Track -- remediation progress measured against framework timelines
- Verify -- re-scan confirms the vulnerability is resolved (not just "patch deployed")
- Evidence -- the complete lifecycle generates compliance artifacts for auditors
The failure mode is step 1: scan results that live in the scanner console, reviewed once, then forgotten until the next audit. Scanning that does not connect to remediation tracking and compliance evidence is wasted compute.
Remediation Timelines by Framework
| Severity | FedRAMP | PCI DSS v4 | CISA BOD 26-04 | Best Practice |
|---|---|---|---|---|
| Critical (CVSS 9.0+) | 30 days | Immediate | By exploitation evidence | 48-72 hours |
| High (CVSS 7.0-8.9) | 30 days | 30 days | Risk-based | 7-14 days |
| Medium (CVSS 4.0-6.9) | 90 days | 90 days | Risk-based | 30-60 days |
| Low (CVSS 0.1-3.9) | 180 days | Quarterly | Risk-based | 90+ days |
Key Takeaways
- Vulnerability scanning spans five domains: network, web application (DAST), container, cloud posture (CSPM), and static analysis (SAST)
- Authenticated scanning covers 85-95% of your plugin library versus 20-30% unauthenticated -- PCI DSS v4 now mandates it
- Monthly scanning is the compliance floor, not the security recommendation; CISA BOD 26-04 demands risk-based continuous detection
- CVSS alone is insufficient for prioritization -- layer EPSS, KEV status, asset criticality, and network exposure
- Scanning without remediation tracking and compliance evidence generation is wasted compute
- No single scanner covers all five domains; multi-source ingestion eliminates blind spots
How Advisedly Helps
Advisedly integrates with vulnerability scanners supporting 350,000+ plugins to ingest findings across network, application, container, and cloud scanning. The platform deduplicates cross-scanner results, applies risk-based prioritization incorporating CVSS, EPSS, and CISA KEV data, and tracks remediation against framework-defined timelines. Compliance evidence generates automatically as findings move through the remediation lifecycle -- from discovery through verification. With 500+ supported compliance frameworks mapped against your scan findings, auditor reporting is a query, not a project. Contact begin@advisedly.ai to unify your vulnerability scanning program.
Frequently Asked Questions
How often should we run vulnerability scans?
It depends on your environment and compliance obligations. Internet-facing assets: weekly minimum, daily or continuous preferred. Internal infrastructure: monthly minimum for compliance, weekly for security maturity. Containers: every build plus continuous registry rescanning. Cloud configurations: continuously. CISA BOD 26-04 pushes toward risk-based continuous scanning for all federal systems. The right answer is "frequently enough that you detect new vulnerabilities before attackers exploit them" -- for most organizations, that means at least weekly for critical assets.
What is the difference between vulnerability scanning and penetration testing?
Vulnerability scanning is automated, broad, and frequent -- it runs thousands of known checks against your entire environment. Penetration testing is manual, deep, and periodic -- a human tester attempts to chain vulnerabilities, bypass controls, and achieve specific objectives (data exfiltration, privilege escalation). Scanning finds known vulnerabilities at scale. Penetration testing finds novel attack paths that scanners miss. You need both: scanning continuously, penetration testing annually or after significant changes.
Should we scan production systems or only test environments?
Both, but production is where it matters most. Scanning only test environments tells you what might be vulnerable in production. Scanning production tells you what is vulnerable right now. The concern about scan-induced outages is valid for aggressive scanning modes, but authenticated credentialed scanning with appropriate rate limiting is safe for production systems. Every compliance framework expects production scanning -- test-only scanning will not satisfy an auditor.
How do we handle scan results for systems we cannot patch?
Legacy systems running end-of-life software that cannot receive patches require compensating controls documented in your risk management process. Options: network isolation (prevent lateral movement), enhanced monitoring (detect exploitation attempts), virtual patching (WAF rules, IPS signatures), and planned migration timelines. Document the residual risk in your POA&M. Auditors accept compensating controls when accompanied by a credible remediation roadmap.
What scanner coverage do we need for FedRAMP?
FedRAMP requires monthly operating system/infrastructure, web application, and database vulnerability scanning, plus continuous monitoring through the ConMon program. All scanning must be authenticated. Results must demonstrate remediation within 30/90/180-day timelines by severity. You need network scanning, DAST, and ideally CSPM for cloud environments. FedRAMP 3PAOs will validate that your scanning covers your entire authorization boundary -- gaps in coverage scope are audit findings.
<!-- LI hook: 2,500 orgs had scanners. They still got breached via MOVEit. -->First developed from vulnerability management program architecture documentation for the Advisedly compliance platform.