These attacks work because attackers borrow the reputation of a trusted project while inserting malicious code into the development pipeline. If the change is accepted, the attacker can steal cloud credentials, passwords, environment variables, or documents, or use CI execution to spread further. The danger is not just code tampering, but abuse of inherited trust across the software supply chain.
Why cloned repositories and pull requests become a supply chain problem
These attacks are serious because they exploit trust that already exists around a popular repository. A cloned project or accepted pull request can look routine to maintainers, reviewers, and automation, which gives the attacker a path to insert code into a development workflow that others already rely on. That makes the issue less about one bad commit and more about inherited trust being weaponised at scale.
The practical danger is that repository workflows often run with access to sensitive build-time material. If the malicious change lands in a CI job, test runner, or release pipeline, it can expose secrets, alter build outputs, or create a stepping stone into downstream systems. That is why clone-and-PR abuse is a supply chain issue even when the initial entry point looks like ordinary collaboration.
Popular projects increase the blast radius because the same code, workflow, or dependency path is reused by many organisations. Once trust is anchored in the repository name, branch history, or maintainer reputation, the attacker does not need to invent a new delivery channel. They only need to convince the pipeline or reviewer to treat the malicious contribution as legitimate.
Where the real exposure comes from in development pipelines
The highest-risk moment is usually not the repository itself, but what the repository can reach during review, build, or test execution. Secrets in environment variables, CI tokens, package publish credentials, cloud keys, signing material, and automation tokens are all attractive targets because they are often present where the code is evaluated rather than where it is permanently stored.
Another weak point is that supply chain controls are frequently fragmented. One team may review code quality, another may own the pipeline, and another may manage secrets, so no single owner sees the full abuse path. That fragmentation lets a malicious change appear harmless at the code-review layer while still being dangerous once it executes in the pipeline.
For a good reference point on the broader pattern, The Ultimate Guide to NHIs highlights how often secrets are stored in vulnerable locations and how commonly organisations expose non-human identities to third parties. For incident-level context, The 52 NHI breaches Report shows how credential exposure and supply chain abuse reinforce each other in real cases.
How teams reduce trust abuse without breaking collaboration
A strong defence treats repository reputation as insufficient and verifies every change on its own merits. That means tighter branch protection, mandatory review for high-impact paths, restricted CI permissions, short-lived credentials, and clear separation between code review rights and pipeline execution rights. The goal is not to stop collaboration, but to make it harder for a trusted workflow to become a hidden exfiltration path.
One useful statistic from NHIMG’s research is that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That matters here because clone and pull request attacks often succeed by reaching exactly those exposed values during build or review. In other words, the attack is amplified when secret handling is already weak.
For practitioners, the key judgement is whether the repository can cause real downstream impact if a single malicious change is accepted. If the answer is yes, then the review process, CI permissions, and secret exposure all need to be treated as part of the same control boundary, not separate problems. Useful implementation guidance is also covered by NIST SSDF (SP 800-218), SLSA, and CISA cyber threat advisories.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Repository and CI access must be limited to reduce malicious PR impact. |
| CIS 16 — Application Software Security | Protects software delivery paths from tampering and unsafe build behavior. | |
| CIS 8 — Audit Log Management | Reviewing repo and CI activity needs visibility into abuse and secret access. | |
| Recommendation — Restrict pipeline and repository privileges to the minimum needed for each role. Harden software delivery controls and validate builds before release. Centralise and review repository and CI logs for anomalous change and access patterns. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Least-privilege access is central when PRs can reach sensitive pipeline resources. |
| PR.DS — Data Security | Secrets and sensitive build artifacts must be protected from exposure in the pipeline. | |
| DE.CM — Continuous Monitoring | Abuse of trusted repositories requires monitoring for suspicious build and access activity. | |
| Recommendation — Enforce least privilege across repository, CI, and release system access. Protect secrets and build data with strong segregation and controlled handling. Monitor repository and CI activity for abnormal cloning, PR, and secret-access behavior. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Reviewer and maintainer identity assurance affects trust in change approval paths. |
| AAL — Authenticator Assurance Level | Strong authentication reduces the chance that attacker-controlled accounts can approve changes. | |
| FAL — Federation Assurance Level | Federated access to source control and CI must be trusted and bounded carefully. | |
| Recommendation — Raise assurance for privileged repository actions and sensitive approvals. Require stronger authentication for maintainers and release-critical accounts. Limit federated access paths that can approve or trigger privileged pipeline actions. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Clone and PR abuse is a classic software supply chain compromise path. |
| Recommendation — Map repository abuse to supply chain compromise and hunt for staging and propagation. | ||
Practitioner Guidance
What to verify: Check whether pull requests can reach build credentials, deployment tokens, or production-connected environments. If they can, treat that path as privileged access, not ordinary developer workflow.
What to prioritise: Reduce the blast radius first by limiting pipeline privileges, separating secret access from code review access, and removing long-lived credentials from repository-adjacent systems. That is usually more effective than adding more manual review steps alone.
Common mistake: Teams often focus on whether the code is malicious and underweight what the pipeline can do after the code is accepted. For this attack class, execution context is often the real asset.
Practitioner takeaway: If a trusted repository change can touch secrets, signing, or release automation, then the supply chain risk is already present, even before any malicious payload is executed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
