The technique of reading process memory on a build or CI runner to extract credentials, tokens, or plaintext secrets that were never written to disk. It is effective because many pipelines inject sensitive values into runtime memory for legitimate work, creating a high-value target inside the process boundary.
What runner memory scraping means in practice
Runner memory scraping is not about breaking the build system itself so much as abusing a trusted execution point. The runner process often holds live secrets long enough to complete legitimate tasks, and those values can be recovered before they ever reach disk, making ephemeral runtime memory a valuable target.
This matters because the technique turns normal automation behavior into exposure: pipelines that inject tokens, cloud credentials, signing material, or other sensitive values into memory create an attack surface inside the job boundary rather than in a file, vault, or repository.
Why build and CI runners are attractive targets
CI runners are high-value because they sit close to source code, artifacts, deployment steps, and privileged automation. If an attacker can read process memory during a job, they may obtain enough material to impersonate the pipeline, access repositories, publish artifacts, or move into downstream systems that trust the runner.
Memory scraping is especially dangerous when runners are shared, long-lived, over-permissioned, or exposed to untrusted code paths. In those environments, one compromised job can become a pivot point for stealing reusable credentials or session material that was only meant to exist briefly in memory.
How organisations assess exposure and reduce the blast radius
Exposure analysis starts with inventorying which pipelines inject secrets at runtime, which jobs run untrusted contributions, and which runner types are reachable from the internet or from broad internal networks. Teams also need to review vendor and platform guidance for how secrets are passed into jobs, because the risk changes when a runner can be influenced by pull requests, forks, reusable workflows, or third-party actions.
Controls that reduce the blast radius include limiting the privilege of pipeline credentials, shortening token lifetimes, isolating sensitive jobs onto dedicated runners, and avoiding reuse of the same secret across many workflows. The less reusable the secret and the narrower the runner trust boundary, the less valuable memory scraping becomes to an attacker.
Detection, response, and post-compromise review
Detection is difficult because memory scraping can happen quickly and may leave no obvious file artifact. Useful indicators include suspicious processes attaching to the runner, unexpected dumping behavior, unusual child processes, and job activity that does not match the normal build pattern. If a runner is suspected of compromise, assume any runtime secret used in that job may already be exposed.
After an incident, review whether credentials, API keys, deploy tokens, signing keys, and any active sessions were present in memory during the affected jobs. Rotate or revoke those values, invalidate dependent sessions, and verify that downstream systems were not accessed with the stolen material. In practice, the compromise review is as important as the immediate containment step.
Risk and Threat Considerations
Runner memory scraping creates a direct credential-theft path inside trusted automation. The main risk is not just secret exposure, but the downstream ability to impersonate pipelines, tamper with artifacts, or access adjacent systems that accept the runner’s credentials as trusted.
Failure mechanism: An attacker gains code execution on or near the runner, inspects live process memory, and extracts secrets that legitimate pipeline tasks loaded temporarily for use.
Impact: Stolen runtime secrets can enable repository access, artifact manipulation, deployment abuse, lateral movement, or persistent compromise if the exposed material is long-lived or reused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runner memory scraping steals runtime credentials that this control governs across their lifecycle. |
| AC-6 — Least Privilege | Reducing runner privilege directly lowers the value of memory-extracted secrets and the damage they can do. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Suspicious runner process behavior and secret abuse require review of logs and runtime evidence. | |
| Recommendation — Limit secret lifetime, rotate exposed credentials quickly, and revoke any authenticator that may have been in runner memory. Constrain CI runner permissions to the minimum needed for each job and workflow. Correlate runner and job telemetry to investigate unusual process access or secret use. | ||
| CIS Controls v8 | CIS-5 — Account Management | The technique targets credentials and sessions that account governance must tightly scope and revoke. |
| Recommendation — Restrict, track, and remove pipeline accounts and credentials that runners can access. | ||
Practitioner Guidance
What to watch for: Treat memory-exposed secrets as a design choice, not an implementation detail. If a workflow depends on plaintext credentials being present during execution, the safer response is to narrow their lifetime and scope, not to assume the runner boundary alone is sufficient.
Governance implication: Assign clear ownership for runner hardening, secret injection design, and post-incident secret rotation. The team operating CI should be able to answer which jobs ever hold sensitive material in memory and what happens if that material is scraped.
Related resources from NHI Mgmt Group
- Who should own response when browser memory scraping exposes identity data?
- 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 breaks when browser memory is not protected against credential scraping?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org