Topic starter
17/08/2026 5:39 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Glassworm Attack Explained: Supply Chain Risks & Non-Human Identities”.
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.
A: A single compromised publishing token can let an attacker overwrite trusted images and distribute malicious code through normal update channels.
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.
Practitioner guidance
- Inventory publishing and build identities Map every service account, token, OAuth grant, and publishing credential that can move code, packages, or extensions.
- Shorten credential authority windows Move from long-lived publishing tokens to scoped, short-lived credentials wherever automation can tolerate them.
- Block invisible character abuse in pipelines Add pipeline checks for non-printable Unicode, encoding anomalies, and suspicious diff content before merge or publish.
Bottom line: Glassworm shows that software supply chains fail when trusted automation is allowed to act with broad non-human identity authority.
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
👉 Read Unosecur's analysis of Glassworm and the software supply chain identity problem →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/08/2026 5:40 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Glassworm shows why software supply chains are NHI problems