The cybersecurity industry has a habit of studying the evidence while ignoring the crime scene.
Every time a software supply chain compromise makes headlines, we focus on the package, dissecting the malicious code, and analyzing the dependency chain. We debate software integrity, package signing, SBOMs, repository security, and development practices.
Those conversations are important, but they’re often focused on the wrong thing.
The recent compromise involving Microsoft-associated npm packages is a perfect example. According to reporting from Ars Technica, attackers were able to introduce credential-stealing functionality into trusted packages after gaining access to credentials associated with the publishing process.[1] The malware became the story because it was the artifact everyone could examine.
What interests me is what happened before the malware ever appeared. Software doesn’t compromise itself. Somewhere along the line, an attacker acquired access to something the ecosystem already trusted, such as a credential, publishing workflow, or privileged identity. The malware showed up at the end of the story, but the compromise began much earlier.
That’s why I titled this article Stop Blaming the Package.
Because the package is evidence.
The trust relationship is the crime scene.
One of the things that still surprises me about our industry is how often we talk about trust as though it were a security control when it isn’t.
Trust is an assumption.
Sometimes trust is unavoidable and modern enterprises would grind to a halt without it. The problem isn’t that trust exists, but that organizations often stop treating trust as something that requires governance the moment it becomes operationally convenient. That tendency becomes increasingly dangerous as organizations rely on interconnected systems, automation platforms, machine identities, and software delivery pipelines that make decisions on behalf of users and businesses every day.[3][5][7]
Over the years I’ve watched organizations spend millions of dollars hardening systems while leaving access decisions and inherited permissions largely unquestioned. Access accumulates. Service accounts remain active. Machine identities inherit permissions. Temporary exceptions become permanent configurations. Eventually nobody remembers why a particular identity has access to a particular resource. The environment keeps functioning, so nobody asks the question.
Attackers ask that question every day.
When I was younger and operating on the other side of the fence, nobody sat around trying to defeat every security control in an environment. We looked for the places where people had stopped questioning access. That’s where convenience had quietly replaced scrutiny and where trust had become invisible.
Human nature has changed far less than the technology surrounding it. The tools, targets, and environments may be different, but attackers are still drawn to the same opportunities: excessive trust, unnecessary access, and assumptions that nobody bothers to revisit.
That is what makes incidents like this important.
The real lesson is not that software supply chains can be compromised. The real lesson is that modern enterprises continue to underestimate the security implications of inherited access. We are building increasingly sophisticated ecosystems that depend on identities making decisions on behalf of users, applications, services, automation platforms, and now AI-driven workflows. Every one of those identities participates in an authorization model and each one of those models creates a potential attack path if access is not continuously governed.[4][5]
That observation is not theoretical. Breach investigations repeatedly show that attackers are remarkably effective at exploiting valid credentials, existing permissions, and established access paths because those pathways often generate less resistance than traditional intrusion techniques. [2][4][6]
The Microsoft package incident should prompt organizations to ask an uncomfortable question: if a trusted publishing identity inside your environment were compromised today, how much damage could it actually cause?
Many security leaders would struggle to answer that question with confidence, and that should concern them more than the malware itself.
The Enterprise Runs on Identities
A lot of organizations still treat identity as an administrative problem. The team that manages accounts sits over here. The team that manages infrastructure sits over there. The security team tries to keep both honest.
That distinction stopped making sense years ago.
Cloud platforms operate through identities. DevOps pipelines operate through identities. Infrastructure automation operates through identities. Applications authenticate through identities. APIs communicate through identities. Secrets are accessed through identities. Increasingly, AI-driven systems operate through identities as well.[3][5][7]
Remove those identities and business operations stop.
Identity isn’t adjacent to infrastructure anymore, and in many organizations, identity is the infrastructure.
When viewed through that lens, incidents like the Microsoft package compromise begin to look different. The software package becomes the visible symptom and the more significant issue is that a trusted identity possessed sufficient authority to influence software consumed by others. Once that identity was compromised, the attacker gained access to a distribution mechanism that organizations already accepted as legitimate.
That is a very different problem than malicious code.
AI Is Accelerating a Problem We Already Had
The timing of this incident is particularly interesting because it arrives as organizations rapidly integrate AI-driven development and automation capabilities into enterprise workflows.
Much of the public conversation around AI security focuses on model behavior, hallucinations, intellectual property concerns, or regulatory questions. Those issues matter, but they are not the risk that concerns me most.
What concerns me is the speed at which organizations are creating new trusted identities.
AI agents are being granted access to repositories, development environments, cloud resources, ticketing systems, documentation platforms, and operational workflows. In many cases these systems perform actions automatically. They retrieve information, generate code, execute tasks, and interact with infrastructure.
In other words, they participate in the same access ecosystem as human users.
The security conversation should not be limited to what an AI system knows. It should also include what it is allowed to do. Machine identities are rapidly becoming some of the most privileged entities inside enterprise environments, yet governance practices frequently lag behind adoption.[5][7]
Attackers are unlikely to overlook that imbalance, and neither should defenders.
Security Maturity Is Measured by Blast Radius
Security teams often evaluate success through prevention metrics. How many attacks were blocked? How many vulnerabilities were remediated? How many alerts were generated?
Those measurements have value, but they often say more about prevention than resilience. A more useful measure of security maturity is understanding what happens after compromise occurs.
Every mature security leader understands that compromise is possible. Credentials can be stolen. Systems can be misconfigured. Users can make mistakes. Vendors can experience failures. Software can contain vulnerabilities.
The organizations that consistently recover from these events are rarely the ones that believed compromise was impossible. They designed their environments with the expectation that access controls, credentials, and authorization boundaries would eventually fail.[3][5]
Least privilege matters for this reason, continuous access review matters for this reason, credential governance matters for this reason, and visibility into privileged activity matters for this reason.
These controls do not eliminate risk. They reduce consequences.
Security maturity is increasingly measured not by whether compromise occurs, but by whether compromise can spread.
The package was compromised. That much is clear.
What is less clear is whether the industry is learning the right lesson from incidents like this.
The package was the delivery mechanism. The credential was the enabling event. The trust relationship was the attack surface.
Those are not interchangeable observations.
As enterprises become more dependent on automation, machine identities, software ecosystems, and AI-driven workflows, access decisions will continue to grow in both complexity and importance. Attackers understand that reality. They understand that compromising a trusted identity often provides greater value than compromising a single endpoint or exploiting a single vulnerability. The use of valid accounts and inherited permissions remains one of the most effective ways to blend malicious activity into legitimate operations.[2][4][6]
That is why we need to stop looking at incidents like this as software stories when they’re access stories, identity stories, and governance stories.
The malware was discovered in a package and the compromise occurred when trust changed hands.
Until organizations begin treating trust itself as critical infrastructure, they will continue focusing on the package while missing the more important lesson hiding underneath it.
Len Noe is a Solutions Architect at BeyondTrust, Transhuman, Podcaster, International Cyber Security Speaker, Author, Technical Evangelist, and Biohacker with 11 implanted microchips.A former blackhat with more than 30 years in technology, he has presented in over 70 countries and is featured in the documentary I Am Machine, which premiered at DEF CON 2025.
[1] Dan Goodin, “For the 2nd time in weeks, Microsoft packages laced with credential stealer,” Ars Technica, June 2026.
https://arstechnica.com/security/2026/06/for-the-2nd-time-in-weeks-microsoft-packages-laced-with-credential-stealer/
[2] Verizon, 2025 Data Breach Investigations Report (DBIR).
https://www.verizon.com/business/resources/reports/dbir/
[3] Cybersecurity and Infrastructure Security Agency (CISA), Secure by Design.
https://www.cisa.gov/securebydesign
[4] MITRE ATT&CK Framework, T1078 – Valid Accounts.
https://attack.mitre.org/techniques/T1078/
[5] National Institute of Standards and Technology (NIST), SP 800-207: Zero Trust Architecture.
https://csrc.nist.gov/publications/detail/sp/800-207/final
[6] Microsoft Security, Microsoft Digital Defense Report 2025.
https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report
[7] National Institute of Standards and Technology (NIST), SP 800-204D: Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines.
