How does CI/CD work?

How CI/CD actually works from code change to release

CI/CD turns software delivery into a repeatable pipeline. A commit or merge request triggers automated checks, then build jobs compile or package the application, run tests, and publish artefacts. If the pipeline is designed well, each stage produces a trusted handoff to the next. The main value is speed with consistency, not removing control from the process.

The practical detail is that CI and CD are linked but distinct. Continuous integration focuses on proving that code still works as it changes, while continuous delivery or deployment extends that discipline into release automation. In mature environments, the pipeline becomes part of the system’s control plane, so its permissions, runners, secrets and approvals matter as much as the application code.

Because the pipeline is automated, every step needs an explicit trust boundary. Source control, build workers, test environments, artefact registries and deployment systems each have different failure modes. A change can move safely through the stages only if the pipeline can verify what it is building, where it came from, and who is allowed to promote it onward. That is why supply-chain integrity is not an add-on, it is part of CI/CD itself. For build provenance and integrity expectations, teams often use SLSA as a reference point.

For teams building the pipeline controls themselves, NHIMG’s CI/CD Security Guide is the most direct map of where the common breakpoints sit, including poisoned pipeline execution, runner isolation and branch rulesets.

Where CI/CD introduces security risk

CI/CD reduces manual release effort, but it also concentrates power. A single pipeline often has write access to repositories, package registries, cloud environments and production deployment paths. If attackers reach the pipeline, they do not need to compromise every application individually, they can often reach many at once through shared build and release controls.

The most common weakness is over-trusted automation. Compromised maintainers, malicious pull requests, unpinned dependencies, exposed tokens, weak branch protection and insecure runners can all turn the delivery system into an attack path. NHIMG’s CI/CD Pipeline Identity Security Guide is useful here because it explains how workload identity, token permissions and trusted publishing change the blast radius of a pipeline compromise.

Secrets are another pressure point because pipelines routinely need access to signing keys, cloud credentials, package publishing tokens and deployment accounts. If those secrets are long-lived or broadly scoped, a low-level compromise can become release tampering, source theft or environment takeover. The right question is not only whether the build passed, but whether the build runner could have reached material credentials that should never have been exposed in that context.

NHIMG’s Guide to the Secret Sprawl Challenge is relevant because CI/CD often becomes the place where secret sprawl is discovered, inherited or amplified rather than eliminated.

What practitioners should validate in a CI/CD pipeline

Start by checking the trust boundaries rather than the YAML syntax. Confirm which identities can trigger jobs, approve releases, push tags, read secrets, and publish artefacts. Then verify that untrusted code cannot inherit production credentials, that the runner environment is isolated, and that artefacts are traceable back to source and build inputs. This is where most practical pipeline failures show up.

Good practice is to separate build, test and deployment permissions instead of giving one pipeline the ability to do everything. The build stage should not automatically inherit deployment authority, and the release stage should not accept unsigned or unverified outputs. When teams skip this separation, they often create a pipeline that is fast but not trustworthy.

NHIMG’s CI/CD Pipeline Identity Security Guide also aligns closely with the need to bound token permissions, use keyless federation where possible, and require signed artefacts before promotion. That is the practical difference between automation that accelerates delivery and automation that silently expands access.

If your release path depends on third-party actions, plugins or shared build components, treat them as part of the control surface. Review them the way you would review code that can run with privileged access, because that is exactly what many pipeline components do. NHIMG’s tj-actions/changed-files compromise 2025 is a concrete reminder that a small supply-chain change can expose large volumes of CI/CD secrets.

Practitioner Guidance

What to prioritise: Focus first on the credentials and approvals that let a pipeline affect production. If those are not tightly scoped, observable and revocable, the rest of the delivery chain is only partially controlled.

What to verify: Confirm that build jobs cannot read unnecessary secrets, that deployment tokens are separated from build identities, and that artefacts are signed or otherwise verifiable before release. Also verify that branch protection and approval rules cannot be bypassed through alternate workflow paths.

Common mistake: Treating CI/CD as a developer productivity feature instead of a privileged automation environment. That mindset usually leads to broad tokens, shared runners, weak artifact provenance and poor separation between untrusted code and release authority.

Practitioner takeaway: CI/CD is safest when the pipeline is trusted to move code, not trusted to own the environment; the closer a job gets to release authority, the more it needs explicit identity, provenance and permission boundaries.

Related resources from NHI Mgmt Group

• How should security teams protect source code when access is spread across developers, contractors, CI/CD systems, and remote work locations?
• Why does CI/CD change the way AI agent governance has to work?
• How does a CI/CD pipeline attack work?
• What is workload identity federation and why is it important for CI/CD security?