Workflow Runner Persistence

Expanded Definition

Workflow runner persistence describes a foothold inside CI/CD automation infrastructure that survives removal of the original malicious package, script, or repository artifact. In NHI and IAM terms, the important distinction is that the attacker is no longer relying only on the payload; the runner itself, its execution context, cached credentials, or trusted registration path becomes the durable access layer. This makes the issue closely related to service account abuse, ephemeral credential handling, and trust boundaries around build and deploy systems. Guidance varies across vendors on whether persistence is achieved through agent registration, job hooks, poisoned images, or retained tokens, but the operational result is the same: automation continues to execute attacker-controlled actions after the initial trigger is gone. Control expectations map naturally to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where least privilege, auditability, and credential lifecycle discipline are required. The most common misapplication is treating a cleaned repository as a fully remediated incident when the runner, token cache, or self-hosted agent registration remains active.

Examples and Use Cases

Implementing controls against workflow runner persistence rigorously often introduces more operational friction, requiring organisations to balance fast CI/CD throughput against stronger isolation, rotation, and re-registration steps.

• A compromised self-hosted runner keeps accepting jobs after the malicious repository file is deleted, because the runner registration token was not revoked.
• An attacker plants a modified step in a pipeline cache so the next deployment job silently reuses the altered execution path, even after source code cleanup.
• A stolen CI secret in a build environment is used to re-register a runner under attacker control, creating a persistent execution channel that outlives the original compromise.
• The incident pattern documented in Salt Typhoon US telecoms breach shows how stolen credentials can extend access beyond the initial intrusion path, which is a useful analogue for automation persistence.
• Teams harden pipeline identity by aligning runner trust with NIST SP 800-53 Rev 5 Security and Privacy Controls and rotating job-bound credentials after every meaningful compromise.

NHIMG research on the Ultimate Guide to Non-Human Identities notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, including code, config files, and CI/CD tools. That reality makes runner persistence especially dangerous when automation secrets remain reachable after a job ends.

Why It Matters in NHI Security

Workflow runner persistence turns a temporary compromise into an operational foothold that can survive incident cleanup. In NHI security, that matters because runners often hold privileged tokens, deployment permissions, and trusted network access that human users never see directly. If those execution paths are not explicitly revoked, an attacker can continue to run jobs, exfiltrate artifacts, or impersonate trusted automation long after the original malicious content is removed. This is why lifecycle control, offboarding, and visibility are central to NHI governance rather than optional hardening steps. NHIMG research shows that only 20% of organisations have formal offboarding processes for revoking API keys, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which helps explain how automation persistence becomes a breach amplifier. The same guide also reports that only 5.7% of organisations have full visibility into their service accounts, leaving many CI/CD identities effectively unmonitored. Organistions typically encounter the consequence only after a deployment anomaly, unexpected access event, or credential abuse report, at which point workflow runner persistence becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should organisations secure workflow platforms that handle both files and secrets?
• Why do workflow engines create such a large blast radius for attackers?
• When does malware persistence become an NHI governance issue?
• How should security teams protect NHI secrets stored in AI workflow platforms?