Why do you need cloud security if the provider secures the cloud?

You need cloud security because providers secure only their side of a shared arrangement. They protect the physical sites and core platform. You remain responsible for your data, identities, configuration and the software you run. Many cloud exposures sit on the customer side of that line, such as an open setting or a leaked key.

What is the shared responsibility idea?

NIST's guide to security and privacy in public cloud computing makes the point that moving to a public cloud shifts some control to the provider, yet the organization stays accountable for the security and privacy of its data and applications. The split depends on the service model. NIST SP 800-145 defines three: infrastructure as a service, platform as a service and software as a service.

• With infrastructure as a service, the provider runs hardware and virtualization. You manage the operating system, patching, network rules, applications and data.
• With platform as a service, the provider also manages the runtime. You manage your code, configuration and data.
• With software as a service, the provider runs the application. You manage users, permissions, data and settings.

Responsibility shrinks as you move up the stack, but it never reaches zero.

What do customers usually get wrong?

1. Identity. Accounts without multi factor authentication, roles with far more permission than needed, access keys left in code or old accounts that were never removed.
2. Configuration. Storage open to the internet, management ports exposed, logging off, default settings left alone.
3. Software. Vulnerable libraries and images in your workloads. The provider does not patch your application dependencies.
4. Data. Sensitive data stored without encryption or without knowing it is there, and copies in places nobody tracks.
5. Visibility. No central logs, no alerting, no inventory, so a problem lasts months.

Notice what is missing from that list: the provider's data center. Every item is something the customer controls.

Constructed example: a startup builds an internal reporting tool on a managed database and file storage. A developer makes a storage container public for quick testing and forgets it. The container holds exports with customer emails. The provider's platform worked exactly as designed. The gap was a setting the company controlled and nobody was watching.

Why does the cloud raise the stakes?

Speed and scale. A person with the right permission can create or expose a hundred resources in a minute. Automation spreads good settings and bad ones equally fast. Everything is reachable through an API, so a stolen key works from anywhere. And the boundary of your network is no longer a building, which is why zero trust architecture focuses on authenticating each request instead of trusting location.

Where does application security fit?

Cloud settings are half the picture. The other half is what runs inside. Safeguard focuses on that layer: scanning dependencies, using reachability analysis to show which vulnerable code is actually used, and applying policies and gates before risky builds ship. Pair it with whatever you use to check account settings.

How to check or apply this

1. Write down, for each cloud service you use, who is responsible for what. Use the provider's own documentation for the exact split.
2. Turn on multi factor authentication for every human account and review administrator roles.
3. Remove long lived access keys where short lived credentials are possible.
4. Search for publicly reachable storage and open management ports, and close what is not intended.
5. Turn on audit logging in every account and send it somewhere an attacker cannot easily delete it.
6. Scan images and dependencies before deploy.
7. Classify your data and encrypt the sensitive classes.
8. Test restore from backup.
9. Review all of this on a schedule, because settings drift.

Quick check

Sources

• NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing
• NIST SP 800-145, The NIST Definition of Cloud Computing
• NIST SP 800-207, Zero Trust Architecture

Last reviewed: 18 October 2026.