Pipeline Security and DevSecOps

Introduction and context

Continuous integration and continuous delivery (CI/CD) make software delivery faster and more repeatable, but they also create a highly privileged path into source-code repositories, build systems, registries, cloud accounts, and production environments. A compromised pipeline can alter software without changing the application repository, expose credentials, or distribute malicious packages to many customers. Pipeline security is therefore not an optional addition to DevOps; it is a central part of software assurance.

DevSecOps is the integration of security responsibilities, controls, and evidence throughout the software delivery lifecycle. It does not mean that developers become security specialists or that every delivery is blocked by manual approval. It means that security requirements are expressed as code and policy, automated where possible, reviewed by appropriate people, and continuously improved using evidence.

A secure pipeline should answer four questions:

1. Who or what is requesting an action?
2. What is that identity allowed to do?
3. What evidence shows that the software was examined and produced from an approved source?
4. Can the organization detect, contain, and recover from compromise?

This chapter develops a practical security model for diploma-level cloud and DevOps practice. It covers identity and least privilege, secrets, code and dependency analysis, containers, software bills of materials (SBOMs), artifact signing, threat modelling, and supply-chain security.

Learning objectives

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

• explain why CI/CD pipelines are high-value security targets;
• apply identity, access-control, and least-privilege principles to pipeline design;
• distinguish secret storage, secret delivery, rotation, and revocation;
• describe the roles of SAST, DAST, dependency scanning, container scanning, and SBOMs;
• explain how provenance and signed artifacts strengthen software supply-chain security;
• create a basic threat model for a pipeline;
• design security gates that balance risk, delivery speed, and developer usability;
• evaluate governance, ethical, and operational limitations of automated security controls.

1. The pipeline as a security boundary

A pipeline is a chain of systems rather than a single tool. A typical flow is:

Figure: Security controls applied across a software delivery pipeline.

The pipeline has a larger attack surface than the application alone. Threats include a stolen developer token, malicious pull-request code, a vulnerable third-party action, a poisoned package, an exposed build log, a compromised self-hosted runner, and an artifact registry with weak access controls. Build outputs may also be deployed to several environments, multiplying the effect of one mistake.

Security objectives can be expressed using confidentiality, integrity, and availability. Confidentiality protects credentials and proprietary code. Integrity ensures that source, dependencies, build processes, and artifacts are not altered improperly. Availability protects the ability to build and deploy, while avoiding security controls so restrictive that legitimate engineering work becomes impossible. Traceability and non-repudiation are additional objectives: an organization should be able to determine what was built, from which source, by which process, and under whose authorization.

2. Identity, authentication, and least privilege

Human and machine identities

A pipeline includes human identities, service accounts, workload identities, repository applications, runners, registries, cloud roles, and deployment controllers. Each should have a distinct identity. Shared accounts obscure responsibility and make revocation difficult.

Authentication establishes identity; authorization determines permitted actions. Multi-factor authentication should protect developer, administrator, source-control, cloud, and registry accounts. For workloads, short-lived identity federation is preferable to long-lived static credentials. For example, a CI job can exchange a trusted, time-limited identity token for a cloud role only when it is running from an approved repository and branch.

Least privilege

Least privilege grants only the permissions required for a task, for the shortest practical time, to the narrowest scope. A test job normally needs read access to source and dependencies, but not permission to delete production databases. A deployment job may need to update one service in one environment, but not create arbitrary users in the cloud account.

Useful design practices include:

• separate build, test, release, and deployment identities;
• use read-only tokens for jobs that do not modify resources;
• restrict permissions by repository, environment, branch, and action;
• require explicit approval for production deployment;
• prevent untrusted pull requests from accessing production secrets;
• use ephemeral runners or destroy runners after sensitive jobs;
• review permissions periodically and after role changes;
• log authentication, authorization, privilege changes, and administrative actions.

A permission matrix makes excessive access visible:

Authorization is not secure merely because a role is named “deploy.” The actual actions, resources, conditions, and duration must be examined.

3. Secret management

Secrets include passwords, API keys, private keys, tokens, certificates, database credentials, and encryption material. A secret committed to source control remains a risk even after deletion because it may survive in history, forks, caches, or backups.

A robust secret-management lifecycle has five activities:

1. Creation: generate strong, unique credentials using an approved system.
2. Storage: place them in a dedicated secret manager or hardware-backed key service, not in source files or pipeline definitions.
3. Delivery: inject them at runtime with the narrowest scope and shortest lifetime.
4. Rotation: replace them on a schedule and after suspected exposure.
5. Revocation and audit: invalidate old values and record access.

Secret values should be masked in logs, but masking is not a complete defence. A job may encode, transform, or exfiltrate a value without printing it directly. Therefore, untrusted code should not run in a context that can access sensitive secrets. Pull requests from external contributors require particular care because their build instructions may execute arbitrary code.

Encryption at rest and in transit protects storage and transport, but it does not protect a secret while it is available to a malicious process. Workload identity, dynamic credentials, per-environment secrets, and secretless connections can reduce exposure. Scanning tools can detect likely secrets in commits, but they produce false positives and cannot replace prevention and rapid revocation.

4. Security testing in the pipeline

No single scanner detects every vulnerability. Effective DevSecOps combines controls that examine different representations and stages of the system.

Static application security testing (SAST)

SAST analyzes source code or an intermediate representation without executing the application. It can identify insecure input handling, injection risks, unsafe cryptography, hard-coded credentials, and authorization mistakes. SAST is most useful early in development, where feedback is cheap. Its limitations include false positives, incomplete framework understanding, and inability to observe runtime configuration or actual deployment behaviour.

A mature SAST process uses secure coding rules appropriate to the language, baseline management for known findings, developer-friendly explanations, and risk-based thresholds. A critical finding in changed code may block a merge, while an older, accepted finding may be tracked with an owner and due date.

Dynamic application security testing (DAST)

DAST tests a running application from an external perspective. It can discover exposed endpoints, weak headers, authentication failures, and some injection vulnerabilities. It requires a realistic test environment and test data. It may miss code paths that the tests do not exercise and can damage systems if run against production without authorization. Rate limits, test accounts, and an isolated environment are essential.

Dependency and software composition analysis

Modern applications depend on libraries, transitive packages, build plugins, container bases, and external actions. Dependency scanning compares component names and versions with vulnerability intelligence. It may also detect license obligations and outdated components.

A finding is not automatically exploitable. Assessment should consider whether the vulnerable function is reachable, whether configuration enables the weakness, whether a patch exists, and the importance of the affected asset. Nevertheless, organizations should not dismiss a finding solely because exploitation has not yet been observed.

Pinning versions and recording integrity hashes improves reproducibility. Updates should be automated where safe, tested, and reviewed. Dependency confusion is a notable supply-chain threat: a malicious public package with the same name as an internal package may be selected if repository precedence is poorly configured.

Container and infrastructure scanning

Container scanning examines image layers, operating-system packages, application dependencies, configuration, and sometimes runtime behaviour. Good practice includes using minimal trusted base images, removing compilers and package managers from production images when possible, running as a non-root user, setting a read-only filesystem where feasible, and rebuilding images rather than manually patching running containers.

Infrastructure-as-code scanning detects insecure cloud or orchestration configurations, such as public storage, unrestricted network rules, excessive permissions, or missing encryption. It should be complemented by policy controls at deployment time because a secure template can be overridden later.

Security gates and risk-based decisions

A gate is a condition that must be satisfied before a pipeline proceeds. Examples include “no critical vulnerabilities in the release image,” “all production artifacts have verified provenance,” or “a deployment to production has two-person approval.” Gates should be explicit, version-controlled, explainable, and measurable.

Blocking on every warning causes alert fatigue and encourages bypasses. A practical policy classifies findings by severity, exploitability, asset criticality, exposure, and remediation availability. Exceptions require justification, an accountable owner, an expiry date, and compensating controls. Security gates should fail safely: a scanner outage should not silently convert a required control into an unrecorded bypass.

5. SBOMs, provenance, and signed artifacts

An SBOM is a machine-readable inventory of software components and their relationships. It can include direct and transitive dependencies, versions, suppliers, licenses, hashes, and package identifiers. Common formats include SPDX and CycloneDX. An SBOM supports vulnerability response, license management, asset inventory, and customer transparency, but it is not itself proof that software is safe.

An SBOM should be generated from the actual build output, retained with the release, and updated when the artifact changes. Organizations need processes for matching component identifiers accurately and responding when vulnerability intelligence changes.

Provenance describes how an artifact was produced: source revision, build definition, builder identity, parameters, dependencies, and timestamps. Reproducible or independently verifiable builds strengthen confidence, although complete reproducibility can be difficult for systems involving timestamps, network retrieval, or nondeterministic compilation.

Digital signatures provide evidence that a holder of a private key signed a particular object. Verification requires a trusted public key, certificate or trust policy, and protection against key compromise. Signing an artifact does not prove that its contents are secure; it proves that the artifact is associated with a signing identity under the stated trust model.

A secure release process commonly performs the following:

• build from a protected, reviewed commit;
• resolve dependencies from approved sources;
• generate test results and an SBOM;
• scan source, dependencies, image, and configuration;
• record provenance;
• sign the artifact and associated metadata using a protected key;
• store the artifact immutably or with controlled retention;
• verify signature, provenance, policy, and vulnerability status at deployment.

Key compromise requires a recovery plan: revoke or rotate keys, identify affected artifacts, update trust policies, and determine whether previously signed releases must be rebuilt.

6. Threat modelling a CI/CD pipeline

Threat modelling is a structured method for anticipating misuse before incidents occur. A useful workflow is:

1. define scope and security objectives;
2. draw data flows and trust boundaries;
3. identify assets and actors;
4. enumerate threats;
5. estimate risk and prioritize mitigations;
6. record assumptions, owners, and residual risk;
7. review the model when architecture or threats change.

STRIDE is one practical mnemonic: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Supply-chain analysis may additionally examine dependency substitution, compromised maintainers, malicious build steps, and trust-policy errors.

For each threat, a simple qualitative risk statement can be used:

Likelihood and impact are ordinal ratings, such as 1 to 5, rather than physical measurements. The multiplication is a prioritization heuristic, not a probability law. It assumes that the organization has defined consistent rating scales and uses the result to compare threats within the same assessment. For example, a threat rated likelihood 4 and impact 5 has a priority score of 20; a threat rated 2 and 3 scores 6. The first receives attention earlier, but the numbers do not establish that it is exactly 3.33 times more probable or damaging.

A pipeline threat model should ask: Can untrusted code reach a privileged runner? Can a build modify a release tag? Can an attacker substitute an artifact after scanning? Can a developer approve their own high-risk change? Can logs disclose secrets? Can an external action change without review? Controls should be linked to these questions rather than added because a tool is fashionable.

7. Software supply-chain security

Supply-chain security extends beyond an organization’s own code. It includes source-control providers, CI platforms, third-party actions, package repositories, base images, signing services, cloud APIs, and contractors. A useful principle is to minimize implicit trust. Pin third-party actions to reviewed immutable references where possible, use allow-lists for registries, verify checksums or signatures, and monitor changes in build dependencies.

The software supply-chain framework can be understood through four properties:

• Identity: the source, builder, publisher, and deployer are identifiable.
• Integrity: source, dependencies, build instructions, artifacts, and metadata resist unauthorized change.
• Provenance: the organization can explain how an artifact was produced.
• Policy: deployment accepts only artifacts meeting declared requirements.

A secure build service should be isolated from arbitrary network access where feasible, use ephemeral workers for sensitive jobs, restrict outbound connections, and preserve tamper-evident logs. Self-hosted runners require patching, hardening, segmentation, and careful cleanup because a compromised runner may retain credentials or workspace data.

8. Illustrative case: securing a cloud payments pipeline

Background

A fictional company, Northstar Payments, operates a containerized payment API on a managed Kubernetes service. Its original pipeline uses a shared cloud key, a long-lived registry password, unpinned third-party actions, and a single “tests passed” gate. It has no SBOM and deploys images by mutable tag.

Problem

A developer discovers that a pull-request job can print environment variables. A dependency scanner also reports a critical vulnerability in a transitive package. The team cannot determine which production images contain the package or whether a deployed image corresponds to reviewed source.

Analysis

The shared key gives build jobs excessive permissions. Because external pull requests run on privileged runners, an attacker could steal credentials. Mutable tags allow an image to change after approval. The absence of an SBOM makes impact analysis slow, while the single gate conceals which security properties are actually being tested.

Approach and solution

Northstar separates identities for testing, image publication, signing, and deployment. Pull-request jobs receive no production secrets and run on ephemeral, restricted runners. Cloud access uses short-lived workload federation, with a role limited to reading dependencies and writing candidate images. Production deployment uses a separate role restricted to the payment namespace.

The pipeline pins external actions to reviewed immutable references, uses an approved dependency proxy, and runs SAST, dependency, image, and infrastructure-as-code scans. It generates a CycloneDX SBOM from the final image, records source and builder provenance, signs the image digest and metadata, and deploys by immutable digest rather than mutable tag. A policy controller verifies the signature, trusted builder, SBOM presence, and severity threshold before admission.

The vulnerability policy blocks new critical findings with an available fix and requires a documented exception for accepted high findings. DAST runs in an isolated staging environment using synthetic payment data. Logs are centralized, access is audited, and a playbook covers credential revocation and signing-key rotation.

Outcome

The company can identify affected releases from the SBOM, prevent untrusted images from entering production, and limit the impact of a compromised pull-request job. Delivery becomes slightly slower because of scanning and approval, but most checks are automated and parallelized. The organization also gains evidence for customer assurance and incident response.

Learning points

The case demonstrates that no single scanner solved the problem. Identity separation reduced blast radius; ephemeral credentials reduced persistence; signatures and provenance improved trust decisions; SBOMs improved visibility; and policy made controls enforceable. Security improvements were strongest when integrated into the delivery design rather than added as a final manual inspection.

9. Governance, ethics, and operational limitations

Security automation affects people and organizations. Excessive monitoring can expose developer activity or personal data. Logs should collect what is necessary, protect access, define retention periods, and comply with applicable privacy and employment requirements. Vulnerability disclosure should be handled responsibly, with coordinated communication rather than blame.

Security tools can encode bias through incomplete vulnerability databases, language-specific coverage, or rules that penalize certain teams more than others. Developers need appeal and exception processes, clear remediation guidance, and training. A critical finding should not automatically justify unsafe emergency workarounds; nor should compliance evidence replace engineering judgment.

Organizations should define ownership using a shared-responsibility model. Platform teams secure runners and common controls; development teams fix application and dependency issues; security teams maintain policy, threat intelligence, and assurance; service owners accept residual risk. Responsibilities must be documented because a control without an owner is likely to fail.

Metrics should measure outcomes rather than tool activity. Useful indicators include time to remediate exploitable vulnerabilities, percentage of releases with verified provenance, percentage of privileged credentials that are short-lived, number of unreviewed exceptions, and recovery time after credential compromise. Counting raw scanner findings can reward teams for producing noise rather than reducing risk.

10. Implementation guidance and contemporary developments

A sensible adoption sequence is:

1. inventory repositories, pipelines, identities, registries, and production targets;
2. protect administrator accounts with MFA and remove shared credentials;
3. classify environments and secrets;
4. isolate runners and restrict permissions;
5. add secret detection and dependency scanning;
6. add SAST, image, infrastructure, and controlled DAST testing;
7. generate SBOMs and retain scan evidence;
8. sign artifacts and verify them at deployment;
9. formalize threat modelling, exceptions, incident response, and metrics.

Artificial intelligence can assist with code review, alert triage, test generation, and explanation of findings. It must not be treated as an authoritative security assessor. Generated code may contain vulnerabilities, models may omit relevant context, and prompts or source code may disclose confidential information to an external service. AI-based pipeline actions require access restrictions, human review for consequential decisions, provenance of generated outputs, and testing against prompt injection and data leakage.

Emerging practices include policy-as-code, confidential build environments, stronger artifact attestations, automated dependency updates, and continuous verification at deployment. These developments are valuable when they support a clear trust model. They do not eliminate the need for secure design, competent review, patch management, and recovery planning.

Chapter Summary

Pipeline security treats the CI/CD system as a privileged production asset and applies security throughout the software lifecycle. Identity controls establish accountable human and machine access; least privilege limits blast radius; short-lived secrets and workload federation reduce credential exposure. SAST, DAST, dependency analysis, container scanning, and infrastructure scanning examine different risk surfaces and must be combined with risk-based gates.

SBOMs provide component visibility, while provenance explains how software was built. Digital signatures connect artifacts to trusted identities, but verification depends on protected keys and explicit trust policies. Threat modelling identifies assets, trust boundaries, abuse cases, and mitigations before incidents occur. Supply-chain security further requires control of dependencies, build services, actions, registries, runners, and deployment policy.

Effective DevSecOps is not the indiscriminate addition of tools. It is an accountable operating model in which controls are automated where reliable, reviewed where necessary, measurable, privacy-aware, and connected to incident response.

Key Terms

Identity: An identifiable human, service, workload, or system principal.

Authentication: Verification of the identity claiming access.

Authorization: Determination of what an authenticated identity may do.

Least privilege: Granting only the minimum necessary access for the minimum practical time.

Secret: Sensitive information such as a password, token, private key, or certificate.

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

SAST: Static application security testing performed without executing the application.

DAST: Dynamic application security testing performed against a running application.

Dependency scanning: Analysis of direct and transitive software components for vulnerabilities or license issues.

Container scanning: Examination of container images, layers, packages, and configuration for weaknesses.

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

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

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

Digital signature: Cryptographic evidence associating an object with a signing identity.

Threat modelling: Structured identification and treatment of threats to a system.

Trust boundary: A point where assumptions about authority, control, or trust change.

Supply-chain security: Protection of code, dependencies, tools, builders, artifacts, and delivery services.

Policy-as-code: Machine-readable rules that automatically evaluate or enforce security requirements.

Software attestation: Signed or otherwise verifiable evidence about an artifact or build process.

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

Review Questions

5 Short Answer Questions

1. Why is a CI/CD pipeline a high-value security target?
2. Distinguish authentication from authorization.
3. What are the main stages in a secret’s lifecycle?
4. What information does an SBOM provide?
5. Why should production deployments use immutable artifact digests where possible?

5 Long Answer Questions

1. Explain how least privilege should be applied to build, test, signing, and deployment identities.
2. Compare SAST, DAST, dependency scanning, and container scanning, including the limitations of each.
3. Explain how provenance and digital signatures contribute to software supply-chain security.
4. Describe a threat-modelling process for a pipeline using trust boundaries and the STRIDE categories.
5. Discuss why security gates should be risk-based rather than blocking every scanner warning.

3 Analytical / Application Questions

1. Design a permission matrix for a pipeline that builds a container, publishes it to a registry, signs it, and deploys it to staging and production.
2. A pull-request job from an external contributor can access a cloud token. Identify the threats, prioritize the risks, and propose layered controls.
3. A production image has a critical vulnerability, but the vulnerable library is not reachable by the application. Decide whether deployment should proceed and specify the evidence, exception process, and compensating controls required.

Multiple Choice Questions with Answers

Question 1

Which control most directly limits the damage caused by a compromised build job?

A. Least-privilege, job-specific permissions

B. A larger build runner

C. A longer log-retention period

D. A mutable image tag

Correct Answer: A. Least-privilege, job-specific permissions

Question 2

What is the primary purpose of SAST?

A. Testing a running service from outside

B. Analyzing source code or an intermediate representation

C. Signing a container image

D. Inventorying cloud accounts

Correct Answer: B. Analyzing source code or an intermediate representation

Question 3

Which practice best protects an external pull-request job?

A. Give it production credentials for realistic testing

B. Run it with no sensitive secrets on an isolated runner

C. Allow it to modify release tags

D. Use a shared administrator account

Correct Answer: B. Run it with no sensitive secrets on an isolated runner

Question 4

What does an SBOM primarily provide?

A. A guarantee that software is vulnerability-free

B. A list of software components and their relationships

C. A replacement for access control

D. A private encryption key

Correct Answer: B. A list of software components and their relationships

Question 5

What does a digital signature on an artifact establish under its trust model?

A. That the artifact contains no vulnerabilities

B. That the artifact is associated with the signing identity

C. That every dependency is open source

D. That the artifact was tested in production

Correct Answer: B. That the artifact is associated with the signing identity

Question 6

Which statement correctly distinguishes DAST from SAST?

A. DAST examines a running application; SAST examines code without execution

B. DAST inventories packages; SAST rotates secrets

C. DAST signs artifacts; SAST deploys containers

D. DAST is performed only on source comments

Correct Answer: A. DAST examines a running application; SAST examines code without execution

Question 7

A threat has a likelihood rating of 4 and an impact rating of 5. Using the chapter’s prioritization heuristic, what is its score?

A. 9

B. 20

C. 25

D. 45

Correct Answer: B. 20

Question 8

Why is deploying by an immutable image digest safer than deploying by a mutable tag?

A. It makes the image smaller

B. It ensures the referenced content cannot silently change under the same identifier

C. It removes the need for scanning

D. It automatically encrypts the application

Correct Answer: B. It ensures the referenced content cannot silently change under the same identifier

Question 9

Which item is most appropriate in a documented vulnerability exception?

A. No owner and no expiry date

B. A justification, accountable owner, expiry, and compensating controls

C. A request to ignore all future scanner results

D. A deletion of the vulnerability record

Correct Answer: B. A justification, accountable owner, expiry, and compensating controls

Question 10

What is the main purpose of artifact provenance?

A. To describe how and from which inputs an artifact was produced

B. To replace multi-factor authentication

C. To conceal dependency versions

D. To authorize every developer as an administrator

Correct Answer: A. To describe how and from which inputs an artifact was produced