Teams should add build-time monitoring directly to the GitHub-hosted runner as the first workflow step. That places detection at the point where files can be changed during execution, before later build stages can propagate the compromise. The goal is to surface unauthorized modifications early enough to stop a tainted pipeline from producing trusted output.
Why the first step belongs inside the runner, not after the build
Detection has to start where tampering can actually happen. In GitHub Actions, that means instrumenting the GitHub-hosted runner at the beginning of the job so file changes, injected steps, altered artifacts, and unexpected process behaviour are visible before later stages can reuse or publish compromised output. A later checkpoint may tell you something was wrong, but it will usually be too late to trust the pipeline.
The practical reason is sequencing. Build jobs often fetch dependencies, unpack archives, generate files, and pass outputs between steps, so a malicious or altered change can be propagated forward if monitoring is added only near the end. Monitoring at the first workflow step helps teams catch tampering while the build is still recoverable and before trust is transferred to artifacts, caches, or downstream jobs.
For teams looking for a broader playbook on how build integrity failures tend to spread, NHIMG’s GitHub Action tj-actions Supply Chain Attack and Reviewdog GitHub Action supply chain attack show how quickly a compromised action or build step can turn into repository-wide exposure. The lesson is not just that tampering is possible, but that early detection has to sit on the same execution path as the compromise.
What teams should watch for in a GitHub Actions build
Build-time monitoring is most useful when it is focused on the things a tampered build is likely to change: unexpected file creation or modification, altered scripts or binaries, changes to downloaded dependencies, and unusual process or network activity during the job. The goal is not broad telemetry for its own sake, but an early signal that the runner state no longer matches what the workflow expected.
Teams should also treat build outputs as sensitive until the job finishes cleanly. If a step rewrites source, injects a new artifact, or changes the contents of a cache, that compromise can survive into later stages even if the original trigger has already passed. That is why the first-step placement matters, it gives the monitoring control a chance to observe the initial state and the first meaningful deviation.
When build integrity is the concern, supply-chain guidance is directly relevant. SLSA is useful here because it treats provenance and build integrity as first-class concerns, while the NIST Cybersecurity Framework 2.0 reinforces the broader detect and respond expectations around integrity monitoring. Teams do not need to turn a workflow into a full security platform, but they do need an observable build path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Build-time tamper detection is continuous monitoring for integrity events in the pipeline. |
| DE.CI — Improvements | Tampering in builds requires rapid detection and containment before compromised outputs spread. | |
| Recommendation — Instrument the runner and job steps to detect unexpected file, process, or network changes. Use integrity alerts to trigger immediate containment of the affected workflow run. | ||
| CIS Controls v8 | 8 — Audit Log Management | Runner-side monitoring depends on capturing actionable build activity and changes. |
| 10 — Malware Defenses | Tampered builds often involve malicious payloads or injected tooling in the runner path. | |
| 16 — Application Software Security | GitHub Actions builds are a software delivery path where integrity controls reduce compromise spread. | |
| Recommendation — Collect and review build execution logs that show file and process changes during the job. Scan build-time artifacts and execution paths for malicious or unexpected payloads. Add integrity checks early in the build pipeline before packaging or release steps. | ||
| MITRE ATT&CK | T1070 — Indicator Removal on Host | Tampering often includes altering files or traces during execution to hide compromise. |
| T1105 — Ingress Tool Transfer | Compromised builds may fetch or stage tools mid-run to change build behaviour. | |
| Recommendation — Hunt for suspicious file modifications and trace removal during workflow execution. Detect unexpected downloads or staged tooling during the build job. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | GitHub Actions build tampering frequently pairs with secret exposure during workflow execution. |
| Recommendation — Monitor runner activity that could expose or misuse secrets during build execution. | ||
Practitioner Guidance
What to prioritise: Put the first monitoring action at the start of the job, before dependency fetches, generated files, or artifact creation. If you place detection later, you may only observe the finished compromise rather than the moment it became visible.
What to verify: Confirm the control can see runner-local file changes and unexpected execution during the build, not just final artifact hashes. A good check is whether the alert would still fire if the attacker altered a script, injected a binary, or modified an intermediate build directory before packaging.
Practitioner takeaway: The first workflow step should establish trust boundaries for the rest of the run, because once a tampered build propagates into cached outputs or published artifacts, detection becomes much harder and response becomes mostly forensic.
Related resources from NHI Mgmt Group
- How should teams respond when they find suspicious GitHub Actions activity?
- How should security teams detect dangerous GitHub Actions usage in public repositories?
- How should security teams detect and block trojanized open source JavaScript packages before they reach production builds?
- What should security teams do first after a GitHub Actions workflow in a public repository is found vulnerable to pull request abuse?
