Scanning cloud assets for vulnerabilities

Why this matters

Vulnerability management in a cloud has a problem traditional scanning never faced: the assets move. A weekly scan of a known address range assumes the things being scanned are still there next week. In an autoscaling estate, an instance can exist for twenty minutes, and a scan that missed it proves nothing about the image it came from.

That single difference reshapes the whole practice. The answer is to scan earlier — the image, the template, the configuration — rather than relying entirely on scanning what happens to be running at the moment the scanner ran.

CompTIA gives vulnerability management one scope bullet out of thirty-one here, and only in a cloud context. Our CySA+ course examines it as a whole domain at CS0-004 depth; this lesson deliberately covers what CV0-004 asks and says so rather than pretending otherwise.

The lesson

Building an asset inventory first, because an unscanned asset is an unknown one

Scanning cannot tell you about something it never looked at, so coverage is the first problem and it is harder in a cloud than it sounds.

Where assets hide:

• Unused regions. Resources created in a region nobody monitors are invisible to a scanner configured for the usual ones.
• Other accounts and subscriptions — a team's sandbox, a project account, something acquired.
• Short-lived instances that exist between scans.
• Container images sitting in registries, unscanned until deployed.
• Serverless functions and their dependency trees, which many traditional scanners do not see at all.
• Managed services, where the provider patches the engine and you are still responsible for the version you pinned and the configuration you chose.

Build the inventory from the platform's own APIs, not from a spreadsheet — query every account and every region for what exists, continuously. That is the only inventory that keeps up, and the provider's asset inventory services exist precisely for this.

Then the operational question is coverage: which assets have been scanned, and which have not? An estate that reports 400 findings across 300 instances sounds informative and is useless if there are 900 instances. Report coverage alongside findings, always, and treat unscanned assets as a finding in their own right.

Tagging (objective 1.8) makes this tractable, giving each asset an owner and an environment so findings can be routed to someone who can act.

Agent-based and network-based scanning, and the ephemeral instance neither catches

Network-based scanning probes from outside: reachable ports, service versions, exposed interfaces. It sees what an attacker on the network sees, needs no installation, and misses anything it cannot reach — which in a correctly-segmented cloud is most things. It is also slow and can be disruptive.

Agent-based scanning runs inside the instance: full package inventory, patch levels, configuration, regardless of network position. Far more accurate and complete, and it requires the agent to be installed — which means baking it into the image (objective 2.4), because an agent installed by hand will be missing from the next instance the scaling group creates.

Use both. The agent tells you what is installed; the network scan tells you what is exposed, and those are different questions — an unexposed critical vulnerability and an exposed medium one need different responses.

Neither reliably catches the ephemeral instance. An instance that lived for an hour between scans was never assessed, and if that hour included serving traffic, the exposure was real. The resolutions, in order of effectiveness:

1. Scan the image, not the instance. Every instance comes from an image; assessing the image assesses everything built from it. This is the primary answer and it fits immutable infrastructure exactly (objective 3.1).
2. Scan in the build pipeline, so a vulnerable image is never published.
3. Agent reports on boot, so even a short-lived instance registers what it is running.
4. Keep image freshness as a metric. "No instance older than N days, built from an image no older than M days" is a stronger control than any scan frequency, because it bounds exposure by construction.

Scanning images in the pipeline so a vulnerability never reaches production

This is the shift that makes cloud vulnerability management work, and it is where the security domain meets objective 5.3.

Scan at three points:

• On build. Every image and container image is scanned as it is produced. Findings go to the team that built it, immediately, while the change is fresh.
• As a gate. The pipeline fails on findings above an agreed severity, so a vulnerable artefact cannot be promoted. This needs care: a gate set too strictly stops all delivery and gets bypassed, which is worse than a gate set sensibly. Start with critical-and-exploitable, with a documented exception path.
• Continuously, on stored artefacts. An image scanned clean in March is not clean in June, because new vulnerabilities are disclosed against software that did not change. Rescanning the registry is what catches this, and it is the step most often missing.

Also scan the things that are not images:

• Dependencies — the libraries an application pulls in, which are the majority of most applications' code and the majority of their vulnerabilities.
• Infrastructure code, for misconfiguration (objective 2.2's policy scan).
• The base images you inherit, and prefer minimal ones: a smaller image carries fewer packages and therefore fewer findings, which is a real security benefit and not just tidiness.

The cultural shift matters as much as the tooling: findings arrive with the team that can fix them, at the moment they can fix them cheaply, rather than as a quarterly report to an operations team who did not write the code.

Cloud configuration scanning as a separate discipline from host vulnerability scanning

This distinction is important and frequently blurred.

Vulnerability scanning asks: is the software out of date or known-flawed? Configuration scanning asks: is the cloud environment set up safely?

They find completely different things, and in cloud incidents the configuration findings are more often the cause:

• Storage buckets readable by anyone
• Security groups allowing management ports from the whole internet
• Identity policies granting far more than needed
• Logging or audit trails disabled
• Encryption not enabled
• Public snapshots or public machine images
• Accounts without multifactor authentication

None of that is a software vulnerability, and a host scanner reports none of it. The tooling category is cloud security posture management, and the provider's own security services do much of it.

Two properties that make it different in kind:

• It is continuous, not periodic. Configuration changes constantly, and a posture check is cheap because it reads the platform's API rather than probing a host.
• It maps to benchmarks — recognised configuration standards — so findings come with an agreed definition of "correct" rather than an opinion.

The strongest version is to push the check left into the infrastructure code (objective 2.2) and further into guardrails that refuse the misconfiguration outright (objective 6.5). Detecting a public bucket is good; making it impossible to create one is better.

Authenticated scans, and the credential handling that has to be right first

An authenticated scan logs into the target and reads its actual state. An unauthenticated scan infers from outside.

The difference in quality is large. Unauthenticated scanning guesses versions from banners, cannot see installed packages, and produces both false positives (a version string that looks vulnerable but has been back-patched) and false negatives (anything not exposed). Authenticated scanning reads the package database and is definitive.

So authenticated scanning is the default for anything you own — and it means the scanner holds credentials to everything in the estate, which makes the scanner itself a high-value target and a serious piece of security engineering:

• Use platform identity rather than stored passwords. A role the scanner assumes, with short-lived credentials, is far better than an account with a permanent password — the same principle as objective 2.4's instance roles.
• Least privilege. Read-only, scoped to what the scan needs. A scanner with administrative rights is an estate-wide compromise waiting for one bad day.
• Rotate and audit. Scanner credential use should be logged and monitored like any other privileged access; unexpected use of them is a strong signal.
• Protect the results. A vulnerability report is a map of where to attack. It deserves the same access control as the credentials.

Keep unauthenticated scanning as well, from outside, because it answers the different and valuable question: what does an attacker actually see? That external view is what catches the thing you did not know was exposed.

What to take into the exam

• Coverage first. Report scanned-versus-total; unscanned assets are a finding. Inventory from the platform API across all accounts and regions.
• Agent = what is installed. Network scan = what is exposed. Use both.
• Ephemeral instances defeat periodic scanning. Scan the image and gate the pipeline, and track image freshness as the real control.
• Rescan stored images: a clean image becomes vulnerable without changing.
• Configuration scanning is a separate discipline from vulnerability scanning and finds what actually causes cloud incidents. It is continuous and benchmark-based.
• Authenticated scans are definitive; unauthenticated ones answer "what can an attacker see". The scanner's credentials must be role-based, least-privilege and audited.