DevSecOps, Supply-Chain Security, and Secrets

Introduction

Modern software is assembled from source code, third-party libraries, container images, build tools, cloud services, and deployment configurations. A vulnerability in any of these components can affect the final service. Security therefore cannot be treated as a final inspection performed immediately before release. It must be designed into planning, coding, building, testing, releasing, deploying, and operating.

DevSecOps extends DevOps by integrating security responsibilities, controls, and evidence throughout the software delivery lifecycle. Its purpose is not to make every developer a security specialist or to create a slow approval bureaucracy. Rather, it uses automation, shared responsibility, secure defaults, and continuous feedback to reduce risk while preserving delivery flow.

This chapter focuses on six connected practices: least privilege, secrets management, dependency and image scanning, software bills of materials (SBOMs), policy checks, and secure artifact provenance.

Learning Objectives

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

1. Explain the purpose and operating principles of DevSecOps.
2. Apply least-privilege reasoning to users, services, pipelines, and workloads.
3. Distinguish secrets from ordinary configuration and select suitable management controls.
4. Describe dependency, container-image, and infrastructure scanning.
5. Explain the purpose and limitations of SBOMs.
6. Use policy checks and provenance evidence to improve release assurance.
7. Design a practical security gate for a cloud CI/CD pipeline.
8. Evaluate trade-offs involving false positives, developer productivity, governance, and incident response.

1. DevSecOps as a Lifecycle Model

Traditional security processes often place a security review at the end of development. This creates a late-discovery problem: vulnerabilities may be expensive to correct after architecture, code, infrastructure, and release procedures have already been established. DevSecOps moves relevant controls earlier, while retaining protection during deployment and operation.

A simplified lifecycle is:

Plan → Code → Build → Test → Package → Release → Deploy → Operate → Monitor and Improve

Security activities occur at each stage:

DevSecOps rests on four principles. First, shared responsibility means developers, operations personnel, security practitioners, and management jointly own outcomes. Second, automation makes repeatable checks reliable and scalable. Third, feedback should be rapid and actionable rather than merely producing a large unprioritised report. Fourth, risk-based control recognises that not every finding has equal severity or exploitability.

DevSecOps is not synonymous with installing a security scanner. A pipeline that scans code but permits an untrusted build runner to publish production images remains insecure. Security depends on the complete system of identities, controls, evidence, and responses.

2. Least Privilege and Identity Design

The principle of least privilege states that a subject should receive only the permissions necessary for its authorised task, for only as long as necessary. A subject may be a human user, CI job, service account, container, function, or deployment controller.

Least privilege has several dimensions:

• Scope: access to one repository rather than every repository.
• Action: read access rather than write or administrative access.
• Resource: one storage bucket, namespace, or database rather than an entire account.
• Time: temporary access rather than permanent credentials.
• Environment: test access separated from production access.

A useful access decision model is:

This is a conceptual model, not a numerical equation. It means that authorisation should evaluate who is requesting an action, what action is requested, which resource is involved, and contextual conditions such as environment, device, network, or time.

In a CI/CD system, a single all-powerful credential is particularly dangerous. If an attacker compromises a dependency, pull request, runner, or build script, that credential can be used to alter releases or exfiltrate data. Better designs use separate identities for building, reading source, publishing artifacts, deploying to staging, and deploying to production.

Practical controls include:

1. Use short-lived tokens or workload identity instead of long-lived static keys.
2. Separate development, test, and production accounts or projects.
3. Restrict production deployment to protected branches and approved workflows.
4. Give build jobs read-only access unless publishing is required.
5. Use just-in-time elevation for exceptional administrative work.
6. Review permissions periodically and remove unused accounts.
7. Log authentication, authorisation, and privilege changes.

Least privilege is not the same as denying all access. Excessive restriction can encourage unsafe workarounds, such as sharing administrator credentials. Permissions should be minimal but usable, with an efficient process for requesting and approving additional access.

3. Secrets Management

A secret is sensitive information used to authenticate, authorise, encrypt, or otherwise protect a system. Examples include passwords, API keys, private keys, database credentials, signing keys, access tokens, and certificates. A secret is not made safe merely because it is hidden in a source-code repository or encoded with Base64; encoding is not encryption.

The secrets lifecycle

Secrets require control throughout their lifecycle:

1. Creation: generate high-entropy values using an approved mechanism.
2. Storage: place them in a dedicated secrets manager or protected key-management system.
3. Distribution: provide them to the workload at runtime through an authenticated channel.
4. Use: avoid printing or exposing them in logs, error messages, process listings, or artifacts.
5. Rotation: replace them on a schedule or after suspected exposure.
6. Revocation: disable compromised or obsolete values.
7. Destruction: remove old copies and confirm that caches and backups are addressed where appropriate.

A robust design keeps secrets out of source code, container images, build logs, and ordinary configuration files. Secret values can be injected at runtime as protected files, environment variables, or service responses, although each method has exposure risks. For example, environment variables may be visible to processes with sufficient operating-system access, while mounted files require careful permissions.

A secrets manager should provide access control, encryption at rest and in transit, audit logging, versioning, and rotation support. Encryption does not eliminate the need for authorisation: an application that can decrypt every secret still has excessive privilege.

CI/CD systems should mask known secret values in logs, but masking is not perfect. A secret may be transformed, split, encoded, or included in a diagnostic output in a way that defeats masking. Pipelines should therefore prevent secret access unless required and should treat pull-request code as potentially untrusted.

Private signing keys require especially strong controls. A stolen API key may permit access to a service; a stolen artifact-signing key may allow an attacker to make malicious software appear authentic. Signing keys should be tightly scoped, protected by a key-management service or hardware-backed mechanism where feasible, and rotated according to a documented procedure.

4. Dependency and Image Security

Modern applications depend on open-source packages, operating-system components, build plugins, base images, and vendor libraries. A dependency vulnerability becomes a product risk when the vulnerable component is present, reachable, and exploitable in the relevant context.

Dependency scanning

Software composition analysis (SCA) identifies components and compares their versions with vulnerability databases. Effective SCA should:

• inspect direct and transitive dependencies;
• distinguish production dependencies from development-only tools;
• identify the version actually resolved by the build;
• detect licences and policy restrictions;
• produce actionable upgrade or mitigation advice; and
• support exceptions with owners, reasons, and expiry dates.

A vulnerability identifier alone does not prove that exploitation is possible. Teams should consider severity, exploit availability, network exposure, reachability, compensating controls, and whether a fix is available. Conversely, a low-scored issue can still matter if it affects a highly exposed service or a critical business function.

Pinning dependencies improves reproducibility, but pinning an unsafe version can preserve a known vulnerability. A sound process combines controlled version updates, automated tests, lockfiles, and regular upgrade work.

Container and image scanning

A container image usually contains an application layer, runtime libraries, operating-system packages, configuration, and metadata. Image scanning can identify vulnerable packages, leaked secrets, insecure configuration, and risky permissions.

Good practices include using minimal and trusted base images, rebuilding regularly, removing package managers and unnecessary tools from production images, running as a non-root user, and publishing immutable image digests. A tag such as service:latest is mutable; a digest identifies a specific content address. Deployments should record the digest actually used.

Image scanning has limitations. A scanner may report vulnerabilities in files that are not loaded or reachable, miss vulnerabilities in proprietary code, or fail to recognise a newly disclosed issue until its database is updated. Scanning must therefore be combined with runtime controls, patch management, and monitoring.

5. Software Bills of Materials

An SBOM is a structured inventory of the components in a software product. It may include package names, versions, suppliers, licences, hashes, relationships, and dependency types. Common exchange formats include SPDX and CycloneDX.

An SBOM supports several activities:

• rapidly locating products affected by a newly disclosed vulnerability;
• checking licence obligations;
• understanding direct and transitive dependencies;
• supporting procurement and customer assurance;
• comparing builds for unexpected changes; and
• contributing evidence to incident response.

An SBOM is an inventory, not a security certificate. It does not demonstrate that components are vulnerability-free, that the build was trustworthy, or that the listed source corresponds to the deployed binary. Its value depends on completeness, accuracy, freshness, and linkage to a specific artifact.

A useful SBOM process generates the document from the resolved build, stores it with the artifact, signs or otherwise protects its integrity, and updates it whenever the artifact changes. Teams should distinguish between an SBOM for source dependencies and one for the final image, because operating-system packages and build-time components may differ.

6. Policy as Code and Automated Gates

Security policies express organisational requirements in a form that can be evaluated consistently. Policy as code represents such rules in machine-readable form and executes them in pull requests, pipelines, registries, or deployment platforms.

Examples include:

• production images must come from an approved registry;
• deployments must use signed artifacts;
• containers must not run as root;
• a workload may not request unrestricted network access;
• critical vulnerabilities require remediation or an approved exception;
• infrastructure must not expose a storage bucket publicly; and
• production changes must originate from a protected branch.

A mature gate has a clear subject, rule, evidence source, decision, and exception process. For example, a rule may reject an image if its vulnerability report contains an unaccepted critical finding. The rule must define what “critical” means, which scanner and database are authoritative, how recently the scan must have run, and who can approve an exception.

Gates should be staged. Early checks can be advisory to help developers learn; release and production checks can be blocking for high-risk conditions. Blocking every warning creates alert fatigue and encourages bypasses. Exceptions should be time-limited, documented, risk-assessed, and reviewed.

7. Artifact Provenance and Integrity

An artifact is a built output such as a package, binary, container image, or infrastructure bundle. Provenance is evidence about how, when, where, and from what inputs the artifact was produced. It may describe the source revision, build system, builder identity, parameters, dependencies, and timestamps.

Provenance answers questions such as:

• Did this artifact originate from the expected repository and revision?
• Was it built by an approved workflow?
• Were the inputs and builder identified?
• Has the artifact changed since it was built?
• Can the deployment platform verify these facts before release?

Cryptographic signing helps protect integrity and authenticity, but signing alone is not sufficient. If an attacker gains access to a legitimate signing process, the resulting malicious artifact may be validly signed. Trust must therefore include protected source control, isolated builders, restricted signing authority, reproducible or traceable builds, and verification at deployment.

A secure release chain commonly performs these steps:

1. A protected commit triggers an approved workflow.
2. The isolated builder retrieves pinned inputs.
3. Tests and security checks execute.
4. The builder generates the artifact and SBOM.
5. Provenance is recorded.
6. An authorised signing service signs the artifact and evidence.
7. A registry stores immutable content and metadata.
8. Deployment policy verifies signature, provenance, scan status, and environment rules.

This is a chain of evidence, not a guarantee of perfect security. Each link must be protected and monitored.

8. Designing a Secure CI/CD Pipeline

Consider a pipeline for a web application deployed as a container to a managed Kubernetes service. A practical design could use the following controls:

The pipeline should fail safely. If the vulnerability database is unavailable, the organisation must decide whether to block, permit with an explicit warning, or use a previously verified result. This decision depends on the risk of stale information and the criticality of the release; it should not be left to accidental tool behaviour.

Security metrics should measure outcomes rather than scanner volume. Useful indicators include the age of critical vulnerabilities, percentage of production artifacts with verified provenance, time to revoke exposed credentials, percentage of workloads using least-privilege identities, and the proportion of exceptions that are current and justified.

9. Illustrative Case: Northstar Health Portal

Background

Northstar Health, a fictional organisation, operates a patient appointment portal in the cloud. Its delivery team uses container images and a hosted CI/CD platform. Developers previously stored a third-party API token in a private repository because the application needed it during testing.

Problem

A compromised developer account allowed an attacker to read the repository history, including an old token. The token was still active. In addition, production images used mutable tags, and the organisation could not quickly determine which services included a vulnerable logging library. Security scans were performed manually before major releases and were frequently skipped for urgent fixes.

Analysis

The incident involved several control failures rather than one isolated mistake:

• a secret was stored in source history and had not been rotated;
• the token had broader permissions than the test application required;
• production images were not identified by immutable digest;
• no reliable SBOM inventory existed; and
• security checks were not integrated into the normal delivery path.

Approach and solution

Northstar revoked the exposed token, reviewed access logs, and issued a narrowly scoped replacement through a cloud secrets manager. The application received the secret at runtime using workload identity. Development and production credentials were separated.

The team then required image digests for deployment, generated an SBOM for each release image, and attached provenance to the build. A deployment policy rejected unsigned artifacts and images with unapproved critical findings. Secret scanning was added to pull requests and repository history. Exceptions required a security owner, a documented reason, and an expiry date.

The team also used a scheduled dependency-update process and rebuilt images regularly. Developers received feedback explaining how to correct findings, rather than only receiving a blocking error.

Outcome

Northstar could identify affected releases when a new library vulnerability was announced, revoke credentials without changing source code, and demonstrate that production artifacts originated from its approved build workflow. The new controls did not remove all risk: the organisation still needed to monitor runtime behaviour, assess scanner accuracy, and maintain its policy definitions.

Learning points

1. A private repository is not a secrets vault.
2. Inventory and provenance make incident response faster.
3. Least privilege limits the damage of credential compromise.
4. Automated controls are most effective when integrated with normal developer workflows.
5. Security gates require ownership, exception handling, and continuous maintenance.

10. Challenges, Governance, and Ethics

Security automation can create false positives, false negatives, delayed releases, and developer frustration. A vulnerable dependency may be difficult to upgrade because of compatibility constraints. A policy that blocks all findings without considering exploitability can cause unsafe workarounds. Conversely, excessive reliance on risk scoring can understate a severe issue in a sensitive context.

Governance should define ownership for vulnerabilities, secrets, policies, signing keys, and exceptions. Organisations should retain evidence proportionate to regulatory and contractual requirements, protect logs from unauthorised alteration, and limit access to security data. Secrets and vulnerability reports can themselves be sensitive information.

Privacy is relevant when scanning source code, logs, and developer activity. Monitoring should have a legitimate purpose, appropriate access restrictions, and retention limits. Automated decisions should be explainable enough for engineers to correct errors and appeal inappropriate blocks.

AI-assisted coding introduces additional supply-chain considerations. Generated code may contain insecure patterns, licences may be unclear, and prompts or retrieved context may expose confidential information. AI output should undergo the same review, testing, dependency analysis, and policy checks as human-authored code. AI tools should not receive production secrets merely because they assist with debugging.

Contemporary supply-chain security increasingly emphasises verifiable builds, signed attestations, trusted execution environments, dependency transparency, and continuous validation rather than one-time certification. Frameworks and standards evolve, but the underlying objective remains stable: establish justified confidence in what is built, how it was built, and what is allowed to run.

Best-Practice Checklist

• Treat all source, dependencies, builders, and pipeline inputs as security-relevant.
• Keep secrets out of source, images, logs, and artifacts.
• Prefer short-lived, narrowly scoped workload identities.
• Scan direct and transitive dependencies and production images.
• Generate a current SBOM for the artifact that is actually deployed.
• Use immutable digests and verify them at deployment.
• Sign artifacts and provenance with restricted signing identities.
• Enforce important controls through policy as code.
• Make exceptions explicit, owned, time-limited, and reviewable.
• Rescan, rotate, patch, monitor, and improve continuously.

Chapter Summary

DevSecOps embeds security across the software delivery lifecycle instead of postponing it until release. Least privilege reduces the impact of compromised users, workloads, and pipeline identities. Secrets require controlled creation, storage, distribution, use, rotation, and revocation; they should not be placed in source repositories or images. Dependency and image scanning provide valuable evidence but must be interpreted in context. SBOMs create a structured inventory for vulnerability response, licensing, and assurance, yet they are not proof that software is secure. Policy as code converts requirements into repeatable decisions, while artifact signatures and provenance help establish where an artifact came from and how it was built. Effective supply-chain security combines these practices with governance, exceptions, monitoring, and continuous improvement.

Key Terms

DevSecOps: An approach that integrates security into development, delivery, and operations.

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

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

Secrets manager: A controlled service for storing, delivering, auditing, and rotating secrets.

Workload identity: An identity assigned to an application or automated workload.

Software composition analysis: Examination of software dependencies for vulnerabilities, licences, and inventory.

Transitive dependency: A component required indirectly through another dependency.

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

Image digest: A content-derived identifier for a specific image version.

SBOM: A structured inventory of software components and their relationships.

Policy as code: Machine-readable rules evaluated automatically by tools or platforms.

Artifact: A build output such as a package, binary, or image.

Provenance: Evidence describing an artifact’s origin, inputs, and build process.

Attestation: A signed statement about an artifact or process.

Artifact signing: Applying a cryptographic signature to support integrity and authenticity verification.

Immutable artifact: An artifact whose referenced content cannot be silently replaced.

Exception: An authorised, documented deviation from a security rule.

Supply-chain attack: An attack that compromises software, tools, dependencies, or delivery processes.

Review Questions

Short Answer Questions

1. What is the primary purpose of DevSecOps?
2. Why is a private source-code repository not an adequate secrets vault?
3. State two dimensions of least privilege.
4. What information does an SBOM provide?
5. Why are mutable image tags risky in production?

Long Answer Questions

1. Explain how security controls can be distributed across the CI/CD lifecycle.
2. Describe the lifecycle of a secret from creation through revocation.
3. Compare dependency scanning, container-image scanning, and SBOM generation.
4. Explain how policy as code can improve both security and delivery consistency.
5. Discuss why artifact signatures alone do not guarantee a trustworthy software supply chain.

Analytical / Application Questions

1. A build pipeline uses one administrator credential to read source, publish images, and deploy to production. Identify the risks and propose a least-privilege redesign.
2. A critical vulnerability is detected in a transitive dependency, but the application does not appear to use the affected function. What evidence should the team examine before deciding whether to block release?
3. Design a secure release path for a containerised application that includes secrets management, image scanning, an SBOM, provenance, signing, and deployment policy verification.

Multiple Choice Questions with Answers

Question 1

Which statement best describes DevSecOps?

A. Security is performed only after deployment

B. Security responsibilities and controls are integrated throughout the delivery lifecycle

C. Only security specialists are responsible for security

D. All software releases require manual approval

Correct Answer: B. Security responsibilities and controls are integrated throughout the delivery lifecycle

Question 2

Which practice most directly implements least privilege for a CI job that only compiles source code?

A. Give the job administrator access to the cloud account

B. Give the job read access to required source and no production deployment permission

C. Reuse the production deployment credential

D. Store a permanent root key in the repository

Correct Answer: B. Give the job read access to required source and no production deployment permission

Question 3

Which item is a secret?

A. A public package version

B. A database password

C. A source-code comment

D. A public container tag

Correct Answer: B. A database password

Question 4

What is the main purpose of an SBOM?

A. To encrypt all application data

B. To list the software components contained in a product

C. To replace vulnerability scanning

D. To deploy containers automatically

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

Question 5

Why is a container image digest preferable to a mutable tag for production deployment?

A. A digest identifies specific content

B. A digest automatically removes vulnerabilities

C. A digest grants administrator privileges

D. A digest stores application secrets securely

Correct Answer: A. A digest identifies specific content

Question 6

Which statement about a vulnerability scan is most accurate?

A. Every reported vulnerability is automatically exploitable

B. A scan proves that an application is secure

C. Findings require contextual assessment and response

D. Scanning removes the need for patching

Correct Answer: C. Findings require contextual assessment and response

Question 7

What does provenance primarily describe?

A. The visual design of an application

B. How and from which inputs an artifact was produced

C. The number of users of a service

D. The encryption algorithm used for passwords

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

Question 8

Which control best protects a production signing key?

A. Placing it in a public code sample

B. Sharing it among all developers

C. Using a restricted signing service with audited access

D. Printing it in build logs

Correct Answer: C. Using a restricted signing service with audited access

Question 9

What is a sound characteristic of a security exception?

A. It is permanent and undocumented

B. It has an owner, justification, and expiry date

C. It bypasses all future reviews

D. It is granted automatically for urgent changes

Correct Answer: B. It has an owner, justification, and expiry date

Question 10

Which sequence best represents secure artifact handling?

A. Build, generate evidence, sign, verify at deployment

B. Deploy, then scan the source repository

C. Store secrets in the image, then publish it

D. Use a mutable tag and skip provenance

Correct Answer: A. Build, generate evidence, sign, verify at deployment