Cloud security best practices for SaaS applications

Most cloud security incidents are not sophisticated attacks. They are routine exploitation of misconfigurations, exposed credentials, and over-permissive access controls that exist because cloud security is treated as an operations task rather than a development discipline. Gartner’s statement that 99% of cloud security failures will be the customer’s fault is an architectural observation, not a blame assignment. The failure modes are well-understood, consistently documented, and largely preventable.

IBM’s cloud security analysis confirms this: through 2025, Gartner states that 99% of cloud security failures will be the customer’s fault. Security misconfigurations have been the predominant cloud security concern for over a decade. IBM identifies Infrastructure-as-Code and policy-as-code as pivotal concepts in cloud security evolution, shifting from reactive configuration review to proactive, automated policy enforcement that prevents misconfigurations rather than detecting them.

This post maps the cloud security controls that apply to SaaS applications across the development lifecycle, from design through deployment and ongoing operation, anchored in Microsoft’s DevSecOps framework, IBM’s cloud security guidance, and NIST’s secure software development documentation.

The shared responsibility model: what the cloud provider secures and what you must

The cloud shared responsibility model defines the security boundary between the cloud provider and the customer. Understanding this boundary is the prerequisite for understanding which security failures are the customer’s responsibility.

IBM documents the shared responsibility model as establishing that cloud providers secure the underlying infrastructure, physical data centers, hypervisor layer, managed network infrastructure, while customers are responsible for securing their applications, the data they put in the cloud, access controls, identity management, and the configuration of cloud services they use. The customer’s portion is where nearly all cloud security failures occur.

The DevSecOps framework for SaaS cloud security

Microsoft defines DevSecOps as a framework that integrates security into all phases of the software development lifecycle across multicloud environments. Microsoft specifically notes that cloud-native applications, built using microservices, containers, and automation, are ideally suited for DevSecOps because their architecture enables continuous security integration at every stage.

The DevSecOps shift-left principle means moving security controls earlier in the development process, so that vulnerabilities are caught at the design or coding stage rather than discovered in production. Microsoft’s guidance frames this as using DevSecOps from the beginning of development rather than auditing at the end.

Design phase security controls

• Threat modeling: before the first line of code, identify the attack surfaces the application will expose, the data it will process, and the trust boundaries between components. A 2-hour threat modeling session at design time prevents architecturally embedded vulnerabilities that are expensive to remediate later
• Security requirements alongside functional requirements: every sprint that adds a feature should include the security requirements for that feature. Authentication requirements, input validation requirements, and data handling requirements belong in the same sprint as the feature they protect
• Data classification before architecture: classify the data the application will handle, PII, PHI, PCI, public, internal, before designing the data layer. Storage, encryption, access, and retention decisions all flow from data classification

Development phase security controls

• SAST (static application security testing): automated code scanning for security vulnerabilities integrated into the pull request workflow. SAST tools catch common vulnerability patterns, SQL injection, XSS, insecure deserialization, before code merges to main
• Secrets scanning: as documented in CI/CD security practice, secrets scanning prevents credentials from reaching version control. Pre-commit hooks and repository scanning should both be active for any codebase that handles sensitive data
• Dependency scanning (SCA): third-party libraries introduce known vulnerabilities. Software Composition Analysis tools scan dependency trees against vulnerability databases on every build. IBM’s Cloud DevSecOps reference implementation includes SBOM generation and assessment as standard controls

Deployment phase security controls

• Infrastructure-as-Code scanning: Terraform, CloudFormation, and Kubernetes manifests define cloud configuration. IaC scanning tools (Checkov, tfsec) identify misconfigured security groups, public storage buckets, and missing encryption before the infrastructure is provisioned
• Container image scanning: container images are built from layers, each of which may include known vulnerabilities. Image scanning before registry push prevents deploying containers with exploitable vulnerabilities. NIST’s NCCoE DevSecOps documentation identifies artifact integrity verification as a core supply chain security control
• Policy-as-code: IBM’s cloud security analysis identifies policy-as-code as a pivotal concept that allows security rules and compliance requirements to be managed through machine-readable files rather than manual review. This ensures that every deployment satisfies defined security policies before promotion to production

Runtime cloud security controls for SaaS applications

Gartner’s cloud security architecture guidance identifies native cloud provider security as the most cost-effective initial control layer. SaaS security posture management (SSPM) continuously assesses SaaS application security risk and manages the security posture. Cloud workload protection platforms (CWPP) safeguard deployed applications across multicloud environments.

• Zero Trust network architecture: Microsoft’s DevSecOps guidance specifies building Zero Trust into the cloud architecture, replacing implicit trust with continuously assessed risk and trust levels based on identity. For SaaS applications, this means every service-to-service call is authenticated, not just user-facing API calls
• Centralized logging and SIEM integration: all application logs, authentication events, API calls, and configuration changes routed to a centralized security information and event management system. IBM’s cloud security reference implementation stores evidence for each control in S3-compatible object storage for continuous audit readiness
• Runtime vulnerability detection: cloud workload protection platforms (CWPP) detect threats to running workloads across multicloud environments. Unlike scanning at build time, CWPPs monitor runtime behavior and flag anomalies such as unexpected outbound connections, privilege escalation attempts, and unusual data access patterns
• Automated compliance monitoring: policy-as-code enforcement at runtime, not just at deployment. IBM’s DevSecOps platform combines security automation, policy enforcement, and auditability with deviations from policy tracked and documented automatically

On-premise vs. cloud security: what changes and what does not

The move from on-premise infrastructure to cloud changes the attack surface and the shared responsibility model. It does not change the underlying security principles. Encryption, least privilege, network segmentation, and audit logging are required in both environments. What changes is who is responsible for implementing each control and which tooling implements it.

• What gets easier in the cloud: physical security, hardware lifecycle management, and network hardware maintenance become the provider’s responsibility. Managed services for identity (IAM), key management (KMS), logging (CloudWatch, Azure Monitor), and compliance reporting reduce the operational burden of implementing baseline security controls
• What gets harder in the cloud: the configuration surface is larger. An on-premise environment has a fixed set of servers and network devices. A cloud environment has thousands of configurable resources, security groups, IAM policies, storage bucket ACLs, function permissions, each of which can be misconfigured. Gartner’s 99% customer fault statistic reflects this configuration complexity
• Cloud migration security: when migrating workloads from on-premise to cloud, data classification and access control policies must be explicitly mapped to cloud service controls before migration begins. Migrating data without translating the access model produces cloud storage with more permissive access than the on-premise equivalent

WebOsmotic’s DevSecOps consulting and cloud security practice implements security controls at the design phase for SaaS clients in fintech, healthcare, eCommerce, and logistics. Cloud architecture, IaC security, SAST/SCA pipeline integration, and compliance-ready logging are included in the initial architecture scope of every regulated industry engagement.

Frequently asked questions

What is the cloud shared responsibility model?

The cloud shared responsibility model defines the security boundary between the cloud provider and the customer. Cloud providers secure the physical infrastructure, the hypervisor layer, and the underlying network, the customer cannot access these layers and has no security responsibility for them. Customers are responsible for everything above this line: application code, data classification and protection, identity and access management configuration, network controls (VPC, security groups, ACLs), and the configuration of every cloud service they use. IBM’s cloud security documentation identifies security misconfiguration in the customer’s portion of the model as the predominant cloud security concern, and Gartner’s statement that 99% of cloud security failures are the customer’s fault reflects this division.

What is DevSecOps and how does it differ from traditional security review?

DevSecOps integrates security into all phases of the software development lifecycle, per Microsoft’s definition, rather than treating security as a gate at the end of development. Traditional security review audits the completed application for vulnerabilities before deployment. DevSecOps embeds security controls at the design phase (threat modeling, security requirements), the development phase (SAST, secrets scanning, dependency scanning), and the deployment phase (IaC scanning, container image scanning, policy-as-code) so that vulnerabilities are caught when they are cheapest to fix. NIST’s NCCoE DevSecOps project documents this approach consistent with the NIST Secure Software Development Framework SP 800-218.

What is SaaS security posture management (SSPM)?

SaaS security posture management is a control category that continuously assesses a SaaS application’s security risk and manages its security posture, per Gartner’s cloud security architecture guidance. SSPM tools connect to SaaS applications, inventory their configuration, compare it against security baselines, and alert on deviations. For SaaS application developers (rather than SaaS application users), SSPM is complemented by SaaS management platforms that control security functions and ensure consistent governance across cloud services. Gartner identifies native cloud provider security as the most cost-effective initial control layer, with SSPM and CWPP adding continuous monitoring on top of provider-native controls.

What is Infrastructure-as-Code security scanning?

Infrastructure-as-Code security scanning analyzes Terraform, CloudFormation, Kubernetes manifests, and other IaC files for security misconfigurations before the infrastructure is provisioned. Common findings include public S3 buckets with no access restrictions, security groups with 0.0.0.0/0 ingress rules, unencrypted storage configurations, and over-permissive IAM roles. IBM’s cloud security analysis identifies IaC and policy-as-code as pivotal concepts in cloud security, they shift from reactive configuration review to proactive enforcement. Tools including Checkov, tfsec, and Terrascan integrate with CI/CD pipelines to run IaC scanning on every pull request that modifies infrastructure configuration.

What are the most important cloud security controls for a SaaS startup?

The highest-priority cloud security controls for a SaaS startup, in sequence: enable MFA on all cloud console accounts before any infrastructure is provisioned; apply least-privilege IAM policies (no human accounts with administrator access in production); encrypt data at rest and in transit (most cloud providers enable this by default for managed services, verify it is not disabled); implement secrets scanning before the first commit reaches the repository; configure VPC with private subnets for databases and application servers; enable centralized logging for all API calls and authentication events; and run IaC scanning on every infrastructure change. These six controls address the most common initial-stage misconfigurations that Gartner identifies as the customer’s responsibility.

How does WebOsmotic approach cloud security for SaaS products?

WebOsmotic treats cloud security as an architectural input at the design phase. Before any infrastructure is provisioned, we define the data classification model, the identity and access architecture, the network segmentation design, and the logging and compliance requirements. During development, SAST, secrets scanning, and dependency scanning are integrated into the CI/CD pipeline before the first merge to main. Deployment includes IaC scanning, container image scanning, and policy-as-code enforcement. For regulated industry clients in fintech and healthcare, the cloud security architecture is included in the compliance documentation alongside application-level controls, because the cloud configuration is part of the compliance posture.