Welcome to the Reality of Supply Chain Attacks

The story changes when the attacker stops hiding the code and starts distributing it as a legitimate open-source project under permissive OSS license. With Shai-Hulud published openly on GitHub, complete with source code, a README, and an MIT license, the threat is no longer only the payload. The threat is the way malicious code can be made to look familiar, legitimate, and easy to adopt.

That is what makes this moment different. This is not only another supply chain compromise, another malicious package, or another reminder that CI/CD environments are now part of the attack surface. This is something more uncomfortable: hostile code presented in the shape of open source.

A public repository creates familiarity. A README creates structure. A permissive license reduces friction. A package manifest gives the project a normal software shape. To a developer moving quickly, those signals can look routine. To a defender, they should raise a harder question: what happens when the attacker understands not only our technology, but also our trust habits?

A Project That Should Not Be Treated Like One

Most software teams know what a normal open-source project looks like. It has source folders, dependencies, build instructions, documentation, and a license. Those signals are part of how developers quickly decide whether something is worth reviewing, testing, or reusing.

But none of those signals prove safety. A README does not prove intent. A license does not validate the author. A public repository does not mean the code was published in good faith. A familiar project structure does not make hostile behavior less hostile.

That is the lesson Shai-Hulud forces into the open. The attacker is not only releasing code. The attacker is borrowing the language of software development to make malicious code feel normal.

The dependency tree reads like an attacker's shopping list: obfuscation, tarball manipulation, cloud exfiltration, resilient retry logic. Every capability the worm has demonstrated in the wild is sitting right there in the manifest. The dependencies tell the whole story.

The other important signal is how much legitimate open source appears to be used in the implementation itself. That is part of what makes this case so uncomfortable. The project does not look like a hand-built artifact sitting outside the software ecosystem. It appears to be assembled with the same open-source building blocks, package patterns, and dependency conventions that legitimate projects rely on every day.

That creates a difficult but important lesson for defenders. Open source is not the problem; open source is the environment. The same ecosystem that helps developers build faster can also help attackers build faster. In this case, the dependency choices do not only support functionality. They also show how easily normal open-source components can be combined into tooling for obfuscation, packaging, exfiltration, and resilience.

The SBOM also gives us another useful signal: the age distribution of the components used by the project. The dependency set is not only made of fresh packages. It includes components spread across multiple age ranges, including older and unknown-age components. That matters because malicious projects do not need to rely only on new or exotic tooling. They can assemble capabilities from ordinary open-source components that already exist across the ecosystem.

This is another reason SBOM analysis is useful even when looking at hostile code. It helps defenders understand not only what the project does, but how it was built. Component age, dependency structure, and package selection can all become part of the intelligence picture. They show whether the project was assembled quickly from available building blocks, whether it depends on older software, and where defenders may want to look for detection, exposure, or policy signals.

This is why SBOM visibility matters even for hostile projects. The dependency tree tells us how the project was constructed, which capabilities were likely assembled from existing components, and where defenders may find useful signals for detection, analysis, and exposure review.

This is the new shape of the supply chain threat. The attacker is not only hiding inside packages. They are publishing. They are branding. They are using the same ecosystem signals that legitimate software projects rely on every day.

Why Would TeamPCP Publish the Source Code?

We should be careful here. We do not know the exact motive, and good threat intelligence should separate what we can observe from what we infer. But the act of publishing the source code is meaningful by itself.

One possible reason is copycat enablement. By making the code available in a familiar open-source format, the attacker lowers the barrier for others to study the approach, reuse pieces of it, or build their own supply chain worm. That does not mean everyone who sees it will misuse it, but it does mean the playbook becomes easier to access.

Another possible reason is reputation. Some threat actors do not only want access. They want attention. They want to show capability. They want defenders, maintainers, and other attackers to know they exist. Publishing source code can become a message: this is what we built, this is how far we can push the ecosystem, and this is how difficult it may be to contain the idea once it spreads.

There is also a persistence angle. Code that is public can be copied, forked, mirrored, and discussed. Even if the original repository disappears, the method can continue to circulate. The malware itself may be disrupted, but the knowledge, patterns, and implementation details can survive.

Could it be an attempt to get the open-source community to improve or maintain it? In the traditional good-faith sense, that seems unlikely. This does not look like a normal project looking for maintainers. It looks more like a hostile release using open-source conventions to create attention, confusion, and reach.

The most important point is this: the source release may be part of the operation. Not because every person will run it, but because it spreads the idea, the method, and the confidence that this kind of attack can be copied.

Friendly License, Malicious Intent

The MIT license matters because it is usually associated with low friction. In legitimate open source, permissive licensing helps teams adopt software faster, avoid unnecessary legal complexity, and move with confidence.

But a license is not a security control. An MIT license does not inspect the code. It does not prove the publisher is trustworthy. It does not tell you whether the package is safe to install. It does not prevent credential theft, malicious build logic, or abuse of automation.

That is why this case is important. A friendly license can sit beside malicious intent. A clean-looking repository can still represent serious risk. A familiar software format can become part of the attack surface.

Security teams need to separate legal permissibility from technical trust. The license may say the code is easy to reuse. Security still has to ask whether it should be trusted at all.

The Real Attack Is Against Trust

The uncomfortable part is that attackers understand how modern software teams work. They know developers rely on package managers, dependency graphs, public repositories, automation, CI/CD pipelines, tokens, and release workflows. They know many organizations move fast. They know teams often trust what looks familiar.

That means the attack surface is no longer only the application. It is the entire software production system around it.

The repository, the package, the dependency, the build runner, the token, the release process, the container, and the final artifact are all connected. If one part of that chain is abused, the impact can move quickly.

So the question is no longer only, “Is this malware?” The better question is, “Could something like this enter our products, pipelines, or release artifacts without us knowing?”

That is the question that matters.

Are We Exposed?

When a campaign like this becomes public, security teams hear the same question from leadership: are we exposed?

It sounds simple. It is not simple if your visibility is fragmented. If answering that question requires manual checks across repositories, build systems, containers, product versions, and engineering teams, the organization is already moving too slowly. The news cycle moves faster than manual investigation. The attacker moves faster than ticket queues.

To answer with confidence, teams need to know what is inside every product and every release. They need to know whether exposure is direct or transitive. They need to know whether a risky component appears only in source, or whether it made its way into a shipped binary, container, firmware image, or customer-facing release.

That is where SBOMs move from compliance artifact to operational capability.

For Fun, We Generated an SBOM for the Repository

While the Shai-Hulud repository was still available on GitHub, we generated an SBOM for it as a defensive research exercise. The repository is no longer accessible and now shows as disabled by GitHub due to a Terms of Service violation.

That may sound unusual, but it is exactly the point. If malicious source code is being distributed like a legitimate open-source project, then defenders should be able to analyze it like software. An SBOM helps turn the repository from a headline into something structured: components, dependencies, package relationships, and signals that can be reviewed, searched, and monitored.

You can review the SBOM here:

Download the Shai-Hulud SBOM

This SBOM should be treated as a research artifact. It is not an endorsement of the repository, and it should not be used to execute or operationalize the code. Its value is defensive: understanding what the project declared, how it was structured, and what the dependency tree can tell us.

Why SBOMs Matter Here

SBOMs matter because they help answer real exposure questions under pressure. Not as paperwork. Not as a checkbox. Not as a file stored somewhere and forgotten.

A useful SBOM program should give teams visibility across source components, binary components, direct dependencies, transitive dependencies, package managers, containers, build artifacts, and released product versions. It should help security and product teams understand not only what was declared during development, but what actually shipped.

That distinction matters. Source-level visibility is important, but it does not always represent the full product. Real products often include compiled components, containers, third-party binaries, legacy software, and artifacts that do not map cleanly back to a package file.

For Shai-Hulud-style supply chain risk, the goal is simple: when someone asks “are we exposed?” the answer should not take days. It should be searchable, explainable, and tied to the products and releases that matter.

What Defenders Should Do Now

The response is not to stop using open source. That would be unrealistic and unnecessary. The response is to stop treating open-source signals as trust signals by themselves.

A public GitHub repository, a clean README, an MIT license, and a familiar project structure should not be enough to move code into a product, build pipeline, or developer environment. Those signals may tell you how the project is packaged, but they do not tell you whether the code is safe, who controls it, or what it will do during install, build, or runtime.

For defenders, the practical shift is to inspect what the project actually contains and where it could create exposure. That means looking at the dependency tree, install scripts, build behavior, network activity, credential access, package publishing logic, and any automation that could touch CI/CD secrets or developer tokens.

The goal is not to slow engineering down for no reason. The goal is to make sure that when code looks legitimate, there is still a process to verify whether it behaves legitimately.

Organizations should also strengthen SBOM coverage across both source and binary artifacts. If source is incomplete, unavailable, or different from what shipped, binary analysis becomes essential. The real question is not only what the developer intended to include. The real question is what ended up in the product.

CI/CD controls need the same attention. Build systems should not blindly trust everything they pull. Teams should review registry tokens, build runner permissions, release credentials, secrets exposure, dependency update automation, and the use of unpinned package versions.

Finally, teams should reduce blind use of “latest.” Automatically pulling the newest version may be convenient, but convenience becomes risk during active supply chain campaigns. Version pinning, controlled updates, and review gates add friction, but that friction can prevent much larger problems later.

The Repository Is Also Intelligence

The repository itself should be treated carefully. It should not be executed casually. It should not be tested on a normal workstation. It should not be treated like a safe open-source project.

But as a threat intelligence artifact, it matters. The README language, project structure, dependencies, forks, issues, pull requests, and public engagement can all become signals. The code tells one story. The conversation around the code may tell another.

That is another important shift. Supply chain attacks can now be public, social, and performative. Attackers may use visibility itself as part of the operation. They may publish not only to distribute malware, but to distribute methods, ideas, fear, and attention.

Defenders need to watch both layers: the technical layer and the social layer.

Final Thought

The most important lesson from Shai-Hulud is that malicious code does not need to look suspicious to be dangerous. It can look like a project. It can have documentation. It can have a permissive license. It can sit in a public repository and still represent serious supply chain risk.

That is the reality of modern software supply chain attacks. The defense starts with visibility. Organizations need to know what is in their software, where it came from, how it was built, where it was used, and how quickly they can respond when risk appears.

This is also why it is important to keep track of SBOMs across the software lifecycle, not only for the final release. Even if a component does not appear in the latest build or the released product, historical SBOMs can provide the audit trail needed to determine whether the organization was exposed at any point.

That matters because supply chain risk is not always about what exists today. It is also about what passed through a build, a pipeline, a developer environment, or an internal release candidate yesterday. Without that history, teams may miss evidence that a malicious package entered the environment, even if it was later removed.

That is why SBOMs matter. Not as paperwork. Not as a compliance checkbox. Not as a one-time file.

As operational visibility and historical evidence.

And in this new reality, that visibility is what gives teams the ability to respond with confidence.