DevSecOps and Software Supply Chain Security

Introduction

Modern software is assembled from source code, open-source libraries, container images, build tools, cloud services, and deployment configurations. This interconnected environment creates a software supply chain: the sequence of people, processes, systems, and components through which software is designed, built, delivered, and operated.

A vulnerability in application code is only one possible security problem. An exposed secret in a repository, a compromised build runner, an unverified dependency, an unsigned container image, or an overly privileged deployment account can also compromise an organisation. DevSecOps addresses this reality by integrating security into the development and delivery lifecycle rather than treating it as a final inspection before release.

DevSecOps does not mean that every developer becomes a security specialist. It means that development, operations, and security teams share responsibility for reducing risk through automated controls, informed decisions, and continuous improvement. Security activities are placed close to the point where changes are made, while higher-risk decisions remain subject to appropriate expert review.

Learning Objectives

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

• explain DevSecOps and software supply chain security;
• distinguish static, dynamic, dependency, secret, container, and infrastructure scanning;
• place security controls appropriately within a CI/CD pipeline;
• apply least privilege and protect credentials used by automation;
• explain SBOMs, signed artifacts, and provenance attestations;
• design a basic vulnerability triage and response process;
• identify limitations, false positives, governance duties, and ethical concerns in automated security.

1. DevSecOps as a Delivery Model

Traditional delivery often placed security near the end of a project. Security specialists performed penetration tests or compliance checks shortly before release. This approach can identify serious defects, but late discovery is expensive: the original developer may no longer remember the design decision, and remediation may delay a release.

DevSecOps shifts security activities left, right, and throughout the delivery process. “Shift left” means detecting problems earlier, for example by scanning code during a pull request. “Shift right” means continuing security observation in staging and production, where runtime behaviour and new threats can be assessed. The objective is not simply more scanning; it is faster, better-informed risk reduction.

A useful DevSecOps operating model has four characteristics:

1. Shared responsibility: developers, platform engineers, operations staff, and security professionals participate in security outcomes.
2. Automation: repeatable checks run consistently in pull requests, builds, deployments, and runtime environments.
3. Risk-based decision-making: findings are prioritised according to exploitability, impact, exposure, and available mitigations.
4. Traceability: the organisation can determine what was built, from which source and dependencies, by which process, and where it was deployed.

Security automation must support delivery rather than create unexamined obstacles. A pipeline that blocks every low-confidence finding encourages unsafe bypasses. Conversely, a pipeline that never blocks a release provides only the appearance of security. Effective controls have explicit thresholds, ownership, exception procedures, and feedback mechanisms.

2. The Software Supply Chain

The software supply chain includes more than third-party libraries. It may contain:

• developer workstations and source repositories;
• source code, package manifests, and build scripts;
• package registries and operating-system packages;
• CI runners, build images, plugins, and actions;
• container base images and deployment charts;
• cloud accounts, infrastructure definitions, and secrets;
• artifact repositories and release systems;
• production platforms and monitoring systems.

An attacker may target any link. For example, compromising a popular package can affect thousands of applications. Altering a build action may inject malicious code into otherwise trustworthy source. Stealing a deployment token may allow an attacker to modify production without changing the application itself.

Supply-chain security therefore asks three related questions:

• Integrity: Has the software or process been altered without authorisation?
• Authenticity: Can the organisation identify who or what produced an artifact?
• Traceability: Can the artifact be connected to its source, dependencies, build process, and deployment?

Confidentiality is also important, particularly because source repositories and CI logs can contain credentials, personal data, proprietary algorithms, or security-test results.

3. Security Controls in the CI/CD Pipeline

A secure pipeline uses several layers rather than one universal scanner. The following controls address different failure modes.

These tools are complementary. A static scanner may find an unsafe input operation but cannot prove whether the deployed environment is configured securely. A dependency scanner can identify a vulnerable library but may not know whether the vulnerable function is reachable. A dynamic scanner observes behaviour but may miss untested application paths.

Static Application Security Testing

Static Application Security Testing (SAST) analyses source code, bytecode, or compiled representations without executing the application. It can identify patterns such as injection risks, insecure cryptographic use, unsafe deserialisation, path traversal, and missing access checks.

SAST is valuable early because it can comment directly on changed lines. Its limitations include false positives, difficulty understanding business logic, and incomplete analysis of generated or dynamically constructed code. Teams should establish severity thresholds and teach developers how to interpret findings rather than treating scanner output as unquestionable truth.

Dynamic Application Security Testing

Dynamic Application Security Testing (DAST) interacts with a running application. It can test HTTP responses, authentication behaviour, headers, input handling, and common web vulnerabilities. DAST is best performed in an isolated environment containing representative test data.

DAST may miss functionality that is not discovered by the test crawler and can cause side effects if run against production. Authentication must be configured carefully: an unauthenticated scan reveals only public behaviour, while an authenticated scan requires controlled test accounts and protected credentials.

Software Composition Analysis

Software Composition Analysis (SCA) identifies direct and transitive dependencies and compares their versions with vulnerability databases. It can also identify licences, abandoned packages, and dependency confusion risks.

A finding is not automatically an exploitable vulnerability. Assessment should consider the affected version, the application’s use of the component, exploit availability, exposure, and the availability of a fix. Lockfiles, private registries, dependency pinning, and review of update provenance improve reliability.

Secret Scanning

Secret scanning searches current files, commit history, pull requests, logs, and build artifacts for credentials such as API keys, private keys, database passwords, and cloud tokens. It may use pattern matching, entropy analysis, and provider verification.

A detected secret must be treated as potentially compromised. The correct response is not merely deleting the line in a later commit. The credential should be revoked or rotated, affected systems examined, and repository history cleaned where appropriate. Logs and artifacts should also be checked because secrets may have been copied there.

Container and Infrastructure Scanning

Container scanning examines image layers, operating-system packages, application dependencies, configuration, and sometimes the image’s runtime behaviour. Good practice includes using minimal trusted base images, rebuilding regularly, removing unnecessary tools, running as a non-root user, and pinning image references by digest where practical.

Infrastructure as Code (IaC) scanning examines definitions for cloud resources, networks, identities, storage, Kubernetes objects, and deployment policies. Common findings include public storage, unrestricted network access, unencrypted data, hard-coded credentials, and excessive permissions. IaC scanning is particularly useful because the configuration is reviewed before it changes a live environment.

4. Designing Pipeline Gates

A security gate is a condition that must be satisfied before a pipeline proceeds. Gates should be proportionate to risk. A mature design commonly uses:

• informative findings for low-confidence or low-severity issues;
• pull-request feedback for developer correction;
• blocking rules for exploitable critical vulnerabilities, exposed production credentials, or prohibited configurations;
• manual approval for exceptional, time-limited risk acceptance;
• scheduled rescans because new vulnerabilities are discovered after release.

A gate should specify the finding’s owner, due date, evidence required for an exception, and the person authorised to approve it. Suppression must be narrow and documented; globally disabling a scanner is not an exception process.

A practical pipeline sequence is:

1. validate source and build dependencies;
2. scan changed code and repository contents;
3. scan dependencies and licences;
4. build the artifact in an isolated runner;
5. scan the resulting container or package;
6. generate an SBOM and provenance record;
7. sign the artifact and related metadata;
8. deploy to a controlled test environment;
9. perform DAST and integration security tests;
10. obtain approval according to risk;
11. deploy the same verified artifact to production;
12. monitor, rescan, and respond to new findings.

The principle of promoting the same artifact is important. Rebuilding between staging and production can produce different dependency resolution, timestamps, or build outputs. If a rebuild is necessary, it should be reproducible and independently verified.

5. Least Privilege and Credential Protection

Least privilege means granting an identity only the permissions required for its task, for only as long as required. It applies to developers, CI jobs, deployment agents, service accounts, cloud roles, package registries, and signing systems.

A secure pipeline should separate duties. A pull-request job may read source and run tests but should not deploy to production. A release job may publish an artifact but should not be able to modify source protection rules. Production deployment should use a narrowly scoped identity, preferably with short-lived credentials and an auditable approval step.

Credentials should be stored in a dedicated secrets manager or the CI platform’s protected secret store, not in source files, container layers, command-line arguments, or ordinary variables printed in logs. Logs should be treated as sensitive outputs. Masking is helpful but not a substitute for preventing secrets from reaching the log.

Important practices include:

• use short-lived, automatically issued tokens where supported;
• rotate credentials and revoke unused identities;
• restrict secrets to the jobs and branches that require them;
• prevent untrusted pull requests from accessing privileged secrets;
• use separate credentials for development, test, and production;
• monitor use of privileged identities;
• require stronger authentication for administrators and signing keys.

Federated identity can allow a CI system to obtain temporary cloud credentials based on a verified repository, branch, workflow, or deployment environment. This reduces the need for long-lived static cloud keys, but federation rules must be narrowly scoped and reviewed.

6. SBOMs, Signing, and Provenance

A Software Bill of Materials (SBOM) is a structured inventory of software components in an artifact. It may include package names, versions, suppliers, licences, relationships, and identifiers such as common package or vulnerability references. Formats such as SPDX and CycloneDX support machine-readable exchange.

An SBOM improves vulnerability response because an organisation can ask which deployed products contain an affected component. It is not, by itself, proof that the software is secure. An inaccurate or outdated SBOM creates false confidence, so generation should occur from the build process and be associated with a specific artifact digest.

Artifact signing uses cryptography to bind an identity to an artifact or metadata statement. Verification answers whether the artifact matches the signed content and whether the signing identity is trusted under the organisation’s policy. Signatures do not prove that the artifact contains no vulnerabilities; they provide evidence of origin and integrity.

Provenance describes how an artifact was produced. It may record the source revision, builder, workflow, dependencies, parameters, time, and resulting digest. Attestations can support policies such as “deploy only artifacts built by the approved workflow from a protected branch.” Provenance is meaningful only when the build environment and signing identity are themselves protected.

A useful trust chain is:

source revision → controlled build → artifact digest → SBOM and provenance → signature → policy verification → deployment

Each link should be auditable. If an artifact is copied to another registry, its digest and signatures should remain associated with it.

7. Vulnerability Management and Response

Vulnerability management is a lifecycle, not a scan-and-close activity. It includes discovery, validation, prioritisation, remediation, verification, and learning.

Prioritisation should consider at least:

• technical severity;
• whether exploitation is known or easy;
• internet or internal exposure;
• sensitivity of affected data;
• privileges required for exploitation;
• presence of compensating controls;
• availability and safety of a fix;
• business criticality and regulatory obligations.

Teams should distinguish a false positive from a risk accepted for a genuine reason. A false positive means the finding does not apply or is incorrectly identified. Risk acceptance means the finding is real but temporarily tolerated with an identified owner, justification, expiry date, and mitigation.

When a critical vulnerability is announced, an effective response process is:

1. identify affected components using SBOMs and dependency inventories;
2. determine whether affected versions are deployed and reachable;
3. assess exploitability and exposure;
4. apply a safe update, configuration mitigation, or temporary isolation;
5. test and release the remedy;
6. rescan and verify the deployed state;
7. document decisions and improve controls.

Emergency response should not permanently bypass normal assurance. Where an emergency change is unavoidable, it should be logged, reviewed retrospectively, and followed by full testing.

8. Illustrative Case: Northstar Payments

Background. Northstar Payments is a fictional medium-sized company operating an online payment service. Its delivery pipeline used unit tests and container builds but had no dependency inventory, no signing, and a shared cloud deployment key.

Problem. A newly disclosed vulnerability affected a library used by several services. Engineers could not determine which deployed images contained the library. Investigation also found that a pull-request workflow could access the shared deployment key through an incorrectly configured secret.

Analysis. The organisation faced two different risks. The vulnerable dependency created an application exposure, while the shared key created a supply-chain and privilege-escalation risk. The absence of an SBOM increased the time required to identify affected services. The pull-request issue was especially serious because untrusted code could potentially execute in the workflow.

Approach. Northstar introduced dependency lockfiles and SCA in pull requests and scheduled scans. The build process generated an SBOM for each image and stored it with the image digest. Images were signed by a protected release workflow. Production deployment accepted only signed images built by the approved workflow. The shared key was revoked and replaced with short-lived, environment-specific federated credentials. Pull-request jobs were prevented from accessing production secrets. IaC checks blocked public storage and unrestricted administrative network access.

The company also introduced severity-based gates. Critical exploitable findings blocked release; lower-risk findings created tracked work items. Emergency exceptions required a security owner, a compensating control, and an expiry date.

Outcome. When the next major library vulnerability was announced, Northstar queried its SBOM repository and identified affected services within minutes. The organisation rebuilt and signed patched images, verified them in staging, and deployed the same digests to production. The change did not eliminate all risk, but it reduced uncertainty, improved response speed, and created auditable evidence.

Learning points. Security depends on both technical controls and operating discipline. An SBOM is valuable when it is accurate and connected to deployed artifacts. Least privilege reduces the impact of a compromised job. Signing and provenance strengthen trust, but only when verification is enforced. Finally, exception management is safer than informal bypasses.

9. Limitations, Governance, and Ethics

Automated scanners are imperfect. They produce false positives, miss business-logic flaws, depend on incomplete vulnerability databases, and may not understand custom frameworks. Security tests can also expose personal or operational data if environments are poorly designed. Tools should therefore be combined with secure design review, threat modelling, code review, penetration testing, and runtime monitoring.

Governance should define ownership, acceptable risk, evidence retention, access control, data handling, and escalation. Organisations may have contractual or regulatory duties concerning vulnerability disclosure, software inventories, privacy, critical infrastructure, and incident reporting. Requirements vary by jurisdiction and sector; legal advice may be necessary.

Ethically, security teams should avoid destructive testing without authorisation, protect discovered sensitive information, minimise collection of personal data, and communicate vulnerabilities responsibly. Developers should not conceal findings to meet delivery targets, and managers should not demand unsafe releases without explicitly accepting the risk.

Artificial intelligence can assist with code review, anomaly detection, vulnerability explanation, and prioritisation. However, AI-generated code may introduce insecure patterns, invent inaccurate remediation, or leak proprietary code to an external service. AI outputs require human review, controlled data handling, reproducible checks, and the same pipeline gates as human-authored code.

10. Contemporary Practices and Best Practices

Current supply-chain practice increasingly emphasises verifiable builds, signed attestations, trusted build environments, dependency transparency, and policy-as-code. Organisations are moving from merely asking whether a scan passed to asking whether the artifact was produced by an authorised process and can be traced to reviewed source.

A certificate-level implementation should prioritise the following sequence:

1. inventory repositories, dependencies, images, identities, and deployment environments;
2. add secret scanning and dependency scanning;
3. protect CI secrets and remove unnecessary privileges;
4. add SAST, container scanning, and IaC scanning;
5. generate SBOMs for release artifacts;
6. sign artifacts and verify signatures before deployment;
7. record provenance and retain audit evidence;
8. establish vulnerability ownership, deadlines, and exception rules;
9. add DAST and runtime monitoring;
10. review results, false positives, and control effectiveness regularly.

Security should be measured by meaningful outcomes rather than the number of tools installed. Useful indicators include time to identify affected products, time to remediate exploitable vulnerabilities, percentage of production artifacts with verified provenance, number of long-lived credentials, and recurrence of previously corrected weaknesses. Metrics must be interpreted carefully: a rising finding count may indicate improved detection rather than declining security.

Chapter Summary

DevSecOps integrates security into development, delivery, and operation. Software supply-chain security protects the complete path from source code and dependencies to build systems, artifacts, deployment identities, and production environments. SAST, DAST, SCA, secret scanning, container scanning, and IaC scanning address different classes of risk and should be combined rather than treated as interchangeable.

Effective pipelines use risk-based gates, protected credentials, least-privileged identities, and controlled exception processes. SBOMs provide component visibility; signatures provide integrity and identity evidence; provenance records how an artifact was built. Together, these controls improve traceability and vulnerability response, although none proves that software is free from vulnerabilities.

Security automation has limitations and must be complemented by human review, threat modelling, testing, governance, and ethical practice. The central professional principle is to make secure delivery repeatable, observable, and proportionate to risk.

Key Terms

DevSecOps: An approach that integrates security responsibilities and controls throughout software delivery and operations.

Software supply chain: The people, processes, systems, and components involved in producing and delivering software.

SAST: Static Application Security Testing that analyses code or compiled representations without executing the application.

DAST: Dynamic Application Security Testing that examines a running application through interaction and observation.

SCA: Software Composition Analysis that inventories and assesses third-party and open-source components.

Secret scanning: Detection of credentials and sensitive tokens in source, history, logs, or artifacts.

Infrastructure as Code: Machine-readable definitions used to create and configure infrastructure.

Security gate: A pipeline condition that permits or prevents progression based on defined security criteria.

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

SBOM: A machine-readable inventory of components contained in a software artifact.

Artifact: A built software output, such as a package, binary, or container image.

Artifact digest: A cryptographic identifier representing particular artifact content.

Digital signature: Cryptographic evidence connecting content with a signing identity.

Provenance: Information describing the source, builder, process, and inputs used to create an artifact.

Attestation: A signed statement about an artifact or the process that produced it.

Dependency confusion: An attack in which a malicious package is selected instead of the intended internal package.

Vulnerability: A weakness that can be exploited to harm confidentiality, integrity, or availability.

Risk acceptance: A documented decision to tolerate a known risk under specified conditions.

Federated identity: An arrangement in which a trusted identity provider issues temporary access based on verified attributes.

Review Questions

Short Answer Questions

1. What is the primary purpose of DevSecOps?
2. How does SAST differ from DAST?
3. Why should an exposed credential be revoked rather than simply deleted from a file?
4. What information does an SBOM provide?
5. State two benefits of least privilege in a CI/CD pipeline.

Long Answer Questions

1. Explain why software supply-chain security must address build systems and deployment identities as well as application source code.
2. Describe how SAST, DAST, SCA, secret, container, and IaC scanning can be combined in a CI/CD pipeline.
3. Explain the relationship between artifact signing, provenance, and deployment policy.
4. Discuss how an organisation should prioritise and manage vulnerability findings.
5. Evaluate the limitations of automated security scanning and explain why human review remains necessary.

Analytical / Application Questions

1. A pull-request workflow can read a production cloud key. Analyse the risk and propose a safer identity and secret-management design.
2. A critical dependency vulnerability is announced, but the organisation has no SBOM. Design an immediate response and a longer-term improvement plan.
3. A team wants to block every scanner finding to demonstrate strong security. Evaluate this proposal and design a more effective risk-based gating model.

Multiple Choice Questions with Answers

Question 1

Which activity is the primary purpose of SAST?

A. Interacting with a running application

B. Analysing source or compiled code for weaknesses

C. Signing container images

D. Monitoring production network traffic

Correct Answer: B. Analysing source or compiled code for weaknesses

Question 2

Which control is most directly concerned with identifying vulnerable open-source libraries?

A. SCA

B. DAST

C. Secret scanning

D. Runtime monitoring

Correct Answer: A. SCA

Question 3

What should normally happen first when a credential is discovered in a repository?

A. Rename the repository

B. Delete only the visible line

C. Revoke or rotate the credential

D. Ignore it if the commit is old

Correct Answer: C. Revoke or rotate the credential

Question 4

What is the main purpose of an SBOM?

A. To encrypt an application

B. To list the components in a software artifact

C. To replace all security testing

D. To provide production network access

Correct Answer: B. To list the components in a software artifact

Question 5

Which practice best implements least privilege for a pull-request job?

A. Give it permanent administrator access

B. Allow it to deploy directly to production

C. Give it only the read and test permissions it requires

D. Share the production deployment key with it

Correct Answer: C. Give it only the read and test permissions it requires

Question 6

What does artifact signing primarily provide?

A. Proof that the artifact has no vulnerabilities

B. Evidence of integrity and association with a signing identity

C. Automatic removal of insecure dependencies

D. A replacement for access control

Correct Answer: B. Evidence of integrity and association with a signing identity

Question 7

Why is promoting the same verified artifact from staging to production preferable to rebuilding it?

A. It ensures the tested artifact is the deployed artifact

B. It eliminates the need for testing

C. It makes signatures unnecessary

D. It guarantees that dependencies are vulnerability-free

Correct Answer: A. It ensures the tested artifact is the deployed artifact

Question 8

Which scan is designed to examine a running application?

A. SAST

B. SCA

C. DAST

D. SBOM generation

Correct Answer: C. DAST

Question 9

What is a documented risk acceptance decision expected to include?

A. No owner and no expiry date

B. A justification, owner, mitigation, and review or expiry conditions

C. A permanent scanner disablement

D. A deletion of the finding

Correct Answer: B. A justification, owner, mitigation, and review or expiry conditions

Question 10

What does provenance primarily describe?

A. The visual design of an application

B. How an artifact was produced and from which inputs

C. The number of users currently online

D. The encryption algorithm used by a database

Correct Answer: B. How an artifact was produced and from which inputs