The theft of tokens or credentials directly from a CI runner’s process memory instead of from files or environment variables alone. This technique defeats controls that only protect secrets at rest and shows why build agents need runtime hardening, privilege minimisation, and tighter isolation.
What Runner Memory Secret Extraction Is
Runner memory secret extraction is a live, runtime theft technique. Instead of finding credentials on disk or in environment variables, the attacker targets secrets while a CI runner has already loaded them into process memory and can still use them.
Why In-Memory Secret Theft Matters
This matters because many pipelines protect secrets at rest but leave a narrower gap while the runner is executing. If a build agent can read, decode, or forward credentials in memory, the control plane still loses the secret even when files, variables, and logs are hardened.
The technique is especially relevant in CI and other ephemeral automation where short-lived access is expected but runtime exposure is easy to underestimate. It turns a temporary execution environment into a high-value target because a single successful memory read can reveal tokens, keys, or session material that was never meant to persist.
How the Technique Works
Memory extraction can happen through malware on the runner, hostile code execution in the job context, debugging hooks, process inspection, or a compromised helper service. The common element is that the secret exists in plaintext or usable form long enough to be copied before the job ends.
That makes runtime protection different from secret storage protection. Encryption, vaulting, and secret scanning still matter, but they do not stop theft once a credential is materialized for use inside the runner’s address space.
For background on the broader class of secret exposure problems, NHIMG’s Guide to the Secret Sprawl Challenge explains how exposed credentials spread across modern delivery systems.
Security Implications for CI Runners
Runner memory secret extraction is a strong reminder that build infrastructure needs runtime hardening, not just secure storage. If a runner is overprivileged, broadly networked, or able to reuse the same credentials across jobs, a single compromise can cascade into source control, package publishing, cloud access, or downstream deployment systems.
NHIMG’s Static vs Dynamic Secrets is relevant here because short-lived credentials reduce the value of anything stolen from memory, while long-lived secrets increase the impact of a successful dump.
NHIMG’s Top 10 NHI Issues also maps well to this pattern, especially overprivilege, secret sprawl, and credential theft in automation-heavy environments.
Risk and Threat Considerations
In-memory extraction is dangerous because it bypasses controls that only protect stored secrets. An attacker who reaches the runner at runtime can often recover high-value credentials with no need to search repositories, configuration files, or environment snapshots.
Failure mechanism: The runner loads a secret for execution, but the secret remains recoverable in memory long enough for an attacker, injected process, or debug-capable workload to copy it before the job exits.
Impact: Stolen runtime secrets can enable lateral movement, pipeline tampering, artifact poisoning, cloud access, or repeated compromise if the same credential is reused elsewhere.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) 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-02 — Secret Leakage | Runner memory extraction is direct secret leakage from execution context. |
| NHI-05 — Overprivileged NHI | CI runners are non-human identities that become dangerous when granted excessive access. | |
| NHI-07 — Long-Lived Secrets | Memory theft is far more damaging when the captured secret remains valid for long periods. | |
| Recommendation — Protect secrets at runtime and reduce the chance that a runner can expose usable credentials. Minimise runner privileges so stolen runtime secrets have less reach. Shorten secret lifetime to limit the value of anything recovered from memory. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | This term concerns how credentials are protected across their lifecycle, including reuse and exposure. |
| IA-9 — Service Identification and Authentication | CI runners and automation authenticate as services or workloads in this pattern. | |
| AC-6 — Least Privilege | The impact of memory theft depends heavily on how much access the runner already has. | |
| Recommendation — Manage authenticator lifecycle so captured credentials expire quickly and are harder to reuse. Use service authentication methods that reduce reusable secret exposure in runners. Constrain runner privileges so a dumped secret does not unlock broad access. | ||
| NIST Zero Trust (SP 800-207) | AC-6 — Least Privilege Access | Zero Trust limits what a compromised runner can reach even if its memory is exposed. |
| Recommendation — Apply least-privilege access so stolen runner secrets have minimal downstream effect. | ||
| CIS Controls v8 | CIS-5 — Account Management | Automation accounts used by runners must be tightly governed because their secrets are a target. |
| Recommendation — Govern runner accounts tightly and remove unnecessary access paths. | ||
Practitioner Guidance
Why practitioners should care: Treat CI runners as high-risk execution environments, not as passive secret containers. The right question is not only whether a secret is stored securely, but whether it can be recovered while it is actively being used.
Practitioner note: Prefer short-lived, tightly scoped credentials for build jobs, and design runners so that compromise of one job reveals as little as possible about the next. Pair that with isolation that limits cross-process visibility, because memory exposure is usually a runtime problem before it is a storage problem.
Related resources from NHI Mgmt Group
- Why do runner memory reads create such a serious secret exposure risk?
- What breaks when a malicious npm package can read CI/CD runner memory?
- What breaks when secrets are loaded into a breached CI/CD runner or runtime memory space?
- What are the signs that a CI/CD runner has been abused for secret theft or persistence?