SCM persistence is the use of source control and repository automation to keep attacker access alive after the first compromise. It can include malicious workflows, runner registration, or artifact abuse, all of which let the attacker re-enter through systems the organisation still trusts.
What SCM Persistence Means in Practice
SCM persistence is not just “staying in a repo,” it is a post-compromise foothold built inside the software delivery system itself. The attacker uses trusted repository features, automation, and build relationships to keep access available even after one credential, session, or host is cleaned up.
That makes it different from opportunistic malware living on a single endpoint. The persistence layer is the collaboration and delivery plane, where commits, workflows, runners, artifacts, and pipeline permissions can be abused to re-establish control without needing to break in again from scratch.
How SCM Persistence Works
Common persistence paths include malicious CI or repository workflows, newly registered or hijacked runners, tampered build scripts, and poisoned artifacts that are later consumed by trusted jobs. Each path turns ordinary automation into a re-entry point, which is why SCM persistence often survives basic password resets and host rebuilds.
The attacker’s goal is usually to preserve execution authority, not merely visibility. Once that foothold exists, the repository or pipeline can become a dependable launchpad for later credential theft, code tampering, supply-chain abuse, or covert staging activity.
Why SCM Persistence Is Hard to Spot
SCM environments are designed to trust frequent change, delegated contribution, and machine-driven automation. That operational model creates ambiguity, because a malicious workflow file, runner registration, or artifact update can look like normal engineering activity unless reviewers know what to inspect.
Persistence is especially effective when access is spread across multiple trusted systems. A cleaned-up user account may not remove a runner token, a workflow secret, or an artifact reference, and an organisation may miss the leftover path if it only checks the original compromise point. The broader identity and access exposure is often best understood through Identity Threat Detection and Response (ITDR) Guide, which covers persistence and response patterns across identity-driven attacks.
Where SCM Persistence Connects to the Wider Attack Chain
SCM persistence is valuable to attackers because it sits at the intersection of source code, build automation, and release trust. That means it can be used to re-enter quietly, alter shipped software, or support lateral movement into adjacent developer, cloud, or credentialed systems once the pipeline is trusted again.
It also overlaps with broader trusted-infrastructure abuse. Campaigns that combine stolen credentials with compromised trusted systems show how attackers use legitimate mechanisms to remain resident and expand, as seen in Salt Typhoon telecom intrusions 2025, where credential abuse and trusted network paths were central to persistence.
Risk and Threat Considerations
SCM persistence creates a high-trust failure mode: the compromise can survive ordinary cleanup because the attacker has embedded themselves in the system that produces and ships software. That increases the chance of repeated reinfection, hidden tampering, and delayed detection across multiple releases or environments.
Failure mechanism: The attacker abuses repository automation, runner registration, or artifact trust to preserve a re-entry path after the initial intrusion appears resolved.
Impact: Code integrity, build integrity, and downstream deployment trust can be undermined at scale, with persistent exposure extending to secrets, release pipelines, and dependent systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0003 — Persistence | SCM persistence is a persistence technique using trusted delivery systems. |
| T1078 — Valid Accounts | SCM persistence often relies on abused legitimate repository or automation accounts. | |
| T1552 — Unsecured Credentials | Repository and pipeline secrets are often the mechanism that sustains re-entry. | |
| Recommendation — Map repo and pipeline abuse to persistence tradecraft and hunt for surviving footholds. Review legitimate account use for signs of abuse and revoke suspicious access paths. Search for exposed automation secrets and remove any credentials that enable repeat access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Persistent SCM access depends on durable accounts, tokens, runners, and service identities. |
| Recommendation — Tighten lifecycle control over repository and automation accounts, tokens, and runners. | ||
| SLSA | Supply-chain integrity | SCM persistence threatens build provenance and artifact trust in the supply chain. |
| Recommendation — Strengthen build provenance checks and reject artifacts that lack verified lineage. | ||
Practitioner Guidance
Why practitioners should care: SCM persistence is a governance and operations problem, not just a malware-removal problem. If the delivery system is trusted by default, then persistence can hide inside the very controls teams use to ship quickly.
What to watch for: Unexplained workflow edits, new or unfamiliar runners, unusual artifact changes, and repository automation that appears to outlive the user or host that created it deserve immediate review. OWASP Non-Human Identity Top 10 is useful here because it frames the secret, privilege, and lifecycle weaknesses that often make persistent automation abuse possible.
For response depth, the right question is not only “what was compromised?” but also “what trusted build and release path still remains?” A robust investigation should treat SCM, CI, and artifact systems as part of the compromise surface, not as neutral infrastructure.
Related resources from NHI Mgmt Group
- When does malware persistence become an NHI governance issue?
- How do security teams know if persistence has been established on a compromised AI node?
- How should security teams prevent unwanted persistence in Active Directory and Entra ID?
- Why do stale accounts and old privilege create such a large persistence risk?
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 October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org