Secure Cloud Operations and DevSecOps

Introduction

Cloud computing has changed how organisations design, deploy and operate information systems. Infrastructure can be created through software, applications can be released several times each day, and security controls can be applied across large and changing environments. These benefits also create new risks. A misconfigured storage bucket, an over-privileged identity, an outdated software library or an unreviewed infrastructure change can expose data and services rapidly.

Secure cloud operations therefore requires security to be integrated into the complete delivery lifecycle rather than added after deployment. DevSecOps is the organisational and technical approach used to achieve this integration. It combines development, security and operations practices so that security requirements, testing, monitoring and remediation become part of ordinary engineering work.

This chapter examines infrastructure as code, secure CI/CD pipelines, vulnerability and dependency scanning, configuration management, policy as code, patching and continuous compliance. The emphasis is practical: a diploma-level practitioner should be able to identify controls, interpret findings, improve a deployment workflow and explain how security responsibilities are distributed.

Learning Objectives

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

1. Explain the purpose and principles of DevSecOps in cloud environments.
2. Describe how infrastructure as code supports repeatability, review and security.
3. Identify security controls for source repositories, build systems and deployment pipelines.
4. Distinguish static analysis, software composition analysis, image scanning and dynamic testing.
5. Apply configuration management and policy-as-code concepts.
6. Explain secure patching, vulnerability prioritisation and continuous compliance.
7. Evaluate governance, accountability and practical limitations in a cloud delivery model.

1. The DevSecOps Operating Model

Traditional delivery often separates responsibilities: developers create software, operations deploy it, and security reviews it near the end. This arrangement creates hand-off delays and encourages security to be treated as a gate rather than a shared responsibility. DevSecOps moves appropriate security activities earlier in the lifecycle and repeats them throughout operation.

A simplified lifecycle is:

Plan → Code → Build → Test → Release → Deploy → Operate → Monitor → Improve

Security activities occur at every stage. During planning, teams identify data classifications, threats and compliance requirements. During coding, developers use secure design patterns and code analysis. During building, dependencies and container images are scanned. During deployment, policies verify identity, network and storage settings. During operation, logs, vulnerability data and configuration changes are continuously assessed.

DevSecOps does not mean that every developer becomes a security specialist. It means that security expertise, automation, standards and accountability are built into the workflow. Security teams provide guardrails and enablement; development and operations teams remain responsible for the security of the systems they create and run.

Shared responsibility in cloud security

Cloud providers secure the physical facilities, underlying hardware and selected managed-service components. Customers remain responsible for matters such as identities, data, application code, network rules and configuration. The exact division depends on the service model:

This model is not a transfer of accountability to the provider. Organisations must understand the provider’s controls, configure services correctly and retain evidence of their own compliance.

2. Infrastructure as Code

Infrastructure as code (IaC) defines infrastructure in machine-readable files rather than relying on manual console actions. Examples include virtual networks, subnets, security groups, databases, encryption settings and identity roles. Tools may use declarative descriptions, in which the desired state is specified, or imperative instructions, in which a sequence of actions is described.

IaC supports security because it makes infrastructure:

• Reviewable: changes can be examined before deployment.
• Repeatable: the same approved definition can create multiple environments.
• Traceable: version control records who changed what and when.
• Testable: automated checks can identify insecure settings.
• Recoverable: earlier versions can be restored when appropriate.

IaC does not automatically produce secure infrastructure. An insecure template can reproduce insecure settings consistently. Files may also contain secrets, excessive permissions or assumptions that are safe only in one environment.

Secure IaC practices

A secure IaC process should include the following:

1. Store templates in a protected version-control repository.
2. Require peer review and, for sensitive changes, separate approval.
3. Prohibit plaintext passwords, tokens and private keys in templates.
4. Retrieve secrets from an approved secrets-management service at deployment or runtime.
5. Use reusable modules with secure defaults.
6. Pin provider and module versions where practical, while maintaining an update process.
7. Scan templates before provisioning.
8. Separate development, testing and production state and credentials.
9. Protect state files because they may contain resource identifiers or sensitive values.
10. Record deployment identity, change reference, result and approval evidence.

A useful distinction is between desired state and observed state. Desired state is what the IaC definition declares. Observed state is what exists in the cloud account. Drift occurs when these differ, for example because an administrator manually changes a firewall rule. Drift detection should generate an alert or an approved reconciliation process. Automatically overwriting changes can be dangerous if the change was an emergency response or if the template is outdated.

Example: secure network module

A reusable network module might require encrypted private connections, deny unrestricted inbound administration ports, enable flow logging and require resource tags such as owner, environment and data classification. The module should expose only necessary parameters and validate them. A parameter that accepts an arbitrary CIDR range is weaker than one that requires an approved network reference or a documented exception.

3. Security Controls in CI/CD Pipelines

Continuous integration (CI) automatically builds and tests changes. Continuous delivery or deployment (CD) moves approved artefacts toward or into production. Because a pipeline can access source code, credentials, cloud accounts and signing keys, it is a high-value security target.

Protecting the pipeline

Important controls include:

• strong authentication and multi-factor authentication for administrative access;
• least-privilege service identities for each pipeline stage;
• short-lived credentials obtained through workload identity or federation;
• protected branches and mandatory review for production changes;
• isolated, ephemeral build workers where feasible;
• restricted network access from build systems;
• signed or integrity-checked build artefacts;
• immutable artefact repositories with retention controls;
• audit logs for source, build, approval and deployment events;
• separation of development and production credentials;
• tested backup and recovery procedures for pipeline definitions.

Pipeline secrets must not be printed in logs. Masking is useful but not perfect; a secret may appear encoded, transformed or embedded in an error message. The safest approach is to avoid placing long-lived secrets in the pipeline at all.

Gates and risk-based promotion

A pipeline gate can stop promotion when a defined condition is violated. Examples include a critical vulnerability with a known exploit, an unapproved public endpoint or a missing encryption setting. Gates should be risk-based and documented. A rule that blocks every low-risk informational finding may encourage teams to disable the scanner. A rule that permits exploitable critical issues creates unacceptable exposure.

Exceptions should have an owner, business justification, compensating control, expiry date and review record. An exception without an expiry becomes an undocumented permanent weakness.

4. Vulnerability and Dependency Scanning

Different scanners identify different classes of weakness. No single scanner provides complete assurance.

Interpreting findings

A scanner result is not automatically a confirmed security incident. Analysts should validate the affected component, version, execution path, exposure, exploitability and business impact. A vulnerability in an unused library may have lower practical risk than a moderate weakness in an internet-facing authentication service.

A simple prioritisation model can use qualitative categories such as critical, high, medium and low. Some organisations calculate a risk score, but a score is meaningful only when its inputs and scale are defined. A generic expression such as Risk = Likelihood × Impact is a conceptual model, not a universal numerical law. Likelihood may consider exposure, exploit availability and attack complexity; impact may consider confidentiality, integrity, availability and regulatory consequences.

Scanning should occur at multiple points: pull request, build, image publication, deployment and operation. Results should be tracked to closure. Teams should avoid treating a clean scan as proof that an application is secure; scanners have false positives, false negatives and incomplete knowledge of runtime behaviour.

Software supply-chain security

The software supply chain includes developers, source repositories, dependencies, build tools, artefact registries and deployment systems. Controls include dependency lock files, approved registries, provenance records, signed artefacts, reproducible or controlled builds, malware detection and rapid revocation of compromised components. Software bills of materials (SBOMs) describe component inventories and support incident response, although an SBOM alone does not prove that components are safe.

5. Configuration Management and Secure Baselines

Configuration management establishes and maintains approved settings. A secure baseline may specify identity controls, logging, encryption, network exposure, backup, time synchronisation and monitoring requirements.

Configuration management has four related activities:

1. Identification: define assets, owners, versions and required settings.
2. Control: approve and restrict changes.
3. Status accounting: record current and historical configuration.
4. Verification: compare actual state with the approved baseline.

Cloud resources are dynamic, so inventories must be automated where possible. Tags and resource metadata should identify the owner, environment, purpose, data classification and support contact. Untagged or orphaned resources increase cost and may escape security monitoring.

A baseline must be practical. If it requires controls unsupported by a service, teams will create exceptions or bypass the process. Baselines should distinguish mandatory controls from recommended controls and explain how compensating controls are assessed.

6. Policy as Code

Policy as code expresses organisational or technical rules in a machine-evaluable form. For example, a policy may deny creation of a storage resource unless encryption is enabled and public access is disabled. Policies can be evaluated against IaC before deployment or against live resources after deployment.

Policy as code offers consistency, speed and evidence. It also introduces risks: an incorrect policy can block valid work or permit unsafe behaviour at scale. Policies should therefore be version-controlled, tested with positive and negative cases, reviewed by subject-matter experts and deployed through a controlled process.

A mature policy framework commonly supports three responses:

• Deny: prevent a clearly unacceptable action.
• Warn: permit the action but notify the owner.
• Audit: record non-compliance for investigation or remediation.

The response should reflect risk and operational context. A policy prohibiting public exposure of highly sensitive data may deny deployment. A policy requiring a cost-centre tag may initially warn while teams correct legacy resources.

7. Patching and Vulnerability Remediation

Patching reduces exposure by correcting software defects, but it must be managed as a lifecycle rather than an occasional emergency activity. The process includes asset discovery, vulnerability identification, prioritisation, testing, deployment, verification and reporting.

Prioritisation should consider severity, exploitability, internet exposure, asset criticality, compensating controls and the availability of a safe fix. Organisations may define service-level objectives, such as remediation of actively exploited critical weaknesses within a shorter period than low-risk internal findings. Exact time limits should be set by organisational risk appetite and regulatory requirements rather than copied without context.

Cloud-native approaches include immutable images, automated instance replacement and managed services with provider-maintained components. These reduce configuration drift but do not eliminate responsibility. Image pipelines must still rebuild from current base images, test compatibility and remove vulnerable artefacts from deployment channels.

A patch record should show the asset, vulnerability, change, test result, deployment time, verification evidence and any exception. Emergency changes should be reviewed after implementation even when normal approval was bypassed.

8. Continuous Compliance and Monitoring

Periodic audits provide snapshots; continuous compliance provides ongoing evidence about changing systems. It combines configuration assessment, identity analysis, vulnerability data, logging and control testing.

Useful compliance indicators include:

• percentage of assets with an identified owner;
• percentage of production resources meeting encryption requirements;
• age of the oldest unresolved critical vulnerability;
• percentage of pipeline deployments using approved artefacts;
• number and age of policy exceptions;
• percentage of cloud accounts sending required logs to protected storage.

Metrics need interpretation. A high compliance percentage may conceal a small number of highly important non-compliant systems. Teams should report both aggregate performance and exceptions by business criticality.

Continuous compliance must protect evidence. Logs should have controlled access, appropriate retention, time synchronisation and protection against unauthorised alteration. Monitoring itself can create privacy concerns, particularly when developer activity, user identifiers or application content is collected. Data minimisation and access controls are therefore necessary.

9. Governance, Ethics and Regulation

Secure cloud operations involves governance decisions about accountability, data location, retention and acceptable risk. Relevant obligations may arise from privacy, financial, health, critical-infrastructure or contractual requirements. Organisations should map obligations to technical controls and retain evidence showing how controls operate.

Ethically, security automation should not create unreasonable surveillance or punish teams for defects without providing resources to correct them. Automated blocking should be transparent, appealable and proportionate. Security teams should protect confidential source code and vulnerability information. Artificial intelligence may assist with log triage, code review or prioritisation, but generated recommendations require human validation. Sensitive code or incident data should not be sent to an AI service without an approved data-protection assessment.

10. Illustrative Case: Online Retail Migration

Background

An illustrative retailer migrated its order-processing platform to a public cloud. Development teams used IaC and a CI/CD platform, but production resources were also changed manually during incidents. The organisation experienced an exposed test database, inconsistent logging and delayed patching of container images.

Problem analysis

An investigation found that templates allowed public network rules, production credentials were shared by several pipeline jobs, and the container registry retained old vulnerable images. No owner was assigned to many cloud resources. Security scanning occurred only before major releases, so newly disclosed vulnerabilities were not detected promptly.

Approach

The retailer introduced protected repositories, peer review and separate environments. Pipeline jobs received short-lived identities with only the permissions required for their stage. IaC scanning blocked public databases and unrestricted administration ports. Container images were built from approved base images, scanned before publication and rebuilt when critical base-image updates were released.

A policy-as-code service audited all accounts for encryption, logging, ownership tags and public exposure. High-risk violations generated tickets with owners and deadlines; public exposure of restricted data was denied. Production changes were made through IaC except for documented emergency procedures. A central dashboard reported vulnerability age, policy exceptions and logging coverage.

Outcome

The organisation reduced unauthorised configuration differences and improved its ability to identify affected resources when a dependency advisory was issued. The programme did not eliminate all risk: false positives required review, legacy applications needed exceptions, and automated controls occasionally conflicted with emergency operations.

Learning points

The case demonstrates that DevSecOps is a system of people, processes and technology. Scanners were useful only after ownership, workflow and remediation responsibilities were established. Prevention, detection and recovery controls were all necessary. The most effective improvements were risk-based, measurable and integrated with existing delivery practices.

11. Implementation Guidance and Common Failure Modes

A practical implementation can proceed incrementally:

1. inventory cloud accounts, repositories, pipelines and production assets;
2. identify critical data and services;
3. establish secure baseline requirements;
4. protect repositories and pipeline identities;
5. scan IaC, source code, dependencies and images;
6. introduce policy checks in audit mode before enforcing selected rules;
7. centralise logging and compliance evidence;
8. define vulnerability and exception processes;
9. measure outcomes and improve controls.

Common failure modes include buying scanners without assigning remediation ownership, creating excessive approval gates, allowing unmanaged manual changes, ignoring pipeline security, storing secrets in code, treating compliance as a once-a-year exercise and measuring only the number of findings rather than the time and risk of unresolved findings.

Chapter Summary

Secure cloud operations integrates security into planning, coding, building, testing, deployment and runtime monitoring. DevSecOps creates shared responsibility while retaining specialist security expertise. Infrastructure as code improves repeatability and review but must be protected against insecure templates, secrets and configuration drift. CI/CD pipelines require least privilege, protected repositories, controlled artefacts, secure identities and auditable approvals.

SAST, SCA, secret scanning, IaC scanning, container scanning, DAST and cloud configuration assessment address different risks and should be combined. Configuration management establishes secure baselines, while policy as code turns selected requirements into repeatable automated checks. Patching requires prioritisation, testing, deployment and verification. Continuous compliance supplies ongoing evidence but must account for privacy, false positives and the importance of individual exceptions. Effective programmes are risk-based, measurable, governed and supported by clear ownership.

Key Terms

DevSecOps: An approach that integrates development, security and operations across the delivery lifecycle.

Infrastructure as code: Machine-readable management of infrastructure resources and settings.

Configuration drift: A difference between approved desired configuration and actual deployed state.

CI/CD: Continuous integration and continuous delivery or deployment practices.

Pipeline gate: A condition that permits or prevents progression to a later delivery stage.

SAST: Static application security testing of source or compiled code.

SCA: Software composition analysis of third-party and open-source components.

DAST: Dynamic testing of a running application.

SBOM: Software bill of materials listing software components and versions.

Secure baseline: An approved minimum set of security configurations.

Policy as code: Machine-evaluable representation of organisational or technical policy.

Least privilege: Granting only the permissions required for an authorised task.

Workload identity: An identity assigned to an application, service or automation process.

Vulnerability: A weakness that can be exploited to compromise security.

Exception: An approved deviation from a required control.

Continuous compliance: Ongoing assessment and evidence of conformity with requirements.

Immutable image: A deployed image that is replaced rather than modified in place.

Shared responsibility model: Division of security responsibilities between provider and customer.

Review Questions

Short Answer Questions

1. What is the principal difference between traditional security review and DevSecOps?
2. Give three security benefits of infrastructure as code.
3. What is configuration drift, and how can it be detected?
4. Distinguish SAST from DAST.
5. Why should pipeline credentials be short-lived and least-privileged?

Long Answer Questions

1. Explain how security controls can be distributed across the CI/CD lifecycle.
2. Compare the purposes and limitations of SAST, SCA, IaC scanning, container scanning and DAST.
3. Describe a secure process for managing cloud configuration baselines.
4. Explain how policy as code can support both preventive and detective controls.
5. Discuss the governance, privacy and accountability issues involved in continuous compliance.

Analytical / Application Questions

1. A development team wants to permit unrestricted inbound access to a test database because it accelerates debugging. Analyse the security risks and propose a safer workflow.
2. A critical vulnerability is discovered in a dependency used by hundreds of container images. Design a prioritised response covering identification, rebuilding, deployment and verification.
3. An organisation has excellent scanning coverage but many unresolved findings. Analyse possible process causes and recommend measures that would improve remediation outcomes.

Multiple Choice Questions with Answers

Question 1

Which practice most directly helps detect infrastructure drift?

A. Comparing observed cloud resources with version-controlled desired state

B. Increasing the number of application features

C. Disabling audit logs after deployment

D. Using one shared administrator account

Correct Answer: A. Comparing observed cloud resources with version-controlled desired state

Question 2

What is the main purpose of software composition analysis?

A. Testing physical data-centre access

B. Identifying risks in third-party and open-source components

C. Measuring network bandwidth

D. Encrypting database backups

Correct Answer: B. Identifying risks in third-party and open-source components

Question 3

Which control best protects a CI/CD pipeline from excessive privilege?

A. One permanent administrator credential for every job

B. Short-lived identities with permissions limited to each stage

C. Storing passwords in build logs

D. Allowing anonymous changes to production branches

Correct Answer: B. Short-lived identities with permissions limited to each stage

Question 4

A policy that prevents creation of an unencrypted production database is an example of what?

A. Preventive policy as code

B. Disaster recovery testing

C. Dynamic application testing

D. Manual configuration drift

Correct Answer: A. Preventive policy as code

Question 5

Which statement about an SBOM is correct?

A. It proves that every component is vulnerability-free

B. It lists software components and supports impact analysis

C. It replaces all application security testing

D. It is used only for physical hardware inventories

Correct Answer: B. It lists software components and supports impact analysis

Question 6

Why should a vulnerability exception have an expiry date?

A. To ensure the risk is periodically reassessed

B. To prevent all future software updates

C. To remove the need for an owner

D. To make the vulnerability invisible to scanners

Correct Answer: A. To ensure the risk is periodically reassessed

Question 7

Which scanning method primarily examines a running application from an external perspective?

A. SAST

B. SCA

C. DAST

D. Secret scanning

Correct Answer: C. DAST

Question 8

What is a major risk of insecure IaC templates?

A. They prevent all infrastructure from being automated

B. They reproduce insecure settings consistently

C. They eliminate the need for version control

D. They guarantee that configuration drift cannot occur

Correct Answer: B. They reproduce insecure settings consistently

Question 9

Which response is generally most appropriate for a clearly unacceptable public exposure of restricted data?

A. Deny the deployment

B. Ignore the finding until an annual audit

C. Record it without notifying anyone

D. Allow it automatically and delete the logs

Correct Answer: A. Deny the deployment

Question 10

Why is a clean automated scan not proof that an application is secure?

A. Scanners can have incomplete coverage and false positives or negatives

B. Scanners always examine only physical servers

C. Security testing is unnecessary after scanning

D. Cloud providers prohibit all automated testing

Correct Answer: A. Scanners can have incomplete coverage and false positives or negatives