A vulnerability management program built around a static asset list starts failing the moment infrastructure gets created by API call instead of by a technician racking a server. The list was never wrong on purpose: someone exported it from a CMDB, an IP range scan, or a spreadsheet a compliance auditor asked for once and nobody retired. In a data center, that list stayed roughly accurate for months because hosts had a physical lifecycle. In AWS, Azure, or GCP, an autoscaling group can launch forty instances at 2 a.m. and terminate them by breakfast, and none of them ever appear in a list that was last refreshed on a Tuesday.
Why a static asset list breaks when infrastructure is created by API call
Traditional vulnerability management assumes discovery is a periodic event: run a network sweep, reconcile against the CMDB, schedule the next sweep in thirty or ninety days. That cadence matches hardware that gets provisioned through a change ticket and decommissioned through another one. Cloud infrastructure removes both tickets. A developer merges a Terraform change, a CI pipeline applies it, and a new subnet full of workloads exists before the security team’s next scheduled scan window even opens.
The practical failure mode is not “we missed a host.” It is that the denominator itself is wrong. If your coverage metric is “hosts scanned divided by hosts in the CMDB,” and the CMDB is stale, you can report 98 percent coverage while genuinely covering 60 percent of what is running in production. Cloud-native discovery has to invert the model: instead of scanning against a list, pull the list from the cloud provider’s own inventory API (AWS Config, Azure Resource Graph, GCP Cloud Asset Inventory) on every cycle, then scan whatever comes back. The list becomes the output of discovery, not an input to it, which is why cloud programs move their asset inventory and attack surface management off a spreadsheet and onto something that queries the provider directly, on a schedule measured in hours, not quarters.
Three broken assumptions: ephemeral hosts, autoscaled fleets, immutable images
Ephemeral hosts
A host that lives for six hours cannot be the unit you track remediation against. If your ticketing system opens a finding against instance i-0a1b2c3d and that instance is terminated by the autoscaler before the ticket is triaged, the finding is now permanently open against a resource that no longer exists, forever inflating your backlog and forever understating your real exposure. The fix is to track findings against the image or template that produced the host, not the instance ID. An EC2 instance dies; the AMI it was launched from persists until someone builds a new one.
Autoscaled fleets
A fleet behind an autoscaling group is not “one asset with N replicas” in the way a load-balanced pair of physical servers used to be. Every scale-out event can, in theory, launch instances from a slightly different AMI if the launch template was updated between events, which means a single autoscaling group can be running two or three different patch levels simultaneously without anyone changing a configuration on purpose. Scanning one instance and assuming the result applies to the group is a common and costly shortcut. The correct check is to sample across launch template versions currently in use, not just across running instances, and to alert when more than one AMI version is active in a group for longer than a defined grace period, for example four hours after a deployment should have completed.
Immutable images
Immutable infrastructure means you do not patch a running container or VM in place; you rebuild the image and redeploy. That is good security hygiene, but it changes what “remediation” means. A finding on a running container is not fixed by SSH-ing in and running apt-get upgrade, because the next deployment will overwrite that fix with the old, vulnerable base layer. Remediation has to happen in the Dockerfile, the base image, or the golden AMI pipeline, then propagate through a rebuild and redeploy. Verifying the fix means scanning the new image in the registry before it ships and re-scanning the running workload after rollout, not just checking a box on the old instance.
Ownership shift: who fixes the CVE when the app team owns the image
In a traditional data center, infrastructure and security teams shared a fairly clean split: ops patched the OS, security patched or compensated for application-layer findings, and both reported into the same change advisory board. Cloud shifts a large share of that OS-layer responsibility onto whichever team owns the Dockerfile or the Terraform module, which is often an application team with no security headcount and no patching SLA of its own.
This ownership question has to be answered before a scanner ever runs, not after a finding lands in someone’s queue with no owner tag. Two mechanisms make this tractable. First, enforce a mandatory owner tag (team, repository URL, or Slack channel) at the infrastructure-as-code layer, rejected at the CI pipeline if missing, so every resource the scanner finds already carries a routing target. Second, route findings by resource tag rather than by CVE severity alone, because a critical CVE on a sandbox resource tagged env:dev and a medium CVE on a resource tagged env:prod, pci:true do not belong in the same queue with the same urgency. Platforms that automate this step, such as SITEY, resolve the tag-to-owner mapping during triage and open the remediation ticket against the repository that owns the image rather than against a generic infrastructure backlog, which is the difference between a finding getting fixed in the next sprint and it sitting untouched because nobody was sure whose job it was.
What carries over unchanged: severity models, SLAs, exception handling
It is tempting to treat cloud vulnerability management as a wholesale replacement for the traditional program, but a meaningful part of the discipline does not change at all, and pretending otherwise causes teams to rebuild things that already worked.
- Severity scoring. CVSS base score combined with EPSS (Exploit Prediction Scoring System) probability and asset context still produces the right prioritization signal, whether the asset is a bare-metal server or a Fargate task. A CVSS 9.8 with an EPSS score under 1 percent and no internet exposure is still lower priority than a CVSS 7.5 with an EPSS score above 50 percent sitting on a public load balancer.
- SLA tiers. Remediation windows tied to severity (for example, critical in 7 days, high in 30, medium in 90) remain valid targets in cloud environments. What changes is the clock start: for immutable infrastructure, the SLA clock should start when the vulnerable image is built, not when a human opens the ticket, since the image could already be running in five autoscaling groups by the time anyone looks at the queue.
- Exception handling. Risk acceptance with an expiration date, a named approver, and a compensating control is exactly as necessary in the cloud, arguably more so because ephemeral resources make it easy for an exception to quietly become permanent when nobody remembers which image it applied to.
Programs that discard these mechanisms because “the cloud is different” end up rebuilding a worse version of the same governance a year later, once the auditors ask for evidence of a consistent SLA across environments.
A reference workflow from cloud discovery to verified closure
A working cloud vulnerability management pipeline generally follows a fixed sequence, regardless of which provider or scanner combination is in use:
- Inventory pull. Query the cloud provider’s native asset API on a schedule (hourly for production accounts is a reasonable default) to get the current list of compute, container, and serverless resources, tagged with owner, environment, and data classification.
- Scan dispatch. Route each resource type to the appropriate scanner: agent-based or agentless host scanning for VMs, registry scanning for container images before deployment, and IaC scanning (Terraform, CloudFormation) at the pull-request stage so misconfigurations are caught before the resource ever exists.
- Deduplication. Collapse the same CVE reported by the image scanner, the runtime scanner, and the cloud provider’s own posture tool into a single finding, keyed by CVE ID plus image digest, so the same vulnerability does not generate three tickets.
- Validation and triage. Confirm the finding is real (not a false positive from a version string mismatch) and route it to the owning team using the tag mapping described above.
- Remediation. Patch the base image or Dockerfile, not the running instance, and trigger a rebuild through the existing CI/CD pipeline.
- Retest and closure. Re-scan the new image and the redeployed workload to confirm the specific CVE is gone, rather than trusting the deployment pipeline’s exit code as proof of a fix.
The step most cloud programs skip is the last one. A deployment that completes successfully tells you the new image was pushed; it does not tell you the vulnerable package was actually removed from the final layer, especially when a base image update silently reintroduces an old dependency through a transitive layer. This is the kind of end-to-end sequence covered under vulnerability lifecycle and retest and closure tracking, and it is worth building or buying specifically for this gap rather than assuming a green pipeline is equivalent to a verified fix.
Metrics that prove the cloud program is working
Three metrics separate a cloud vulnerability management program that is actually functioning from one that looks fine on a dashboard built from stale data.
| Metric | Definition | Reasonable target |
|---|---|---|
| Discovery coverage | Resources scanned in the last 24 hours divided by resources returned by the cloud provider’s inventory API in the same window | Above 95 percent, checked daily, not against a static baseline |
| MTTR by severity | Time from image build to verified re-scan showing the CVE resolved, not time to ticket closure | 7 days critical, 30 days high, measured from build date |
| Exposure window | Total hours a given CVE was running on an internet-facing resource before the fix was deployed and verified | Tracked per finding, trending down month over month |
Coverage and MTTR are the two most commonly gamed metrics in vulnerability management, cloud or otherwise, usually by accident rather than intent. Coverage looks great when the denominator is wrong, and MTTR looks great when the clock stops at ticket closure instead of verified remediation. Exposure window is harder to fake because it requires tying a specific CVE to a specific resource’s actual internet-facing status over its actual runtime, which is why it is the metric worth showing a board or an auditor: it answers the question they are actually asking, which is not “how many things did we scan” but “how long was the door open.”
Programs that want to report exposure window accurately need discovery, scanning, and retest data joined on a common resource identifier that survives instance churn, which is exactly the gap a manually stitched spreadsheet cannot close and a properly automated pipeline can. Details on how the full sequence is implemented are covered on the features page.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.