What are the key CI/CD best practices?

What CI/CD best practices actually protect

CI/CD best practices are mainly about keeping the software delivery pipeline trustworthy under pressure. The pipeline is not just a build convenience, it is a privileged production path that can change code, inject secrets, publish artefacts, and deploy software. Good practice therefore focuses on provenance, access restriction, isolation, review, and monitoring so that automation accelerates delivery without becoming a blind trust channel.

A useful way to think about this is to separate the pipeline control plane from the application it builds. If an attacker or careless change can alter the pipeline itself, every downstream release may inherit that weakness. That is why pipeline security guidance treats build definitions, runners, signing keys, and release permissions as production assets, not as developer tooling that can be loosely managed.

For a deeper treatment of the controls that reduce poisoned builds, runner abuse, and workflow tampering, see the CI/CD Security Guide.

How to make builds, artefacts, and release paths trustworthy

The strongest CI/CD controls aim to ensure that what gets deployed is what was actually reviewed and built from the intended source. That means requiring signed commits or equivalent source trust, pinning dependencies and actions where supported, and producing artefacts that can be traced back to a specific build run. Trusted provenance matters because a build system is often the easiest place to hide a malicious change inside otherwise routine automation.

Build integrity also depends on isolating execution contexts. Runners should not share credentials, state, or filesystem residue across unrelated jobs unless there is a clear control reason. Ephemeral runners, minimal permissions, and tight environment separation reduce the chance that one compromised job can influence the next one or exfiltrate high-value material from a long-lived worker.

It is also important to treat dependencies as part of the release chain. Dependency updates, third-party actions, and package install steps can all introduce risk even when the application code itself looks clean. Use the release process to make dependency drift visible, and require review for changes that affect build logic, publish steps, or trusted sources.

For build provenance and integrity verification, the SLSA framework is the best external reference point, because it helps teams reason about how artefacts are produced, not just whether they exist.

Where CI/CD failures usually start

Most CI/CD failures are not exotic. They usually start with excessive pipeline privilege, leaked secrets, untrusted execution, or unaudited changes to workflow files and release scripts. Once a pipeline can read secrets, publish packages, or trigger deployments, a single compromised token or workflow change can spread quickly across repositories and environments. That is why pipeline security should be measured by blast radius, not by whether the latest job passed.

Secret handling is especially sensitive because CI/CD systems tend to concentrate credentials in a place designed for automation, not long-term storage. Long-lived tokens, shared environment variables, and unchecked logs create a narrow but severe exposure path. A clean build log does not prove safety if the runner, artefact store, or dependency fetch process has already leaked material needed for later compromise.

Change control is the other common failure point. If unreviewed changes can modify pipeline definitions, branch rules, or release permissions, then the pipeline becomes a software supply-chain target. The practical lesson is that the path to production must have stronger controls than ordinary code paths, because compromise there can affect many releases at once.

Risk and Threat Considerations

CI/CD systems concentrate high-value trust, so compromise tends to have outsized impact. An attacker who gains pipeline access can steal secrets, insert backdoors into builds, or silently alter release logic, which makes the pipeline an efficient route to broad downstream compromise.

Failure mechanism: Weak approval gates, exposed credentials, or insecure runners allow malicious changes or secret theft to move from one job to many repositories and environments before the anomaly is noticed.

Impact: The result can be polluted artefacts, leaked signing material, unauthorized deployments, and a supply-chain incident that affects customers, internal systems, or downstream consumers.

Practitioner Guidance

What to prioritise: Start with the controls that reduce the widest blast radius, namely pipeline write access, secret exposure, and release authority. If a control only protects the application after build time, it is usually secondary to controls that protect the pipeline itself.

What to verify: Confirm that pipeline definitions, runner identities, and publishing credentials are owned and reviewed like production assets. Also verify that a failed build cannot still publish, deploy, or silently retain reusable credentials.

Decision rule: If a change can affect artefact integrity, secret access, or deployment authority, require review and traceability before it reaches the main delivery path. If the change only affects local developer convenience, keep it out of the privileged pipeline surface.

Practitioner takeaway: The real objective is not faster automation by itself, but bounded automation, where every step that can change production is visible, reviewable, and hard to abuse.

Related resources from NHI Mgmt Group

• What are the key CI/CD pipeline attack best practices?
• How should security teams make NHI best practices usable across the business?
• How should security teams enforce AWS security best practices in CI/CD pipelines?
• What are best practices for integrating interactive application security testing (IAST) into CI/CD pipelines and development workflows?