Why do cloud VMs still need dedicated security controls if they are rebuilt from images rather than patched in place?

Why immutable rebuilds do not remove the need for VM controls

Rebuilding a cloud VM from a clean image changes how you recover, but it does not change the fact that the VM is live, network-reachable, and exposed between rebuilds. Security still has to cover the running instance, the image source, the packages baked into it, and the configuration that is applied after launch. That is why rebuilds complement controls rather than replace them.

An image can be vulnerable before it is ever launched, and a VM can drift after deployment through configuration changes, temporary fixes, injected dependencies, or exposed services. A control that only looks at the next rebuild cycle will miss the period when the instance is actually serving traffic. Continuous scanning and policy enforcement narrow that gap by finding issues during the active lifecycle, not after the fact.

That lifecycle view is consistent with NIST Cybersecurity Framework 2.0, which treats ongoing identification, protection, detection, response, and recovery as continuous functions rather than a one-time hardening event.

What dedicated controls protect that rebuilds do not

Dedicated controls cover three different failure points: the image, the running VM, and the path between the two. Image scanning helps catch vulnerable base layers and stale packages before deployment. File integrity monitoring helps spot unexpected modification after boot. Policy enforcement helps ensure the VM still matches approved configuration, even if a rebuild would eventually restore it later.

Network controls matter for the same reason. Rebuildability does not reduce exposure from open management ports, permissive security groups, weak segmentation, or overly broad east-west access. If an attacker can reach the VM, exploit it, or move through it before the next rebuild, the image strategy has not prevented compromise, it has only limited the cleanup method.

Practitioners usually get the best operational coverage when they pair those controls with vulnerability intelligence and prioritisation, for example using the NIST National Vulnerability Database to identify known weaknesses and the CISA Known Exploited Vulnerabilities Catalog to focus on issues that are already being actively exploited.

How to think about rebuilds as a control, not a substitute

Immutable infrastructure is strongest when teams treat it as a remediation path and a consistency mechanism, not as a guarantee of security. Rebuilds reduce persistence and make rollback easier, but they do not prove the current instance is trustworthy, do not prevent exposure during runtime, and do not fix an unsafe image pipeline.

The practical question is whether you can detect and contain a bad VM before the next replacement event. If the answer is no, then you still need runtime controls around integrity, logging, access, and vulnerability management. That is especially important when the same image is cloned widely, because one weak template can spread the same flaw across many instances at once.

If your cloud programme needs a control baseline for that kind of lifecycle exposure, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides the relevant control families for configuration management, system integrity, logging, and access control, while NIST SP 800-190 Container Security is useful for the similar image, runtime, and orchestration risks that arise in cloud-native build-and-rebuild models.

Practitioner Guidance

What to verify: Confirm that the image pipeline, launch configuration, and runtime monitoring are all in scope. A hardened image is not enough if post-launch access, security group rules, or package drift can still introduce exposure before the next rebuild.

What good looks like: You can answer three questions quickly for any VM, what image it came from, what changed after boot, and whether its current exposure has been measured recently enough to trust. That is the operational standard that makes rebuilds safe enough to rely on.

Common mistake: Treating “rebuildable” as equivalent to “secure.” Rebuildability lowers recovery cost, but it does not eliminate the need to detect compromise, enforce policy, or remove risky network reachability while the instance is still live.

Practitioner takeaway: Use immutable images to improve recovery and consistency, but use runtime controls to protect the VM during the period when it is actually exposed, because that is where most of the security risk exists.

Related resources from NHI Mgmt Group

• Why do organisations still need dedicated email security controls when they already rely on Microsoft 365?
• Why do cloud security tools still fail when organisations have IAM in place?
• How should security teams design access controls that still work during a cloud outage?
• Why do organisations still struggle with sensitive data exposure even when they have DLP controls in place?