DevSecOps, Secrets and Software Supply-Chain Security

Introduction

Modern software is assembled from source code, open-source dependencies, container images, build tools, cloud services, deployment platforms, and operational credentials. Each component creates opportunities for failure or attack. A vulnerable library, an accidentally committed password, an untrusted build runner, or a tampered deployment artifact can compromise an entire organisation.

DevSecOps is the practice of integrating security into software delivery rather than treating security as a final inspection. It combines development, operations, and security responsibilities through shared ownership, automated controls, continuous feedback, and risk-based decision-making. The objective is not to make every developer a security specialist. It is to ensure that security requirements, evidence, and controls are present throughout the delivery lifecycle.

This chapter focuses on four connected concerns: threat awareness and least privilege; secrets management; dependency and image security; and software supply-chain assurance through software bills of materials (SBOMs), artifact signing, provenance, and vulnerability remediation.

Learning Objectives

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

1. Explain the purpose and principles of DevSecOps.
2. Identify common threats in source-code, build, dependency, container, and deployment workflows.
3. Apply least-privilege principles to users, services, pipelines, and cloud identities.
4. Distinguish secrets from ordinary configuration and select suitable management practices.
5. Explain software composition analysis, container-image scanning, SBOMs, signing, and provenance.
6. Design a practical vulnerability-remediation workflow based on risk rather than scan volume alone.
7. Evaluate governance, ethical, and operational issues in secure software delivery.

1. DevSecOps as a Delivery-Lifecycle Capability

Traditional delivery often placed security after implementation. A security team might perform a penetration test shortly before release, when architectural changes were expensive and deadlines were tight. DevSecOps shifts suitable security activities earlier while retaining deeper review for high-risk systems.

A simplified lifecycle is:

Plan → Code → Build → Test → Package → Release → Deploy → Operate → Learn

Security activities are distributed across this lifecycle:

• Plan: identify assets, trust boundaries, regulatory obligations, and abuse cases.
• Code: use secure coding practices, peer review, protected branches, and secret detection.
• Build: isolate runners, pin tools, restrict credentials, and record provenance.
• Test: perform static analysis, dependency scanning, dynamic testing, and security tests.
• Package: generate SBOMs, scan images, sign artifacts, and preserve immutable metadata.
• Release and deploy: enforce policy gates, verify signatures, and use controlled identities.
• Operate: monitor vulnerabilities, detect misuse, rotate credentials, and respond to incidents.
• Learn: feed operational findings into architecture, backlog, and engineering standards.

DevSecOps is not equivalent to installing a security scanner. A scanner produces findings; DevSecOps establishes ownership, prioritisation, remediation, verification, and learning. Excessive false positives, unowned findings, and ineffective exception processes can create the appearance of security without reducing risk.

Shared responsibility and risk ownership

Security responsibility is distributed, but accountability must remain clear. Developers generally own the security of code they change; platform teams own the security of reusable build and deployment mechanisms; operations teams own runtime controls; and security specialists provide standards, threat expertise, testing, and assurance. Product owners decide how risk affects release decisions, within organisational and regulatory constraints.

A useful distinction is between a control owner and a risk owner. The control owner implements and maintains a safeguard, such as image scanning. The risk owner accepts, transfers, reduces, or avoids the remaining risk. These roles may be held by different people.

2. Threat Awareness in the Software Supply Chain

A software supply chain includes all people, processes, systems, and components involved in creating and delivering software. Threats may originate internally or externally and may target confidentiality, integrity, availability, or accountability.

Important threat categories include:

Threat modelling makes these possibilities explicit. At certificate level, a practical method is to ask:

1. What are the important assets?
2. Who should be trusted, and across which boundaries?
3. What could an attacker control or influence?
4. What would be the impact of compromise?
5. Which preventive and detective controls are proportionate?

For example, a pull request from an external contributor should not automatically receive production credentials. A build job that only compiles code should not possess authority to delete cloud databases. These conclusions arise from analysing trust boundaries and required actions.

Least privilege and blast radius

Least privilege means granting an identity only the permissions required for an approved task, for only as long as needed. It applies to human users, service accounts, CI jobs, containers, cloud roles, package registries, and database accounts.

Effective least privilege has several dimensions:

• Scope: restrict access to a project, repository, namespace, or resource.
• Action: separate read, write, deploy, delete, and administrative operations.
• Time: use short-lived credentials and just-in-time elevation.
• Context: require approved branches, environments, networks, or devices.
• Identity: use individual or workload identities rather than shared accounts.

Least privilege reduces blast radius, but it can complicate automation. Teams should begin with observable permissions, remove unused access, test failure modes, and review permissions after system changes. Denying all access is not a practical security strategy if it prevents reliable operation; the goal is narrowly sufficient access.

3. Secrets Management

A secret is sensitive data used to authenticate, authorise, encrypt, or otherwise establish trust. Examples include passwords, API keys, private keys, database connection strings, signing keys, OAuth client secrets, and cloud access tokens. A username or public certificate is not normally a secret, although it may still be sensitive configuration.

Why secrets fail

Common failures include:

• committing a secret to a public or internal repository;
• placing secrets in shell history, build logs, or chat messages;
• using one credential across development, test, and production;
• embedding credentials in container images;
• granting long-lived, broadly privileged tokens to pipelines;
• failing to rotate a secret after suspected exposure;
• assuming that deleting a line removes it from repository history;
• logging complete request headers or connection strings.

Secret scanning is valuable, but it is not a complete solution. A secret may be encoded, generated dynamically, stored in an unusual file, or exposed only at runtime. Prevention, restricted access, monitoring, and response are all required.

A secrets-management model

A mature model separates four activities:

1. Creation: generate high-entropy credentials using an approved mechanism.
2. Storage: place secrets in a dedicated secrets manager or hardware-backed system where appropriate.
3. Use: retrieve secrets at runtime or during a narrowly controlled job, avoiding source control and unnecessary exposure.
4. Rotation and revocation: replace credentials periodically or after events, and invalidate the old values.

Secrets managers commonly provide encryption at rest, access policies, audit logs, versioning, and automated rotation. Encryption alone is insufficient: if every pipeline can decrypt every secret, the system remains overprivileged.

A preferred pattern is workload identity. Instead of storing a permanent cloud key in CI, the job proves its identity to the cloud provider and receives a short-lived token with limited permissions. This reduces the value of a leaked credential and improves attribution.

Handling an exposed secret

When exposure is suspected, the correct order is usually:

1. prevent further use by revoking or disabling the secret;
2. assess where it was exposed and what permissions it had;
3. preserve relevant evidence without spreading the value;
4. rotate or replace the credential;
5. inspect logs for misuse;
6. remove the secret from active files and history where appropriate;
7. document the incident and improve preventive controls.

Removing a secret from the latest commit does not make the old value safe. Repository history, forks, caches, logs, and artifacts may retain it. The value must be treated as compromised until revoked.

4. Dependency and Container Security

Modern applications depend on direct and transitive packages. A direct dependency is explicitly selected by the application; a transitive dependency is brought in by another component. Both can introduce vulnerabilities, licensing obligations, malicious code, or maintenance risk.

Software composition analysis

Software composition analysis (SCA) identifies components and compares their versions against vulnerability and licence information. Good SCA practice includes:

• recording direct and transitive dependencies;
• using lockfiles where the ecosystem supports them;
• pinning versions or using controlled update policies;
• verifying package checksums or signatures where available;
• reviewing abandoned or unmaintained components;
• testing updates before production use;
• monitoring newly disclosed vulnerabilities after release.

Version pinning improves reproducibility, but it does not mean that a version is permanently safe. A pinned vulnerable version remains vulnerable. Automated update tools can create pull requests, yet each update still requires compatibility and security evaluation.

Container image security

A container image typically contains an application, libraries, a base operating-system layer, metadata, and sometimes tools not required at runtime. Image scanning can identify known vulnerable packages, but scanners differ in databases, reachability analysis, and severity interpretation.

Practical controls include:

• use minimal and maintained base images;
• build from trusted, controlled sources;
• avoid compilers, shells, and debugging tools in runtime images when unnecessary;
• run as a non-root user;
• set a read-only filesystem where feasible;
• scan images before release and periodically afterward;
• pin image digests rather than relying only on mutable tags;
• sign approved images and verify signatures at deployment;
• separate build, test, and production registries.

A tag such as app:latest is a human-readable label, not a guarantee of immutable content. A digest identifies content by its cryptographic hash. Digest pinning improves reproducibility, although it must be combined with a trusted source and signature verification.

Interpreting vulnerability severity

Severity is not the same as organisational risk. Risk depends on exploitability, exposure, affected functionality, compensating controls, data sensitivity, and business impact. A high-severity library vulnerability in unreachable code may require a different response from a medium-severity issue in an internet-facing authentication service.

Teams should define policies such as:

• block production release for exploitable critical findings in reachable components;
• require a documented exception for unresolved high findings;
• assign owners and due dates;
• permit temporary compensating controls where justified;
• re-scan after remediation;
• report overdue risk to an accountable owner.

Policies should distinguish the build result from the vulnerability result. A failed scan should not be silently ignored, but an automatic block without an exception process can encourage unsafe workarounds.

5. SBOMs, Provenance, and Artifact Signing

Software bills of materials

An SBOM is a machine-readable inventory of software components in an artifact. It may include component names, versions, suppliers, identifiers, relationships, licences, and hashes. Common data formats include SPDX and CycloneDX.

An SBOM helps organisations answer questions such as:

• Which deployed products contain a newly disclosed component?
• Which version of a library is present?
• Which supplier or package introduced it?
• Which systems require urgent remediation?

An SBOM is not a security certificate. It describes contents and relationships; it does not prove that the contents are safe or that the inventory is complete. It should be generated from reliable build data, stored with the artifact, and updated when the artifact changes.

Provenance

Provenance records how an artifact was produced. Useful information includes source revision, build definition, builder identity, dependencies, timestamps, parameters, and results of relevant checks. Provenance supports reproducibility and helps establish whether an artifact came from an approved process.

The strength of provenance depends on its integrity. If a developer can freely alter provenance after a build, it provides weak assurance. Provenance should therefore be generated by trusted systems, associated with immutable artifacts, and protected from unauthorised modification.

Signing and verification

Artifact signing uses a private key to create a digital signature over artifact content or a digest. Verification uses the corresponding public key and a trusted key-distribution process. Signing answers an authenticity and integrity question: was this content signed by an approved identity, and has it changed since signing?

Signing does not prove that software is free of vulnerabilities or that the signer reviewed every line of code. Key protection is essential. Private signing keys should be access-controlled, audited, rotated according to policy, and preferably held in a hardware-backed or managed signing service. Verification should occur at deployment, not only when an artifact is uploaded.

A reliable release decision may require all of the following:

1. the artifact originates from an approved repository and build workflow;
2. the artifact digest matches the tested content;
3. the signature chains to an approved identity;
4. provenance satisfies policy;
5. the SBOM is present and meets required quality;
6. vulnerability findings are within policy;
7. deployment authorization is valid.

6. Designing a Secure CI/CD Pipeline

A practical pipeline can be structured as follows:

Pipeline configuration is code and must itself be reviewed. Third-party CI actions and plugins can execute with pipeline permissions, so they should be pinned, sourced carefully, and granted only necessary access. A build runner should not retain credentials between jobs. Untrusted pull requests should be isolated from privileged workflows.

Security checks should be fast and proportionate. Developers benefit from immediate feedback on secrets and obvious coding errors, while deeper scans can run asynchronously or before release. Results must be understandable: a finding should identify the affected component, evidence, severity rationale, owner, due date, and remediation or exception path.

7. Vulnerability Remediation as a Managed Process

Remediation begins with discovery but ends only after verification. A useful workflow is:

Discover → Triage → Assign → Fix or Mitigate → Test → Release → Verify → Record

Triage should consider at least:

• technical severity;
• exploit availability and active exploitation;
• network exposure;
• privileges required by an attacker;
• data and business impact;
• reachability of the vulnerable code;
• presence of compensating controls;
• cost and risk of the proposed fix.

A simple qualitative model can classify findings as critical, high, medium, or low, but organisations should document the criteria. Numerical risk scores may support consistency, yet they should not create false precision. The absence of a score does not imply the absence of risk.

Remediation options include upgrading, replacing, removing, disabling a feature, changing configuration, isolating a service, adding runtime controls, or accepting the residual risk for a defined period. Exceptions should be time-limited, approved by an accountable risk owner, and revisited when circumstances change.

Metrics should measure outcomes rather than scanner activity. Useful measures include the age of open critical findings, time to remediate, percentage of production artifacts with verified signatures, percentage of workloads with SBOMs, and the proportion of pipelines using short-lived identities. Metrics must be interpreted carefully: a reduction in reported vulnerabilities may reflect reduced scanning rather than improved security.

Illustrative Case: Northstar Payments

Background

Northstar Payments is an illustrative mid-sized company that operates a web payment service. Its teams use a shared CI platform, public package registries, and container orchestration. Releases are frequent, but security controls developed inconsistently across teams.

Problem

An engineer discovers that a test repository contains a cloud access token. The token was also printed in a failed pipeline log. At the same time, a production image includes an outdated operating-system package with a known critical vulnerability. The organisation has no reliable inventory of deployed dependencies and cannot prove which image was tested.

Analysis

The token is treated as compromised because it appeared in repository history and logs. Investigation shows that it had permissions to read source repositories and modify a staging environment. The image issue is difficult to scope because teams deploy mutable tags and do not retain SBOMs. The immediate technical issues reveal broader governance problems: excessive permissions, weak artifact identity, and incomplete ownership of findings.

Approach and solution

Northstar first revokes the token, examines access logs, and issues a narrowly scoped replacement through its secrets manager. Pipeline logs are reviewed and access to sensitive log data is restricted. Secret-detection checks are added to pre-commit and CI workflows.

The platform team then introduces workload identity for CI, separates staging and production roles, and prevents pull-request jobs from receiving deployment credentials. Container images are rebuilt from a maintained minimal base image. Each release receives an immutable digest, an SBOM, provenance metadata, and a signature from a managed signing service. The cluster admission policy verifies the signature and rejects unsigned production images.

Finally, the security team defines remediation priorities, assigns component ownership, and establishes a time-limited exception process. Teams receive dashboards showing affected deployed components when a new vulnerability is disclosed.

Outcome

Northstar cannot eliminate all vulnerabilities, but it can identify exposure faster, reduce the consequences of credential theft, and demonstrate which artifact entered production. The controls also improve audit evidence and release reproducibility.

Learning points

1. Revoking an exposed secret is more important than merely deleting it from a file.
2. Least privilege reduces the damage caused by inevitable mistakes.
3. SBOMs support impact analysis but do not replace scanning or secure design.
4. Signing provides artifact integrity and identity, not proof of vulnerability-free software.
5. Controls are effective only when linked to ownership, policy, and operational response.

8. Governance, Ethics, and Regulatory Considerations

Security controls affect employees, suppliers, customers, and the public. Organisations should collect only the security telemetry they need, protect logs containing personal or sensitive information, and define retention periods. Secret and pipeline logs may contain identifiers, source fragments, or customer data; unrestricted access can create a secondary privacy risk.

Responsible vulnerability disclosure requires a process for receiving reports, acknowledging researchers, reproducing findings, coordinating fixes, and communicating risk. Organisations should avoid retaliatory behaviour toward good-faith researchers and should publish clear contact information where appropriate.

Open-source use creates both security and licensing obligations. A component may be technically secure but incompatible with the organisation’s distribution model. SBOMs can support licence review, but legal interpretation may require specialist advice.

Regulatory and contractual requirements differ by industry and jurisdiction. Common expectations include access control, change management, vulnerability management, auditability, incident response, supplier oversight, and evidence that critical systems are protected. Compliance is a baseline, not a substitute for threat analysis.

9. Contemporary Developments and Limitations

Several developments are shaping DevSecOps:

• Policy as code expresses release and deployment rules in testable form.
• Software supply-chain frameworks encourage stronger provenance, signing, and verification.
• Managed identity and ephemeral environments reduce long-lived credential exposure.
• Reachability analysis attempts to distinguish vulnerable code that is actually used.
• AI-assisted coding can increase productivity but may introduce insecure code, licensing uncertainty, hallucinated dependencies, or inadvertent disclosure of confidential material. Generated code requires review, testing, and provenance like any other code.
• Continuous exposure management links asset inventory, vulnerabilities, identity, and runtime context to prioritise actual organisational exposure.

No tool is complete. Vulnerability databases can be delayed or inaccurate; scanners produce false positives and false negatives; signatures can validate an approved but malicious artifact; SBOMs can be incomplete; and strict gates can encourage teams to bypass controls. Security therefore depends on defence in depth, trustworthy processes, skilled people, and continuous improvement.

Best-Practice Checklist

• Define security ownership for code, pipelines, artifacts, and deployed services.
• Threat-model important trust boundaries and high-impact workflows.
• Use individual and workload identities with least privilege.
• Store secrets in an approved manager, not in source code or images.
• Revoke exposed credentials immediately and investigate their use.
• Pin and review dependencies, base images, and CI actions.
• Generate SBOMs and provenance for released artifacts.
• Sign artifacts with protected keys and verify them at deployment.
• Use immutable digests and controlled registries.
• Prioritise vulnerabilities using exposure and impact, not severity alone.
• Assign findings, set due dates, document exceptions, and verify fixes.
• Monitor deployed software because new vulnerabilities can emerge after release.

Chapter Summary

DevSecOps integrates security into planning, coding, building, testing, releasing, deploying, and operating software. Its foundation is shared responsibility supported by clear ownership and risk-based decisions. Threat awareness identifies trust boundaries and likely attack paths, while least privilege limits the blast radius of compromised users, services, and pipelines.

Secrets require dedicated storage, controlled retrieval, rotation, revocation, and careful handling of logs and repository history. Dependencies and container images must be inventoried, updated, scanned, and configured securely. SBOMs describe software contents; provenance describes how artifacts were built; signatures provide integrity and signer identity. None alone proves that software is safe.

A mature delivery process connects discovery to triage, remediation, verification, and governance. Effective DevSecOps is therefore not a collection of scanners. It is an operational capability combining technology, policy, human judgement, evidence, and continuous learning.

Key Terms

DevSecOps: Integration of security practices and responsibility throughout the software delivery lifecycle.

Software supply chain: The people, processes, systems, and components used to create and deliver software.

Least privilege: Granting only the access required for an approved task.

Blast radius: The extent of damage possible after an identity, component, or system is compromised.

Secret: Sensitive data used for authentication, authorisation, encryption, or trust establishment.

Secrets manager: A controlled system for storing, accessing, auditing, and rotating secrets.

Workload identity: An identity assigned to a software process or service rather than a human user.

Software composition analysis: Examination of direct and transitive software components for vulnerabilities, licences, and maintenance risks.

Transitive dependency: A component included indirectly through another dependency.

Container image: A packaged filesystem and metadata used to create a container instance.

Image digest: A cryptographic identifier representing specific image content.

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

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

Artifact signing: Applying a digital signature to software content or its digest.

Vulnerability: A weakness that can be exploited to violate security properties.

Remediation: Action taken to remove, reduce, or manage a vulnerability or other risk.

Compensating control: An alternative safeguard that reduces risk when the preferred fix is unavailable.

Policy as code: Security or governance rules expressed in machine-evaluable configuration or code.

Threat modelling: Structured analysis of assets, trust boundaries, threats, impacts, and controls.

Review Questions

Short Answer Questions

1. What is the main difference between DevSecOps and a final security review before release?
2. Why should an exposed secret be revoked rather than merely deleted from source code?
3. What information does an SBOM provide?
4. How does least privilege reduce blast radius?
5. What is the purpose of verifying an artifact signature at deployment?

Long Answer Questions

1. Explain how security controls can be distributed across the software delivery lifecycle.
2. Describe a complete secrets-management process from creation through rotation and revocation.
3. Compare dependency scanning, container-image scanning, SBOMs, provenance, and artifact signing.
4. Explain why vulnerability severity alone is insufficient for remediation prioritisation.
5. Design a secure CI/CD pipeline for a containerised application and justify its main controls.

Analytical / Application Questions

1. A CI job has permission to deploy to production, read every organisational secret, and modify databases. Analyse the risks and propose a least-privilege redesign.
2. A newly disclosed vulnerability affects a package listed in an SBOM, but the package is not reachable in the running application. What evidence and controls should inform the release decision?
3. A team removes a cloud key from the latest repository commit but does not revoke it. Evaluate the response and specify the actions required to manage the incident.

Multiple Choice Questions with Answers

Question 1

Which statement best describes DevSecOps?

A. Security testing performed only after deployment

B. Integration of security activities throughout the delivery lifecycle

C. Replacement of developers with security specialists

D. A method for eliminating all software vulnerabilities

Correct Answer: B. Integration of security activities throughout the delivery lifecycle

Question 2

What is the most appropriate first action after discovering a cloud credential in a public repository?

A. Rename the repository

B. Delete the latest commit only

C. Revoke or disable the credential

D. Wait for the next scheduled rotation

Correct Answer: C. Revoke or disable the credential

Question 3

Which practice most directly supports least privilege in CI/CD?

A. Giving every pipeline administrator access

B. Using short-lived identities with narrowly scoped permissions

C. Sharing one permanent production token

D. Storing all credentials in pipeline source code

Correct Answer: B. Using short-lived identities with narrowly scoped permissions

Question 4

What is the primary purpose of an SBOM?

A. To guarantee that software has no vulnerabilities

B. To encrypt application source code

C. To inventory components and their relationships in an artifact

D. To replace artifact signatures

Correct Answer: C. To inventory components and their relationships in an artifact

Question 5

What does artifact-signature verification primarily establish?

A. That the software contains no vulnerable code

B. That the content is associated with an approved signer and has not changed

C. That every dependency is open source

D. That the application will have no runtime failures

Correct Answer: B. That the content is associated with an approved signer and has not changed

Question 6

Why is using an image digest preferable to relying only on a mutable image tag?

A. A digest identifies specific image content

B. A digest automatically patches the image

C. A digest removes the need for access control

D. A digest guarantees that the image is vulnerability-free

Correct Answer: A. A digest identifies specific image content

Question 7

Which item is an example of a transitive dependency?

A. A library explicitly selected in an application manifest

B. A package installed indirectly by a selected library

C. A production database password

D. A container registry policy

Correct Answer: B. A package installed indirectly by a selected library

Question 8

Which factor should influence vulnerability remediation priority besides technical severity?

A. The colour of the scanner interface

B. The number of developers on the team

C. Exposure, exploitability, and potential business impact

D. Whether the finding appears on a Monday

Correct Answer: C. Exposure, exploitability, and potential business impact

Question 9

What is provenance intended to describe?

A. How an artifact was produced and from which inputs

B. The customer’s payment history

C. The password used by a developer

D. The visual design of a web application

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

Question 10

Which statement about an SBOM is correct?

A. It is a complete replacement for vulnerability scanning

B. It proves that the signer reviewed every line of code

C. It helps identify affected products when a component vulnerability is disclosed

D. It prevents all dependency tampering by itself

Correct Answer: C. It helps identify affected products when a component vulnerability is disclosed