Attackers only need one weak point in your supply chain to disrupt your builds, so security teams have to take precautions against every threat and advisory that comes out. Most teams no longer ask whether a software supply chain attack will affect them. They ask whether the right controls are already in place when it does.
Proactive defensive measures give teams the best opportunity to neutralize supply chain attacks before they strike, or to catch them early, before they can do significant damage. The artifact registry is the ideal location to enforce security policy because it provides a control point at ingestion for incoming packages. Because every stage of the development process pulls packages from the same artifact registry, policy decisions made at ingestion apply to developer workstations, CI builds, and production deployments.
A package cleared at ingestion enters downstream stages already vetted against your policies. A package blocked at ingestion never enters the build environment in the first place.
Attacks are more sophisticated now, targeting points earlier in the development process. Traditional malware, like ransomware, targeted individual machines and impacted them in an obvious way. Endpoint tools that scan files before execution evolved to combat this attack vector, and much of today’s security stack assumes this attack model as the default.
Supply chain attackers don’t need to target a specific machine. They compromise the actual software supply chain and what bad actors are trying to achieve through these attacks is much less transparent. Oftentimes malware exfiltrates sensitive information so that attackers can compromise additional systems. For example, Shai-Hulud spread by stealing npm, GitHub, and cloud tokens. Other times, the goal is to utilize the resources of a compromised machine for activities like cryptomining. These attacks are subtle by design and can delete evidence of their existence before you realize you’ve been compromised (like the Shai-Hulud variant that hit TanStack).
Attackers increasingly gain entry through the open source packages you depend on, and most teams rely on open source software to build the bulk of their applications. When an application uses hundreds or thousands of dependencies, attackers only need to compromise one to gain access.
Beginning in September 2025, Shai-Hulud turned install-time malware into a self-propagating worm. TeamPCP, the group behind the Shai-Hulud attacks, open-sourced the code for the worm in May 2026, which gave rise to the Miasma and Hades versions and spread this attack type to PyPI, RubyGems, and other open source ecosystems.
These worm attacks rely on code that runs automatically at install time (e.g., npm preinstall / postinstall hooks, and equivalent build hooks in other affected ecosystems), so the malicious payload runs the moment a developer or CI runner installs the package.
Note: npm 12, released in July 2026, turns off install scripts by default. However, this feature only works with upgraded and configured versions of npm, and allowlists can re-enable install scripts. It’s also an ecosystem-specific solution, where a registry-level policy applies to every package that gets pulled in.
At that point, downstream scans of the build output or container image aren’t able to see the compromised package. Further, for newly released packages an advisory may not exist yet for the scanner to evaluate against. The critical point here is that this attack model exposes architectural gaps in security posture, not tooling failures. Scanners remain a critical and useful tool; however, they’re not designed to evaluate install-time code execution. As a result, controlling package ingestion is critical for defending against this type of attack. When installing a package means running its code, choosing a version means granting that code execution rights, so package selection becomes a trust decision.
The Shai-Hulud class of attacks garners headlines, but software supply chain challenges exist beyond malware. Different organizations have different tolerances for package vulnerability risk signals, like CVSS severity, EPSS exploit probability, or a listing in CISA’s KEV catalog. Similarly, package licensing can have a significant impact on the legality and economic viability of using certain packages. The last thing teams want to happen is to get to the deploy stage only to find a critical vulnerability, or a license issue. Vetting package properties at the registry prevents issues from impacting downstream workflows.
AI exacerbates the dependency problem. AI agents work at machine speed and can do so around the clock. These tools generate high volumes of code with more dependencies than humans have the capacity to review. Many of these are transitive dependencies and developers may not have visibility into these package decisions, especially with the increased volume of overall dependencies. This is another facet of package trust that can be dealt with by using the artifact registry as a control point for evaluating these packages at ingestion.
If the artifact registry is the ideal control point for the software supply chain, what does that control actually look like?
Configuring your artifact registry as a dependency firewall allows you to enforce security policy before problematic packages reach your build environment. Policy enforcement is automatic and can be set once at the Cloudsmith workspace level and applied to every pipeline and developer that pulls from it. You can scope policy at the repo level as well, so any repos that require additional protection or leeway can be set up according to your needs.
The general shape of a dependency firewall includes:
MAL- advisory automatically get blocked.The artifact registry touches the entire software development lifecycle. Traditionally, it was a tool for storing artifacts and packages, but its ability to enforce policy at ingestion makes it the ideal control point for software development. Preventing compromised packages from entering your environment denies attackers the opportunity to inflict damage on your systems. Clearing packages at the registry layer also ensures that downstream workflows and processes, like scanning, have safer inputs.
Every control described above is a policy you can write once and enforce across every repo. Learn more about policy management.
