Scanning for malicious packages at deployment catches issues already inside your environment. Scanning at the pull request catches what your CI pipeline already ran. If security controls don’t see a malicious package until after ingestion, it already has multiple chances to execute.

This is an architecture problem that requires an architectural answer. A dependency firewall is that answer. It’s a security posture that places guardrails between your development environment and public registries, evaluating what enters before any build runs.

How malicious packages enter your build environment without inspection

Build tools connecting directly to public registries like 

, and packages arriving as requested is a common approach to open source software consumption. When scanning runs at the pull request, in the pipeline, or at deployment, the package is already inside your environment.

) tools identify known vulnerabilities in packages already present in a codebase. That's genuinely useful. But even with the best scanners, an architectural gap exists between ingestion and where the first scanner sits. Establishing a control point in that gap allows teams to better govern the packages that enter their environments.

Two patterns produce this gap consistently.

The first is when no artifact management exists at all and developers pull directly from public registries. Teams can’t implement security controls because the layer necessary to do so isn’t in place.

The second, and it’s more common than most organizations realize, is when an existing artifact management tool handles the storage of software artifacts but enforces no security controls on the consumption of those artifacts (for example: AWS CodeArtifact or GitHub).

A third pattern is emerging due to the use of AI coding tools.

These agents generate code that expands the attack surface faster than most security programs have adjusted for. Tools like Cursor, AI-assisted editors, and LLM-powered agents recommend and install packages as a normal part of their workflow. Teams need governance that can match the pace of AI-powered development.

Developers tend to accept those recommendations without the scrutiny they'd apply to a manual dependency addition. The packages arrive through the same registries and the same pipelines as they would with manually-written code, but the human review step between "

Modern attacks execute before the scanner runs

The latest supply chain compromises exploit trusted open source packages. The 

 attacks succeeded because they targeted specific packages developers already trusted and executed payloads at install time – before any scanner ran.

Cloudsmith's analysis of 2025 OSV.dev data, comparing when malicious versions were published to npm against when OSV flagged them, shows that 

99 percent of npm package compromise attacks are identified within 72 hours of publication

. A package scanned within that exposure window looks clean because no malware identifier exists yet. By the time the community flags the threat, pipelines are already running it.

Scans are snapshots – threat intelligence isn't

There's a second failure mode related to scanning that plays out more slowly. A package enters your environment, the scanner runs, nothing matches, and it's marked clean. That evaluation is correct at that moment because no known vulnerability exists. Then six months later, a researcher discloses a critical CVE. Nothing triggers a re-evaluation, so the original point-in-time scan remains the most recent one and the package is still in production.

. That package existed in production codebases for years before threat intelligence identified the vulnerability. The problem in cases like this is when you treat a one-time evaluation at the boundary as permanent clearance.

New advisories arrive constantly for packages that evaluate as clean at ingest. A scanner that runs once, when a package first arrives, doesn't protect against what threat researchers find next month or next year. The scan result ages out the moment new intelligence contradicts it.

That said, scanning remains essential. But the fluid nature of supply chain threats, packages that evaluate as clean at ingest and become risks as new intelligence emerges, reveals a gap that point-in-time evaluation can't close on its own. Addressing it means supplementing scanning with controls that operate earlier in the process, before packages enter an environment where they can execute.

The control point that doesn't depend on developer behavior

A dependency firewall addresses both failure modes described above by changing where and when evaluation happens. The first is early detection at the boundary: identifying threatening or malicious dependencies before they enter your environment, rather than after they had the chance to execute. The second is ongoing assessment: unlike a scanner that runs once and treats the result as permanent, this posture evaluates continuously as new threat intelligence arrives. A package that cleared evaluation at ingest doesn't remain cleared by default; it remains cleared only if current intelligence still supports that conclusion.

Developers start their work with packages that clear those guardrails, meaning the inputs to their work are more likely to be secure from the start. Vulnerabilities, threats, and license flags caught at the boundary save considerable rework compared to discovering the same issues in a PR review, a pipeline scan, or a post-incident forensic report.

For the vast majority of packages that clear evaluation, the process is entirely transparent and frictionless to developers. When friction occurs, like disabled scanner plugins, skipped linting rules, and manual approval workflows, developers create workarounds. Developers don’t need to bypass a control they don’t interact with. Compliance that relies on structural enforcement is more reliable than manual, behavior-based approaches.

For security and DevSecOps teams, the value is consistency at scale. Every developer, every AI agent, every pipeline, and every team in the organization hits the same guardrails. Policy applies universally and automatically, closing the gap between what policy says and what enforcement carries out.

A dependency firewall posture doesn't replace the scanning you already have. It moves the trust decision to the ingestion boundary, so your team uses safe, evaluated packages before anyone writes a line of code.

For a practical guide to building a dependency firewall, covering controlled ingestion, continuous policy evaluation, and the OPA-backed policy engine, read 

How to use Cloudsmith as a dependency firewall

A dependency firewall gives your scanner better inputs

Every container inherits its base image. If that image carries unpatched CVEs, your application does too – before you've written a line of code. Hardened images fix the baseline: compiled from source with SLA-backed patching that keeps them clean after day one.

Distribution of these hardened images becomes a challenge. Security teams can pick a better image source, but making that image the default for every developer and build agent means new registry credentials per team and changes to how they pull. Adoption rollout becomes its own project, and it compounds across every team building containers. That's where adoption stalls.

 and Cloudsmith address the security and distribution aspects of using hardened images. WizOS compiles hardened container base images from source in an auditable pipeline, backed by strict remediation SLAs and cryptographic provenance. Cloudsmith puts those images behind the registry URL your teams already use, authenticated with credentials they already have.

Wiz doesn't pull pre-built packages from upstream public repos and assemble them. Wiz compiles its WizOS images from source in a controlled, auditable pipeline they own. You benefit from strict remediation SLAs that guarantee near-zero CVEs: 7 days for criticals, 14 days for highs and mediums. These builds also produce cryptographically verifiable provenance and signatures, so you can confirm exactly what shipped and where it originated. WizOS images have a minimal footprint, using only the components an image actually needs and 

 for broad compatibility with existing applications.

Hardened images writ large have the same goal: trust a maintained baseline instead of public open source upstreams. Wiz backs its WizOS hardened images with its own vulnerability and runtime data.

Cloudsmith treats the WizOS Registry like any other upstream (e.g., Docker Hub, npm, PyPI), as a source you proxy and cache behind your existing Cloudsmith repository URL. Developers don’t need to change how they pull images.

 In your Cloudsmith repository's Upstream Proxying settings, create a new Docker-format upstream pointing at 

, set your priority, and choose Cache and Proxy.

. Grab your Wiz Registry credentials from your WizOS tenant (Profile > Tenant Info > Wiz Registry Credentials) and configure them on the upstream. From here, Cloudsmith handles authentication on behalf of every developer and build agent, so nobody else needs a WizOS login.

 and pull images using their existing Cloudsmith repository path, for example:

Cloudsmith resolves the image, caches it on the first pull, and serves it from Cloudsmith's edge network on every subsequent pull.

Once you configure WizOS in Cloudsmith the one remaining manual step, 

, becomes optional. The Cloudsmith CLI's new Docker credential helper (added in 

) lets Docker authenticate to Cloudsmith registries automatically, using credentials your CLI already has.

 against your Cloudsmith registries, WizOS included, just work. You don’t need to worry about a login step, copying a token into CI secrets, or risk having credentials sitting in a config file that can expire or leak.

The helper also discovers any custom Cloudsmith registry domains on your account via the API and caches them locally, so it isn't limited to the default 

 host. If you need to point it at additional hostnames, pass 

 to preview what it would change before it changes anything; and skip the auto-discovery step with 

 if you'd rather manage the domain list yourself. When you need to back the help out, 

cloudsmith credential-helper uninstall docker

The Cloudsmith credential helper gives you one line in your provisioning script for all your build agents instead of a 

 call (and a credential) in every pipeline.

What the WizOS/Cloudsmith combination gives you is a pattern, not just a configuration. Your WizOS credentials live in Cloudsmith's upstream config once. No developer or build agent ever handles them directly. The credential helper removes the last manual authentication step, so pipelines authenticate using CLI credentials they already have. The initial base image pull caches in Cloudsmith, so every build after that comes from your own repo and upstream availability stops affecting your pipeline.

The credential handling and image caching are the operational wins. The broader payoff is that Cloudsmith becomes the control plane across your entire software supply chain. The same policy engine that applies to your application dependencies applies to WizOS images sitting in the same repository. Vulnerability scanning, environmental policies, and access controls run consistently from the base image through to the finished artifact, without separate tooling at each layer.

When your upstreams converge on a single Cloudsmith endpoint (e.g., WizOS, Docker Hub, npm, PyPI), security teams have one governed URL to apply policy to, and development teams have one URL to pull from. Nobody manages a separate credential per upstream, and policy coverage doesn't have gaps between the container layer and the application layer.

WizOS gives you a hardened starting point: images compiled from source, with SLA-backed patching that protects from CVEs. Cloudsmith makes that starting point the default across your org. Developers pull from the same URL with the same credentials. The secure path is also the easiest one.

Want to see how WizOS hardened images and your existing registries can all sit behind one Cloudsmith endpoint? 

Start secure, stay secure with WizOS and Cloudsmith

, you're not just installing the requested package. You're also pulling in every transitive dependency in the package’s dependency graph. Many of these are packages you didn’t consciously choose, from maintainers you don’t know, including code that executes automatically before any build pipeline step runs. An average React application can pull in over 900 dependencies, most of which arrive automatically, not by selective choice.

That's the architecture of modern software development. Reusing open source packages at scale makes it possible to ship complex applications that meet the high expectation of users without rebuilding foundational infrastructure from scratch. But the security model currently in use wasn’t designed to address the exposures created by reusing open source packages.

A leaked npm publish key makes that exposure visible. The credential isn't the problem, rather it's what reveals the gap between where organizations believe enforcement happens and where it actually happens.

The evolving nature of software development and the rise of security supply chain attacks changed who's paying attention to this gap. Security teams don't need to experience an incident to start conversations around their supply chain. The 

-style worms, and near-misses reported by high-profile engineering organizations present a threat environment that makes industry signals a catalyst for change. So, while the trigger is different, the gap is the same.

It may seem like a leaked npm key is a credential rotation problem and not a supply chain problem. Here’s how we get from key to attack.

No matter how a publish key gets exposed, whether that’s in a CI log, a repository that was briefly public, or a secret rotation that wasn't fully completed, that key grants write access to one or more packages on the public npm registry. Write access means the ability to publish a new version.

The attacker publishes a version that looks legitimate: same package name, incremented version number, valid metadata. In the axios compromise, the malicious versions were tagged 

. Consumers pulling the latest version get the malicious one automatically on their next install.

Here's where the transitive dependency becomes the attack surface. Most downstream consumers aren't pulling the compromised package directly. They're pulling a framework that depends on a tool that depends on the package. No developer makes a conscious choice to install it. The package manager resolves the dependency graph and pulls everything in. In the axios case, the attackers added a new software dependency named 

 which serves as a legitimate encryption and hashing utility. The associated npm 

 script runs automatically during installation. The malicious code executed before any build step, before any scanner ran, before anyone knew the package arrived.

By the time a developer or CI job completes 

, attack code can exfiltrate credentials, establish remote access, and take steps to avoid detection.

The credential leak opened the door. The artifact pipeline, specifically, the absence of an interception point between a package being requested and when the package is executed. This is precisely where the adversary makes an impact.

Investing in security tooling can create a sense of false confidence. Especially as organizations grow, adapting to nuanced changes in the software development process at scale can be challenging. So, this confidence makes sense: they have application security scanning, CI/CD pipeline scanning, and endpoint detection. These are good tools, but where they sit in the timeline is the problem.

 analyze the code your team wrote. SAST tools like Checkmarx, Veracode, Snyk, and Semgrep, do serious work and find real vulnerabilities. They analyze source code before the build runs. The SAST tool already finished its pass by the time your build system is pulling packages from npm. It has no visibility into the dependency tree. So, a compromised transitive dependency gets pulled in, its installation script executes, and the SAST report comes back clean because the SAST tool never saw the dependency tree.

 runs after the package manager pulls the requested packages. In npm, 

 scripts run during download, not during execution. When the malicious code runs at install time and your pipeline scanner runs afterward, then it's checking the pool for contaminants after the swimmers have been in it for an hour. The tool works correctly and you get a clean report, but that’s because the timing is wrong once again. The attacker already has your credentials.

 is excellent at detecting anomalous behavior once code is running, like suspicious network traffic, unusual file operations, and credential access patterns. CrowdStrike, your EDR tooling, etc., catch these things, but they're reactive by design. By the time your endpoint detection notices the suspicious outbound connection, the credentials are already gone. Detection at minute three doesn't help much when the exfiltration happened at minute one.

This is the architecture of the standard security model, and it has a structural blind spot: every control point operates after ingestion. Code downloads and executes before any of those controls see it. That's not a problem you solve by adding another scanner at a later stage in the same pipeline. Adding more tooling downstream of the gap doesn't close the gap.

Consider a fire department. They detect and respond to fires. We need fire departments. But we also need a fire code that prevents fires from starting. The fire code is embedded in the design and operation of buildings; it’s invisible because it's foundational. Fire response and prevention are different things, and both matter. The difference is that only one of them stops the problem before it starts.

The artifact registry functions like the fire code. It’s where that kind of foundational control can actually live for software supply chains. It sits at the boundary between untrusted software, like everything on the public internet, and your trusted environment. Every package your developers and build systems consume passes through it. That makes it the one place in the entire delivery pipeline where enforcement can happen before code downloads, installation scripts run, or anything executes.

Enforcement at the trust boundary changes the attack timeline entirely. A compromised version of a package previously marked as safe gets evaluated against policy before it enters the environment, so doesn’t reach your environment at all. Policy stops being advisory ("

this package is risky, here's a dashboard entry

") and instead becomes an automated enforcement control ("

this package is not entering this environment for this reason

A few things become possible at the artifact layer that aren't possible anywhere downstream:

 A package that was clean when it arrived six months ago and has a new CVE or a threat intelligence flag today gets re-evaluated without manual action. Build-time scanning doesn't revisit what's already in the environment, but an enforcement layer at ingestion can.

 Most modern supply chain attacks don't begin with a known vulnerability. They begin with compromised open source maintainers. These threats don't appear in a common vulnerabilities feed and instead rely on scanning the open source upstream registries (PyPI, npm, Packagist, etc.) for unwanted code changes (

) using a database like OSV.dev. . This data is actionable at the artifact layer, before the package is introduced into any developer builds.

An audit trail that answers the incident question.

" should be answerable from a single system of record. An enforcement layer at ingestion is that record – what entered, when, under what policy state, with what provenance. Not a multi-tool investigation across disconnected logs.

The instinctive response to a supply chain incident is to add tooling. Buy the additional security module. Enable scanning at another pipeline stage. Each addition addresses a visible gap and each one is a reasonable decision in isolation.

The accumulated result is a different problem: a patchwork of controls with seams between them. Each tool has its own configuration requirements, its own maintenance cycle, its own expertise to operate correctly. The security stack grows in response to incidents until nobody fully understands how it fits together or what to do when something falls through a seam. The operational burden of the stack becomes its own risk.

This pattern shows up consistently in teams that started with a repository and added security on top: fragmented coverage, high maintenance overhead, and a circumvention problem. When authentication against an internal proxy creates enough friction, developers route around it and pull directly from the public registry. A control that gets bypassed at scale is worse than no control because it creates the appearance of coverage while the actual exposure grows.

The architectural distinction matters here. Controls built into the artifact layer from the foundation behave differently from controls added on top of a repository designed for something else. The former is simply infrastructure while the latter is configuration layered on infrastructure with a different original purpose. Those are two different approaches that behave differently under pressure.

Teams choosing a platform built for supply chain security describe making that choice explicitly to avoid assembling the capability from components. The assembly works, until it doesn't. The seams are where attacks succeed.

The leaked npm key is almost never the actual exposure. It's the event that made the exposure visible.

The supply chain incident – the credential, the flagged package, the build that broke in a way nobody could explain quickly – functions as a diagnostic. It reveals where enforcement actually lives in the pipeline, which is almost always different from where teams assumed it lived.

The useful question that comes out of the diagnostic: where in your pipeline does enforcement actually happen? Does it occur before packages enter the environment, or after?

For most organizations running standard CI/CD scanning on top of a repository, the answer is after. The follow-on question is what it would take to move it upstream. The teams that have made that move describe the same outcome: not more tooling on top of the existing architecture, but a different architectural starting point. A platform where enforcement at the boundary is the foundation, not an addition.

Cloudsmith is a cloud-native artifact management platform that enforces policy at the point of ingestion – before packages enter your environment – and provides continuous re-evaluation, full audit logging, and developer-transparent controls across every package format your teams use.See how Cloudsmith protects your software supply chain from dependency attacks. 

Schedule a conversation to discuss your tech stack today

Dependency attacks start before your scanner runs

 are one of the most common and well-understood security failures in software development. A credential committed to a repo, copied into a script, or exposed in a CI log can sit undetected until abuse makes it visible. By then, the damage is done.

Cloudsmith is now a member of the GitHub Secret Scanning Partner Program. That means 

Cloudsmith-issued API keys are uniquely identifiable

, and GitHub can detect them automatically when they appear in a repository.

Cloudsmith issues API keys with a unique prefix. That prefix is registered with GitHub's secret scanning infrastructure, so when a Cloudsmith credential appears in a repo – in source code, a config file, a committed 

, or anywhere else GitHub indexes – GitHub detects and flags those credentials automatically.

When a leak happens, Cloudsmith notifies the affected customer directly. Teams can revoke or rotate the compromised key before it gets misused.

The workflow is straightforward: detection happens automatically, notification is immediate, and your team decides how to respond.

The window between a credential leak and credential abuse is short and it closes fast. Automated scanners can pick up a key exposed in a pull request or pushed to a public repo within minutes. Discovering issues through billing anomalies or abuse reports put teams in a challenging position, and one they want to avoid. 

Automatic detection of leaked API keys changes that dynamic. When exposure triggers an immediate notification, the response begins before most incidents have a chance to develop.

This works inside the workflows your team already uses. There is no new tooling to adopt, or new configuration required on your end. GitHub-based teams get detection in place from the moment they issue their next Cloudsmith API key.

See how Cloudsmith secures your software supply chain end to end. 

Cloudsmith credentials are now detectable by GitHub Secret Scanning

Long-lived API keys are a liability. They sit in secret managers, leak into logs, and eventually someone has to remember to rotate them. If you run workloads on Google Cloud, you can skip that whole problem: every VM, container, and function already carries a service account identity, and you can use it to authenticate to Cloudsmith directly.

 work together to handle authentication. Your workload swaps its service account identity for a short-lived Cloudsmith token at runtime. Nothing long-lived gets written to an environment variable or a key file on disk.

Google's metadata server can issue signed JSON Web Tokens (JWTs), and Cloudsmith verifies them against Google's public keys. The flow:

Your workload asks the Google metadata server for an ID token, naming Cloudsmith as the intended audience

Google returns a signed JWT carrying your service account's identity (its email and your chosen aud)

You pass this token to Cloudsmith's OIDC endpoint

Cloudsmith fetches Google's public verification keys and validates the signature

If the claims you pinned all match, Cloudsmith hands back a short-lived token for API calls

Setting this up has two parts. Your workload needs a way to get a Google token, and Cloudsmith needs to know when to trust that Google token.

On a server you want the token to carry a meaningful audience and a dedicated identity. Service account identity tokens give you both: a custom aud and an explicit email.

The simplest source is the metadata server, available on GCE, Cloud Run, GKE, App Engine, and Cloud Build:

 claims you'll pin against in Cloudsmith.

You can also impersonate the service account from another identity, such as your own user. However, the calling identity needs 

 and the payload looks roughly like this:

Before wiring up a workload, you can prove the whole flow with your own Google login:

 doesn’t give you any isolation because it is hard-wired to the gcloud SDK's shared OAuth client ID, which is the same value every gcloud user carries. For a local proof of concept, pin the 

 (hosted domain) claim, e.g., your Google Workspace domain, which ties the token back to your organization.

Now tell Cloudsmith to trust tokens from your service account. You'll need the Manager or Owner role, at least one Cloudsmith service account, and the robot identity that holds your repository entitlements must already exist. Go to Settings > Authentication > OpenID Connect and create a provider:

 is a planet-wide issuer used by every Google account, so the issuer alone proves nothing. The isolation comes from the 

 claim. Only something that can act as that exact service account can mint a token carrying its address, and that is gated by IAM. The 

 value just binds the token to Cloudsmith so it can't be replayed elsewhere.

Swap the Google token for Cloudsmith credentials:

 with your Cloudsmith service account slug, and 

 with your Cloudsmith organization identifier.

If everything's configured correctly, you'll see something like:

gcp-pipeline

The returned token is a normal Cloudsmith API key, valid for 2 hours. Pass it on any Cloudsmith API request, as the verify call above shows.

This works anywhere you have a Google Cloud service account identity. Both tokens are short-lived, so there's nothing long-lived to store, and you're reusing an identity you already manage.

Compute Engine instances use their attached service account to request a token from the metadata server, then exchange it for Cloudsmith access whenever they need it.

Cloud Run and GKE work the same way through their workload identities, fetching a fresh token for each job or when the current one nears expiry.

Cloud Functions and App Engine can request a token on demand within the handler.

Cloud Build pipelines with a service account attached can do the token exchange to gain Cloudsmith access.

You're reusing an identity you already manage, and the token it gets back expires in two hours. Nothing long-lived sits in an environment variable, and there's no rotation schedule for anyone to own.

 and point an existing Google Cloud workload at it. For the details, see 

Authenticate to Cloudsmith with your Google Cloud identity

AI dev frameworks are becoming a key target for software supply chain attackers. The logic is rather simple: if you can compromise the framework itself, you have the ability to compromise highly sensitive infrastructure today. That includes LLM API keys, cloud provider secrets, the kind of credentials that would allow an attacker to move laterally from there.

On June 17, a sophisticated software supply chain incident, specifically targeted 

 package name. Mastra is a popular open-source TypeScript framework used for building AI agents and 

By hijacking a former contributor’s creds, attackers were able to inject a malicious dependency across 144 packages in the Mastra ecosystem. With core components like 

 pulling nearly a million weekly downloads, the blast radius of an attack like this is massive. In this blog we’ll look at how the attack unfolded, how the malware evades detection, and how developers can secure their environment today.

The attackers executed a multi-stage campaign that relied on a blend of account takeover, social engineering (via package mirroring), and a dynamic second-stage runtime payload designed to bypass traditional static analysis.

The groundwork was laid a day prior to the primary breach. An npm user named 

. At this point, the package appeared entirely benign, indicating it was a fully functional clone of the highly popular 

By copying the original library’s version numbering, MIT license, and author metadata (

), the attackers ensured that any casual visual or automated sanity check of the package structure would look clean - one of the many ways the attacker is evading detection.

In the next stage, the threat actor updated the 

. Again, this version looked identical to its predecessor but introduced a relatively small, obfuscated file named 

, along with an execution trigger in the 

. Following a wave of community concern, 

 flag was explicitly used to suppress the Node.js runtime environment warnings, which ensured devs remained unaware during the installation.

A few minutes later, the attackers struck the 

, a legitimate former Mastra contributor whose organisational scope access had never been revoked. From there, they used an automated script that rapidly populated the 

 in just over an hour. Each package was updated to include the malicious dependency:

), any fresh install or build runner pulling the clean pinned version 

 was automatically forced to resolve and download the malicious 

 patch. From an execution perspective, when a dev or automated CI/CD pipeline runs 

 hook fires immediately, which causes the 

 script to initiate a highly-evasive first-stage dropper into the environment.

The underlying mechanics of the first-stage execution reveal a strong emphasis on evasion and anti-forensics. It has four clear evasion tactics:

 allows the script to safely reach out to an attacker’s C2 infrastructure even if the interception tools or self-signed proxies attempt to inspect or block the traffic.

, the second-stage payload is then able to spin out into its own OS process. When the core 

 routine finishes or is terminated, the malware continues running silently in the background.

: Finally, the script finishes by calling 

 immediately after execution, the installer leaves behind a clean directory tree, baffling standard post-incident file scanners.

: Mastra utilises npm's trusted publisher flow inside their CI pipeline, generating robust Sigstore-backed SLSA provenance attestations for authentic releases. However, while Mastra generated provenance, their 

The tragedy of this fourth evasion tactic is that it was entirely preventable. Because a strict verification policy wasn't required on the registry side, 

 willingly accepted the attacker’s mass updates pushed directly from a stolen PAT, even though they dropped the cryptographic provenance signature. Any client configuring a strict signature-verifying installation policy would have immediately blocked this entire campaign.

How developers can secure their environments today

By using open infrastructure tooling like 

, organisations can detect the malicious 

 package as well as the various malicious packages published to the compromised Mastra org on June 17.

However, security shouldn’t just be reactive. Developers can’t just wait for security advisories. While 

 has stepped in to pull any compromised versions from the registry, if you had run an install during the exposure window, before these advisories were published, you should treat the environment as compromised.

Securing your software supply chain requires a proactive architecture. If you're managing external dependencies using Cloudsmith, here’s how you could mitigate attacks like 

: You’ll be hearing this from us a lot, but cooldown policies really are one of the most effective solutions to this recent wave of open-source supply chain attacks. Malicious packages are often caught and reported within hours of publication. By establishing an upstream proxy with a cooldown window (let’s say, holding newly-published packages for 

 before they become eligible for download), you create a natural buffer that keeps automated pipeline scripts from pulling zero-day dependencies.

: As highlighted earlier, you should never rely purely on range-based specifiers (either 

) for high-value upstream dependencies. Where possible, ensure a strict 

 is enforced across all local and CI/CD builds. This guarantees that your builds anchor exclusively to known, cryptographically hashed versions.

Inside the Mastra npm supply chain attack

By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Cloudsmith Blog

Keyv and Cacheable npm packages compromised in active supply-chain attack

Kubernetes 1.37 – What you need to know

How to configure time for cooldown policies

The evolution of Shai-Hulud-style worms

Inside the AsyncAPI npm supply chain attack

What Cloudsmith shipped in Q2 2026

Cloud Native Digest - July 2026