Glassworm shows why software supply chains are NHI problems

At a glance

What this is: Glassworm is a supply chain attack that exploits compromised non-human identities, hidden code, and automated distribution to move through trusted software ecosystems.

Why it matters: It matters because IAM, PAM, and IGA teams must govern the identities behind build, release, and dependency workflows, not just the humans who approve them.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Unosecur's analysis of Glassworm and NHI risk in the software supply chain

Context

Glassworm is best understood as an identity failure in the software supply chain. The attack does not need a novel software vulnerability if it can compromise the service accounts, tokens, and publishing credentials that let build systems, package managers, and extensions operate.

That matters because the modern supply chain is executed by non-human identities. When those identities are overprivileged, long-lived, or poorly monitored, code distribution becomes an access problem rather than only a code integrity problem. This is a typical condition in software delivery environments, not an edge case.

The article's key claim is that invisible code techniques and credential abuse work together because human review and machine execution are not governed by the same controls. That gap is where NHI governance becomes the decisive security layer.

Key questions

Q: What breaks when supply chain identities are not governed like privileged assets?

A: The delivery path becomes an attacker-controlled trust channel. A single exposed token or publishing credential can let malicious code move through repositories, registries, and build systems without triggering the kind of scrutiny applied to human accounts. That is why software delivery identities need the same separation, review, and revocation discipline as other privileged NHI assets.

Q: Why do non-human identities increase supply chain risk in developer tools?

A: Non-human identities such as registry tokens, CI secrets, and publishing accounts often have durable access and broad scope. That makes them attractive to attackers who want persistence, propagation, or code injection. In supply chain attacks, those identities can outlive the endpoint that first exposed them.

Q: How do security teams detect malicious software delivery when the code looks legitimate?

A: By looking at identity behaviour and build artefacts together. Check for unusual Unicode, unexpected publishing patterns, token use from abnormal environments, and releases that do not match historical workflow behaviour. A clean diff is not enough if the underlying identity activity is anomalous.

Q: Who is accountable when a stolen publishing token is used to spread malware?

A: Accountability sits with the team that owns the publishing identity, the platform that governs distribution, and the security function that defines revocation and monitoring requirements. In practice, governance must cover the full lifecycle of the token, from issuance to offboarding, because stale publishing access becomes an attack primitive once compromise occurs.

Technical breakdown

How Unicode obfuscation bypasses human code review

Glassworm uses non-printable or zero-width Unicode characters to hide malicious logic inside otherwise legitimate source code. Human reviewers see a clean diff, while parsers and runtimes interpret the hidden instructions. This is not a vulnerability in Unicode itself. It is a mismatch between what humans inspect and what machines execute. The attack succeeds when review processes assume visual inspection is enough, even though the real execution path is machine-mediated and automated. In supply chain environments, that means integrity controls must account for encoding, rendering, and build-time interpretation, not just file contents.

Practical implication: block unexpected Unicode patterns in source, package, and extension pipelines before review ever relies on visual inspection.

Why compromised publishing credentials become control-plane access

Developer tokens, package publishing credentials, and extension marketplace access are control-plane identities. They do not merely authenticate a person. They authorize software distribution, dependency updates, and downstream execution at scale. Once those credentials are stolen, the attacker can act as a trusted publisher rather than an outsider. That changes the blast radius from a single account to every workflow that consumes the compromised channel. In NHI terms, the identity is the control surface, and the software ecosystem inherits its trust decisions from that identity.

Practical implication: treat publishing and deployment identities as privileged NHI assets with tighter scope and shorter lifetimes than ordinary developer accounts.

How automated propagation turns trust into reach

Package managers, CI/CD pipelines, and IDE extensions resolve and execute updates automatically. That means once malicious content is published, downstream systems may consume it without human intervention. The attacker does not need to keep exploiting entry points because the ecosystem performs the propagation work for them. This is why supply chain abuse is so effective against environments that rely on implicit trust between repositories, packages, and developer tools. The mechanism is ordinary automation, but the security failure is that the automation lacks identity-aware validation at each trust boundary.

Practical implication: add identity-aware verification at publish, fetch, and execution boundaries so automation cannot propagate unverified code by default.

Threat narrative

Attacker objective: The attacker aims to turn trusted software distribution channels into a persistent access path for credential theft, code injection, and downstream compromise.

1. Entry occurs when attackers obtain developer tokens, publishing credentials, or extension marketplace access and use those non-human identities as trusted control points.
2. Escalation follows when the compromised identity is used to publish malicious packages or updates that hidden Unicode techniques keep out of normal human review.
3. Impact occurs when automated consumers install or execute the poisoned software, expanding access into repositories, developer environments, and downstream systems.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Glassworm is an NHI problem before it is a malware problem. The article is right to shift attention from code artifacts to the identities that publish, build, and distribute them. A package manager or CI pipeline is not a neutral tool when it authenticates with tokens and service accounts that can be abused like any other privileged NHI. Practitioner conclusion: the supply chain must be governed as an identity estate, not as a collection of files.

Invisible code exploitation creates a review gap, not a detection gap alone. Human approvers and machine interpreters do not consume source in the same way, so visual review is structurally incomplete for obfuscated payloads. That is why supply chain governance needs controls that inspect encoding, rendering, and execution artifacts together. Practitioner conclusion: if your review model assumes humans can always see what machines will run, Glassworm breaks that assumption.

Credential compromise in the supply chain creates identity blast radius. A single publishing token can reach multiple repositories, ecosystems, and downstream automation paths because non-human identities are often reused across systems. That makes the control problem one of scope and separation, not just rotation. Practitioner conclusion: map which automation identities can cascade across environments and remove shared trust paths.

Standing privilege in automation is the core failure mode this campaign exposes. The assumption that publishing access can remain broadly enabled because it is exercised infrequently is designed for slower, human-paced workflows. That assumption fails when the actor is an NHI that can publish, replicate, and trigger downstream execution at machine speed. The implication is that identity governance must stop treating long-lived publishing access as a normal operating state.

Non-human identity governance is now the deciding layer for software trust. Security teams that still anchor supply chain defence in code review or endpoint controls are looking at the wrong boundary. The decisive question is which identities are authorised to change what, and for how long. Practitioner conclusion: govern the identities that create software trust, not only the software they create.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why software delivery identities remain a repeatable attack path.
• That same research line also shows how quickly exposed credentials are acted on, so readers should pair exposure reduction with the 52 NHI Breaches Report to examine recurring identity failure patterns.

What this signals

Identity blast radius is now the right way to think about software supply chain risk. The more build, release, and publishing authority a single non-human identity carries, the more damage one compromise can produce. That is the governing concept teams should use when reviewing CI/CD, package registries, and extension ecosystems, especially as delivery chains get more automated and less visible.

With 43% of security professionals already worried that AI systems may learn and reproduce sensitive patterns from codebases, the pressure on supply chain governance will only increase as automation expands. The right response is to treat publishing identities, secrets hygiene, and build integrity as one control plane rather than separate programme workstreams.

If your programme still measures supply chain security mostly through code review quality or endpoint alerts, it is lagging behind the threat model. The more useful indicators are identity provenance, credential scope, and anomalous automation behaviour, which map naturally to the OWASP Non-Human Identity Top 10 and the MITRE ATT&CK Enterprise Matrix.

For practitioners

• Inventory every publishing and automation identity Map service accounts, API tokens, package publisher credentials, and CI/CD identities to the repositories, registries, and environments they can touch. Remove unknown or duplicate identities first because hidden trust paths are where supply chain attacks compound.
• Separate build, publish, and deploy privileges Prevent one credential from controlling the full delivery path. Distinct identities for build, release, and distribution reduce the chance that a single compromise can push malicious code from source to production.
• Block invisible Unicode and encoding anomalies Add automated checks in pre-commit, pull request, and package ingestion workflows to detect zero-width characters, mixed encodings, and other hidden payload techniques before human review begins.
• Shorten credential lifetimes for software delivery systems Move publishing credentials and automation tokens to short-lived, scoped access with explicit rotation and revocation paths. Where possible, bind credentials to specific workloads or environments so reuse across systems is not possible.
• Monitor identity behaviour, not just code events Alert on unusual publishing times, cross-environment token use, unexpected extension or package releases, and access from non-standard build contexts. Those signals often appear before the malicious payload is visible in downstream systems.

Key takeaways

• Glassworm shows that trusted software distribution becomes fragile when the identities behind it are overprivileged, long-lived, or invisible.
• The relevant evidence is not a novel exploit chain but the repeated abuse of developer tokens, publishing credentials, and automated update paths.
• Teams should harden the identity layer first, because supply chain resilience depends on controlling who can publish, propagate, and trigger execution.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Supply chain control plane: The supply chain control plane is the set of identities, permissions, and automation paths that decide what code gets built, published, updated, and executed. It is an identity problem because trust is enforced by credentials and service accounts, not just by code review or infrastructure policy.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• How the Glassworm campaign affected GitHub repositories, NPM packages, and VS Code extensions across real delivery paths
• The specific detection signals the vendor highlights for Unicode obfuscation, token misuse, and unusual publishing activity
• The remediation steps for reducing credential exposure and separating build, release, and distribution roles
• The vendor's applied perspective on how SaaS and cloud identity controls can reduce blast radius in software delivery workflows

👉 Unosecur's full blog adds the campaign background, detection signals, and mitigation steps for software delivery identities.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.