Security teams should monitor the build runner itself, not just the source repository or signed artifact. Tampering during CI can happen after code review and before signing, which means branch protection and artifact signing may miss it. A practical control is file modification monitoring on the build host, with alerts tied to the exact process that changed the file.
What to watch in the build stage, not just the repository
Source code tampering during CI is a build integrity problem, not only a repository protection problem. If an attacker or insider changes files after review, during checkout, or in the build workspace, the signed artifact can still be malicious even when the branch was protected and the final package was signed. The detection point has to be the runner and its filesystem activity.
The practical signal is file modification on the build host, correlated to the process that made the change. That gives you an observable path from the changed file to the exact command, script, or service account context that touched it. For teams using stricter build provenance, SLSA is the clearest external model for reasoning about build integrity and where tampering can enter the pipeline.
Detection should therefore focus on the workspace, build scripts, dependency caches, generated files, and any ephemeral secrets or config copied onto the runner. Tampering often looks ordinary at first, so the value is not in noisy content inspection alone, but in knowing that a file changed at build time when it should have been immutable.
How to make file modification monitoring actionable
File integrity monitoring is most useful when it is scoped to the build runner’s high-value paths and tied to process context. Monitor source checkout directories, pipeline definitions, build scripts, dependency manifests, and signing or packaging inputs, then alert when those files change outside the expected build step sequence. That helps distinguish a normal compiler write from an unauthorized overwrite or injected payload.
Good detection also requires timing discipline. Compare the modification event against the pipeline stage, the build identity, and the expected parent process chain. If a file changes during checkout, test execution, or pre-signing packaging, treat it differently from a controlled temporary artifact created by the compiler. For teams that want a broader operational baseline around build and release controls, NIST Cybersecurity Framework 2.0 helps anchor detection and recovery expectations, while Guide to the Secret Sprawl Challenge is useful for understanding how CI/CD exposure often travels with embedded secrets.
In practice, the alert should answer three questions quickly: what file changed, which process changed it, and whether that process was expected at that moment. Without all three, teams tend to over-triage benign build activity or miss a low-and-slow change hidden inside a healthy pipeline.
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 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Build tampering detection depends on monitoring runner file changes and process activity. |
| PR.DS — Data Security | Source code and build inputs are sensitive assets that need integrity protection during pipeline execution. | |
| PR.PS — Platform Security | CI runners are trusted execution platforms whose integrity affects build trustworthiness. | |
| Recommendation — Monitor build-host file integrity and process lineage to detect unauthorized changes during CI. Protect build inputs and generated artifacts from unauthorized modification during CI processing. Harden CI runners and restrict write paths that can alter build inputs before signing. | ||
| CIS Controls v8 | 8 — Audit Log Management | File-change alerts tied to the process that wrote them require strong audit visibility on the runner. |
| 10 — Malware Defenses | Tampering in CI often involves malicious payload insertion or runner compromise that defensive telemetry should catch. | |
| 16 — Application Software Security | Build integrity is a software delivery security concern that includes protecting source and build artifacts. | |
| Recommendation — Log build-host file and process activity so tampering can be traced to the responsible execution context. Detect unauthorized modifications and suspicious execution on CI runners before artifacts are produced. Apply software delivery controls that preserve integrity across checkout, build, and packaging stages. | ||
| OWASP Non-Human Identity Top 10 | NHI-08 — Secrets in Code and Pipelines | CI tampering commonly overlaps with pipeline exposure of credentials, tokens, and build inputs. |
| NHI-09 — Improper Rotation and Revocation | If build credentials are abused during tampering, rapid invalidation limits further pipeline compromise. | |
| NHI-10 — Supply Chain and Third-Party Risk | Tampering during CI is a supply-chain integrity failure that can poison released software. | |
| Recommendation — Scan build paths for secrets and treat pipeline file changes as a potential credential exposure event. Rotate and revoke build credentials quickly when CI tampering is suspected. Treat CI file tampering as a software supply-chain risk and enforce provenance controls on build output. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Build-stage alerts become stronger when runner and automation identities are strongly authenticated and attributable. |
| Recommendation — Require strong authentication and attributable runner identity for actions that modify build inputs. | ||
Practitioner Guidance
What to verify: Confirm that the monitoring scope includes the runner filesystem, not only the repository mirror or artifact store. The control should cover the exact directories where checkout, build, and packaging occur, otherwise tampering can happen in the gap between review and signing.
Decision rule: If a file changes after source approval but before artifact publication, prioritise runner compromise investigation and process lineage review before you rely on the signed output. That sequence matters because signature validity does not prove the build input was clean.
What good looks like: Alerts should identify the changed path, the writing process, and the pipeline stage in one event. If your current telemetry cannot do that, the control is still too weak for CI tampering detection.
Practitioner takeaway: The real control is not “did the repository stay clean?”, it is “can we prove nothing altered the build inputs on the runner before signing?”
Related resources from NHI Mgmt Group
- How should security teams detect malicious open source packages when attackers use aliases and code obfuscation?
- How should security teams detect indicators of compromise in CI/CD pipelines before malicious code reaches production?
- How should security teams detect compromised open-source maintainer accounts before malicious code lands in a package?
- How should security teams detect dosfuscation in code before it reaches CI and production?
