# Put software-supply-chain checks inside the CI/CD path > A CI/CD pipeline carries source through build, test, package, and deployment operations. Protect each transition, identity, dependency, artifact, approval, and evidence record in the path. - Canonical URL: https://update.dsesecurity.com/updates/ci-cd-software-supply-chain-controls/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:04+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know A CI/CD pipeline carries source through build, test, package, and deployment operations. Protect each transition, identity, dependency, artifact, approval, and evidence record in the path. ## Potentially affected Organizations using automated continuous integration or deployment to build, test, package, promote, or deploy software and infrastructure changes. ## DSE recommendation Model the pipeline as a production supply chain, constrain its identities and inputs, verify artifact transitions, separate promotion authority where justified, and retain evidence that connects source to deployment. ## Article Bottom line: a deployment pipeline is not just an efficiency tool. It is a chain of privileged operations that converts source and dependencies into an artifact and then changes production. Security checks are strongest when they are part of those transitions and leave verifiable evidence. ## Source fact: what NIST addresses [NIST SP 800-204D](https://csrc.nist.gov/pubs/sp/800/204/d/final) describes continuous integration and continuous deployment pipelines as flow processes that move software through stages such as build, test, package, and deploy. NIST treats these operations as part of the software supply chain and outlines strategies for integrating supply-chain security measures into CI/CD pipelines, particularly in cloud-native DevSecOps environments. The source supports evaluating the path as a system rather than treating a source repository or final scanner as the whole supply chain. ## What the source does not establish The publication does not certify a pipeline product or define a universal set of mandatory tools. Automation does not establish integrity by itself: a fast, repeatable process can reproduce a compromised input or over-privileged change. A generated bill of materials, signature, or scan report is only useful when its origin, scope, verification, and decision role are understood. Applicability depends on the development model, artifact types, deployment targets, supplier inputs, secrets, signing or attestation mechanisms, and the consequences of unauthorized or erroneous release. ## Applicability questions - Which sources, dependencies, build images, actions, plugins, and external services can influence the artifact? - Which human and machine identities can change pipeline logic, approve promotion, publish artifacts, or deploy? - What immutable information connects source, inputs, build execution, test results, artifact, and deployment? - Which findings block movement, and who can approve a bounded exception? - Can the organization stop, revoke, or roll back a release if the pipeline or an input is later questioned? ## DSE recommendation: secure each transition The following steps are DSE recommendations based on the cited source. - Diagram stages, trust boundaries, inputs, outputs, identities, stores, external calls, approvals, and production destinations. Include infrastructure-as-code and administrative pipelines. - Pin and review executable dependencies such as build images, pipeline actions, plugins, and package sources. Record authorized provenance and update ownership. - Use narrowly scoped automation identities and short-lived credentials where supported. Separate the ability to change the pipeline from the ability to approve or perform consequential promotion when risk warrants it. - Generate and protect evidence at each stage: source revision, resolved dependencies, build environment, test results, artifact digest, approval, promotion, and deployment result. - Verify artifacts when they cross a trust boundary. Define what happens when provenance, integrity, policy, or required evidence cannot be validated. - Rehearse containment: pause the path, revoke a credential or artifact, locate deployments, restore a known release, and preserve logs for investigation. ## Verification and evidence Trace one deployed release backward to an immutable artifact, build execution, exact source and dependencies, tests, policy decisions, identities, and approvals. Then sample a denied unapproved change and a rollback. Record any stage that depends on mutable labels, shared credentials, or evidence outside retention. ## Official references - [NIST SP 800-204D — Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines](https://csrc.nist.gov/pubs/sp/800/204/d/final) — National Institute of Standards and Technology; published February 2024 - [NIST SP 800-218 — Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) — National Institute of Standards and Technology ## Primary reference - Name: NIST SP 800-204D — Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/204/d/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Put software-supply-chain checks inside the CI/CD path,” DSE Security, https://update.dsesecurity.com/updates/ci-cd-software-supply-chain-controls/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.