Google Threat Intelligence Group
Mandiant
Written by: Kelli Vanderlee, Stuart Carrera
For years, the cybersecurity industry's understanding of software supply chain compromise has been anchored by a few watershed events, including Russian cyber espionage actor ICE RELIC’s (formerly known as APT29) 2020 compromise of SolarWinds and North Korean cyber espionage actor UNC4736's 2023 compromise of 3CX. However, Google Threat Intelligence Group (GTIG) has been tracking growth in threat activity targeting open source software repositories to conduct supply chain compromises over the past several years. A series of large scale open source software supply chain compromise campaigns in 2025 and the first half of 2026 underscore how important it is that organizations implement defensive strategies that directly address this threat vector.
In this blog post, GTIG and Mandiant discuss trends we have observed in threat actor use of software supply chain compromise, and provide mitigation and hardening recommendations that incorporate insights we have developed as a result of supporting customers through recent campaigns in which threat actors manipulated open source packages.
Open Source Supply Chain Compromise Grows in Volume and Impact in 2025 and Early 2026
The majority of the most impactful and far-reaching supply chain compromise incidents that GTIG tracked in 2025 and early 2026 involved the compromise of code repositories, software dependencies and developer tools (T1195.001). Open source supply chain compromises offer attackers the same efficiency, scale, and initial stealth as traditional supply chain compromises, but typically require significantly less planning and resources to execute. However, open source supply chain compromises are also noisy once enabled; malicious open source packages are often discovered and publicized much more quickly than traditional supply chain compromises.
GTIG assesses with high confidence that the growth in very large-scale, open-source supply chain compromise campaigns, including use of worms and iterative compromises in 2025 and early 2026, represent a significant expansion in use of this tactic compared to prior years. We anticipate that threat actors will emulate the tactics of these campaigns and contribute to growth in open-source supply chain compromise through the rest of 2026 and years to come. GTIG identified several notable supply chain compromises in 2025 and early 2026 that we believe exemplify this trend of exceptionally large campaigns, as measured by size and/or impact (Figure 1).
Figure 1: Notable open source supply chain compromises, 2025 - early 2026
For example from February to May 2026, UNC6780 (aka "TeamPCP") conducted extensive open source supply chain compromises targeting ecosystems like PyPI, npm, and Docker Hub. Initial infection vectors varied across incidents, and included abuse of the pull_request_target
GitHub Actions trigger to obtain base repository secrets and write permissions. The threat actor typically used compromised packages to deploy credential stealers, including SANDCLOCK, to obtain high value secrets. In incident response engagements, we observed UNC6780 attempting to pivot from compromised artificial intelligence (AI) software to broader network environments. UNC6780 has monetized stolen credentials through either direct sale of the stolen data, or through partnerships with ransomware and data theft extortion groups.
In March 2026, GTIG observed the introduction of a malicious dependency in the legitimate axios
package. GTIG analysis and the maintainer's post mortem indicate that the maintainer account was compromised via social engineering and used to publish the updated versions. We identified the malicious dependency as a dropper that deploys the WAVESHAPER.V2 backdoor, and attributes the activity to North Korean actor MIDNIGHT NEPTUNE (formerly known as UNC1069). While the malicious versions of axios were removed from the npm registry within three hours of their release, the scope of the compromise is estimated to be broad, as the package has over 100 million weekly downloads. GTIG supported customers in at least 15 industry verticals and 13 different countries affected by this incident. Further, axios is also a dependency for tens of thousands of other packages, and open sources reported that the malicious axios update had spread to several of these.
AI Likely to Accelerate Open Source Supply Chain Compromises
GTIG anticipates AI will accelerate the growth of open source software supply chain compromise. Integration of AI into open source software development practices, including "vibe coding," increases attacker opportunities both to manipulate AI functionalities and to take advantage of AI to speed and scale their own operational planning. Open sources have documented multiple instances of threat actors planting malicious resources on open source AI communities and inserting malicious code into open source Model Context Protocol (MCP) packages. MCP is a standardized protocol for AI to interact with tools and data. Malicious packages have also tricked AI coding agents, which have unwittingly incorporated them into projects. North Korean threat actors reportedly uploaded malicious cryptocurrency-themed packages, and subsequently an AI coding agent co-authored a commit integrating one of the malicious packages as a dependency to a legitimate cryptocurrency trading project.
Thousands of Malicious Open Source Packages Detected
Corroborating GTIG's findings, statistics compiled by the Open Source Security Foundation (OpenSSF), a cross-industry, non-profit collaboration under the Linux Foundation, indicate that the number of malicious open source software packages identified increased exponentially, or 1,444% from 2024 to 2025 (Figure 2).
Figure 2: Count of malicious open source packages reported 2022–2025 (source: OpenSSF)
Traditional Supply Chain Compromise Remains Rare
In contrast to what we observed in the open source ecosystem, GTIG assesses with high confidence that traditional software supply chain compromise, the manipulation of source code or update/distribution mechanisms (T1195.002), remains rare. The handful of identified cases in 2025 and early 2026 were predominantly cyber espionage incidents with intentionally limited targeting scopes.
In the most significant case, North Korean threat actor UNC4899 reportedly used social engineering to compromise a developer's machine at a web3 organization. The threat actor used this access to inject malicious code into the frontend systems, specifically impacting smart contract functionality to alter transactions initiated by a third party organization that utilized the multi-signature wallet with the targeted organization. This compromise was tailored to a single victim, but did not directly touch the targeted organization's infrastructure. The compromise ultimately led to a cryptocurrency theft of assets with an estimated value of $1.4B USD.
Other examples include the compromise of hosting infrastructure serving updates of Notepad++ from June to December 2025, activity GTIG attributes to UNC6688. GTIG observed organizations in South Korea and France affected by this activity. GTIG also tracked the early 2026 compromise of DAEMON Tools installers. During this campaign, UNC6863 deployed SLICKDEMON to perform broad-spectrum reconnaissance and filter for targets of strategic interest. Following this profiling stage, the group selectively delivered the shellcoded loader BADFALL to facilitate hands-on-keyboard activity and bridge the deployment of the advanced QUIC RAT. The campaign targeted Russia, Brazil, and Turkey, with follow-on exploitation of government and scientific entities in Belarus and Thailand.
In addition to likely cyber espionage incidents, we observed suspected financially motivated compromises with broader distribution. In two separate incidents threat actors compromised underlying software used in consumer-facing websites: in one case, automotive dealership websites served ClickFix lures leading to the installation of SHADOWLADDER (aka SectopRAT), and in another, eCommerce websites were infected with web skimmers.
Mitigation Recommendations
To effectively mitigate and harden against software supply chain compromises, organizations should adopt a multi-tiered defensive strategy designed to minimize exposure and strengthen resilience against potential compromises.
Administrative Oversight and Risk Governance
-
Cataloging Assets and Dependencies: Maintain a tiered, continuous inventory of all applications, third-party vendors, and services based on operational importance to detect single points of failure and security risks.
-
Software Bill of Materials (SBOM): Implement an automated SBOM for all internal and third-party software packages, allowing security teams to continuously monitor and cross-reference active code inventories against newly disclosed vulnerabilities.
-
Action Bill of Materials (ABOM): Maintain a dedicated ABOM to inventory every third-party pipeline vendor and development utility in use, linking it to your container image inventory to track exactly which external actions are building your production images.
-
Software Development Lifecycle (SDLC) Threat Modeling and Attack Chain Mapping (Wiz SITF): Align your software supply chain risk management with capabilities such as the Wiz SDLC Infrastructure Threat Framework (SITF) to transition from treating security as a checklist of isolated controls to a holistic threat model. With this freely available framework, organizations can map recent incidents, threat actor campaigns, and red team exercises directly to Wiz SITF Reference IDs indexing each risk to its specific lifecycle stage: Version Control Systems (VCS), continuous integration and continuous delivery (CI/CD) pipelines, package registries, or production infrastructure. This methodology allows security teams to model complex "attack chains" where minor, isolated weaknesses (e.g., a lockfile bypass combined with an overprivileged pipeline token) are chained together by sophisticated threat actors to execute critical, high-impact breaches
-
Active Risk Monitoring: Maintain a dedicated supply chain risk register and a centralized remediation tracker to systematically group development lifecycle (SDLC) threats into clear operational domains: Governance, Identity, Pipeline Logic, and Supply Chain Hygiene. If using Wiz SITF, each vulnerability must be mapped to its exact pipeline stage with a unique Wiz SITF Reference ID. Instead of treating vulnerabilities as isolated bugs, prioritize the blocking of complex "attack chains" (such as a leaked token combined with missing branch protections and overprivileged OIDC trust) that pose the highest breach risk. Ensure each logged item has a designated owner, a targeted completion date, and clear tracking of technical dependencies.
-
Standardized Configuration & Change Control: Form a Change Advisory Board (CAB) to manage the rollout of all enterprise software and hardware. Ensure every modification includes a pre-deployment risk review, post-deployment monitoring, and a verified plan for recovery or backout.
-
Staff Security Education: Deploy ongoing training initiatives centered on supply chain hazards, social engineering techniques, and internal procedures for reporting incidents.
-
Node.js (npm/pnpm): Enforce cooldown controls by using the
minimumReleaseAge
configuration. Setting this value to at least 24 hours (1440 minutes) ensures that freshly published, potentially poisoned packages are quarantined until the broader security community has had time to identify and remove them. Ensure that older, unsupported package manager versions (such as legacy Yarn or pnpm versions) are modernized, as they will silently ignore these cooldown boundaries. -
Python (pip): Ensure that Python project environments do not pull dependencies directly from the public PyPI registry, which bypasses internal release-age policies and gating controls. All configurations must specify a secure, vetted private
--index-url
in their configuration files to ensure consistent quarantine and vetting of upstream packages.
Vendor Lifecycle Management
-
Vendor Security Vetting: Conduct rigorous due diligence prior to procurement by assessing third-party security frameworks against industry standards such as ISO 27001 or SOC 2.
-
Cybersecurity Provisions in Contracts: Integrate specific security mandates into vendor agreements, including strict timelines for incident notification, persistent audit rights, and clear liability terms.
-
Hardware Provenance and Verification: Use supply chain tracing to confirm the integrity of components, establish methods for detecting counterfeit items, and secure the logistics of repairs and replacements.
Security Architecture and Engineering Controls
Identity and Access Management
-
Automated System and Workload Identities: Transition third-party integrations and build-system processes away from static, long-lived administrative Personal Access Tokens (PATs). Instead, mandate the use of dedicated GitHub Apps or short-lived system tokens via federated OpenID Connect (OIDC) for automated machine integrations. This ensures that credentials used by system-to-system workflows expire in a matter of minutes, neutralizing the risk of a persistent compromise if an automation pipeline is breached.
-
Developer and User Identity Controls (command-line interface (CLI) and Repository Access): Enforce strict access control boundaries for programmatic developer sessions. Because Okta-linked SAML SSO is only capable of verifying identity during the initial creation or authorization of personal tokens and keys, continuous session state cannot be challenged over programmatic CLI connections. Therefore, session security must be enforced through credential expiration and hardware-backed controls.
-
Enforce Strict Token Expiration: Strictly limit the allowable lifespan of all personal access tokens (PATs) and programmatic application programming interface (API) keys to a minimum threshold (e.g.a maximum 7-day limit). This guarantees that credentials expire regularly, forcing developers to re-authenticate through the primary SSO gateway.
-
Consider Restricting Personal Access Tokens to Neutralize Git-over-HTTPS & Mandate FIDO2 Secure Shell (SSH): To protect developer environments against credential theft, organizations should consider restricting Personal Access Tokens (PATs) globally across GitHub Enterprise Cloud. Because GHEC has no direct protocol-disable switch, administrators should consider disabling classic PATs and enforcing short token lifespans to effectively block unauthorized programmatic HTTPS connections. This protocol containment helps encourage developers to shift entirely to SSH authentication. To secure this transport layer, consider mandating the use of hardware-backed FIDO2 security keys to cryptographically verify physical token possession for all command-line repository actions.
-
Isolated CI/CD Execution: Utilize ephemeral runners for build pipelines that are purged immediately after completing a single task. This prevents malicious actors from maintaining a persistent presence between different build phases.
-
Workflow Trigger Governance (pull_request_target): Strictly limit and secure the use of highly privileged triggers such as pull_request_target in automated environments. Multiple prominent supply chain campaigns have actively exploited vulnerable workflows using this trigger as their initial entry vector.
Infrastructure Protection
-
Zero Trust and Least Privilege: Maintain rigorous control over managed service providers (MSPs) and third-party vendors by enforcing role-based access control (RBAC), multifactor authentication (MFA), and frequent audits of access rights.
-
Network Micro-Segmentation: Segregate vital hardware and software from the rest of the enterprise network. Use allow-list-only firewall rules to block unauthorized outbound traffic and disrupt command-and-control (C2) activities.
Secure Development Ecosystems
-
Pipeline and Sandbox Isolation: Ensure that testing environments, CI/CD pipelines, and informal scripting sandboxes are physically or logically isolated from production assets.
-
Artifact Management: To secure the supply chain, organizations can integrate Google's Assured Open Source Software into their internal workflows to defend against dependency confusion and malicious hijacking. This process provides "provenance" cryptographically signed evidence that the code has not been tampered with and originates from a verified source thereby establishing a higher level of trust for third-party dependencies.
-
Quarantine Gates: Require all binaries, packages, and container images to be hosted in monitored internal repositories. To defend against zero-day dependency hijackings, implement localized "quarantine gates" by enforcing cooling windows on newly published third-party assets.
-
Lifecycle Script Sandboxing (ignore-scripts): Mitigate the critical threat of arbitrary code execution by disabling the automatic running of package install scripts. Attackers commonly hijack dependencies and add malicious post-installation execution scripts to steal credentials from developer environments and runners during routine installs. Organizations should mandate
ignore-scripts=true
in their repository-level .npmrc files and configure native allowlists, such as pnpm'sonlyBuiltDependencies
, to restrict execution exclusively to verified, essential tools. -
Software Composition Analysis (SCA) with Google OSV-Scanner: Integrate Google's open source OSV-Scanner tool into CI/CD build pipelines to continuously scan project dependencies for known security flaws. This tool provides an officially supported frontend to the OSV.dev database that maps a project's list of dependencies with the specific vulnerabilities affecting them.
-
High-Fidelity Vulnerability Detection: Unlike traditional scanners that rely on imprecise name matching, the OSV schema stores vulnerability data in a machine-readable format that maps unambiguously onto version ranges and commit hashes. This results in fewer false positives and produces highly actionable remediation notifications, significantly reducing development team triage overhead.
-
Authoritative & Collaborative Threat Intel: The underlying OSV.dev database aggregates high-quality threat intelligence from authoritative open sources, allowing the broader developer community to suggest continuous improvements. Utilizing OSV-Scanner helps developers identify impactful third-party open source vulnerabilities in their applications and focus remediation on genuine risks.
-
Hardware-Backed Key Protection: Secure code-signing certificates using Hardware Security Modules (HSMs) or vaulting solutions. Monitor public transparency ledgers and logs to detect any unauthorized certificate activity.
-
Hardened Distribution Points: Audit and lock down software delivery channels, such as Content Delivery Network (CDN) endpoints and FTP servers, to ensure legitimate binaries cannot be replaced by compromised payloads.
-
Audit NPM Package Maintainer Accounts for Stale or Expired Recovery Email Domains: Expired maintainer email domains are a critical risk because attackers can purchase them to intercept password reset emails, take over the package registry account, and publish malicious code to downstream users. To identify vulnerable packages, organizations can perform the following:
-
Deploy automated scanning tools to audit the entire dependency tree and verify the domain name system (DNS) resolution and registration status of all maintainer email domains.
-
For defense-in-depth, pipelines must disable package execution scripts and employ cold periods.
-
Use by default ephemeral, single-use runners to prevent compromised packages from accessing persistent build environments.
-
Isolate runners in a restricted network segment with strict egress filtering blocks any unauthorized connection to external domains even if an active exploit is triggered.
Integration with Native Ecosystem Guardrails
-
These organization-controlled quarantine policies must operate in conjunction with native platform-level security updates to achieve a Defense-in-Depth posture. Relying solely on client-side configurations or automated update tools in isolation creates single points of failure. The following native platform controls must be orchestrated alongside standard controls:
-
Dependabot Native Cooldowns (July 2026): Dependabot now enforces a default three-day cooldown on version updates to allow for the public discovery of upstream compromises (such as the historical chalk and debug hijackings) before automated Pull Requests are generated].
-
PyPI Server-Side Immutability (July 2026)]: PyPI now natively rejects new file uploads to any release older than 14 days. This prevents adversaries possessing compromised tokens from retroactively poisoning legacy, pinned dependencies (as observed in the LiteLLM and Telnyx compromises) .
-
npm v12 Install-Time Defaults (July 2026): npm v12 disables all lifecycle scripts by default (
allowScripts: off)
, replacing manual, workflow-level ignore flags with explicit, commit-verified package allow-lists
By explicitly aligning baseline configurations including .npmrc and pip.conf registry pinning, immutable installation protocols via npm ci, and runner isolation with these native platform-level guardrails, while committing to the continuous evaluation and adoption of new upstream security features as they are released, the organization establishes a resilient, multi-layered security boundary across the entire software supply chain
Continuous Verification, Monitoring, and Response
Automated Ingestion and Validation
-
Automate SBOM Management: Implement a Software Bill of Materials (SBOM) for all third-party and internal software. This enables continuous monitoring for emerging vulnerabilities like Log4j through automated cross-referencing. Automate and scale this process by feeding SBOMs into central vulnerability management platforms that continuously cross-reference deployed inventory against newly disclosed exploits.
-
Security Analysis Integration: Incorporate automated dynamic application security testing (DAST) and static application security testing (SAST) tools within development pipelines to identify and block compromised third-party code before it is compiled.
-
Verification of Cryptographic Integrity: Prior to installing updates, use automated systems to validate digital signatures and hashes against vendor-provided specifications.
-
Implement autonomous security verification: Organizations should look to integrate advanced security workflows directly into their CI/CD pipelines. These systems can behaviorally evaluate threats by executing simulations in isolated sandboxes, cross-reference those flags with cloud context to determine a flaw's actual reach, and automatically generate tested code patches to rapidly remediate verified risks at scale.
Proactive Threat Hunting and Monitoring
-
Egress and Proxy Analysis: Establish network traffic baselines to identify suspicious egress flows to external repositories or unrecognized Internet Protocol (IP) addresses.
-
Comprehensive Endpoint Security: Utilize endpoint detection and response (EDR) tools across infrastructure and developer workstations to detect post-execution malicious activities from supply chain compromises.
-
Log Aggregation and Alerting: Unified log management should alert on the following anomalies:
-
Development Systems: Watch for unauthorized code changes, build parameter adjustments, or irregular user activity.
-
CI/CD Integrity: Alert on unauthorized workflow modifications or anomalous triggers (e.g., repository_dispatch) that bypass standard code-review gates.
-
Injection Detection: Monitor logs for shell-escape characters or command-substitution patterns within untrusted input variables.
-
Credential Misuse: Track authentication hits on long-lived static keys from unrecognized IP addresses or regions.
-
Physical Assets: Record all firmware modifications, including installation status and source information.
Incident Response Strategies
-
Specific Supply Chain Playbooks: Perform tabletop exercises and document response plans for:
-
Upstream Package Takeover: Maintainer account takeover (ATO) on public registries leading to direct runtime application code manipulation
-
Dependency Confusion Exploits: Malicious registration of lapsed administrative recovery domains or unscoped internal namespaces on public registries to hijack local developer and build runner installations.
-
Automated Pipeline Harvesting: Pipeline poisoning of CI/CD environments via runner exploitation to harvest credentials and perform unauthorized package publication.
- Developer Workstation & IDE Compromise: Targeted social engineering, malicious IDE extensions, or typosquatted local dependencies designed to exfiltrate private cryptographic keys, API tokens, and local session credentials.
-
-
Operational Re-evaluation: Create processes for immediate vendor re-mapping and security re-assessment during industry-wide security events.
Recommendations for mitigation strategies are also available publicly via:
-
Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (NIST SP 800-161 Rev. 1) from the US National Institute of Standards and Technology (NIST)
-
Securing the Software Supply Chain: Recommended Practices Guide for Developers from the US National Security Agency (NSA)
-
WIZ SDLC Infrastructure Threat Framework (SITF) SDLC Infrastructure Threat Framework
Acknowledgements
This analysis would not have been possible without the assistance of Matthew McWhirt and Michael Veal.