Cloud Security, Compliance and DevSecOps

Introduction

Cloud deployment changes the location, speed and scale of computing, but it does not transfer security responsibility entirely to a cloud provider. AWS and Google Cloud Platform (GCP) secure the underlying infrastructure, while customers remain responsible for identities, data, configurations, applications and operational decisions. The precise division depends on the service model: customers generally manage more in virtual machines than in managed databases or serverless services.

Cloud security is therefore a socio-technical discipline. It combines technical controls with governance, risk management, privacy, professional ethics and continuous assurance. DevSecOps integrates these concerns into the software delivery lifecycle so that security is designed, tested and monitored rather than added immediately before release.

Learning Objectives

By the end of this chapter, students should be able to:

• explain defense in depth and the shared-responsibility model;
• apply encryption, key-management and secret-management principles;
• implement identity-centered and zero-trust controls;
• select vulnerability-scanning and software supply-chain controls;
• design audit logging, monitoring and incident-response practices;
• distinguish important privacy, compliance and ethical obligations; and
• integrate security controls into a practical DevSecOps pipeline.

1. Security as Risk Management

Security protects confidentiality, integrity and availability—the CIA triad. Confidentiality prevents unauthorized disclosure; integrity prevents unauthorized or undetected alteration; and availability ensures that authorized users can obtain services when required. Additional objectives include authenticity, accountability, privacy and resilience.

Risk can be understood conceptually as the interaction of threat, vulnerability and impact. A vulnerable internet-facing service may be exploited by a threat actor, producing financial, operational, legal or human harm. Risk assessment should identify assets, trust boundaries, likely threats, weaknesses, business impact and treatment options. Treatment may involve mitigation, transfer, avoidance or informed acceptance.

A useful operational distinction is between a control and an assurance activity. A firewall rule is a preventive control; a log review is a detective control; restoring from a backup is a corrective control; and an independent audit provides assurance that controls are designed and operating effectively.

The Shared-Responsibility Model

Cloud providers typically secure facilities, hardware, networking foundations and managed-service platforms. Customers are usually responsible for identity permissions, data classification, configuration, application code, operating systems in infrastructure-as-a-service environments and compliance decisions. Responsibility changes with the service:

This model is not a substitute for reading service documentation. For example, a provider may encrypt a storage service by default, but the customer must still configure access policies, protect keys, classify data and verify that logs meet organizational requirements.

2. Defense in Depth

Defense in depth uses multiple, partially independent safeguards. A typical cloud architecture may include:

1. Governance: policies, risk ownership, asset inventories and security standards.
2. Identity: multifactor authentication, least privilege and separation of duties.
3. Network: private subnets, segmentation, controlled egress and application-layer filtering.
4. Compute and platform: hardened images, patching, workload isolation and secure defaults.
5. Application: input validation, secure authentication, authorization and dependency control.
6. Data: classification, encryption, backups, retention and loss-prevention controls.
7. Detection and response: immutable logs, alerting, investigation and tested recovery.

Layering is valuable because no single control is perfect. However, “more controls” does not automatically mean “more secure.” Controls must be correctly configured, monitored and proportionate to risk. Excessive complexity can create misconfiguration and operational failure.

3. Identity, Access and Zero Trust

Identity is the principal security boundary in cloud environments. Human users, workloads, services and automated pipelines should have distinct identities. Shared accounts and long-lived administrator credentials make attribution and revocation difficult.

Least privilege grants only the permissions required for a defined task, for only as long as necessary. Role-based access control assigns permissions to roles rather than individuals; attribute-based access control can additionally use attributes such as department, resource tag, environment or device posture. Privileged access should use separate administrative accounts, multifactor authentication, approval workflows and short-lived credentials.

Zero trust is a security model rather than a single product. Its central principle is not to grant implicit trust based solely on network location. Each request should be evaluated using identity, device or workload context, resource, action, policy and risk. Authentication is not the same as authorization: authentication establishes who or what is requesting access, while authorization determines what that identity may do.

Practical zero-trust measures include private service endpoints, mutual TLS where appropriate, workload identities, service-to-service authorization, continuous session evaluation and explicit egress policies. Network segmentation remains useful, but a private subnet alone does not make an application trustworthy.

4. Encryption and Key Management

Encryption transforms readable plaintext into ciphertext using a cryptographic key. It protects data in transit, at rest and, in limited cases, during processing. Transport Layer Security (TLS) protects network communication when correctly configured and authenticated. Storage encryption protects disks, object stores, databases and backups, but it does not prevent an authorized application or compromised identity from reading plaintext.

Key-management principles

A key-management system should support generation, protected storage, controlled use, rotation, revocation or disabling, auditing and recovery procedures. Cloud platforms provide provider-managed encryption keys and customer-managed keys. Customer-managed keys offer greater control and auditability but impose responsibilities for permissions, availability, rotation and recovery. Hardware security modules can provide stronger key protection for selected high-value workloads.

Key permissions should be separate from data permissions where feasible. A service should receive permission to use a key for a narrowly defined operation, not broad administrative control. Backups of keys and recovery procedures must be designed carefully: destroying or losing a key can make encrypted data permanently inaccessible.

Encryption is not a complete security strategy. Access control, secure endpoints, application authorization, data minimization and monitoring remain necessary. Passwords, API tokens and database credentials should not be stored in source code, container images, tickets or unprotected configuration files. They belong in a secrets manager, with access granted through workload identity and retrieved at runtime.

5. Vulnerability and Configuration Management

Vulnerability management is a lifecycle: discover, assess, prioritize, remediate, verify and report. Scanning may include:

• software composition analysis for third-party dependencies;
• static application security testing for source or compiled code;
• dynamic testing against running applications;
• container-image and operating-system scanning;
• infrastructure-as-code scanning; and
• cloud-configuration posture assessment.

A scanner finding is not automatically a confirmed exploitable risk. Teams should consider exposure, exploitability, asset criticality, compensating controls and remediation feasibility. False positives require expert review; false negatives are an unavoidable limitation of scanning.

Secure images should be minimal, patched, versioned and rebuilt rather than manually modified. Infrastructure should be defined as code, peer reviewed and checked before deployment. Dangerous changes—such as public storage, unrestricted administrative ports or disabled logging—should be blocked by policy where practical. Emergency exceptions require an owner, justification, expiry and later review.

6. Audit Logging, Monitoring and Incident Response

Audit logs support detection, investigation, accountability and compliance. Important events include authentication, authorization failures, privilege changes, key use, configuration changes, data access, network events, deployment activity and administrative actions. A useful event records who or what acted, what happened, when it happened, where it occurred, the result and a correlation identifier.

Logs should be time-synchronized, protected from unauthorized modification, retained according to business and legal requirements, and separated from the systems that generate them. Centralization helps investigators identify patterns across AWS, GCP, applications and identity providers. Logs may contain personal or sensitive information, so logging must follow data-minimization and access-control principles.

Monitoring converts events into signals. An alert should have a defined severity, owner, response objective and escalation path. Examples include impossible-travel sign-ins, unexpected privilege grants, unusual data export, disabled logging and deployment from an unapproved identity.

Incident response normally includes preparation, detection and analysis, containment, eradication, recovery and lessons learned. Organizations should preserve evidence, document decisions and communicate through approved channels. Recovery is not complete until root causes are addressed and controls are tested again.

7. DevSecOps and the Software Supply Chain

DevSecOps integrates security into planning, coding, building, releasing and operating. Security responsibilities are shared by development, operations, security and product teams. The objective is not to make developers security specialists in every topic, but to provide secure platforms, usable controls, rapid feedback and clear accountability.

A practical pipeline may contain the following gates:

Threat modeling asks what is being built, what can go wrong, which controls reduce the risk and how those controls will be verified. A data-flow diagram can reveal trust boundaries, privileged operations and sensitive-data paths.

The software supply chain includes source code, developers, dependencies, build systems, container bases, plugins, registries and deployment tools. Controls include protected branches, strong developer authentication, dependency pinning, trusted registries, artifact signing, build isolation, provenance records, review of CI/CD permissions and rapid revocation of compromised credentials. No single label or framework guarantees software integrity; the chain of custody must be evaluated end to end.

8. Privacy, Compliance and Ethics

Security and privacy overlap but are not identical. Security protects systems and information from unauthorized activity; privacy governs the appropriate collection, use, disclosure, retention and disposal of information about people. Privacy-by-design practices include purpose limitation, data minimization, transparent notices, access and correction processes, retention limits, pseudonymization where suitable and privacy impact assessment for high-risk processing.

Regulatory obligations depend on jurisdiction, sector, customer contracts and the type of data. Examples include the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA/CPRA), the Health Insurance Portability and Accountability Act (HIPAA) in relevant US healthcare contexts, and the Payment Card Industry Data Security Standard (PCI DSS) for payment-card environments. ISO/IEC 27001 and SOC 2 are assurance frameworks or reports rather than universal laws. Compliance does not prove that a system is secure, and security controls do not automatically satisfy every legal obligation.

Organizations should identify the data controller and processor roles where applicable, document processing purposes, manage international transfers, establish breach-notification procedures and retain evidence of control operation. Legal advice is necessary for jurisdiction-specific decisions.

Ethically, engineers should avoid unnecessary surveillance, deceptive consent, discriminatory automated decisions and insecure defaults. They should disclose material risks, protect vulnerable users and use data only for legitimate, proportionate purposes. Artificial intelligence introduces additional concerns: training data may contain confidential information, generated code may include vulnerabilities or incompatible licenses, and automated security decisions may produce opaque or biased outcomes. AI tools should therefore operate under approved data-handling rules, human review and testing.

9. Illustrative Case: Securing a Cloud Retail Platform

Background

A fictional online retailer operates a containerized application on a managed Kubernetes service. Its payment component uses a managed database, while product images are stored in object storage. Developers deploy through a CI/CD pipeline.

Problem

An assessment discovers that a storage bucket is publicly readable, CI/CD uses a long-lived cloud administrator key, container images contain outdated dependencies, and audit logs are retained in the same account without immutability. The organization has customers in multiple jurisdictions.

Analysis

The public bucket creates a confidentiality risk. The administrator key creates a high-impact supply-chain and identity risk because compromise of the pipeline could affect every environment. Vulnerable dependencies increase application risk, while weak log protection reduces the ability to investigate. Regulatory exposure depends on the data involved, contractual commitments and the locations of customers and processing.

Approach and solution

The retailer first classifies data and removes public access, replacing it with private storage and short-lived, signed download requests. It creates separate development, staging and production accounts or projects and uses workload identity for the pipeline. Deployment roles can publish approved artifacts but cannot modify audit settings or grant themselves unrestricted access.

The team moves secrets to a managed secrets service, separates encryption-key administration from application access, and enables multifactor authentication for human administrators. It rebuilds minimal images, pins and reviews dependencies, scans images and infrastructure code, and requires signed artifacts with provenance before production deployment.

Central audit logs are exported to a restricted security project or account with retention and immutability controls. Alerts cover public-resource changes, unusual exports, privilege escalation and pipeline activity. Threat modeling and privacy review are added to planning, and incident-response exercises test customer notification and recovery procedures.

Outcome

The retailer reduces standing privilege, improves traceability and makes accidental public exposure less likely. It does not claim that risk has been eliminated; instead, risks are documented, monitored and periodically reassessed.

Learning points

Cloud security failures commonly arise from identity, configuration and process weaknesses rather than from a missing advanced product. Effective improvement combines preventive controls, detection, recovery, governance and continuous verification.

10. Implementation Guidance and Limitations

A diploma-level practitioner should begin with an accurate asset and identity inventory, a documented responsibility matrix and secure baseline configurations. Enable multifactor authentication, remove unused accounts, enforce least privilege, protect secrets, encrypt sensitive data, centralize logs, scan code and images, and test restoration. Controls should be automated where possible but reviewed by accountable people.

Important limitations remain. Cloud abstractions can hide dependencies and create concentration risk. Managed services reduce operational effort but may reduce configuration visibility. Automated scanners miss business-logic flaws and can overwhelm teams with low-value findings. Encryption can complicate search, recovery and lawful access. Zero trust can become a slogan if policies are not specific and continuously evaluated. Compliance evidence can become a paperwork exercise if it is disconnected from real operational risk.

Security is therefore an iterative capability. Metrics should measure meaningful outcomes, such as time to remediate high-risk findings, percentage of privileged access using strong authentication, successful recovery-test rate, age of unreviewed exceptions and coverage of critical assets—not merely the number of tools installed.

Chapter Summary

Cloud security follows a shared-responsibility model in which providers secure parts of the platform while customers secure identities, configurations, applications and data. Defense in depth combines governance, identity, network, platform, application, data and response controls. Zero trust treats every request as requiring explicit, contextual authorization.

Encryption protects data, but key and secret management determines whether protection is usable and auditable. Vulnerability management combines scanning with prioritization, remediation and verification. Audit logging and monitoring support accountability and incident response. DevSecOps embeds threat modeling, testing, artifact integrity and supply-chain protection throughout delivery.

Privacy, ethics and compliance require more than technical safeguards: they require lawful purpose, proportionality, transparency, retention control and responsible governance. Effective cloud security is continuous, risk-based and measurable.

Key Terms

Shared responsibility model: Division of security duties between a cloud provider and its customer.

Defense in depth: Use of multiple complementary security layers.

Confidentiality: Protection against unauthorized disclosure.

Integrity: Protection against unauthorized or undetected alteration.

Availability: Ability of authorized users to access a service when needed.

Least privilege: Granting only the permissions necessary for a task.

Zero trust: Security approach that grants no implicit trust based solely on network location.

Authentication: Verification of an identity.

Authorization: Decision about permitted actions.

Encryption: Transformation of plaintext into protected ciphertext.

Key management: Generation, protection, use, rotation and recovery of cryptographic keys.

Secret: Sensitive credential or token used to authenticate or authorize access.

Vulnerability: A weakness that may be exploited or cause harm.

Threat modeling: Structured analysis of possible threats and mitigations.

Audit log: Recorded evidence of activities and events.

DevSecOps: Integration of security into development and operations practices.

Software supply chain: People, code, dependencies, tools and artifacts used to produce software.

Privacy by design: Incorporation of privacy safeguards from the beginning of system design.

Compliance: Conformance with applicable laws, standards, contracts or policies.

Review Questions

Short Answer Questions

1. What responsibilities normally remain with a customer when using a cloud provider?
2. Distinguish authentication from authorization.
3. Why should secrets not be stored in source code?
4. Name three activities in a vulnerability-management lifecycle.
5. What is the purpose of centralized audit logging?

Long Answer Questions

1. Explain defense in depth using a cloud-hosted application as an example.
2. Compare provider-managed and customer-managed encryption keys, including operational trade-offs.
3. Describe how zero-trust principles can be applied to service-to-service communication.
4. Explain how DevSecOps changes the traditional software development lifecycle.
5. Discuss why compliance does not necessarily demonstrate effective security.

Analytical / Application Questions

1. A deployment pipeline has a permanent administrator credential and can publish directly to production. Identify the major risks and propose a staged control plan.
2. A company wants to place customer records in a public object-storage bucket for convenience. Analyze the security, privacy and governance issues and recommend an alternative design.
3. After a suspected credential compromise, design an incident-response sequence covering containment, evidence, recovery and lessons learned.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the cloud shared-responsibility model?

A. The provider is responsible for all customer application security.

B. The customer is responsible for all physical data-center security.

C. Security duties are divided according to the service and configuration used.

D. No security responsibility exists for managed services.

Correct Answer: C. Security duties are divided according to the service and configuration used.

Question 2

Which control most directly supports least privilege for a deployment pipeline?

A. Giving the pipeline permanent global administrator access

B. Granting only the permissions required to deploy its approved artifacts

C. Sharing one administrator account among all developers

D. Disabling audit logging to improve deployment speed

Correct Answer: B. Granting only the permissions required to deploy its approved artifacts

Question 3

What is the primary purpose of a secrets-management service?

A. To make all application data public

B. To store and control access to credentials and tokens

C. To replace vulnerability scanning

D. To eliminate the need for authorization

Correct Answer: B. To store and control access to credentials and tokens

Question 4

Which statement about encryption is correct?

A. Encryption eliminates the need for access control.

B. Encryption protects data, but key management and authorization remain necessary.

C. Encryption prevents an authorized application from reading plaintext.

D. Encryption makes audit logging unnecessary.

Correct Answer: B. Encryption protects data, but key management and authorization remain necessary.

Question 5

Which activity is most closely associated with software supply-chain security?

A. Signing artifacts and recording their build provenance

B. Removing all code review from the pipeline

C. Using one credential for every environment

D. Allowing unverified dependencies without review

Correct Answer: A. Signing artifacts and recording their build provenance

Question 6

What does zero trust reject?

A. Explicit authorization decisions

B. Multifactor authentication

C. Implicit trust based only on network location

D. Workload identities

Correct Answer: C. Implicit trust based only on network location

Question 7

Which property makes audit logs more useful for investigations?

A. They can be freely modified by the same administrator being investigated.

B. They record relevant actor, action, time, result and context.

C. They contain no timestamps.

D. They are stored only on the endpoint that generated them.

Correct Answer: B. They record relevant actor, action, time, result and context.

Question 8

Which statement best distinguishes privacy from security?

A. Privacy concerns appropriate collection and use of personal information, while security protects systems and information from unauthorized activity.

B. Privacy and security are identical terms in every jurisdiction.

C. Privacy applies only to passwords.

D. Security makes legal obligations unnecessary.

Correct Answer: A. Privacy concerns appropriate collection and use of personal information, while security protects systems and information from unauthorized activity.

Question 9

A vulnerability scanner reports a critical issue in a non-exposed test image that is never deployed. What is the best next step?

A. Ignore every scanner result permanently.

B. Assess context and exposure, then remediate or document an appropriately governed decision.

C. Publish the image immediately.

D. Disable scanning for all future images.

Correct Answer: B. Assess context and exposure, then remediate or document an appropriately governed decision.

Question 10

Which sequence best represents a typical incident-response lifecycle?

A. Recovery, detection, preparation, containment, disposal

B. Preparation, detection and analysis, containment, eradication, recovery and lessons learned

C. Deployment, marketing, billing, recovery

D. Scanning, encryption, deletion, publication

Correct Answer: B. Preparation, detection and analysis, containment, eradication, recovery and lessons learned