Glassworm and the Rise of Non-Human Identities in the Software Supply Chain

Executive summary

Recent research into the Glassworm campaign highlights a new class of supply chain attack that combines invisible code injection using Unicode obfuscation, the compromise of developer and publishing credentials, and automated propagation through trusted software ecosystems. While these techniques have been documented by multiple security researchers, the broader implication is often missed: modern supply chains are not primarily operated by humans. They are operated by non-human identities (NHIs). Applications, pipelines, extensions, and package managers act autonomously using tokens and service credentials, and Glassworm succeeds by compromising this layer rather than targeting individual users.

This blog builds on publicly reported findings and reframes them through a critical lens: the real attack surface is the identity layer used by applications to operate.

Background: What Glassworm demonstrates

Public reporting and research, including work by Fluid Attacks and others, describe campaigns where attackers embedded malicious payloads using non-printable Unicode characters, distributed code through trusted repositories and extensions, leveraged compromised developer credentials, and used resilient, decentralized infrastructure for payload delivery. These campaigns affected GitHub repositories, package ecosystems such as NPM, and developer tooling, including VS Code extensions. Importantly, there is no evidence of novel zero-day exploitation. Instead, the attacks relied entirely on trust that was already granted to identities and software distribution mechanisms.

Key Observation: The supply chain is identity-driven

In modern environments, software delivery is executed by systems such as CI/CD pipelines, package managers, build systems, and IDE extensions. These systems operate using API tokens, OAuth credentials, service accounts, and session artifacts, all of which are non-human identities (NHIs). NHIs act without user interaction, execute code automatically, maintain persistent or high-privilege access, and are often weakly governed compared to user identities. This leads to a structural reality: code flows through identities that are not visible, not reviewed, and not continuously validated.

Where Glassworm fits: Exploiting the NHI layer

1. Invisible Code Bypasses Human Review 
Glassworm leverages Unicode techniques, such as zero-width characters, to hide logic that is not visible in standard editors or code diffs, passes both manual and automated review processes, and yet executes when interpreted by machines. This creates a critical gap: humans approve code while machines execute hidden instructions. The attack targets machine interpretation, not human visibility.

2. Credential Compromise Enables System-Level Access 
Attackers obtain source control tokens, package publishing credentials, and extension marketplace access. These credentials are not merely user access points; they are control points for automation systems. With them, attackers can publish updates, modify dependencies, and trigger downstream execution. Compromising a single identity often grants indirect control over multiple NHIs.

3. Automated Systems Enable Propagation 
Once malicious updates are published, package managers resolve and install dependencies, IDEs fetch and execute extensions, and pipelines build and deploy updated code. These processes are automatic, trusted, and identity-driven. Glassworm leverages this to propagate without requiring phishing interaction, manual execution, or additional exploitation.

4. Credential Harvesting Expands the Attack Graph 
Observed behaviors include the collection of developer tokens, environment secrets, SSH keys, and session data. These credentials enable lateral movement across repositories, package ecosystems, and developer environments. This creates a compounding effect: each compromised system increases access to additional identities and automation paths.

5. Resilient Infrastructure Reduces Disruption Options 
Glassworm-related activity has been observed using decentralized or blockchain-based retrieval mechanisms, as well as public platforms for signaling or fallback communication. While implementation details vary, the intent is clear: reduce reliance on centralized infrastructure that defenders can disrupt.

‍

Why traditional security models struggle

Glassworm does not fit neatly into traditional security categories. Code review cannot detect invisible logic. Endpoint security sees only legitimate processes and identities. Network controls have limited visibility into decentralized channels. And IAM tooling is focused on users, not application identities. The result is that malicious activity is executed through legitimate, authenticated workflows, entirely below the threshold of traditional detection.

‍

Reframing the problem: NHIs as the primary attack surface

The key takeaway is not just about obfuscation or credential theft. It is about who, or what, operates the supply chain. Today, pipelines deploy production systems, package managers introduce dependencies, and extensions execute code inside developer environments. All of these rely on NHIs. Yet in many environments, the NHI inventory is incomplete, permissions are excessive, credential lifetimes are long, and monitoring is minimal. This creates a dangerous asymmetry: the most powerful identities in the environment are the least governed.

Detection considerations

Defenders should shift visibility toward identity usage and automation behavior rather than focusing solely on code or infrastructure. At the code level, indicators include the presence of non-printable or unusual Unicode characters and encoding inconsistencies in commits or packages. At the identity level, defenders should watch for token usage from unexpected environments, changes in publishing or commit patterns, and cross-system reuse of credentials. At the system level, indicators include unexpected dependency updates, anomalous extension or package releases, and changes in pipeline behavior.

Mitigation strategies

1. Establish an NHI Inventory. Organizations should identify all service accounts, tokens, and automation identities and map where they are used and what they can access.

2. Reduce Credential Risk. Short-lived, scoped credentials should be the standard. Rotation policies must be enforced, and tokens should be bound to specific environments or workloads.

3. Apply Least Privilege to Automation. Publishing and deployment permissions should be limited, and build, release, and distribution roles should be clearly separated.

4. Validate Code Beyond Visual Inspection. Non-printable Unicode should be detected and blocked in pipelines. Signed commits and artifacts should be enforced, and build outputs should be validated independently.

5. Monitor Identity Behavior, Not Just Access. Organizations should track how identities are used over time, detect deviations in automation workflows, and correlate activity across repositories and systems.

‍

How Unosecur helps organizations stay ahead of identity-driven attacks

While Glassworm itself operates within software supply chains, it reflects a broader shift: attacks increasingly target identities, especially non-human identities, that power modern systems. In SaaS and cloud environments, these identities control access, automation, and data movement, making them a critical layer for both attack propagation and defense. Unosecur helps organizations stay ahead of these risks by focusing on visibility, control, and continuous validation of identities across SaaS and cloud environments. Specifically, Unosecur enables teams to gain visibility into identities across SaaS and cloud environments (including non-human identities), identify overprivileged accounts and risky access configurations before they are exploited, monitor identity usage and detect anomalous activity even when valid credentials are used, reduce credential exposure and limit blast radius in the event of compromise, and bring identity (particularly NHIs) into the center of security operations, where modern attacks operate.

By strengthening how identities are managed and monitored, organizations can detect misuse earlier, reduce the impact of compromised credentials, and limit the ability of attacks to spread.

Key takeaways

Glassworm demonstrates a supply chain attack that succeeds without exploiting any software vulnerabilities. It works by abusing trusted identities and automated systems, where invisible code techniques exploit the gap between human review and machine execution. Non-human identities are central to how software is built, distributed, and executed. Most importantly, the supply chain is no longer just code. It is a system of identities acting on behalf of code.

Conclusion

Glassworm is not an isolated technique; it reflects how modern environments operate. Software delivery is automated, identity-driven, and distributed. Security models that focus only on users or infrastructure miss the core issue entirely. Applications and the identities they use are now the primary execution layer of the supply chain. As a result, securing the software supply chain requires securing non-human identities as first-class assets.

‍