Modern software is assembled from many sources: developer-written code, open-source libraries, container images, operating-system packages, build tools, cloud services, and deployment configuration. A vulnerability or malicious modification in any of these components can compromise an entire application. Software security is therefore not only a property of the final program; it is also a property of the process and relationships through which the program is produced.
DevSecOps integrates security into DevOps practices so that security controls operate continuously across planning, coding, building, testing, releasing, deploying, and operating. It replaces the traditional assumption that security is a final approval gate with shared responsibility, automated evidence, risk-based decision-making, and rapid remediation. Supply-chain security extends this concern beyond an organisation’s own source code to dependencies, suppliers, build systems, registries, identities, and delivery infrastructure.
A secure pipeline does not guarantee that software is free from vulnerabilities. Rather, it makes risks more visible, reduces opportunities for tampering, strengthens assurance about what was built, and provides mechanisms for responding when new weaknesses are discovered.
Learning Objectives
By the end of this chapter, students should be able to:
Explain DevSecOps and the software supply-chain threat landscape.
Apply threat modelling to a CI/CD system and its deployed application.
Design practical controls for secrets, identity, access, and zero-trust pipelines.
Explain SBOMs, artifact signing, provenance, and verification.
Develop vulnerability triage, remediation, and exception-management processes.
Analyse a supply-chain attack and propose layered preventive and detective controls.
Evaluate the operational, ethical, governance, and regulatory implications of DevSecOps.
1. DevSecOps as a Security Operating Model
DevOps connects development and operations through automation, feedback, and shared ownership. DevSecOps adds security engineering, governance, and risk management to the same flow. Security specialists remain important, but they increasingly provide platforms, policies, threat expertise, and enablement rather than manually inspecting every release.
The central principles are:
Shift left: identify and correct defects near their origin, when remediation is generally cheaper and less disruptive.
Shift right: continue security observation in staging and production because some risks appear only at runtime.
Automate evidence: record test results, approvals, identities, versions, and deployment decisions.
Make security proportional to risk: a public payment service and an internal prototype need different controls.
Preserve delivery flow: controls should be reliable, fast, explainable, and designed with developers.
Assume compromise: protect critical assets even if a workstation, dependency, credential, or pipeline runner is compromised.
Security is often represented as a quality attribute alongside reliability, performance, and maintainability. Unlike a feature that is complete once implemented, security is exposed to changing threats, newly disclosed vulnerabilities, configuration drift, and evolving dependencies. Consequently, DevSecOps is a continuous control system rather than a one-time project.
2. The Software Supply Chain and Its Threats
A software supply chain includes the people, processes, systems, data, and components involved in creating and delivering software. A simplified chain is:
Software supply chain security flow from source through deployment and monitoring
Figure: Software supply chain security flow from source through deployment and monitoring
Figure: Security controls apply across the complete software supply chain, not only to source code.
Important threats include:
Dependency compromise: a malicious or vulnerable library enters an application through a package manager.
Typosquatting and dependency confusion: an attacker publishes a similarly named package or exploits package-resolution rules.
Build-system compromise: a runner, plugin, build script, or credential is altered to inject malicious code.
Artifact substitution: a legitimate package is replaced in a registry or during transport.
CI/CD privilege abuse: a pipeline token is used to alter source, release artifacts, or production resources.
Compromised maintainer accounts: attackers use stolen credentials or social engineering to modify trusted projects.
Malicious insider activity: an authorised person intentionally introduces a backdoor or exfiltrates secrets.
Provenance ambiguity: an organisation cannot establish which source, dependencies, tools, or instructions produced an artifact.
Operational exploitation: a vulnerability not detected during build is exploited after deployment.
The SolarWinds compromise and Log4Shell illustrate different supply-chain lessons. SolarWinds demonstrated the impact of tampering with a trusted build and distribution path. Log4Shell showed that a widely used dependency can create urgent exposure across many organisations, including those that did not directly know they used it.
3. Threat Modelling for DevSecOps
Threat modelling is a structured method for identifying assets, trust boundaries, threat actors, attack paths, and mitigations before or during implementation. It is not a prediction of every attack. Its value lies in making assumptions explicit and directing engineering effort toward high-consequence risks.
A practical workflow is:
Define scope: identify the application, pipeline, repositories, registries, cloud accounts, environments, and data.
Map data flows: show how source, credentials, build instructions, artifacts, and deployment requests move.
Identify trust boundaries: distinguish developer workstations, hosted runners, self-hosted runners, registries, production clusters, and external services.
Identify assets: include source code, signing keys, credentials, customer data, release metadata, and deployment authority.
Enumerate threats: consider spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege—the STRIDE categories.
Assess risk: consider likelihood, exploitability, exposure, and impact.
Validate: test controls and revisit the model when architecture or dependencies change.
A useful conceptual risk model is:
Risk ≈ Likelihood × Impact
Likelihood expresses the estimated chance that a threat will succeed during a defined period; impact expresses the consequence if it does. This is a prioritisation model, not a precise probability law. Organisational risk methods may use ordinal scales rather than numerical probabilities. A high-impact, low-likelihood event can still require treatment when regulatory, safety, or systemic consequences are severe.
For example, a pipeline that can deploy directly to production has high-value deployment authority. Its threat model should address branch protection, runner isolation, approval policy, credential scope, artifact verification, and emergency revocation.
4. Security Testing in the Pipeline
No single scanner detects all classes of weakness. Effective programmes combine complementary techniques and interpret results rather than treating scanner output as absolute truth.
4.1 Static Application Security Testing
SAST examines source code, bytecode, or an intermediate representation without executing the application. It can identify insecure input handling, injection paths, weak cryptography, dangerous APIs, and data-flow problems early in development. It is well suited to pull-request feedback, but may produce false positives, miss runtime configuration problems, and struggle with generated or highly dynamic code.
SAST should be configured with language-aware rules, secure coding guidance, severity thresholds, and a process for reviewing suppressed findings. A finding that is accepted as a false positive should have a recorded rationale and, where appropriate, an expiry or review date.
4.2 Dynamic Application Security Testing
DAST interacts with a running application, usually in a controlled test environment. It can reveal authentication, session, configuration, and externally observable web vulnerabilities that static analysis cannot confirm. DAST requires a representative and safely instrumented environment; incomplete crawling, unavailable test accounts, or destructive requests can reduce its value. It should not be directed carelessly at production.
Interactive application security testing and runtime instrumentation can complement DAST by observing application behaviour during tests. Penetration testing remains valuable for complex business logic and adversarial reasoning that automated tools may miss.
4.3 Software Composition Analysis
Software composition analysis (SCA) inventories direct and transitive dependencies, compares versions against vulnerability databases, and may identify licence obligations. It should inspect lockfiles and built artifacts, because declared dependencies do not always equal what is actually packaged. A vulnerability score is not the same as exploitability in a particular deployment; reachability, exposure, compensating controls, and available fixes must be considered.
Dependency controls include pinned versions, verified lockfiles, trusted registries, review of new packages, removal of unused libraries, update automation, and protection against dependency confusion. Pinning improves reproducibility but does not itself prove that a package is safe.
4.4 Container and Infrastructure Scanning
Container scanners inspect image layers, operating-system packages, language dependencies, configuration, and sometimes malware indicators. Good practice includes minimal base images, non-root execution, removal of package caches and build tools from runtime images, regular rebuilding, and immutable image promotion.
Infrastructure-as-code scanning examines declarative resources such as cloud policies, network rules, storage permissions, and Kubernetes manifests. It can identify public storage, unrestricted ingress, excessive privileges, missing encryption, and unsafe defaults. Scanning should be combined with policy-as-code and runtime configuration assessment because a secure template can be changed after deployment.
4.5 Choosing Pipeline Gates
A pipeline gate should be tied to a defined risk decision. Examples include blocking a release when a critical exploitable vulnerability is present in a production image, or requiring security approval when a high-risk exception is requested. Gates should not blindly block every warning: excessive false positives encourage bypasses and undermine trust.
A mature design uses fast checks on every change, deeper checks on merge or release, and periodic comprehensive assessment. Findings should be correlated to prevent duplicate tickets and assigned to accountable owners.
5. Secrets, Identity, and Zero Trust
Secrets include passwords, API tokens, private keys, certificates, signing keys, and cloud credentials. They must not be placed in source code, container layers, build logs, issue trackers, or unencrypted pipeline variables. Secret-scanning tools detect known formats and high-entropy strings, but they cannot prove that a repository contains no secret.
A secrets-management system should provide encrypted storage, controlled retrieval, auditing, rotation, revocation, and separation of duties. Prefer short-lived, dynamically issued credentials over long-lived static tokens. If a secret is exposed, treat it as compromised: revoke or rotate it, investigate use, remove it from future history where appropriate, and assess whether downstream systems were accessed.
Identity controls should include:
federated authentication rather than shared accounts;
multi-factor authentication for human administrators;
workload identity for jobs and services;
least privilege and narrowly scoped permissions;
separate identities for build, test, release, and deployment;
branch protection and signed or verified commits where justified;
short-lived tokens with audience and environment restrictions;
independent approval for high-impact production changes;
logging of authentication, authorisation, and administrative actions.
Zero trust is a security approach, not a single product. It assumes that network location does not establish trust and that every access request should be evaluated using identity, device or workload context, policy, and resource sensitivity. In CI/CD, a runner should not automatically trust every repository, and a deployment job should receive only the permissions required for its specific environment.
Self-hosted runners require special attention. A job may execute untrusted code from a pull request; if the runner has persistent credentials or access to other projects, compromise can spread. Isolation, ephemeral runners, restricted network access, clean workspaces, and separate trusted and untrusted execution pools reduce this risk.
6. SBOMs, Signing, and Provenance
A software bill of materials (SBOM) is a structured inventory of components in a software artifact. It may contain package names, versions, suppliers, relationships, licences, and identifiers such as common platform enumeration references. SPDX and CycloneDX are widely used SBOM formats.
An SBOM supports vulnerability response, licence management, procurement assurance, and incident investigation. It is not a security certificate: an SBOM can accurately list a malicious component, omit a component, or become stale. It should be generated from reliable build information, associated with a specific artifact digest, stored securely, and updated when the artifact changes.
Artifact signing uses cryptographic signatures to provide evidence that an identified signer approved a particular artifact. A digest is a fixed-length representation of content; if the content changes, its digest should change. Verification must establish both that the signature is valid and that the signing identity is authorised for the relevant repository, environment, or release policy. Key protection, rotation, revocation, and recovery are essential.
Provenance describes how an artifact was produced: source revision, builder identity, build parameters, dependencies, timestamps, and sometimes the exact workflow. Frameworks such as SLSA provide graduated guidance for increasing build and provenance assurance. Reproducible builds seek to make the same source and controlled inputs produce equivalent output, but reproducibility alone does not prove that the source is benign.
A verification policy might require that:
the artifact digest matches the deployment request;
the signature chains to an accepted identity;
provenance identifies an approved repository and workflow;
required security tests passed;
the artifact contains an SBOM;
the artifact was built by an isolated and authorised builder;
the vulnerability status is within the organisation’s release policy.
7. Vulnerability Remediation and Security Metrics
Vulnerability management begins with reliable discovery and asset ownership. Findings should be prioritised using severity, exploitability, internet exposure, business criticality, affected data, active exploitation intelligence, and availability of mitigations. Common Vulnerabilities and Exposures (CVEs) and the Common Vulnerability Scoring System (CVSS) provide useful references, but neither automatically determines local risk.
A practical remediation lifecycle is:
detect and normalise the finding;
identify affected assets and owners;
validate reachability and exposure;
select a fix, upgrade, configuration change, isolation measure, or compensating control;
test the change;
deploy and verify;
record evidence and close or formally accept the risk.
Risk acceptance should be explicit, time-bounded, approved by an accountable authority, and accompanied by compensating controls. “Accepted” must not mean “forgotten.” Emergency vulnerabilities may require temporary feature disablement, network controls, or accelerated release procedures.
Useful metrics include mean time to remediate, percentage of critical assets with current SBOMs, percentage of releases with verified provenance, dependency age, secret exposure response time, and the rate of recurring findings. Metrics should encourage improvement rather than concealment. For example, measuring only the number of findings can reward teams for avoiding detection; measuring closure without measuring recurrence can reward superficial fixes.
An illustrative online retailer operates a web application on Kubernetes. Developers use a hosted Git service, a CI platform, a public package registry, an internal container registry, and a cloud provider. Releases occur several times each day. The original pipeline builds images and deploys them when tests pass, but it has no SBOM, no image-signing policy, and a long-lived cloud access token stored as a pipeline variable.
Problem
A malicious package with a name similar to an internal library is downloaded during a build. The package executes a build script that searches the workspace for credentials. The exposed cloud token permits access to the container registry and deployment account. The attacker replaces a release image with a modified image that exfiltrates customer session data.
Analysis
Threat modelling identifies several trust-boundary failures. The build resolves packages from an unverified public source, the runner has access to a long-lived credential, the artifact registry does not require signatures, and deployment trusts an image tag rather than an immutable digest. There is also no reliable inventory to identify which releases contain the malicious package.
The incident demonstrates that a vulnerability scanner alone would not necessarily prevent compromise. The package may contain no known CVE, while the primary issue is malicious behaviour and excessive pipeline privilege.
Approach and Solution
The retailer takes the following actions:
revokes and rotates the exposed cloud token;
investigates registry, CI, and cloud audit logs;
isolates affected workloads and invalidates sessions;
establishes an internal proxy registry with package allow-listing and review;
uses lockfiles and dependency-resolution controls;
replaces static credentials with short-lived workload identity;
creates ephemeral, isolated runners for untrusted changes;
generates an SBOM for every image;
signs images and records provenance from an approved workflow;
deploys by digest, not mutable tag;
requires admission policy to verify signatures, provenance, and vulnerability thresholds;
adds SAST, SCA, container, secret, and infrastructure scanning at suitable stages;
implements a documented emergency response and dependency-update process.
Outcome
The organisation can now identify components in each deployed image, determine which workflow produced it, prevent unsigned images from entering production, and limit a compromised build job’s access. The controls do not eliminate risk, but they reduce the probability of successful tampering and make investigation faster.
Learning Points
The case shows why supply-chain security is layered. Trust in a package name is insufficient; a passing unit test is insufficient; a vulnerability scan is insufficient; and a valid signature is insufficient if the signing identity is overprivileged or the build process is compromised. Assurance comes from the combination of controlled inputs, least-privilege identities, isolated builds, tested software, signed artifacts, verifiable provenance, runtime enforcement, and incident readiness.
9. Governance, Ethics, and Regulatory Considerations
Security controls affect people and organisations, so governance must address more than technical correctness. Developers should receive understandable findings and a fair process for challenging inaccurate results. Monitoring pipeline activity should be proportionate, transparent, and limited to legitimate security and operational purposes. Secrets and personal data in logs require careful handling and retention controls.
Organisations should define ownership for source repositories, dependencies, build infrastructure, artifact registries, signing keys, and production policies. Supplier contracts may require vulnerability disclosure, incident notification, SBOM delivery, secure development practices, and evidence of access control. Depending on sector and jurisdiction, obligations may arise from data-protection law, critical-infrastructure regulation, contractual requirements, or secure software guidance.
AI-assisted coding introduces additional risks. Generated code can contain insecure patterns, reproduce licensed material, leak prompts or proprietary information, and create false confidence. AI-generated code must undergo the same review, testing, dependency analysis, and provenance controls as human-written code. AI can assist with triage and code explanation, but automated recommendations should not be treated as authoritative security decisions without human accountability.
scanners generate false positives and inconsistent severity assessments;
legacy systems lack tests, ownership, or reproducible builds;
dependency graphs are large and change rapidly;
security gates can slow delivery when poorly designed;
signing keys and identity systems become high-value targets;
provenance may be incomplete across third-party components;
teams may bypass controls under delivery pressure;
vulnerability databases may lag behind emerging threats;
small organisations may lack dedicated security engineering capacity.
These limitations favour incremental adoption. Begin with asset inventory, ownership, secret protection, dependency visibility, and high-value pipeline boundaries. Establish baseline policies, measure outcomes, and improve controls through incident lessons. Security should be embedded in reusable pipeline templates and developer platforms rather than recreated inconsistently in every project.
Best-Practice Reference Architecture
A practical advanced-diploma implementation can use the following sequence:
Protect repositories with multi-factor authentication, branch rules, code review, and audit logs.
Run secret scanning and fast SAST on pull requests.
Resolve dependencies through controlled registries and verified lockfiles.
Build in ephemeral isolated runners using least-privilege workload identity.
Generate test results, SBOMs, and provenance as build outputs.
Run SCA, container, infrastructure, and policy checks before release.
Sign artifacts using protected identities and store immutable versions.
Promote the same tested artifact across environments rather than rebuilding it.
Verify signatures, provenance, policy, and digest at deployment.
Monitor runtime behaviour, configuration drift, and newly disclosed vulnerabilities.
Maintain revocation, rollback, incident response, and recovery procedures.
Chapter Summary
DevSecOps integrates security into the complete software-delivery lifecycle. Software supply-chain security addresses risks in source code, dependencies, build tools, runners, registries, identities, artifacts, and deployment systems. Threat modelling reveals assets, trust boundaries, attack paths, and appropriate mitigations. SAST, DAST, SCA, container scanning, infrastructure scanning, and secret detection provide complementary evidence rather than a universal guarantee.
Strong pipeline security depends on least privilege, short-lived identities, protected secrets, isolated runners, zero-trust access decisions, and explicit approval policies. SBOMs improve component visibility; signatures establish evidence of approval; provenance records how artifacts were produced; and deployment verification ensures that only authorised, policy-compliant artifacts run. Vulnerability management must combine discovery, contextual prioritisation, remediation, compensating controls, and accountable risk acceptance. Governance, ethics, supplier assurance, AI oversight, and incident response are essential because technical controls operate within human and organisational systems.
Key Terms
DevSecOps: An operating model that integrates security practices into development and operations.
Software supply chain: The people, processes, systems, and components used to produce and deliver software.
Threat modelling: A structured analysis of assets, threats, trust boundaries, and mitigations.
SAST: Static Application Security Testing performed without executing the application.
DAST: Dynamic Application Security Testing performed against a running application.
Software composition analysis: Examination of application dependencies for vulnerabilities, licences, and provenance.
SBOM: A structured inventory of components contained in a software artifact.
Provenance: Evidence describing the source, builder, process, and inputs used to produce an artifact.
Artifact signing: Use of cryptographic signatures to authenticate an artifact and its approving identity.
Digest: A fixed-length cryptographic representation of content.
Zero trust: A security approach that continuously evaluates access rather than trusting network location.
Least privilege: Granting only the permissions required for an identity or process.
Workload identity: An identity assigned to an application, job, or service rather than a human user.
Dependency confusion: An attack that causes a build to select a malicious package from an unintended source.
Typosquatting: Registering a misleadingly similar name to a legitimate package or service.
Vulnerability: A weakness that can be exploited to violate confidentiality, integrity, or availability.
Risk acceptance: A documented decision to tolerate a defined risk under specified conditions.
Policy as code: Machine-readable rules used to evaluate configuration or delivery decisions.
SLSA: A framework providing guidance for increasing software supply-chain assurance.
Review Questions
Short Answer Questions
What is the principal difference between DevOps and DevSecOps?
Why is an SBOM useful during vulnerability response?
State two limitations of SAST.
What does least privilege mean in a CI/CD pipeline?
Why should production deployments use immutable artifact digests?
Long Answer Questions
Explain how threat modelling can be applied to a CI/CD pipeline, including assets, trust boundaries, threats, and mitigations.
Compare SAST, DAST, SCA, container scanning, and infrastructure-as-code scanning. Explain why they should be combined.
Discuss how secrets management, workload identity, and zero trust reduce the impact of a compromised build runner.
Explain the relationship between SBOMs, artifact signatures, and provenance. Identify what assurance each does and does not provide.
Design a vulnerability remediation process for an organisation that releases software several times each day.
Analytical / Application Questions
A pipeline downloads dependencies from a public registry, uses a persistent cloud token, and deploys by mutable image tag. Identify the principal attack paths and propose a prioritised control plan.
A scanner reports a critical vulnerability in a library that is present in an image but unreachable by the application. How should the team investigate, prioritise, remediate, and document the decision?
An organisation verifies artifact signatures but allows any developer repository to sign images for production. Analyse the trust failure and redesign the signing and deployment policy.
Multiple Choice Questions with Answers
Question 1
Which activity best represents threat modelling in a DevSecOps pipeline?
A. Selecting a faster compiler
B. Mapping trust boundaries and identifying possible attack paths
C. Compressing container layers
D. Increasing the number of deployment replicas
Correct Answer: B. Mapping trust boundaries and identifying possible attack paths
Question 2
Which testing method examines application source code without executing the application?
A. DAST
B. SAST
C. Penetration testing
D. Runtime monitoring
Correct Answer: B. SAST
Question 3
What is the primary purpose of an SBOM?
A. To encrypt source code
B. To list the components contained in software
C. To replace all security testing
D. To provide network availability
Correct Answer: B. To list the components contained in software
Question 4
Which practice most directly reduces the risk of a leaked CI credential?
A. Using a longer-lived static token
B. Storing the token in source control
C. Using short-lived workload identity with narrowly scoped permissions
D. Printing the token in build logs
Correct Answer: C. Using short-lived workload identity with narrowly scoped permissions
Question 5
What does artifact signing primarily provide?
A. Proof that the artifact contains no vulnerabilities
B. Evidence connecting an artifact to an authorised signing identity
C. Automatic encryption of customer data
D. A guarantee that the build was reproducible
Correct Answer: B. Evidence connecting an artifact to an authorised signing identity
Question 6
Which attack involves publishing a malicious package with a name similar to a legitimate package?
A. Typosquatting
B. Denial-of-service amplification
C. Session fixation
D. Port scanning
Correct Answer: A. Typosquatting
Question 7
Why are ephemeral CI runners valuable?
A. They preserve all credentials permanently
B. They reduce persistence between jobs and limit contamination
C. They eliminate the need for access control
D. They allow every job to run as administrator
Correct Answer: B. They reduce persistence between jobs and limit contamination
Question 8
Which statement about vulnerability severity scores is most accurate?
A. A score automatically determines the exact local business risk
B. A score is irrelevant to prioritisation
C. A score is useful evidence but should be interpreted with exposure and exploitability
D. A score proves that a vulnerability is actively exploited
Correct Answer: C. A score is useful evidence but should be interpreted with exposure and exploitability
Question 9
In a zero-trust pipeline, access decisions should primarily be based on which principle?
A. Network location alone
B. Permanent trust of all internal jobs
C. Verified identity, context, policy, and resource sensitivity
D. The age of the pipeline
Correct Answer: C. Verified identity, context, policy, and resource sensitivity
Question 10
Why is deploying by immutable digest safer than deploying by mutable tag?
A. A digest identifies specific content and is harder to replace unnoticed
B. A tag always contains a cryptographic signature
C. A digest automatically removes vulnerabilities
D. A tag cannot be audited
Correct Answer: A. A digest identifies specific content and is harder to replace unnoticed