Zero trust in CI/CD means verifying each person, service, input, build step, artifact, and deployment request before granting access or accepting its output. A trusted network, repository, or successful login is not enough: control access by identity and purpose, verify integrity across handoffs, and keep checking after release. NIST provides adaptable guidance for building those controls, not a prescribed tool stack or a guarantee that any one product achieves zero trust.
What does zero trust mean in a CI/CD pipeline?
NIST SP 800-207, Zero Trust Architecture (2020), centers protection on resources rather than network segments. It says location or asset ownership alone should not create implicit trust; subjects and devices should be authenticated and authorized before access to enterprise resources. Applied to CI/CD, that means considering not only developers but also automation, runners, repositories, build tools, dependencies, artifact stores, deployment identities, and the systems they reach.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
Security as Code: DevSecOps Patterns with AWS | $39.73 | Buy on Amazon |
| 2 |
|
Security as Code: DevSecOps Patterns with AWS | $41.82 | Buy on Amazon |
Trust is specific to an action and resource. A build identity may need permission to read one repository and publish a particular artifact, but not to change repository settings or deploy to production. A successful authentication establishes who or what is making a request; authorization determines whether that actor may perform that action. Integrity checks and policy decisions then help determine whether the resulting input, build, or artifact is acceptable for the next handoff.
NIST SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines (February 2024), frames the work around defending the pipeline and build processes while protecting the integrity of upstream sources and artifacts. Its central practical implication is that trust must be re-established as work moves between pipeline components, rather than assumed from the initial login or repository boundary.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
Which identities and resources should you protect?
Start with an inventory of both human and machine actors, the resources they use, and the actions they need. Include the evidence used to approve changes and releases: test results, vulnerability findings, signatures, provenance, and attestations are themselves inputs to security decisions and should have identifiable origins.
| Actor or resource | Questions to answer |
|---|---|
| People | Which developers, reviewers, maintainers, and operators can read, change, approve, or deploy? |
| Automation | Which workflow, runner, build service, or deployment identity is acting, and what is it allowed to do? |
| Code and configuration | Who can change application code, infrastructure as code, policy as code, and pipeline configuration? What review or validation is required? |
| Build inputs | Where do dependencies and build tools come from, and how can their versions and integrity be checked? |
| Outputs and evidence | Where are artifacts and security results stored? Which identity produced them, and what evidence is required before they can be consumed or deployed? |
| Targets and secrets | Which environments, services, and credentials can an actor reach? Are access rights limited to the task and environment? |
For cloud-native services, NIST SP 800-207A (September 2023) extends the identity focus to application and service identities as well as users and networks. It discusses components such as API gateways, sidecar proxies, and application identity infrastructure including SPIFFE as possible ways to enforce policy across on-premises and multi-cloud environments. These are architectural options for relevant systems, not a requirement that every CI/CD pipeline adopt a service mesh.
How do you apply zero trust across the delivery lifecycle?
The following lifecycle view translates NIST guidance into decisions teams can make at each handoff. It is a practical organization of controls, not a mandatory NIST architecture. The NCCoE reference model spans planning through operation and includes security, monitoring, and feedback throughout.
| Stage | Control focus | Evidence or decision |
|---|---|---|
| Planning | Define requirements for application code, infrastructure as code, policy as code, and configuration. Assign ownership for pipeline roles and approval rules. | Documented requirements and authorization policy. |
| Development | Protect source-control settings and review changes, including dependency updates. Scan for leaked secrets and assess dependency vulnerabilities before merge. | Reviewed change and relevant source or dependency checks. |
| Build | Harden and isolate execution environments, scope runner permissions, control access to credentials, and verify expected inputs and outputs for each build step. | Build records tied to an authorized workflow and its inputs. |
| Test | Run appropriate automated analysis, which may include static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA). | Test and vulnerability evidence evaluated against organizational policy. |
| Release | Protect artifacts and signing credentials; verify artifact integrity and evidence of origin. | Artifact accepted only if it meets release policy and came from an approved process. |
| Deployment | Check authorization for the target environment and evaluate artifact evidence, including the freshness of vulnerability findings where policy requires it. | Deployment decision with a documented exception route. |
| Operation | Monitor deployed systems and policy violations, verify running software as appropriate, and feed findings into remediation and future development. | Operational signals inform response and updated controls. |
The examples of SAST, DAST, and SCA are categories of function-specific tools identified by NIST, not a requirement to purchase particular products. Choose checks according to the system, threat model, and risk, and define what result allows work to proceed.
Recommended Free Tools
How should you secure runners and untrusted pull requests?
Harden the execution environment
Reduce the attack surface of build and test environments, assign explicit roles to pipeline actors, and grant task-level permissions instead of broad standing access. The runner should receive only the credentials, network reach, and capabilities required for its job. Where practical, use ephemeral build and test environments so a job does not inherit state from unrelated work; the NIST NCCoE model includes ephemeral environments as an implementation pattern.
Separate external contributions from privileged workflows
Code from an external pull request is not safe merely because it is hosted in a trusted repository. NIST SP 800-204D describes two approaches: run such workflows in sandboxes without network, privileged, or secret access, or delay execution until a maintainer with write access approves it. Choose a policy that prevents untrusted code from obtaining credentials or using a privileged runner before it is trusted.
Limit credential exposure
Keep secrets and signing keys available only to authorized workflows and actors, and define which identity can issue trusted build evidence. NIST’s reference model includes credential and secrets management and hardware or virtual hardware security modules as possible components; it does not require one particular implementation. The essential policy question is who or what may use a credential, for which task, and under what conditions.
How can you verify code, dependencies, and artifact origin?
Control and identify inputs
Restrict who can alter repositories and pipeline definitions, review dependency risk, and use controlled sources for tools and packages. The NCCoE reference model gives pinned dependencies identified by immutable values such as cryptographic hashes and internal repositories as implementation examples. These practices help make the inputs to a build identifiable and reduce the chance that a name or mutable location silently resolves to different content.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteCheck each handoff
For every build step, determine whether the expected component or identity handled the expected inputs and produced the expected outputs. Verify repository and artifact integrity as material moves through storage and release stages. NIST SP 800-204D explicitly treats trust establishment as recurring because artifacts travel through multiple repositories before becoming a final product.
Rank #2
Require evidence proportionate to risk
Collect the evidence needed to support your decisions, which may include build records, tests, vulnerability results, signatures, provenance, and attestations. Set a policy for which evidence is required, who can produce or approve it, and how old it may be at deployment. Require evidence that deployed artifacts came from an approved build process, and use recent vulnerability scan evidence where it is relevant to the release decision.
SP 800-204D does not recommend a specific SBOM, signing, or attestation standard; it notes that specifications were still evolving when the publication appeared in February 2024. Select formats and verification methods that your organization can produce, validate, and maintain rather than treating a format name as proof of trust.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How do you gate deployment and keep checking after release?
Translate security requirements into explicit release and deployment policies. A policy can evaluate whether the artifact came from an approved workflow, whether required checks completed, whether integrity evidence validates, and whether vulnerability evidence satisfies the organization’s freshness and severity rules. Apply the decision at the relevant merge, build, release, or deployment point; a check that only reports a problem without affecting an approval decision is not an enforced gate.
Define an exception path before it is needed: who can approve an exception, what justification and compensating controls are required, and how the decision is recorded and reviewed. A gate without a controlled exception process can encourage informal bypasses; an exception should not silently change the normal policy.
Trust does not end at deployment. Monitor operational and security signals, investigate policy violations and vulnerabilities, and feed findings back into source review, build controls, and release policy. NIST’s NCCoE model includes runtime signature verification and continuous monitoring as reference-model activities, not universal requirements for every architecture.
How should you roll out the controls?
NIST SP 800-204D notes that implementation may not be adopted all at once without business disruption and operational cost. Use a staged plan suited to your architecture, threat model, and risk tolerance; the sequence below is a practical synthesis of NIST guidance, not a NIST-prescribed maturity model.
- Map actors and resources. Inventory human and automated identities, repositories, runners, build tools, artifact stores, deployment targets, secrets, and security evidence. Record which identity may perform each action.
- Harden and isolate execution. Reduce runner permissions and separate untrusted contributions from workflows that can access secrets or privileged environments.
- Protect inputs. Set repository and dependency controls, review vulnerable dependencies, use controlled sources, and verify the integrity of tools and artifacts.
- Protect credentials and signing. Limit secrets and key access to authorized jobs, and define who or what may issue trusted evidence.
- Generate and verify evidence. Select the build, test, vulnerability, signature, provenance, or attestation evidence your policies require; specify acceptable freshness and validation.
- Enforce release and deployment decisions. Require approved-process and policy checks before promotion, and document the exception route.
- Monitor and improve. Observe deployed systems, respond to vulnerabilities and violations, and use findings to adjust controls.
How do you evaluate CI/CD security tools and platform patterns?
Evaluate a tool by the controls it can demonstrate in your workflow, not by a claim that it makes a pipeline “zero trust.” NIST SP 800-204D observed in its February 2024 publication context that integrated DevSecOps platform baselines lacked maturity and consensus; that observation is not a current market assessment. NIST guidance also does not establish that one vendor or platform is sufficient.
- Identity and authorization: Can permissions be scoped by actor, project, environment, and action?
- Isolation: Can untrusted code run without secrets, privileged access, or unnecessary network access?
- Input integrity: Can teams control source origins, assess dependencies, and verify the inputs used in builds?
- Credential handling: Can secrets and signing keys be limited to authorized workflows and managed under the organization’s rotation and access rules?
- Artifact evidence: Can the organization validate signatures, build origin, provenance, attestations, and vulnerability evidence?
- Policy integration: Can controls be enforced at the appropriate merge, build, release, and deployment points without breaking required workflows?
- Monitoring and response: Can teams observe deployed artifacts and policy violations, investigate them, and act on findings?
- Operational fit: Does the deployment model suit existing processes, staffing, risk tolerance, and operational costs?
Choose a combination of practices and tools that closes identified control gaps and can be operated consistently. Reassess coverage as the pipeline, threat model, and organizational requirements change.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
