A cloud misconfiguration can expose data as surely as an unpatched server. Think of a storage bucket anyone can read, an identity role that can do anything, or a database port open to the whole internet. Yet many vulnerability programs track CVEs carefully while configuration findings sit in a separate console that nobody owns. Our view is simple: treat misconfigurations as vulnerabilities. Give them a severity, an owner and a deadline, measure them against a published benchmark, and stop the worst ones from being created in the first place.

Why are cloud misconfigurations a vulnerability management problem?

Under the shared responsibility model, the provider secures the underlying infrastructure and you secure how you configure it. Settings for identity, storage, networking and logging are your side of that line. When they're wrong, no vendor patch will arrive to fix them. The fix is a change your own team has to make.

Cloud environments also change fast. Engineers create resources in minutes through a console, a script or an infrastructure-as-code pipeline, often across dozens of accounts, subscriptions or projects. A setting that was correct last month can drift after a single console change.

Traditional network vulnerability scanners don't cover most of this. They see hosts and open ports, but not bucket policies, role permissions or whether audit logging is switched on. Those live in the provider's control plane and have to be assessed through its APIs. If your program only counts what the network scanner reports, you're missing a large part of your attack surface.

What are the most common cloud misconfigurations?

The same handful of issues shows up in almost every cloud assessment we run.

Publicly accessible storage

Object storage that anyone on the internet can list or read is the classic example. It often starts out intentional, such as a bucket serving public website images, and then someone stores something else there. Some providers now block public access by default on newly created storage, but older resources keep whatever settings they were given. Turn on account-level or organization-level public access blocks and handle genuine public use as a documented exception.

Overly permissive identity and access management

Wildcard permissions, administrator roles handed out broadly, service accounts with owner rights and trust policies that let too many outside accounts assume a role are all common. The danger is the blast radius. If a set of credentials is stolen, excessive permissions turn a contained incident into access to everything. Work toward least privilege and use your provider's access analysis features to find unused permissions.

Exposed management ports

Security groups and firewall rules that allow SSH (port 22), RDP (port 3389) or database ports from 0.0.0.0/0 get probed constantly by automated scanning across the internet. A management interface that is open to the world is one weak password or one unpatched service away from compromise. Restrict administrative access to known source ranges, a VPN or a bastion host, or use your provider's managed session access instead.

Disabled or incomplete logging

If control-plane audit logs aren't enabled in every region and account, you can't reconstruct who changed what. The same goes for storage access logs and network flow logs. Disabled logging rarely causes an incident, but it turns a manageable one into guesswork. Send logs to a separate, locked-down account where the people being audited can't delete them.

Unencrypted data

Many services now encrypt data at rest by default, but not all of them, and not always with keys you control. Check disks, snapshots, database instances and backups. Also check data in transit: database connections that don't require TLS, and load balancers that still accept outdated protocol versions.

Permissive default network rules

Default networks and security groups are built for convenience, not security. Some come with rules allowing remote administration from anywhere or unrestricted traffic between everything in the same network. The CIS Benchmarks for AWS and Google Cloud, for instance, recommend locking down the default security group and removing the default network. Either change is a good place to start.

Long-lived access keys

Static access keys that never expire end up in scripts, CI pipelines, laptops and occasionally source code repositories. Each one is a standing credential that works from anywhere until someone notices. The CIS Amazon Web Services Foundations Benchmark, for example, recommends rotating access keys every 90 days or less and disabling credentials unused for 45 days or more. Better still, replace static keys with short-lived credentials issued through roles, instance identities or workload identity federation.

How do you treat misconfigurations as findings?

The shift is mostly one of process. A misconfiguration should travel through the same pipeline as a missing patch.

Put them in the same register. Configuration findings belong in the same queue, dashboards and reports as your other vulnerabilities. If they live in a separate tool that only the cloud team looks at, they'll lose every argument for attention.

Rate severity on context. A public bucket holding customer records is critical. A missing cost-allocation tag isn't a vulnerability at all. Base severity on exposure (is it reachable from the internet?), data sensitivity and how easily the weakness can be abused.

Assign an owner. Every cloud account, subscription or project needs a named owning team, and resources should carry an owner tag. Unowned findings don't get fixed.

Set SLAs. Remediation targets should match your existing vulnerability SLAs so nobody can argue that configuration is a lesser category. Here's an example you can adapt:

Severity Example misconfiguration Example fix target
Critical Public storage containing sensitive data; active access key with administrator rights exposed 24–72 hours
High Management port open to the internet; wildcard administrator permissions on a workload role 7 days
Medium Audit logging disabled in an unused region; unencrypted volume holding non-sensitive data 30 days
Low Hardening deviation with little exposure 90 days or next planned change

Manage exceptions properly. Some findings are deliberate. A bucket that serves public website assets is supposed to be public. Record the exception, the reason, the approver and any compensating controls, and give it an expiry date so it gets reviewed.

Measure progress. Track open findings by severity and age, time to remediate, and the percentage of accounts meeting your benchmark baseline. Report them next to your patching metrics.

How do the CIS Benchmarks help?

The Center for Internet Security publishes free, consensus-developed configuration benchmarks for the major cloud platforms. They include the CIS Amazon Web Services Foundations Benchmark, the CIS Microsoft Azure Foundations Benchmark and the CIS Google Cloud Platform Foundation Benchmark, along with benchmarks for specific services such as managed Kubernetes.

Each recommendation explains the rationale, how to audit the setting and how to fix it. Recommendations are grouped into profiles: Level 1 covers baseline settings with limited operational impact, and Level 2 adds defense-in-depth controls that may affect functionality.

A few practical tips:

  • Start with Level 1 across all accounts before chasing Level 2 anywhere.
  • Map each recommendation to your own severity scale rather than treating every failed check as equal.
  • Document deliberate deviations as exceptions instead of letting them drag down your score forever.
  • CIS updates the benchmarks periodically, so check which version your assessment tooling maps to.

Don't treat a perfect benchmark score as the goal. The benchmarks are a well-tested baseline, and your own risk assessment decides what matters most.

What is policy-as-code, and how do guardrails prevent misconfigurations?

Finding misconfigurations after they exist is necessary. Stopping them at creation is cheaper. We think of it in layers.

  1. Preventive guardrails at the organization level. All three major providers let you set policies that apply across every account or project, such as service control policies in AWS, Azure Policy and organization policy constraints in Google Cloud. Use them to deny the things that should never happen: making storage public, disabling audit logs, creating resources in unapproved regions, or launching unencrypted volumes.
  2. Checks in the deployment pipeline. Scan infrastructure-as-code templates before they're applied and fail the build on high-severity issues. This catches problems while the fix is a one-line change in a pull request.
  3. Continuous detection in live environments. Console changes and emergency fixes bypass pipelines. Assess the running configuration against your baseline continuously and alert on drift.
  4. Automatic remediation for clear-cut cases. Re-enabling a disabled audit log or removing a world-open management port can be automated safely, with a notification to the owner. Save automation for cases where the right answer is unambiguous.

Policy-as-code ties these layers together. You write rules as code, keep them in version control, review changes like any other code and test them before rollout. Open Policy Agent, a Cloud Native Computing Foundation project, is one widely used open-source option, and the providers' own policy languages work the same way.

Roll out guardrails in audit mode first so you can see what would be blocked, then switch to enforcement. Give engineers a clear, fast exception route. A guardrail that blocks legitimate work without explanation will be worked around.

Frequently asked questions

Is a misconfiguration really a vulnerability if it has no CVE?

Yes. A CVE is an identifier for a flaw in software, not a definition of risk. A publicly readable bucket or an administrator key in a script can be abused just as easily as an unpatched service, and often more easily.

How often should we assess cloud configuration?

Continuously, or at least daily, because cloud resources change constantly. Scanning infrastructure-as-code before each deployment catches issues even earlier.

Who should own cloud misconfiguration findings?

The team that owns the account or workload should fix them. Security sets the baseline, runs the assessments, agrees severities and verifies the fix.

Do we need a dedicated cloud security posture tool?

Not necessarily at first. Provider-native assessment features and open-source checks mapped to the CIS Benchmarks can take you a long way. The process of owners, SLAs and exceptions matters more than the tool.

Next steps

  1. Pull a list of every cloud account, subscription and project, and assign an owner to each.
  2. Run a CIS Benchmark Level 1 assessment across all of them.
  3. Load the results into your existing vulnerability register with severities and SLAs.
  4. Fix the public storage, exposed management ports and long-lived administrator keys first.
  5. Add organization-level guardrails for the settings that should never change, starting in audit mode.
  6. Add infrastructure-as-code checks to your deployment pipelines so new resources start compliant.