9. DevSecOps, Infrastructure as Code and Supply-Chain Security

Introduction and Context

Cloud-native development has changed the way software is designed, delivered, and operated. Applications are assembled from open-source libraries, container images, managed cloud services, application programming interfaces (APIs), infrastructure templates, and automated deployment pipelines. Development teams may release changes several times a day, while infrastructure can be created or destroyed through a single code commit. These capabilities improve speed and scalability, but they also enlarge the security and governance problem. A vulnerable library, compromised build runner, exposed secret, or incorrectly configured cloud resource can move rapidly from source code into production.

DevSecOps addresses this problem by integrating security into development and operations rather than treating it as a final approval activity. Its purpose is not simply to add more security tools to a delivery pipeline. It is to establish shared responsibility, automated assurance, rapid feedback, traceability, and risk-based decision-making throughout the software development life cycle (SDLC).

This chapter examines the practical architecture of DevSecOps, including static and dynamic testing, software composition analysis, API testing, infrastructure-as-code (IaC) scanning, policy as code, software bills of materials (SBOMs), artifact signing, vulnerability remediation, and software supply-chain frameworks such as SLSA. The discussion is particularly relevant to cloud and enterprise environments, where code, infrastructure, identities, data, and third-party services are tightly connected.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the principles, objectives, and operating model of DevSecOps.

2. Distinguish between SAST, DAST, SCA, API testing, IaC scanning, and container security.

3. Design security controls across a CI/CD pipeline.

4. Explain how policy as code, SBOMs, provenance, and artifact signing support assurance.

5. Apply risk-based approaches to vulnerability triage and remediation.

6. Evaluate supply-chain threats using frameworks such as SLSA.

7. Analyse organizational, technical, ethical, and governance issues in DevSecOps adoption.

From DevOps Automation to DevSecOps Assurance

DevOps unifies development and operations through collaboration, automation, continuous integration, continuous delivery, monitoring, and feedback. DevSecOps extends this model by making security a continuous engineering concern. Security requirements are defined during planning, tested during coding and building, enforced during deployment, and observed during operation.

A mature DevSecOps model has four characteristics. First, responsibility is shared: developers, security specialists, platform engineers, operations personnel, and managers jointly own outcomes. Second, controls are automated wherever reliable automation is possible. Third, security feedback is delivered close to the point where a defect is introduced, reducing the cost of correction. Fourth, exceptions are governed rather than silently ignored.

Security automation does not mean that all security decisions should be delegated to tools. Automated scanners produce findings, not final risk judgments. A finding must be interpreted in relation to exploitability, business criticality, exposure, compensating controls, data sensitivity, and remediation cost. The appropriate goal is therefore continuous, risk-informed assurance rather than an unrealistic promise of defect-free software.

A typical secure delivery flow is:

Plan and code -> commit and review -> build and test -> package and attest -> deploy -> operate and monitor -> learn and improve.

Security activities are distributed across this flow. Threat modelling and secure design occur before implementation. Source scanning, secret detection, and dependency analysis occur during coding. Build isolation, image scanning, signing, and provenance generation occur during packaging. Deployment policies validate identities, configurations, and approvals. Runtime monitoring detects behaviour that pre-deployment tests could not reveal.

Security Testing Across the Pipeline

Static Application Security Testing

Static application security testing (SAST) examines source code, bytecode, or compiled representations without executing the application. It can identify patterns associated with injection, insecure cryptography, improper input validation, path traversal, and dangerous data flows. Modern SAST tools may use abstract syntax trees, control-flow analysis, data-flow analysis, and semantic rules.

SAST is most useful early in development because developers can correct defects while the relevant code is still being written. Its limitations include false positives, difficulty understanding business logic, incomplete support for programming languages, and inability to observe runtime configuration. A SAST result should therefore be reviewed and tuned rather than used as an unquestioned release veto.

Dynamic Application Security Testing

Dynamic application security testing (DAST) evaluates a running application from an external perspective. It sends requests and examines responses for weaknesses such as reflected cross-site scripting, insecure headers, authentication failures, session problems, and some forms of injection. DAST is valuable because it tests the deployed behaviour and its interaction with configuration and middleware.

However, DAST may fail to reach unauthenticated or complex application paths, and aggressive testing can disrupt services. Test environments, safe credentials, rate limits, and carefully selected production validation are necessary. DAST complements rather than replaces SAST: one analyses implementation patterns, while the other evaluates observable behaviour.

Software Composition Analysis

Software composition analysis (SCA) identifies open-source and third-party components, maps them to known vulnerabilities, and often detects license obligations. It may analyse manifest files, lock files, binary packages, container layers, and transitive dependencies. SCA is essential because an application can contain more externally developed code than original organizational code.

A vulnerability identifier alone does not establish priority. The component may not be reachable, the vulnerable function may not be used, or a compensating control may exist. Conversely, a vulnerability with no public exploit at the time of discovery can become urgent later. Organizations need dependency ownership, upgrade policies, reachability analysis where available, and a process for handling unsupported or abandoned components.

API and Contract Testing

APIs are often the principal connection between microservices, mobile applications, partners, and cloud services. API security testing examines authentication, authorization, input validation, rate limits, schema enforcement, error handling, object-level access control, and excessive data exposure. Tests should include both expected and malicious requests.

Contract testing verifies that a service conforms to an agreed interface. It reduces integration failures, but a technically valid contract is not necessarily a secure one. Security requirements must be represented in API specifications and tests. For example, a test should verify that user A cannot retrieve user B's records merely by changing an object identifier in a request.

Infrastructure-as-Code Scanning

IaC describes infrastructure in machine-readable form, using technologies such as Terraform, CloudFormation, Kubernetes manifests, or policy-oriented configuration. IaC improves consistency and auditability, but it can also reproduce insecure configurations at scale. IaC scanning identifies issues such as publicly accessible storage, unrestricted network rules, excessive permissions, unencrypted databases, missing logging, and insecure Kubernetes settings.

IaC analysis should occur before deployment and, where possible, against the resolved plan rather than only the source template. Modules and reusable components require review because a single insecure module can affect many environments. Scanning cannot determine every operational consequence; architectural context and cloud-provider controls remain necessary.

Container and Build Security

Container security includes base-image selection, package reduction, non-root execution, image scanning, secret exclusion, runtime restrictions, and signature verification. A container image should be built reproducibly, tagged meaningfully, scanned for vulnerabilities, and stored in a controlled registry. Tags alone are weak identifiers because they can be moved; immutable digests provide stronger reference integrity.

Build systems themselves are high-value targets. An attacker who modifies a build script, steals a signing key, or compromises a runner can produce legitimate-looking malicious artifacts. Build isolation, short-lived credentials, minimal permissions, protected branches, review requirements, and auditable logs are therefore supply-chain controls, not merely operational preferences.

Policy as Code and Governance in the Pipeline

Policy as code expresses organizational and security rules in machine-evaluable form. Examples include: production deployments must use approved registries; storage containing regulated data must be encrypted; images must run without privileged access; infrastructure changes require an owner; and critical vulnerabilities require remediation or documented exception.

Policy may be enforced at several layers. Source-control policies protect branches and require reviews. CI policies evaluate test results and dependency thresholds. Admission policies validate images, identities, and manifests before deployment. Cloud policies monitor and correct resource configurations after deployment. The same policy should not be copied carelessly across all contexts; a development environment may permit controlled exceptions that production cannot.

Effective governance distinguishes between blocking and advisory controls. A critical, exploitable vulnerability in an internet-facing service may justify blocking a release. A low-confidence SAST warning may require review but not automatically stop delivery. Exceptions should have a reason, owner, expiry date, compensating control, and approval authority. Permanent exceptions indicate that the policy, architecture, or remediation capacity requires reconsideration.

SBOMs, Provenance, and Artifact Integrity

An SBOM is a machine-readable inventory of the components present in a software product. It commonly records package names, versions, suppliers, relationships, licenses, and vulnerability references. SBOMs support incident response, procurement, vulnerability impact analysis, and regulatory reporting. They are most useful when generated automatically, associated with an immutable artifact, and updated when the artifact changes.

An SBOM does not prove that software is safe. It may be incomplete, inaccurate, or unable to describe build-time tools and indirect relationships. It should therefore be combined with provenance: information about where, how, and by which process an artifact was built. Provenance can record the source revision, build system, parameters, dependencies, builder identity, and time of creation.

Artifact signing uses cryptographic signatures to establish that an artifact was signed by an expected identity and has not been altered since signing. Verification should occur close to deployment, not only at publication. Key management is critical: keys should be protected, access should be limited, signing identities should be attributable, and compromise-recovery procedures should be tested. Modern systems increasingly use identity-based, short-lived signing credentials rather than unmanaged long-lived keys.

Together, SBOMs, provenance, and signatures answer different questions:

• SBOM: What components are included?
• Provenance: How and from what inputs was the artifact produced?
• Signature: Can the artifact's origin and integrity be verified?

Software Supply-Chain Security and SLSA

The software supply chain includes source repositories, developers, dependencies, build systems, artifact stores, deployment platforms, and service providers. Threats include dependency confusion, typosquatting, malicious packages, compromised maintainers, source-code theft, build-pipeline manipulation, artifact substitution, and unauthorized release processes.

SLSA, commonly pronounced “salsa,” is a framework for improving software supply-chain integrity through increasing levels of assurance. Its central ideas include preventing tampering, producing trustworthy provenance, and enabling consumers to verify how software was built. Higher assurance generally requires stronger controls over source and build systems, protected and isolated builds, authenticated provenance, and resistance to unauthorized modification. SLSA is not a vulnerability scanner and does not certify that code is functionally secure. It addresses confidence in the chain from source to artifact.

A practical SLSA-oriented programme can begin by identifying build inputs and outputs, separating build environments from developer workstations, generating provenance, protecting the main branch, and verifying artifacts before deployment. Organizations should select assurance levels according to risk. A payment platform, medical system, or critical infrastructure component may require substantially stronger controls than an internal prototype.

Vulnerability Management as a Decision Process

Vulnerability management in DevSecOps is a lifecycle rather than a list of scanner results. The process includes discovery, validation, prioritization, assignment, remediation or mitigation, verification, and closure. Prioritization should consider severity, exploitability, exposure, asset value, data sensitivity, reachability, exploit availability, and the age of the finding.

Remediation options include upgrading a dependency, changing code, disabling a feature, restricting network access, adding runtime protection, replacing a component, or accepting the risk temporarily. Risk acceptance is legitimate only when it is informed, authorized, documented, and time-bounded. Security teams should measure meaningful outcomes such as time to remediate exploitable critical issues, recurrence rate, exception age, coverage of critical repositories, and percentage of deployed artifacts with verifiable provenance. Counting raw findings can reward noisy scanning rather than improved security.

An Illustrative Case: Securing a Multi-Cloud Insurance Platform

Background

Consider an illustrative enterprise, Meridian Assurance, operating a customer portal and claims-processing platform across two public clouds. Its services are developed by several teams using Java, Python, containers, managed databases, and Terraform. Releases occur weekly, but security testing is performed mainly before major releases.

Situation and Problem

A third-party library vulnerability is announced after the organization has deployed the affected version in several services. The security team cannot quickly determine which products contain the library. An audit also discovers that one Terraform module permits public access to a storage resource in a non-production account. The development teams complain that security reviews delay delivery, while security personnel lack reliable evidence about the build process.

Analysis

The immediate issues are technical, but the deeper problem is inadequate visibility and ownership. There is no authoritative component inventory, no consistent pipeline policy, no artifact provenance, and no defined risk-based exception process. Manual review at the end of the lifecycle is too slow for a distributed cloud environment.

Approach and Strategy

Meridian introduces a standard pipeline pattern. SAST, secret detection, SCA, IaC scanning, and container scanning run on pull requests and protected branches. Findings are classified by confidence and risk; only defined high-risk conditions block merging. Every production artifact receives an SBOM and signed provenance. The deployment platform verifies approved signatures and rejects unsigned images.

The platform team converts baseline cloud requirements into policy as code. Public storage, unrestricted administrative ports, privileged containers, and unencrypted regulated-data stores are blocked in production. Development exceptions require an owner and expiry date. A central inventory links repositories, services, images, SBOMs, and operational owners. A vulnerability response group reviews exploitable issues daily and less urgent findings in a scheduled backlog.

Build runners are isolated, credentials are short-lived, branch protection is enabled, and release permissions are separated from source-code modification permissions. DAST and authenticated API tests run against staging environments, while production monitoring detects unexpected behaviour.

Outcome

When a later dependency vulnerability is disclosed, Meridian queries its SBOM inventory and identifies affected services within hours rather than days. The organization can distinguish vulnerable but unreachable components from exposed components requiring immediate action. IaC policy prevents the previously observed public-storage pattern from reaching production. Delivery speed is maintained because developers receive findings during pull requests and security gates are targeted at meaningful risks.

Learning Points

The case illustrates that DevSecOps is an operating model, not a collection of scanners. Visibility, ownership, policy, provenance, and remediation processes are as important as technical detection. It also demonstrates that supply-chain assurance must cover both third-party components and the organization's own build and release systems.

Challenges, Limitations, and Common Mistakes

DevSecOps programmes often fail when tools are purchased without workflow design. Excessive alerts create fatigue, encourage indiscriminate suppression, and damage trust between security and engineering. Another mistake is scanning only source code while ignoring CI runners, registries, deployment identities, and cloud configuration.

A further limitation is that automated testing cannot fully evaluate business logic, authorization intent, emerging attack techniques, or organizational misuse. Human threat modelling, secure architecture review, penetration testing, and incident exercises remain necessary. Security gates can also become bottlenecks when they are slow, unreliable, or disconnected from actual risk.

Organizations should avoid treating compliance evidence as equivalent to security. A signed artifact may be malicious if the authorized build process was compromised; an SBOM may be accurate but incomplete; and a passing scan may reflect inadequate test coverage. Assurance requires defence in depth and continuous improvement.

Ethical, Regulatory, and Professional Considerations

Security automation processes source code, dependency data, credentials, logs, and sometimes personal information. Access should follow least privilege, and scanning data should be protected from unauthorized disclosure. Dynamic testing must be authorized and conducted in environments where service disruption and privacy risks are controlled.

Professional responsibility includes reporting vulnerabilities honestly, avoiding concealment through suppression, and communicating uncertainty. Organizations operating in regulated sectors may need evidence of secure development, vulnerability management, software provenance, incident response, and third-party risk oversight. Regulatory requirements differ by jurisdiction, so technical controls should be mapped to applicable obligations rather than assuming that a single framework satisfies all requirements.

Emerging Directions

DevSecOps is increasingly connected with platform engineering, internal developer portals, software supply-chain levels, and continuous authorization. Machine learning can assist with code review, dependency prioritization, anomaly detection, and remediation suggestions, but generated code and automated recommendations require human validation. Attackers may also exploit AI-generated dependencies, poisoned training materials, or automated build agents.

Emerging practice is moving toward verifiable build systems, hermetic and reproducible builds, in-toto-style attestations, workload identity, confidential build environments, and runtime admission based on attestations rather than simple image tags. The strategic direction is clear: software delivery decisions will increasingly rely on machine-verifiable evidence about identity, origin, process, and policy compliance.

Best-Practice Guidance

A sustainable programme should:

• define security ownership for every repository, service, artifact, and infrastructure module;
• secure source control, CI runners, registries, deployment credentials, and administrative interfaces;
• introduce fast feedback through SAST, secret detection, SCA, API tests, IaC scanning, and container scanning;
• tune rules and prioritize findings using exploitability and business context;
• generate SBOMs and provenance for released artifacts;
• sign artifacts and verify signatures at deployment;
• enforce critical production requirements through policy as code;
• maintain a time-bound exception and risk-acceptance process;
• measure remediation performance and control coverage rather than scanner volume; and
• review the pipeline itself through threat modelling, audits, penetration testing, and incident exercises.

Chapter Summary

DevSecOps integrates security with agile development, CI/CD, cloud operations, and organizational governance. SAST identifies weaknesses in code, DAST evaluates running behaviour, SCA manages third-party components, API testing examines interfaces and authorization, and IaC scanning detects insecure infrastructure definitions. These controls are most effective when they provide early feedback and are governed by risk-based policies.

SBOMs provide component visibility, provenance records the origin and build process of an artifact, and cryptographic signatures support integrity and identity verification. SLSA provides a useful framework for strengthening confidence in the software supply chain, although it does not replace functional security testing. Effective vulnerability management combines discovery with validation, prioritization, remediation, exception governance, and measurement. Ultimately, DevSecOps succeeds when people, processes, platforms, and evidence work together to make secure delivery repeatable.

Key Terms

DevSecOps: An operating model that integrates security into development and operations throughout the software life cycle.

CI/CD: Continuous integration and continuous delivery or deployment practices that automate software build, test, and release activities.

SAST: Static analysis of source, bytecode, or compiled code without executing the application.

DAST: Security testing of a running application from an external or black-box perspective.

SCA: Analysis of open-source and third-party components for vulnerabilities, versions, and license information.

API security testing: Evaluation of interfaces for authentication, authorization, validation, exposure, and abuse weaknesses.

Infrastructure as Code: Machine-readable definition and management of infrastructure resources.

Policy as code: Encoding governance and security rules in a form that can be automatically evaluated and enforced.

SBOM: A machine-readable inventory of software components and their relationships.

Provenance: Evidence describing an artifact's source, inputs, builder, process, and creation context.

Artifact signing: Use of cryptographic signatures to verify an artifact's integrity and issuing identity.

Software supply chain: The people, code, tools, dependencies, systems, and processes used to produce and deliver software.

SLSA: A framework for improving software supply-chain integrity and build provenance.

Dependency confusion: An attack in which a package manager retrieves a malicious package instead of an intended internal package.

Vulnerability remediation: Correcting, mitigating, or formally accepting a security weakness based on risk.

Exception: An authorized, documented departure from a security policy, normally with an owner and expiry.

Provenance attestation: A signed or otherwise verifiable statement about how an artifact was produced.

Immutable digest: A cryptographic identifier that refers to a specific artifact content rather than a changeable tag.

Threat modelling: A structured analysis of assets, trust boundaries, threats, and security controls.

Review Questions

Short Answer Questions

1. What is the principal difference between SAST and DAST?

2. Why is an SBOM useful during a newly disclosed dependency vulnerability?

3. What types of controls are commonly expressed as policy as code?

4. Why are immutable image digests stronger than mutable tags?

5. What information does provenance add beyond an SBOM?

Long Answer Questions

1. Explain how security activities should be distributed across a CI/CD pipeline.

2. Compare SAST, DAST, SCA, API testing, and IaC scanning, including the limitations of each.

3. Explain the relationship among SBOMs, provenance, artifact signing, and SLSA.

4. Develop a risk-based vulnerability remediation process for a cloud-native enterprise.

5. Discuss the organizational and technical conditions required for successful DevSecOps adoption.

Analytical / Application Questions

1. A pipeline reports a critical vulnerability in a transitive dependency used by an internal service that is not internet-facing. What evidence would you seek before deciding whether to block release?

2. Design policy-as-code rules for a production Kubernetes environment and explain which rules should block deployment and which should generate warnings.

3. An attacker compromises a CI runner and publishes a malicious image signed with a legitimate key. Analyse which controls in this chapter could detect or limit the attack, and identify remaining gaps.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the complementary relationship between SAST and DAST?

A. SAST tests only infrastructure, while DAST tests only dependencies.

B. SAST analyses implementation without execution, while DAST evaluates behaviour in a running application.

C. SAST is performed after deployment, while DAST is performed before coding.

D. SAST and DAST are identical methods using different terminology.

Correct Answer: B. SAST analyses implementation without execution, while DAST evaluates behaviour in a running application.

Question 2

An organization wants to identify every released service affected by a newly disclosed open-source vulnerability. Which capability is most directly useful?

A. A network intrusion detection system

B. An SBOM inventory associated with released artifacts

C. A password rotation schedule

D. A manual review of production screens

Correct Answer: B. An SBOM inventory associated with released artifacts

Question 3

Which statement correctly distinguishes an SBOM from provenance?

A. An SBOM describes components, while provenance describes how an artifact was produced.

B. An SBOM signs an artifact, while provenance encrypts its source code.

C. An SBOM blocks deployment, while provenance performs DAST.

D. An SBOM applies only to infrastructure, while provenance applies only to APIs.

Correct Answer: A. An SBOM describes components, while provenance describes how an artifact was produced.

Question 4

A Terraform module unintentionally creates publicly accessible storage in multiple accounts. Which control would most directly prevent recurrence before deployment?

A. Policy-as-code evaluation of the infrastructure plan

B. Employee password training

C. A post-incident press release

D. A larger production database

Correct Answer: A. Policy-as-code evaluation of the infrastructure plan

Question 5

Why should a security team avoid automatically blocking every scanner finding?

A. Scanners never identify genuine vulnerabilities.

B. All vulnerabilities have identical business impact.

C. False positives and contextual risk require validation and prioritization.

D. Blocking findings is prohibited in CI/CD systems.

Correct Answer: C. False positives and contextual risk require validation and prioritization.

Question 6

Which practice most directly strengthens artifact integrity during deployment?

A. Using mutable image tags without verification

B. Verifying signatures and approved identities before deployment

C. Disabling registry audit logs

D. Allowing every developer to use a shared signing key

Correct Answer: B. Verifying signatures and approved identities before deployment

Question 7

What is a central concern addressed by SLSA?

A. Improving confidence in the source-to-artifact build and provenance process

B. Replacing all application security testing with encryption

C. Increasing the number of software features per release

D. Providing a universal vulnerability severity score

Correct Answer: A. Improving confidence in the source-to-artifact build and provenance process

Question 8

An API allows a logged-in user to change an object identifier and retrieve another user's claim. What type of testing is especially relevant?

A. API authorization and object-level access-control testing

B. Disk defragmentation testing

C. SBOM formatting only

D. Image compression testing

Correct Answer: A. API authorization and object-level access-control testing

Question 9

Which is the strongest example of a properly governed security exception?

A. A developer silently suppresses a critical finding forever.

B. A team ignores a policy because the pipeline is inconvenient.

C. An authorized owner documents the reason, mitigation, approval, and expiry date.

D. A scanner is removed from all repositories after producing alerts.

Correct Answer: C. An authorized owner documents the reason, mitigation, approval, and expiry date.

Question 10

A signed malicious artifact is deployed after a CI runner was compromised. Which conclusion is most accurate?

A. Signatures alone prove that the software is functionally secure.

B. The signing control may verify origin but cannot guarantee that the authorized build process was uncompromised.

C. SBOMs automatically remove malicious code from artifacts.

D. DAST guarantees that the build system was trustworthy.

Correct Answer: B. The signing control may verify origin but cannot guarantee that the authorized build process was uncompromised.