Security teams should combine access control, code signing, continuous scanning, runtime protection, and clear governance. The goal is to make unauthorised changes hard to introduce and easy to detect before release. Preventive controls reduce the chance of malicious modification, while detection and monitoring catch deviations quickly. Incident response procedures should define how to contain, investigate, and restore trusted code paths.
Where pipeline tampering usually enters
Code tampering in a delivery pipeline is rarely a single event. It usually starts with weak repository permissions, exposed build secrets, overtrusted automation, or a compromised dependency path that can alter source, build definitions, or artifacts before release. The practical question is whether each stage has a control point that can prevent modification, prove provenance, or make tampering visible early enough to stop promotion.
A good starting point is to treat the pipeline as a chain of trust, not just a sequence of jobs. If source control, CI runners, artifact stores, and deployment targets are all allowed to mutate the same release path, an attacker only needs one weak link to introduce malicious code or replace a trusted artifact. That is why supply-chain integrity and build provenance matter as much as source review.
For teams building stronger provenance, SLSA is the clearest external reference point for verifying how software was built, while NHIMG’s Reviewdog GitHub Action supply chain attack shows how a compromised action can pivot from a trusted workflow into secret exposure.
Controls that make tampering hard to land
Prevention works best when access control, signing, and change governance reinforce each other. Limit who can modify pipeline definitions, lock down privileged build credentials, protect release branches, and require signed commits or signed artifacts where the workflow supports it. If a build system can publish or promote code without strong approval boundaries, tampering becomes a process problem as much as a technical one.
Continuous scanning should cover both code and pipeline configuration. That includes dependency checks, secret detection, policy checks on infrastructure and workflow files, and artifact integrity validation before deployment. Runtime protections then provide the last barrier, catching unexpected process behaviour, unauthorized network calls, or drift from the intended artifact once software is executing.
NHIMG’s CI/CD pipeline exploitation case study is a useful companion for understanding how a small configuration weakness can become broad pipeline compromise, and the Guide to the Secret Sprawl Challenge is relevant where hardcoded credentials or CI/CD secrets create an easy tampering path.
One statistic makes the exposure concrete: NHIMG reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. For delivery pipelines, that is not just a secrets-management issue, it is an integrity issue, because exposed credentials can be used to alter build inputs, signing paths, or release approvals.
Practitioner priorities for trustworthy delivery
What to prioritise: protect the release path first, not just the application code. The most valuable controls are the ones that reduce write access to pipeline assets, constrain who can approve promotion, and ensure the artifact you deploy is the artifact you inspected.
What to verify: confirm that pipeline permissions are separated by role, that signing keys and release credentials are isolated from general build access, and that every promotion step leaves an auditable trail. If you cannot reconstruct who changed the workflow, who approved the build, and which artifact hash was deployed, the control set is too weak.
Common mistake: teams often focus only on scanning the source repository while leaving pipeline YAML, build images, package registries, and third-party actions less governed. Tampering often enters through those adjacent systems because they are treated as implementation details instead of part of the trusted release boundary.
Practitioner takeaway: the best defense is layered trust reduction, fewer places where code, credentials, or build logic can be changed, and more independent checks that prove the released artifact matches what the team intended to ship.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 6 — Access Control Management | Limits who can alter pipeline code, credentials, and release approvals. |
| CIS Control 8 — Audit Log Management | Tampering detection depends on logs that show workflow, build, and release changes. | |
| CIS Control 16 — Application Software Security | Covers scanning, validation, and hardening of code and pipeline components before release. | |
| Recommendation — Restrict write access to pipeline assets and release paths to approved administrators. Centralize and retain pipeline audit logs for workflow and artifact changes. Scan pipeline code, dependencies, and artifacts before promotion. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Supports least-privilege control over build, signing, and deployment actions. |
| DE.CM-8 — Monitoring for Unauthorized Software and Code Changes | Directly supports detection of tampered workflows, artifacts, or release inputs. | |
| PR.DS-6 — Integrity Checking Mechanisms | Artifact integrity checks help prove releases were not altered in transit or build. | |
| Recommendation — Apply least privilege to all pipeline and release permissions. Monitor for unauthorized changes to code, build definitions, and artifacts. Validate signed artifacts and hashes before deployment. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Pipeline tampering often starts with exposed CI/CD secrets or build credentials. |
| NHI-02 — Least Privilege and Access Boundaries | Build and release identities should not have broad write or publish power. | |
| NHI-06 — Monitoring, Detection and Response | Tampering must be observable across build, signing, and deployment activity. | |
| Recommendation — Move CI/CD secrets out of code and rotate any exposed credentials immediately. Constrain pipeline identities to the minimum actions needed for each stage. Alert on anomalous pipeline behaviour and unauthorized artifact changes. | ||
| OWASP Agentic AI Top 10 | A3 — Tool and Action Authorization | Automated build or release agents need bounded authority to prevent unauthorized changes. |
| Recommendation — Restrict agent tool access to approved build and release actions only. | ||
Related resources from NHI Mgmt Group
- How should security teams reduce risk in software delivery pipelines with NHI controls?
- How should security teams govern autonomous coding agents in software delivery pipelines?
- How do security teams detect malicious software delivery when the code looks legitimate?
- How should security teams structure SLA workflows for dependency vulnerabilities in software delivery pipelines?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
