TL;DR: Unosecur shows that Glassworm combines invisible Unicode payloads, compromised publishing credentials, and automated propagation to turn trusted software channels into a supply chain attack path. The real control gap is identity governance for the non-human systems that build, publish, and distribute code, not code review alone.
At a glance
What this is: This analysis frames Glassworm as a software supply chain attack that exploits non-human identities, credentialed automation, and invisible payloads rather than software flaws alone.
Why it matters: It matters because IAM, PAM, and NHI governance teams have to treat build, publish, and distribution identities as first-class assets, or trusted automation becomes the attack path.
👉 Read Unosecur's analysis of Glassworm and the software supply chain identity problem
Context
Glassworm is a software supply chain problem because the compromise path runs through identities that publish, build, and distribute software, not through a single vulnerable application control. In practice, that means the trust boundary is the automation layer: tokens, service accounts, and extension or package publishing credentials.
The article argues that modern software delivery is executed by non-human identities, so human review alone cannot see every malicious action. That is the governance gap for IAM and NHI programmes, especially where CI/CD runners, package managers, and developer tooling hold persistent or high-value access.
The article's central claim is that the supply chain is identity-driven. That is typical of contemporary software ecosystems, where machine-to-machine trust is built into delivery pipelines before defenders ever see the resulting code.
Key questions
Q: What breaks when non-human identities are not governed in software supply chains?
A: When non-human identities are not governed, attackers can use tokens, service accounts, and secrets to reach build, release, and data systems that were never meant to be exposed together. The result is hidden persistent access, broad blast radius, and compromise that can spread through trusted automation before anyone notices.
A: A single compromised publishing token can let an attacker overwrite trusted images and distribute malicious code through normal update channels. That turns the release pipeline into the delivery mechanism for malware, which means downstream users inherit the compromise from a seemingly legitimate artifact. The risk is amplified when teams trust signed or familiar sources without runtime verification.
Q: What are the signs that a software supply chain identity is being abused?
A: Watch for unexpected token usage, cross-environment reuse of credentials, unusual publishing times, and artefacts that appear from identities that do not normally publish. Also look for encoding anomalies such as non-printable Unicode in source or packages. Those signals often appear before downstream compromise becomes obvious.
Q: How should teams govern build and release identities in appsec?
A: Treat build and release credentials as privileged machine identities with limited scope, short lifetimes, and strict ownership. If those identities can sign, deploy, or fetch dependencies broadly, a code flaw can become a platform-wide incident. Identity controls should be part of every vulnerability remediation discussion.
Technical breakdown
How invisible Unicode payloads bypass human review
Glassworm uses non-printable or zero-width Unicode characters to hide malicious logic inside code that still executes normally when interpreted by machines. This creates a split between what reviewers see and what build or runtime systems process. The issue is not simply obfuscation; it is that automated interpretation follows the encoded content, while human inspection often collapses it into something harmless-looking. In supply chain terms, that means code review and diff inspection can validate the visible surface but miss the executable intent. The control problem sits at the boundary between human readability and machine execution.
Practical implication: block or flag unusual Unicode in repositories and pipelines before code reaches build or publishing stages.
Why publishing credentials turn a single compromise into ecosystem control
The article describes stolen developer tokens, package publishing credentials, and extension marketplace access as control points for automated distribution. These are NHI credentials because they do not authenticate a person in isolation, they authorise software systems to act on behalf of that person or team. Once attackers hold those credentials, they can publish malicious updates, modify dependencies, and trigger downstream installs through trusted channels. That is why supply chain compromise often scales faster than endpoint compromise: the attacker inherits the distribution privileges of the publishing identity, not just access to one workstation.
Practical implication: separate build, release, and publishing identities so one credential cannot control the full software distribution path.
Why automated propagation makes the supply chain an identity problem
Package managers, CI/CD systems, and IDE extensions consume updates automatically, which means propagation happens through legitimate authenticated workflows. That makes the supply chain a machine-to-machine trust problem, not just a malware delivery problem. Glassworm succeeds because downstream systems trust signed or published artefacts enough to execute them without a human re-authorising each step. In governance terms, the blast radius is defined by how far a credential can propagate trusted actions across repositories, registries, and developer environments. Security teams need to think in terms of identity reach, not only code provenance.
Practical implication: limit the blast radius of automation credentials and verify artefacts independently before execution.
Threat narrative
Attacker objective: The objective is to weaponise trusted software distribution paths so malicious updates propagate through developer and build ecosystems under valid identity and automation trust.
- Entry occurs when attackers gain access to developer, publishing, or extension credentials that can act as non-human identities in trusted software ecosystems.
- Credential access expands as attackers collect tokens, environment secrets, SSH keys, and session data that let them move from one automation path to another.
- Lateral movement happens when compromised publishing rights are used to push malicious updates through repositories, package systems, and developer tooling.
- Impact is the spread of malicious code through trusted distribution channels, creating ecosystem-wide contamination without a traditional exploit chain.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Glassworm is not a code-review failure first, it is an identity-governance failure first. The attack works because the software supply chain already trusts non-human identities to publish, build, and distribute at machine speed. Human review can miss hidden payloads, but the deeper problem is that trusted automation has been granted durable authority over software movement. Practitioners should treat the publishing identity as the control plane, not a supporting detail.
Non-human identities are the primary execution layer of modern software delivery. CI/CD runners, package managers, and marketplace publishing accounts act on behalf of software teams with minimal human intervention. That means supply chain risk is no longer limited to source code integrity; it extends to the credentials that move artefacts through the ecosystem. The implication is that NHI governance, not just secure coding, now sits inside software supply chain defence.
Invisible payloads expose the limit of visual assurance. Unicode obfuscation defeats the assumption that a human reviewer can reliably validate what a machine will execute. That assumption was designed for readable code paths and manual approvals. It fails when attackers encode behaviour that is only visible to parsers and runtimes. The implication is that assurance has to move from eyes-on-code to policy on machine interpretable content.
Ephemeral trust debt is the right concept for this problem. Every publishing token, session artifact, or service credential creates a short or long window in which trusted automation can be abused. Glassworm shows that when those windows are wide, one compromise becomes a distribution event. The practical conclusion is that software supply chain teams need to govern credential lifetime and authority as actively as they govern source control.
Supply chain security has become a cross-domain identity discipline. This is where human IAM, NHI governance, and build-system controls intersect. The same organisation that manages developer sign-in also has to manage the credentials that let automation act independently across repositories and registries. Teams that keep these controls in separate silos will keep missing the attack path.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: Ultimate Guide to NHIs
What this signals
Identity blast radius is the better way to think about software supply chain risk. The question is not whether a package or extension is trusted at the moment of release. The question is how far that trust can travel once a publishing identity is compromised, because every additional trust edge increases the number of systems that will consume malicious updates before detection.
Supply chain defenders need to move from artefact-centric controls to identity-centric controls. Code signing, review, and dependency scanning still matter, but they do not answer who can publish, who can rotate credentials, or who can revoke access when the release path changes. That is where NHI governance becomes the control that limits spread rather than merely documenting it.
For practitioners
- Inventory publishing and build identities Map every service account, token, OAuth grant, and publishing credential that can move code, packages, or extensions. Record where each identity is used, what it can publish, and which downstream systems trust it.
- Shorten credential authority windows Move from long-lived publishing tokens to scoped, short-lived credentials wherever automation can tolerate them. Pair that with enforced rotation and revocation for developer and release identities.
- Block invisible character abuse in pipelines Add pipeline checks for non-printable Unicode, encoding anomalies, and suspicious diff content before merge or publish. Treat these as supply chain integrity signals, not just code-quality issues.
- Separate build, release, and distribution roles Ensure the identity that compiles code is not the same identity that publishes artefacts or approves downstream distribution. Segregation reduces the blast radius when one credential is stolen or reused.
- Monitor identity behaviour, not just access Track token usage from unusual environments, cross-system reuse of credentials, and unexpected publishing patterns across repositories and registries. Behavioural drift often appears before the malicious update is visible.
Key takeaways
- Glassworm shows that software supply chains fail when trusted automation is allowed to act with broad non-human identity authority.
- The campaign combines hidden payloads, credential compromise, and automatic propagation, which makes the distribution layer the real attack surface.
- Teams that want to reduce exposure need stronger lifecycle control over publishing identities, not only more code inspection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Glassworm depends on leaked or stolen publishing and automation secrets. |
| NHI-05 — Overprivileged NHI | Publishing and release identities often hold more authority than the task requires. | |
| NHI-07 — Long-Lived Secrets | Long-lived tokens extend the window for supply chain abuse after compromise. | |
| Recommendation — Scan repositories and build logs for exposed automation secrets and revoke any leaked credentials immediately. Reduce publish and release authority to the minimum scope needed for each automation identity. Replace long-lived publishing secrets with short-lived, tightly scoped credentials wherever possible. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The campaign progresses through stolen credentials and propagation across trusted systems. |
| Recommendation — Map compromised publishing identities to TA0006 and TA0008 to prioritise containment across adjacent systems. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core failure is excessive authority in automation and release identities. |
| Recommendation — Review automation entitlements under PR.AA-05 and remove rights that are not needed for publishing. | ||
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.
- Supply Chain Identity: The collection of credentials, tokens, workflow permissions, and publishing rights that let software move from source to deployment. In NHI terms, it is the identity layer of the pipeline, and when it is weak, compromise can propagate through legitimate automation rather than obvious malware channels.
- Ephemeral trust debt: Ephemeral trust debt is the accumulated risk created when short-lived access, credentials, or trust relationships are issued quickly and not fully governed. In practice, it appears when temporary permissions, tokens, or sessions outlive their intended purpose, lack clear ownership, or are not revoked, audited, or rotated with enough discipline.
- 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.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- Examples of invisible Unicode techniques used to hide malicious logic in code and packages
- The article's specific detection ideas for token misuse, extension abuse, and anomalous publishing behaviour
- Unosecur's mitigation list for short-lived credentials, segregation of release roles, and runtime monitoring
- Context on how the campaign affected repositories, npm ecosystems, and VS Code extension channels
Deepen your knowledge
NHI governance, workload identity security, and secrets management 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.
Published by the NHIMG editorial team on August 17, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org