Look for unauthorized runner registration, unusual repository creation, strange commit or discussion activity, and secrets-access patterns that do not match normal build behaviour. In this campaign, those signals matter because the malware hid inside ordinary GitHub workflows. A healthy environment should not show new automation identities appearing without an approved change.
What signals show a CI/CD environment is already being abused?
The fastest indicators are control-plane changes that do not match normal engineering activity: a new runner or bot identity, unfamiliar repositories or workflows, commits that were not part of an approved change, and secret access at odd times or from odd jobs. In practice, compromise often first looks like “legitimate” automation doing things it was never meant to do.
A useful mental model is that attackers rarely start by breaking the entire CI/CD system. They more often hijack one trust path, then use it to create more access, more workflows, or more secret visibility before defenders notice.
Why runner registration, repository creation, and commit activity matter
CI/CD compromise usually becomes visible where the platform records authority: runners, workflow files, repository creation, branch updates, and discussion or issue activity. If a runner appears without an approved change, that is not just noise, it is evidence that someone may have introduced a new execution point into the pipeline. Likewise, sudden repo creation or commit bursts can be a sign of malicious staging rather than normal developer work.
The key question is whether the change matches the environment’s normal build and release rhythm. A trusted pipeline should have a stable pattern of who can register automation, which branches can alter workflows, and which identities can create or modify repositories. When those patterns change without a corresponding ticket, review, or release event, teams should treat it as suspicious until proven otherwise.
GitHub-centric supply-chain intrusions show why this matters, because malicious workflow changes and fake commits are often used to turn build systems into secret-exfiltration points. tj-actions/changed-files compromise 2025 and Fake Dependabot commits 2023 are both useful references for how false legitimacy can be manufactured inside otherwise normal developer activity.
What secret-access anomalies usually reveal
Secret-access patterns often provide the clearest signal because the attacker’s goal is usually to reach tokens, signing material, cloud credentials, or publishing secrets. A healthy environment will show secret retrieval that lines up with expected jobs, expected repositories, and expected timing. When secrets are accessed by a new workflow, a newly registered runner, or a repository that should not need them, the access pattern itself becomes the indicator.
It is also important to watch for secrets that are exposed indirectly, such as through logs, artifacts, forked pull requests, or workflow outputs. Those paths can make a compromise look like an operational mistake until the sequence is connected. If the build system starts behaving like a credentials distribution service instead of a controlled release system, the environment is already at elevated risk.
Campaigns such as Shai Hulud npm malware campaign and ArtiPACKED 2024 show how workflow data, artifacts, and tokens can be exposed during routine automation. The broader pattern is that secret theft is often visible first in the process that touches the secret, not in the endpoint where the stolen value is finally used.
Risk and Threat Considerations
When CI/CD is compromised, the attacker is usually trying to convert build trust into broader access, persistence, or secret theft. The danger is not limited to the pipeline itself, because an abused runner or workflow can become a launch point for repository tampering, package poisoning, signing abuse, or cloud credential harvesting.
Failure mechanism: A malicious actor gains execution inside a trusted workflow, registers unauthorised automation, or modifies build logic so that routine jobs begin leaking secrets, creating backdoors, or approving attacker-controlled changes.
Impact: The environment can lose release integrity, expose signing or publishing credentials, and spread compromise across multiple repositories or downstream services before the abuse is detected.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Unexpected runner and workflow identities point to abused automation auth. |
| NHI-05 — Overprivileged NHI | CI/CD abuse often succeeds through excessive pipeline and token privileges. | |
| NHI-07 — Long-Lived Secrets | Secret-access anomalies are most dangerous when credentials persist too long. | |
| Recommendation — Verify runner and workflow identity provenance before allowing secret access. Reduce pipeline token scope and remove unnecessary repository access. Rotate long-lived CI/CD secrets and replace them with short-lived credentials. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Compromised workflows often execute attacker-controlled build commands. |
| T1565 — Data Manipulation | Malicious commits and workflow edits can alter release content or build steps. | |
| Recommendation — Detect unexpected script execution inside build and release jobs. Monitor for unauthorized changes to workflows, artifacts, and release files. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | CI/CD compromise detection depends on logging runner, workflow, and secret events. |
| AC-6 — Least Privilege | Pipeline abuse is amplified when automation can reach too many repos or secrets. | |
| IA-5 — Authenticator Management | Credential theft and rotation are central to CI/CD compromise handling. | |
| Recommendation — Log runner registration, workflow edits, and secret access events centrally. Restrict CI/CD identities to the minimum repositories, jobs, and secrets required. Rotate exposed build credentials immediately and invalidate unused authenticators. | ||
| CIS Controls v8 | CIS-5 — Account Management | Unauthorized runners and new automation identities are account-management failures. |
| CIS-8 — Audit Log Management | Suspicious build activity must be observable to confirm compromise quickly. | |
| Recommendation — Inventory and remove unapproved CI/CD accounts, tokens, and service identities. Preserve immutable logs for runner, repo, workflow, and secret-access activity. | ||
Practitioner Guidance
What to verify: Confirm that every runner, bot, and workflow identity has an approved origin, expected ownership, and a documented lifecycle. If you cannot explain why the identity exists, assume it is an incident investigation item rather than a benign configuration change.
Decision rule: If the suspicious activity involves secrets access, workflow modification, or runner registration, prioritise containment and credential rotation before spending time on intent analysis. The main question is not whether the attacker already succeeded broadly, but whether they have a path to keep using trusted automation.
What good looks like: Stable runner inventories, tightly controlled workflow change paths, and secret access that is attributable to specific jobs and change events. If those signals are noisy or unauditable, the environment is already too permissive for reliable trust.
Practitioner takeaway: In CI/CD, compromise is often visible as an identity or workflow anomaly before it is visible as a failed build. Teams should treat unexplained automation, unusual repository activity, and secret access drift as evidence of trust abuse until the pipeline’s behaviour is explained.