What are the warning signs that a repository or runner has been abused for persistence?

What the warning signs usually look like

Abuse for persistence often shows up as trusted automation behaving in ways that do not match the normal release process. The clearest clue is that the attacker is trying to blend into repository and runner activity, so the signal is usually not a single malicious action but a cluster of small changes that extend access, hide execution, or create a durable foothold.

In practice, that means watching for workflow files appearing where they were not expected, runners being added or reconfigured without a normal change record, and artifacts that are uploaded or downloaded outside the usual build pattern. Repository edits that look mechanically generated, or that originate from a context no maintainer recognizes, deserve the same scrutiny as an obvious login anomaly.

A useful way to think about these signs is whether the activity increases the attacker’s ability to keep running code, recover access, or reintroduce credentials after cleanup. If a repository or runner starts behaving like a control plane for repeated access rather than a delivery tool, persistence may already be established.

How repository abuse differs from ordinary automation noise

Not every unusual workflow or runner event is hostile, but abuse tends to break the normal relationship between change, approval, and execution. A benign automation change normally has an owner, a ticket, a review trail, or a clear operational reason. Abuse often lacks that context, or it borrows legitimacy from existing automation so it can persist under the cover of routine maintenance.

Look closely at secret access patterns as well. Repeated reads, access at odd hours, access from jobs that should not need secrets, or access that is followed by workflow changes can indicate that the attacker is chaining repository access into secret retrieval and then into longer-lived control. That pattern matters more than a one-off request because it suggests deliberate persistence rather than opportunistic misuse.

Self-hosted runners deserve special attention because they can become durable execution points if an attacker can register, modify, or reuse them. Once a runner is trusted, it may be able to execute future jobs, observe build content, or be used as a staging point for later movement. For deeper context on identity-driven compromise patterns that often accompany this kind of abuse, the Identity Threat Detection and Response (ITDR) Guide is a useful companion, and the attack style is closely related to what Salt Typhoon telecom intrusions 2025 illustrates: stolen access is turned into durable, trusted presence.

What to investigate first when you suspect persistence

Start with the point where trust was most likely extended. Check for recent workflow additions, runner registrations, repository permission changes, secret exposure events, and any automation account activity that lacks an obvious owner. The goal is to identify the first durable foothold, not just the latest symptom.

Then trace whether the suspicious activity is repeatable. Persistence usually leaves a pattern: the same workflow, runner, secret, or automation identity keeps reappearing after cleanup, or the same type of change keeps being reintroduced from a path that was assumed to be controlled. If the same mechanism can reestablish access after you delete the visible artifact, you have a persistence problem, not just an incident response cleanup issue.

It is also worth separating build-system anomalies from source-control anomalies. A repository can be compromised without the runner being owned, and a runner can be abused without the repository itself showing obvious malicious code. Treat both surfaces as part of one trust chain because a weakness in either can preserve access even after the other is remediated.

Risk and Threat Considerations

Repository and runner abuse is dangerous because it uses trusted automation as camouflage. Once an attacker can create or reuse workflow paths, they can hide in normal operational noise, re-access secrets, and keep execution available after a maintainer believes the incident is closed.

Failure mechanism: The attacker gains a durable execution or secret-retrieval path through workflow changes, runner registration, or automation credentials, then reuses that path to restore access after remediation.

Impact: Cleanup becomes incomplete, secrets may be re-exposed, malicious jobs can recur, and the repository or runner can continue serving as a persistence layer for later stages of compromise.

Practitioner Guidance

What to verify: Confirm whether each suspicious workflow, runner, or artifact event has a named owner, an approved change path, and a clear business purpose. If any of those are missing, treat the event as a potential persistence indicator until the access path is explained.

Decision rule: If a repository change can create or revive execution without a maintainer’s normal approval flow, prioritise revocation, workflow review, and secret rotation before you spend time proving intent. The practical question is whether the attacker can come back, not whether they have already done visible damage.

Common mistake: Teams often focus on code diffs and miss control-plane abuse, such as a new runner, a modified workflow trigger, or an automation identity that has inherited too much trust. Those are often the mechanisms that keep the compromise alive.

Practitioner takeaway: Persistence in SCM is usually a trust problem before it is a malware problem, so the safest response is to validate who can execute, who can fetch secrets, and who can reintroduce those capabilities after cleanup.

Related resources from NHI Mgmt Group

• What are the signs that a CI/CD runner has been abused for secret theft or persistence?
• How should teams reduce the risk of exposed AI credentials being abused?
• What are the signs that exposed cloud workloads or AI infrastructure are being abused for propagation and persistence?
• What are the signs that credential-based access is being abused inside a cloud or document repository?