DevSecOps, Infrastructure as Code and Supply-Chain Security

Introduction

Cloud applications are assembled from source code, open-source packages, container images, infrastructure definitions, build tools, deployment workflows, and managed cloud services. This composition creates speed and flexibility, but it also enlarges the attack surface. A vulnerable library, an over-privileged deployment identity, an altered build artifact, or an insecure infrastructure template can compromise an entire cloud environment.

DevSecOps addresses this problem by integrating security into software delivery rather than treating it as a final inspection. Infrastructure as Code (IaC) extends the same principle to networks, compute, identity, storage, databases, and security controls. Supply-chain security protects the relationships and processes through which software and infrastructure components are acquired, built, tested, distributed, and operated.

The central principle is that security controls should be early, automated, repeatable, evidence-producing, and proportionate to risk. Automation does not eliminate professional judgement; it makes judgement more timely and consistent.

Learning Objectives

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

1. Explain DevSecOps and distinguish it from traditional security gatekeeping.
2. Design security controls across a cloud CI/CD lifecycle.
3. Identify common IaC risks and apply static scanning and policy as code.
4. Explain SBOMs, dependency assurance, provenance, and artifact signing.
5. Design automated compliance tests and interpret their limitations.
6. Evaluate governance, ethical, operational, and regulatory implications.
7. Propose a practical secure delivery architecture for a cloud application.

1. DevSecOps as an Operating Model

DevSecOps is a culture, set of practices, and technical operating model in which development, security, and operations share responsibility for secure delivery and reliable operation. It is not merely the installation of a security scanner in a pipeline. It changes ownership, feedback timing, evidence collection, and risk acceptance.

Traditional delivery commonly follows a sequence: developers build software, operations deploy it, and a security team performs a review near release. This arrangement creates late discovery, manual bottlenecks, weak context, and pressure to waive findings. DevSecOps distributes controls throughout the lifecycle:

• Plan: identify security requirements, data classifications, abuse cases, and regulatory obligations.
• Code: apply secure coding standards, peer review, secret prevention, and developer-focused analysis.
• Build: isolate build jobs, scan dependencies, produce provenance, and create reproducible artifacts where feasible.
• Test: perform unit, integration, static, dynamic, API, infrastructure, and compliance tests.
• Release: enforce approvals, artifact integrity, separation of duties, and deployment policy.
• Deploy: use least-privilege identities, protected environments, and controlled configuration.
• Operate: monitor vulnerabilities, identity use, drift, incidents, and policy compliance.
• Retire: revoke credentials, archive evidence appropriately, and remove unused resources and data.

Security should be embedded through shift left, shift right, and shield forward practices. Shift left moves useful checks toward design and development. Shift right validates production behaviour through monitoring and response. Shield forward means platform teams provide secure defaults, reusable controls, and guardrails so that developers can be productive without repeatedly solving the same security problem.

Security ownership and the shared-responsibility model

Cloud providers secure the underlying facilities and managed service infrastructure according to their service model. Customers remain responsible for matters such as identities, data, configurations, application code, and workload-specific controls. The exact division varies among Infrastructure as a Service, Platform as a Service, and Software as a Service.

DevSecOps therefore requires a clear responsibility matrix. For example, a provider may patch a managed database engine, while the customer must configure network access, encryption keys, database permissions, and data retention. Ambiguous ownership is itself a risk.

2. Secure CI/CD Architecture

A secure pipeline is a controlled production system. It has identities, inputs, processing stages, outputs, logs, and failure modes. Pipeline security must therefore cover both the application and the delivery mechanism.

A representative control sequence is:

1. Authenticate commits and restrict who can modify protected branches.
2. Detect secrets before code is accepted and prevent credentials from entering repositories.
3. Compile and test in an isolated, minimally privileged environment.
4. Analyse source code, dependencies, containers, and IaC.
5. Generate a bill of materials and provenance metadata.
6. Sign the artifact and store it in a controlled registry.
7. Test the deployment configuration in an ephemeral environment.
8. Require policy checks and, for high-risk changes, accountable approval.
9. Deploy only the signed artifact that was tested.
10. Monitor runtime behaviour and feed findings back into development.

Figure: A secure delivery flow with continuous controls and feedback.

Pipeline threats

Important threats include compromised source repositories, malicious pull requests, poisoned build dependencies, exposed CI secrets, vulnerable runner images, tampered artifacts, unauthorized workflow changes, and excessive deployment permissions. A pipeline can be attacked even when the application source is secure.

Recommended controls include short-lived credentials through workload identity federation, protected branches, mandatory reviews for workflow changes, runner isolation, dependency pinning, network egress restrictions, immutable artifact repositories, comprehensive logs, and separate identities for build, test, and deployment. Pipeline logs should avoid printing secrets and should be retained according to evidence and privacy requirements.

Security testing categories

Findings should be triaged by exploitability, exposure, asset criticality, compensating controls, and remediation cost—not by severity score alone. A critical library in an unreachable development image may present less immediate risk than a moderate identity misconfiguration on a public production service.

3. Secure Coding in Cloud Applications

Secure coding begins with threat modelling. Teams identify assets, trust boundaries, actors, attack paths, and security properties such as confidentiality, integrity, availability, authenticity, and accountability. Threat modelling methods may include data-flow diagrams, STRIDE-style analysis, abuse cases, and attack trees.

Cloud-specific secure coding concerns include:

• validating authorization on every sensitive operation rather than trusting the front end;
• preventing tenant isolation failures in multi-tenant systems;
• using parameterized queries and safe serialization;
• applying input validation and output encoding appropriate to the context;
• protecting APIs with authentication, authorization, rate limits, and schema validation;
• avoiding hard-coded credentials and using managed secret stores;
• configuring secure logging without recording passwords, tokens, or unnecessary personal data;
• designing idempotent and replay-resistant operations for event-driven systems;
• handling queues and retries without creating duplicate financial or administrative actions;
• setting explicit timeouts, resource limits, and failure behaviour in serverless functions and containers.

Security requirements should be testable. “The service must be secure” is not a useful acceptance criterion. “A user can retrieve records only for authorised tenant identifiers, and unauthorized requests are logged without exposing record contents” is more actionable.

4. Infrastructure as Code

IaC represents infrastructure in machine-readable files that can be reviewed, versioned, tested, and applied consistently. It may describe virtual networks, firewall rules, identity policies, storage, Kubernetes objects, databases, and observability resources.

IaC improves reproducibility and auditability, but it also makes insecure configurations scalable. A permissive firewall rule copied across many environments can create systemic exposure. IaC security therefore covers the template, its modules, variables, state, execution identity, provider plugins, and deployed result.

IaC risk areas

1. Network exposure: public management ports, unrestricted ingress, missing egress controls, or incorrect segmentation.
2. Identity: wildcard permissions, privilege escalation paths, long-lived service credentials, and missing resource conditions.
3. Data protection: unencrypted storage, public buckets, weak key policies, or excessive retention.
4. State security: plaintext secrets in state files, broad state access, weak locking, or unprotected backups.
5. Configuration drift: manual changes that cause deployed resources to differ from approved code.
6. Module risk: unreviewed third-party modules, mutable versions, unsafe defaults, and transitive dependencies.
7. Availability: missing backups, weak recovery settings, single-zone dependencies, or unsafe autoscaling limits.

IaC scanning and testing

IaC analysis may be static or dynamic. Static tools inspect templates before deployment. Dynamic validation deploys to a test account or ephemeral environment and checks actual provider behaviour. Both are necessary because provider defaults, implicit dependencies, and generated resources may not be visible from a simple text scan.

A mature IaC pipeline commonly performs formatting and syntax checks, semantic validation, static security analysis, plan review, policy evaluation, ephemeral deployment tests, and post-deployment drift detection. Secrets must not be placed in templates or state files; references should point to a secret-management service and use controlled retrieval at runtime.

Policy as code

Policy as code expresses rules in a machine-evaluable form. Examples include:

• production storage must use encryption with an approved key;
• no security group may permit unrestricted administrative access;
• every internet-facing service must have an approved owner and monitoring;
• images must originate from an approved registry and carry a valid signature;
• deployment identities may modify only the target environment.

Policies should distinguish preventive, detective, and corrective controls. A preventive policy blocks a deployment. A detective policy reports a violation. A corrective policy remediates a known condition, but automatic remediation must be carefully designed to avoid destroying evidence or interrupting essential services.

Good policy engineering includes version control, testing, exception workflows, ownership, expiry dates, risk-based enforcement, and readable violation messages. A policy that blocks all progress without explaining remediation will encourage bypasses.

5. Software Supply-Chain Security

The software supply chain includes developers, source repositories, package registries, build systems, CI runners, base images, signing services, artifact repositories, deployment systems, and operational environments. Security must address both malicious activity and accidental compromise.

Dependency assurance

Organisations should maintain an inventory of direct and transitive dependencies, pin versions where practical, use trusted registries, verify checksums or signatures, and review package provenance. Automated updates are valuable but should pass tests and policy checks. Dependency risk assessment should consider maintenance activity, popularity, ownership changes, known vulnerabilities, licensing, reachability, and whether the vulnerable component is actually used by the deployed function.

A vulnerability identifier is an input to analysis, not an automatic emergency command. Teams should determine affected versions, exploitability, exposure, available mitigations, and remediation deadlines. Emergency exceptions must be documented and revisited.

Software bills of materials

An SBOM is a structured inventory of components in a software artifact. It may include package names, versions, suppliers, licenses, hashes, relationships, and generation metadata. Common exchange formats include SPDX and CycloneDX.

An SBOM supports vulnerability response, license governance, asset inventory, and customer assurance. It is not a security certificate. An incomplete SBOM, an inaccurate version, or an untracked runtime-loaded component can produce false confidence. SBOMs should be generated as close as possible to the build, linked to an immutable artifact, retained with provenance, and updated when the artifact changes.

Provenance and attestations

Provenance describes how, where, and from what inputs an artifact was built. An attestation can record the source revision, builder identity, build parameters, dependencies, tests, and policy results. Provenance is stronger when it is generated by a trusted, isolated build service and is cryptographically protected.

Artifact signing and verification

Signing binds an artifact or statement to a signing identity through cryptographic mechanisms. Verification must occur at the deployment boundary, not only when the artifact is published. The verifier should check the signature, trusted identity, artifact digest, certificate or key validity, required attestations, and policy conditions.

Signing does not make vulnerable software safe; it provides authenticity and integrity evidence. Key management is central: keys should be protected, access should be least privileged, signing events should be logged, and rotation and revocation procedures should be tested. Modern keyless approaches can use short-lived identities and transparency records, but they still require trust-root governance and protection of the identity-issuance process.

6. Automated Compliance and Evidence

Automated compliance testing converts selected requirements into repeatable checks. Examples include verifying encryption settings, logging coverage, backup configuration, approved regions, least-privilege roles, vulnerability remediation windows, and signed deployment artifacts.

Compliance automation should map each check to a control objective, its evidence source, frequency, responsible owner, failure action, and exception process. Evidence must be trustworthy: timestamps, identities, immutable logs, versioned policies, and links to the exact artifact or configuration being evaluated are important.

Automation has limits. A test may verify that logging is enabled but not that alerts are reviewed. It may find a public storage setting but not determine whether the data is legally permitted to be public. Human review remains necessary for context, novel threats, business risk acceptance, and ethical judgement.

7. Governance, Ethics and Regulation

Secure delivery involves governance decisions about surveillance, accountability, access, and acceptable risk. Pipeline logs may contain developer identifiers, code metadata, or operational events. Collection should be limited to legitimate purposes, protected from misuse, and retained according to law and policy.

Important governance practices include separation of duties for high-impact production changes, documented risk acceptance, independent review of critical controls, supplier contracts, incident notification procedures, and secure handling of vulnerability reports. Organisations should avoid penalizing responsible disclosure or creating incentives to hide defects.

Regulatory obligations vary by jurisdiction and sector, but recurring themes include protection of personal data, demonstrable access control, breach response, retention, auditability, software assurance, and third-party risk management. Compliance is a baseline; an organisation can satisfy a checklist and remain vulnerable.

8. Applied Case: Illustrative Online Health-Appointment Platform

Background

A fictional provider operates a cloud platform through which patients book appointments. The platform uses a web front end, APIs, containers, a managed database, open-source packages, infrastructure templates, and automated deployment.

Problem

A security review finds three weaknesses: a container includes an outdated library, a storage resource is accidentally public in a non-production template, and the deployment pipeline uses a long-lived administrator credential. The organisation also cannot identify every component in a deployed image.

Analysis

The library creates supply-chain and vulnerability risk. The public storage setting demonstrates that IaC errors can be replicated. The administrator credential creates a high-impact pipeline compromise path. The absence of an SBOM prevents efficient impact analysis and customer communication.

Approach and solution

The team first classifies patient information as highly sensitive and establishes production ownership. It replaces the administrator credential with short-lived, federated deployment identities scoped to the target account and environment. Protected branches and mandatory review are enabled for application code, workflow files, and IaC modules.

The pipeline then adds secret scanning, SAST, SCA, container scanning, IaC scanning, and policy-as-code checks. The storage policy blocks public access and requires encryption. A test account is used for ephemeral deployment and automated verification. The build generates an SBOM, records provenance, signs the image, and publishes it to an immutable registry. The deployment controller verifies the signature and approved builder identity before release.

Runtime controls include database encryption, tenant-aware authorization tests, audit logging, vulnerability monitoring, backup testing, and drift detection. A vulnerability response process links SBOM components to affected deployments and assigns remediation deadlines based on exposure and exploitability.

Outcome

The platform can now identify the exact image and dependency set deployed to production, reject unsigned or unapproved images, prevent the known IaC error, and reduce the impact of pipeline credential theft. The controls do not guarantee perfect security, but they improve prevention, detection, response, and accountability.

Learning points

1. A pipeline is part of the production attack surface.
2. IaC makes both secure and insecure decisions repeatable.
3. SBOMs improve visibility but require accuracy and maintenance.
4. Signing proves origin and integrity, not absence of vulnerabilities.
5. Effective automation combines technical controls with ownership and governance.

9. Challenges and Contemporary Developments

Security automation can generate alert fatigue, false positives, pipeline delays, and pressure to create exceptions. Tools may disagree about package names, severity, reachability, or ownership. Organisations should measure remediation quality and control effectiveness rather than merely counting scans.

Emerging practices include hermetic and reproducible builds, isolated ephemeral runners, confidential computing for sensitive workloads, stronger provenance standards, continuous authorization, admission control for containers, and software supply-chain frameworks such as SLSA-oriented assurance levels. Artificial intelligence can assist code review, vulnerability prioritization, test generation, and policy explanation. However, AI-generated code may reproduce insecure patterns, introduce licensing uncertainty, leak sensitive prompts, or create false confidence. AI outputs require human review, testing, provenance, and approved data-handling controls.

10. Best-Practice Implementation Roadmap

An organisation beginning DevSecOps should proceed incrementally:

1. Inventory applications, pipelines, repositories, identities, artifacts, and cloud accounts.
2. Define ownership, risk tiers, security requirements, and exception authority.
3. Protect source repositories and remove long-lived pipeline secrets.
4. Establish baseline SAST, secret scanning, dependency scanning, and IaC checks.
5. Centralize artifacts and generate SBOMs for critical products.
6. Introduce policy as code with actionable messages and tested exceptions.
7. Sign artifacts and verify them at deployment.
8. Add dynamic testing, ephemeral environments, drift detection, and runtime feedback.
9. Measure outcomes such as critical exposure time, unauthorized change attempts, coverage of signed artifacts, and recurring policy violations.
10. Review controls after incidents, major architecture changes, and supplier changes.

Chapter Summary

DevSecOps embeds security in planning, coding, building, testing, releasing, deploying, operating, and retiring cloud systems. Its effectiveness depends on shared responsibility, secure pipeline design, least privilege, protected secrets, meaningful automated testing, and feedback from runtime operations.

Infrastructure as Code improves consistency and auditability but can scale insecure configurations. IaC scanning, dynamic validation, policy as code, drift detection, protected state, and controlled exceptions reduce this risk. Supply-chain security requires dependency assurance, SBOMs, provenance, artifact signing, trusted builders, immutable repositories, and deployment-time verification.

Automated compliance produces timely evidence but cannot replace context, ethical judgement, or accountable governance. The most mature approach combines technical controls, human review, measurable ownership, and continuous improvement.

Key Terms

DevSecOps: A delivery model integrating development, security, and operations responsibilities.

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

Infrastructure as Code: Machine-readable management of infrastructure configuration.

Shift left: Moving security activities earlier in the lifecycle.

Policy as code: Machine-evaluable rules that govern systems or delivery decisions.

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

DAST: Dynamic application security testing of a running application.

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

SBOM: A structured inventory of software components and relationships.

Provenance: Evidence describing how an artifact was produced.

Attestation: A digitally protected statement about an artifact, process, or result.

Artifact signing: Cryptographically binding an artifact to a trusted identity.

Dependency pinning: Restricting dependency resolution to specified versions or digests.

Drift: Difference between approved declared configuration and deployed state.

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

Immutable artifact: An artifact whose contents cannot be changed after publication.

Supply-chain security: Protection of software components, tools, processes, and relationships from compromise.

Risk acceptance: A formally accountable decision to tolerate a specified risk.

Review Questions

Short Answer Questions

1. What is the principal difference between DevSecOps and a final security review before release?
2. Why should deployment systems verify artifact signatures rather than merely trust a registry?
3. State two security risks associated with IaC state files.
4. What information can an SBOM provide?
5. Why is policy as code not sufficient by itself to guarantee compliance?

Long Answer Questions

1. Explain how security controls can be distributed across the stages of a cloud CI/CD lifecycle.
2. Discuss the relationship between dependency assurance, SBOMs, provenance, and artifact signing.
3. Compare static IaC scanning with dynamic infrastructure validation, including the limitations of each.
4. Explain how least privilege and short-lived identities reduce CI/CD pipeline risk.
5. Design a governance process for security exceptions in an automated deployment pipeline.

Analytical / Application Questions

1. A team discovers that a production container was built from an unreviewed source commit, although the image has a valid signature. Analyse what the signature proves, what it does not prove, and which additional provenance controls are needed.
2. An IaC policy blocks every storage resource that is not encrypted, but a legacy application requires a temporary exception. Propose a policy and governance approach that permits justified work without creating a permanent bypass.
3. A critical vulnerability is reported in a package used by several services. Using SBOM data, exposure analysis, and deployment evidence, develop a prioritised response plan.

Multiple Choice Questions with Answers

Question 1

Which practice most directly verifies that the artifact deployed is the artifact that was tested?

A. Increasing the number of code reviewers

B. Verifying the artifact signature and digest at deployment

C. Running a vulnerability scan once per year

D. Allowing developers to deploy from local machines

Correct Answer: B. Verifying the artifact signature and digest at deployment

Question 2

What is the primary purpose of an SBOM?

A. To prove that software contains no vulnerabilities

B. To replace penetration testing

C. To provide an inventory of software components and relationships

D. To encrypt source code

Correct Answer: C. To provide an inventory of software components and relationships

Question 3

Which is an example of policy as code?

A. A meeting in which engineers discuss firewall design

B. A machine-evaluated rule blocking unrestricted administrative access

C. A manually written incident report

D. A developer’s informal coding preference

Correct Answer: B. A machine-evaluated rule blocking unrestricted administrative access

Question 4

Which control best reduces the risk of a stolen CI/CD credential being reused indefinitely?

A. Longer passwords stored in a repository

B. Short-lived federated deployment identities

C. Disabling all pipeline logs

D. Using one administrator identity for every environment

Correct Answer: B. Short-lived federated deployment identities

Question 5

What does artifact signing primarily provide?

A. Proof that the artifact is free of defects

B. Proof of authenticity and integrity associated with a signing identity

C. Automatic compliance with every regulation

D. A replacement for dependency management

Correct Answer: B. Proof of authenticity and integrity associated with a signing identity

Question 6

Which IaC weakness can cause a secure configuration to differ from the deployed environment?

A. Configuration drift

B. Source formatting

C. Unit testing

D. Artifact immutability

Correct Answer: A. Configuration drift

Question 7

Why are SBOMs insufficient as a complete supply-chain security measure?

A. They cannot list any dependencies

B. They are useful only for physical hardware

C. They may be incomplete or inaccurate and do not themselves prevent compromise

D. They automatically grant deployment permissions

Correct Answer: C. They may be incomplete or inaccurate and do not themselves prevent compromise

Question 8

Which test is designed primarily to analyse a running application from an external perspective?

A. SAST

B. SCA

C. DAST

D. Secret scanning

Correct Answer: C. DAST

Question 9

What is a key limitation of automated compliance testing?

A. It can never produce evidence

B. It cannot replace contextual human judgement

C. It always requires manual execution

D. It prevents all policy exceptions

Correct Answer: B. It cannot replace contextual human judgement

Question 10

Which practice most directly protects the build process from unauthorized modification?

A. Using protected workflow files and isolated build runners

B. Publishing artifacts without version identifiers

C. Disabling branch protection

D. Sharing build credentials among developers

Correct Answer: A. Using protected workflow files and isolated build runners