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.

Artifact Security Maturity Assessment

At approximately 0300 on the 24th of November 2025, a new wave of compromised open source packages began circulating in the npm ecosystem. This iteration (dubbed “Shai-Hulud: The Second Coming” by the attackers) is designed to leak developer secrets, including GitHub tokens, CI/CD credentials, and cloud credentials.

This is a targeted supply chain attack affecting over 425 packages, including high-traffic dependencies.

Here is what we know, how we responded, and what you need to do.

The malware creates unauthorized GitHub repositories on a compromised developer’s account. While the naming convention of the repository is random, the description reads “Shai-Hulud: The Second Coming”. The attack vector also involves specific malicious workflow files injected into repositories.

High-traffic packages confirmed as affected include 

 continues to grow as upstream providers identify and remove malicious versions.

Cloudsmith response: We have notified impacted customers

Cloudsmith immediately initiated an investigation and identified customers who may have pulled the compromised versions of these packages. We have notified potentially impacted customers with recommended remediation steps.

However, because upstream providers are still identifying and removing malicious versions, we strongly recommend you perform the audit steps below.

Investigate all repositories for dependencies that include affected packages.

Remove and block: Remove malicious packages immediately and implement blocking rules to prevent re-introduction.

Clean environment: Clean your npm cache and reinstall all packages in project environments. Ensure you use a package lock file and pinned versions.

Rotate secrets: Rotate environment variables and secrets (GitHub, NPM, Cloud credentials). Crucial: Ensure this is done after the malicious packages have been removed and the workstation is deemed safe.

Investigate repositories: Check all GitHub repositories (organization and employee accounts) for any containing the description “Sha1-Hulud: The Second Coming” or suspicious workflow files like .github/workflows/discussion.yaml.

Workstation audit: Check potentially affected workstations for downloads of these affected versions. Ensure EDR tooling scans are carried out to eradicate local copies of compromised packages.

Any GitHub, NPM, development related environment variables or secrets and Cloud credentials potentially affected should be monitored for misuse and rotated if compromise is suspected, ensuring this is done after the malicious packages have been removed and the workstation environment deemed safe

Future-proofing: detection is not prevention

The software supply chain has been weaponized such that the challenge with supply chain attacks like Shai-Hulud is the gap between the 

 and its detection. Attackers rely on this window to infiltrate builds before security feeds have a chance to catch up.

To close this gap, organizations need to address protection in two distinct phases: defending against the unknown (Zero-Day) and managing the known (N-Day).

In the initial hours of an attack, before a CVE or MAL identifier exists, security tools are often blind. The most effective defense here is not signature detection, but metadata-based policy.

allows you to implement a "cool-down" period for new assets. By creating a policy that blocks or quarantines packages published within the last week, you effectively neutralize the threat of pulling malicious packages prior to detection. This ensures that no package enters your pipeline until it has been in the wild long enough to be vetted by the community and security researchers.

Once a threat is identified and cataloged, as these packages now are, the focus shifts to immediate isolation.

 constantly re-evaluates your stored artifacts against the latest threat intelligence streams. As soon as a package in your registry is flagged with a MAL identifier or vulnerability, Cloudsmith detects the change in status. When paired with Enterprise Policy Management, the platform can automatically trigger a quarantine action, preventing that specific version from being served to developers or build agents, without requiring manual intervention.

By layering these two approaches, metadata policies for zero-day prevention and continuous scanning for known threats, you replace manual investigation with automated governance.

We are continuing to monitor the situation. If you need assistance analyzing your logs or setting up EPM policies for package cool-down periods, please reach out to our support team.

Nick Peacock

VP, Customer Success

Shai-Hulud: The Second Coming - What You Need to Know and Do Now 

The npm ecosystem was hit yesterday by a malware attack affecting popular packages like 

. Both packages are typically bundled into frontend builds. Once included, the malicious payload executes.

These attacks are becoming more frequent - we reported on a 

similar attack on npm packages just 12 days ago

How you react depends on what is known about the threat:

The issue is real, but not yet reported in public databases

You cannot automatically detect or block it - your only option is rapid manual actions

The issue is documented and tracked (i.e. it has a CVE or MAL ID)

Security feeds and tools, including Cloudsmith’s Enterprise Policy Management (EPM), can use that tracking to automatically quarantine or block affected packages

, it was considered a zero-day threat (potentially compromised packages were identified, but no official designation yet).

Within 24 hours, these packages were confirmed as malicious, and added to the 

. Cloudsmith and other similar platforms can then OSV.dev updates and thereby enable automated remediations.

We recommend the following actions for all Cloudsmith customers, regardless of whether you’ve confirmed that any affected packages have been used in builds or are currently present in any of your Cloudsmith repositories.

For Zero-day threats - Block with Deny Rules

1. Add [Deny Rules] that block downloads immediately. 

This stops any installs in dev, CI, or production environments.

For this scenario, a simple set of rules targeting the compromised packages/versions would have blocked all download attempts. This protects developers who may not have heard the news yet.

See the end of this article for a full list of Deny Rules.

 to identify who pulled compromised packages and when. Cloudsmith logs are near real-time, so searching for and identifying users andservice accounts that have accessed these packages will help determine potential impact.

For N-Day threats - Quarantine and Flag with EPM

. Put policies in place to quarantine malicious packages that do not have a fix, or have not been verified and granted an exception from your security team.

Our OSV.dev feed refreshes every hour and will detect newly identified malicious packages automatically. This protects you if compromised packages are already in Cloudsmith repositories. In order to enable continuous securityadd an 

 to automatically tag and quarantine new malware.

The gap between zero-day and n-day is when development teams are most exposed. This “lag” introduces risk, against which the fastest defense is Deny Rules.

Once advisories are live and the zero-day is now an n-day, EPM and Continuous Security take over, eliminating manual effort and keeping build pipelines safe.

Looking ahead: smarter protection is coming

Cloudsmith includes detection and protection against malware and vulnerabilities as a native capability in our Ultra and Enterprise tiers. Every artifact in a Cloudsmith repository is, by definition, in a controlled, policy-enforced environment.

We’re working to include more threat intel sources, richer context, and community feeds like deps.dev, along with the ability to bring your own internal threat data into Continuous Security.

Create a Deny Rule for each separate query string.

npm ecosystem alert: What you need to do today with Cloudsmith

 tool, I wish more teams realized the significant impact that customer support can have on your overall experience and the effectiveness of the tool in your workflow. In my role, I hear lots of stories from Cloudsmith customers about the poor support they received from past vendors and the disruptions it caused—a shortcoming they only discovered after they were live with the vendor.

But this disappointment and frustration is avoidable. You can gauge the quality of a vendor’s customer support before signing the contract—

 you evaluate support as part of your selection process. It may be a little harder to verify than product features and functionality because it’s less tangible and assessment requires some personal experience and interaction, but it’s not difficult. To help, here are my 12 signs that a vendor will provide the support and guidance you need for ongoing success:

In the initial phase of shopping around, when you’re browsing vendors’ websites but not quite ready to talk to sales, here are three encouraging signs:

If a vendor provides support to every paid tier they offer, it’s a strong signal that they care about all of their customers. It suggests that they want everyone to get maximum use of their product with minimal friction and have a ‘no customer left behind’ ethos. Visit their pricing page to check (for example, here are 

). If you don’t see support across all paid plans, it could mean you might have to upgrade to a higher-tier plan before the vendor’s technical support will unblock you.

Good documentation is essential for self-reliance and a positive user experience, but what does ‘good’ look like? In my experience, these are early signs of quality documentation:

 or help hub full of product documentation;

 to help you get the max from your investment;

, logically structured, easy to follow, and uses technical terms correctly;

 so you can clearly tell which version(s) of the product the documentation applies to (particularly important when considering on-premises or hybrid vendors that are maintaining multiple versions of the their platform); and

 to documentation, which indicates that the vendor is refreshing its materials to reflect improvements and changes within its platform to ensure accuracy.

You can learn a lot about a vendor’s technical support and customer experience by browsing 

 or other social media. Filter the reviews by keywords such as ‘support,’ ‘issue,’ or ‘team’ to quickly get a picture of how current users feel about the support they’re getting.

Once you have an account, whether that’s for a short-term free trial or a longer proof-of-concept, you can gather more evidence of a vendor’s support style and capabilities. Here are a few indicators of long-term quality service during that short introductory period:

A vendor that makes it easy to reach a human through multiple channels (email, Slack, live chat, etc.), shows a willingness to be open, transparent, and responsive. Detailed responses that address the actual specifics of your query, rather than boilerplate replies, are also a good sign. Ultimately you should feel valued (like Cloudsmith customer Richard Vodden, below). A vendor that offers high quality support as the norm will be consistent and treat trial users with the same care as paying customers.

Subject matter expertise and empathy are cornerstones of exceptional support, and they show up in these key ways:

Frontline support quickly and easily understands the issue you describe.

They are just as knowledgeable about the role of their tool in your operations as they are about how their platform works, which ensures they have context for 

 it is so important to quickly provide solutions to your support requests.

They get that their service is critical to your success and treat your success as 

At Cloudsmith, our frontline support team is made up of experienced software engineers to ensure our team has the knowledge and empathy to effectively assist you if an issue arises.

When something goes wrong in their platform, good vendors own it. They tell you what went wrong, why, when it will be fixed, and they maintain transparency and trust with status updates. Quickly and openly communicating and resolving their own issues tells you a lot about a company’s culture and what treatment you can expect if an issue arises in 

In the final stage of your selection process, look for these signals around customer success:

A vendor committed to quality support has Service Level Objectives (SLOs) in place between its platform engineering team and its support team. While the Service Level Agreement (SLA) between the client and vendor often gets more attention, I believe the presence of these internal service targets are a more significant predictor of support quality. After all, a 12-minute response time that meets your SLA doesn’t matter if the engineers never fix the problem. SLOs are your assurance that changes will get actioned within specific timeframes and are what empower support teams to deliver a high quality of service through to resolution.

If the vendor’s sales team initiates conversations about their support and the top-notch experience their customers have, it’s a great sign they’re proud of their service and have proof to back up their claims.

Confirm who in your organization can contact support and whether there’s a cap on the number of support users and requests. Caps are a danger sign. Unlimited support requests for all users show that the vendor values removing friction and bottlenecks in software delivery and prioritizes its clients’ time and productivity.

If the sales team works to understand your long-term goals and vision, it indicates they see themselves as an active partner rather than just a supplier. Vendors with this mentality take a proactive approach to customer success, delivering value, and supporting clients throughout their journey.

Assigning a specific customer success manager to your organization shows commitment to your long-term success and ROI. Customer success teams focus on preventing issues, suggesting optimizations, and sharing best practices—helping you sidestep or mitigate day-to-day issues.

Often 80% of a vendor’s platform will meet your needs straight off the shelf, but a great vendor will consider options to help you get that last 20% of utility. This willingness to explore your use case and work with you to customize your deployment indicates flexibility and a customer-centric ethos. It shows they care about your experience and satisfaction and aim to provide the solution that works best for you—something PagerDuty's Dave Bresci discovered firsthand when they selected Cloudsmith.

Those are my 12 green flags that an artifact management vendor likely delivers outstanding customer support and has your success as their top priority

 into your vendor-comparison matrix to track which platforms get green flags and which get the reds. Then you can ensure the vendor you choose provides the proactive, empathetic, and knowledgeable customer experience necessary for your success.

If you’d like to include Cloudsmith in your shortlist, 

 with any questions you have about our customer experience and support services.

12 Signs of Stellar Support in an Artifact Management Vendor

One of our core motivations in building Cloudsmith is to make software developers' lives easier. We want Cloudsmith to be one of those great products that feels intuitive and automates everything.

As we’re picking up more and larger customers, we’re seeing an increased need for migration tools. We want to make it as easy as possible for teams who are stuck using JFrog Artifactory, or Sonatype Nexus, or other legacy tools to move over to the joy of SaaS artifact management using Cloudsmith.

In theory, anyone can migrate their own repos and data to Cloudsmith, using our APIs, CLI, and webhooks. But we really want to make this 

So, we’ve established a new team at Cloudsmith called 

. The mission of Customer Engineering is to build migration and integration tools that extend Cloudsmith. This will include migration tools, GitHub Actions, and extensions to our Terraform provider.

We want to let the Cloudsmith community contribute to and extend the tools we build, so we’re going to make all the source code available in GitHub and invite anyone to make improvements, submit pull requests, and take these tools wherever they need to go.

Our first project is a Cloudsmith Migration Toolkit. The Toolkit provides repository structure mappings, upstream/remote source configurations, and ETL-style data migration, specifically targeted at teams migrating off JFrog Artifactory. The Toolkit will securely create your Cloudsmith repos, let you decide which Artifactory repos you want to migrate, transfer artifacts, and preserve metadata and versioning.

If you are interested in trying out the Toolkit, 

 (we just need your name + email address), and the Customer Success team will be in touch.

Cloudsmith Blog

Shai-Hulud: The Second Coming - What You Need to Know and Do Now

npm ecosystem alert: What you need to do today with Cloudsmith

12 Signs of Stellar Support in an Artifact Management Vendor

Coming Soon: Cloudsmith Migration Toolkit