By submitting this form, you agree to our 

For most developers, the traditional security pipeline is a source of friction, not a tool for enablement. You push a new feature, the CI build kicks off, and suddenly you're facing a wall of 1,200 critical CVEs from a transitive dependency you didn't even know you had. The release is blocked, and the security team becomes the "Department of No" - a metaphorical bottleneck that seems to exist solely to slow down velocity. This dynamic is broken. The goal isn't to have 

 security; it's to have smarter security that enables speed; that requires moving from noisy alerts to prioritised, actionable risk.

" culture is a direct result of missing context. When a security team sees a thousand CVEs, they have to assume all are critical. Without clear software provenance, every new dependency is a potential "

" - an unaudited package that could be anything from a benign tool to a typosquatted nightmare. An SBOM (Software Bill of Materials) provides the "what," but it doesn't provide the "so what?" This is why developers get buried in alerts for vulnerabilities that aren't even reachable in their code. To fix this, you need a system that doesn't just find problems, but also provides the context to 

This is where the pipeline needs to get smarter, starting at the build. A tool like 

 integrates directly into your CI pipeline to provide this missing context 

 an artifact is ever created. Its job isn't just to find every CVE; it's to intelligently triage them. By performing context-aware analysis, it determines if a vulnerability is 

 within your application's call path. This is the practical power of 

 (Vulnerability Exploitability eXchange) reporting. That jaw-dropping list of 1,200 CVEs becomes a manageable, actionable list of something like 

 that can genuinely pose a threat. Kusari acts as the guardian of the build, generating a tamper-proof evidence packet containing a signed SBOM, a VEX report, and a provenance attestation, ensuring you only build what you trust.

Once Kusari verifies a build and signs its evidence packet, the artifact can be pushed to the Cloudsmith artifact repository. Cloudsmith isn't simply a passive vault, it also serves as an intelligent admission control layer via Enterprise Policy Management (

 offering allows users to quarantine packages with a deep-level of context. This is where you set the rules: "Block any artifact with a non-compliant license from being pulled," or "Prevent any package with a critical-severity CVE from being deployed to production, if we know there’s a fix already available." It gives you the "last mile" of control, ensuring that only verified, secure, and compliant artifacts are distributed and consumed by developers and production systems.

This combination of Kusari and Cloudsmith creates a closed-loop security system that finally busts the "Department of No" myth. For developers, this means an end to the noise. You get fast, actionable feedback directly in your CI pipeline, allowing you to fix the five critical, reachable vulnerabilities instead of arguing about the 1,200 that aren't. For the organisation, it means security transforms from a reactive bottleneck into a proactive, automated discipline. You can trust that anything you pull from Cloudsmith is pre-vetted, and security teams have an end-to-end, auditable trail from source to deployment. This is how you stop fearing security and start automating it, enabling your team to ship with confidence and speed.

Nigel Douglas

Head of Developer Relations

Breaking the "Department of No": Ship fast but also secure

Artificial intelligence has moved beyond a futuristic concept to a daily collaborator for almost all development teams today. Tools like GitHub Copilot and ChatGPT are writing functions, suggesting dependencies, and building application skeletons at a blistering pace. This revolution in speed is undeniable, but it comes with a critical, often-overlooked consequence: AI-generated code is fundamentally changing the demands on artifact management.

We're moving faster than ever, but that speed has created massive blind spots in our software supply chain. The core question is no longer just "

Does AI check its sources and provide provenance checks?

Let's address the first fundamental question. When an LLM suggests a software package or a new dependency, does it perform 

" if a dependency is credible, accurate, or safe. It's not testing that package in a sandbox. It's making a statistically probable recommendation based on the data it was trained on.

This creates a terrifying new attack vector. The AI has no concept of:

, pulling in a malicious package. Oftentimes it depends on what you ask for, and sometimes you get exactly what you asked for - whether that’s a good package or not.

: AI can't scan a dependency for malware before recommending it. After the ‘s1ngularity’ and ‘

’ attacks on the NPM ecosystem, there is a heightened focus on understanding the contents of open-source packages that we consume from these upstreams.

: AI doesn't differentiate between a well-maintained library from a trusted foundation like the CNCF vs. an abandoned, vulnerable package from a random user that likely will not be actively maintained going forward.

If a developer accepts that suggestion, a compromised dependency is instantly pulled into the codebase, bypassing all traditional human vetting.

Typosquatting is a type of cybercrime where attackers register domain names, or in this case dependency names, that are common misspellings or slight variations of legitimate websites/packages/dependencies to trick users into visiting a malicious site or downloading a software dependency that ultimately contains malware. A perfect example is the 

 example we mentioned earlier. One extra letter and many users wouldn’t immediately recognise it as a typo. Let’s query PyPi to see the owner of both packages:

 (AKA bitprophet). Whereas, the typosquatted package name returns “

” for the owner. You’ll have probably noticed by now that this package no longer exists on PyPi as it was intentionally created to cause harm - and has since been removed. While that’s good for the community, there’s a chance that an organisation may have already cached that package locally. In those cases, the OSV.dev public API can be really useful to identify whether your cached dependencies were created as part of a typosquatting campaign:

So what’s all this got to do with generative AI? Well, GenAI is just as guilty of hallucinating and recommending package names that simply don’t exist. Adversaries pick up on the behaviour, and thus create more typosquatted upstream packages in the hope that “

” code generation recommends one of those typosquatted package names. This is commonly known as 

. To stay ahead of slopsquatting, modern artifact management are expected to have full provenance checks on all software artifacts to understand who created them, are they credible, and have they already been flagged as compromised according to the 

Malware, unlike vulnerabilities in software, is a dedicated piece of software that is specifically designed to disrupt, damage, or gain unauthorised access to a computer system. Traditional vulnerability scanners are looking for flaws in an application code that can be exploited. These are marked by CVEs (like 

). However, malware contained within compromised upstream packages will not show-up in those CVE reports. Instead, we can use the same OSV.dev public API to see if an open-source upstream package, such as 

After running this command, you see that the package is identified as containing malware, with a unique identifier - 

. Now you couldn’t be expected to run this manual action every time you want to check if a specific dependency and version contain malware, that would take all day. Thankfully, Cloudsmith integrates the 

 API directly within our product. So on package synchronisation, we will automatically scan for known Malware identifiers (ie: MAL-YEAR-ID) associated with the open-source software dependency. If there’s a match, we can quarantine this automatically through 

Most recently, a variant of PhantomRaven malware was found in 

, designed to steal GitHub Tokens from developers. If LLMs cannot quickly identify whether an upstream package is compromised or not, what stops these generative AI tools from suggesting compromised packages? As the prevalence of malware in upstream repositories increases, this simultaneously changes the demands being put on artifact management. Modern artifact management solutions need to be able to identify and prevent compromised open-source software packages from being used by developers.

AI models used for code generation are trained on vast, uncurated datasets of public repositories, learning statistical patterns rather than semantic quality. This training methodology makes them incapable of assessing 

. The model does not understand that a CNCF-hosted project undergoes rigorous security audits, has a dedicated maintenance team, and follows a clear governance model. To the AI, that project's code patterns may look statistically similar to an abandoned, single-maintainer package on GitHub that contains known CVEs or is a prime candidate for a typosquatting attack. This "

" means the AI's suggestions are based on pattern frequency, not on a risk assessment of the dependency being recommended.

This blind spot directly reflects the current software supply chain risk. An AI can confidently recommend a dependency that, while functionally correct for the prompt, introduces significant security debt. This is backed up in the data. Chainguard’s "

" found that 1 in 5 respondents said that their engineers are not allowed to use AI for some of the most time-intensive tasks, such as patching vulnerabilities, running tests, or conducting code reviews. These are the tasks where technical credibility is needed to make those final judgements.

Furthermore, AI models trained on these OSS software ecosystems will inevitably learn from and recommend historically compromised packages from those upstreams. This problem is recognised by security foundations like OWASP, whose "

" lists risks like "Insecure Output Handling" (LLM03) and "Training Data Poisoning" (LLM04), where the model's output or its training data can be leveraged to inject vulnerabilities directly into a developer's workflow.

Ultimately, the credibility of these outputs can be benchmarked against frameworks such as the 

. This project was built by open-source developers to help secure the critical projects the community depends on. It assesses open-source projects for security risks by running a series of automated checks. You can use it to proactively analyse the security posture of your own code and make better-informed decisions about acceptable risks. The tool also helps you evaluate other projects and dependencies, giving you a basis to work with LLMs on improvements before you integrate into your codebase.

Does this mean we should be discouraged from using AI-generated code?

The short answer is 'no,' but a cautious and deliberate approach is essential.

We view generative AI much like any other programmable interface. It excels at following instructions, which means the quality of the output is directly dependent on the quality of the input.

A developer who is skilled in their domain will understand how to instruct the AI to produce high-quality, relevant content, thereby accelerating their workflow. For example, knowing precisely which software packages and versions are appropriate for a production application prevents the AI from referencing and introducing compromised dependencies.

By providing specific context, such as example code, the application framework, established code styles, library usage, specific dependency versions, and error handling protocols, a developer can guide the AI. This ensures it follows established rules and helps produce code significantly faster than manual methods.

Regardless of popular sentiment, our view is that generative AI is not close to replacing human intelligence in software development. Its current, practical role is to speed up and facilitate the quality work humans do, ultimately increasing overall productivity.

This new power, however, requires a corresponding increase in diligence for software governance, provenance checks, and vulnerability scanning. Maintaining control over AI-generated code means knowing exactly what is running in the estate, who created it, and being confident whether it is safe or not. This is all achievable through a comprehensive artifact management platform. If you’d like to learn more about this, we have an 

 on the topic of slopsquatting in the age of GenAI.

AI generated code is changing the demands being put on artifact management

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.

Nick Peacock

Senior Director, Customer Success

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

attackers published malicious versions of the popular 

 and several plugins to npm, abusing a post-install script (telemetry.js) that ran on Linux and macOS to sweep developer machines and CI for secrets (SSH keys, GitHub/npm tokens, API keys, crypto wallets). Uniquely, the payload also tried to 

co-opt local AI CLI tools (Claude, Gemini, q)

 to help with recon and exfiltration, one of the first documented cases of malware doing so.

 – A vulnerable GitHub Actions workflow was introduced in the Nx repo; although reverted in master on Aug 22, an outdated branch was later exploited to steal a GITHUB_TOKEN with read/write perms and ultimately the npm publish token.

 – Multiple malicious Nx releases and plugins were pushed over ~2 hours; within hours, npm removed them and 

2FA required for all packages and publishing moved to npm’s Trusted Publisher

, and the window, though brief, was enough to 

1,000+ valid GitHub tokens, dozens of valid cloud and npm credentials, and ~20,000 files

 exfiltrated; execution was seen on developer machines (often via the Nx VS Code extension) and in CI (e.g., GitHub Actions).

Cloudsmith integrates this data feed via 

, providing hourly checks against the OpenSSF database. When an already cached or a newly uploaded package is detected as malicious, Continuous Security works with 

 (EPM) to automatically flag and quarantine it, preventing the harmful software from entering your builds.

Cloudsmith offers this capability as a part of our 

 (EPM) feature, a programmable policy-as-code layer that controls the security, compliance, and flow of artifacts across the software supply chain.

When a new threat is discovered that affects an artifact in your workspace, Continuous Security will flag it via EPM without the need for a full manual or scheduled re-scan.

In the Nx incident, entries for nx and related @nx/* packages appeared in the OpenSSF/OSV malicious-package feed within ~24 hours of first detection (e.g., MAL-2025-41443 for npm/nx, plus @nx/devkit, @nx/node, @nx/workspace, and others). With Cloudsmith’s hourly ingestion, these packages would have been automatically flagged and quarantined, shrinking exposure time and limiting downstream blast radius.

You can check out a deeper dive of how EPM uses OSV to detect and block malicious packages here.

: EPM enforces organization-wide rules automatically upon detection (no manual triage to start protecting builds).

: OpenSSF’s open database aggregates cross-ecosystem reports in the OSV schema, which Cloudsmith consumes directly.

Enable EPM and add a Malicious Package policy

 (OSV/OpenSSF source). This is the switch that turns detection into 

Understanding the defense in depth approach: 

A malicious package can be ingested into a build pipeline before threat intelligence sources like OpenSSF or OSV publish indicators, creating a blind spot during which the artifact remains undetected. Mitigating this exposure requires a defense-in-depth strategy: enforce ingress controls at the artifact repository level (e.g., Cloudsmith) to block known and suspicious packages, and implement downstream detection via CI scanners and endpoint monitoring to identify and remove compromised dependencies already in use. 

(This is about realistic risk staging: block new ingress at Cloudsmith; find and purge what’s already inside with endpoint/CI scans.)

: Even though npm has removed the bad Nx versions, follow the incident guidance (rotate tokens/keys, search for s1ngularity-repository* and results.b64, clean shell startup files, audit CI). Wiz and the Nx advisory provide concrete steps.

AI-assisted malware isn’t hypothetical anymore, it’s in mainstream OSS supply chains. Cloudsmith’s 

 that can turn multi-hour chaos into a contained non-event. Pair it with good credential hygiene and CI hardening—and insist on provenance/Trusted Publisher for your own releases, just as the Nx team has done post-incident.

Claire McDyre

Product Manager

NX npm Supply Chain Attack: How Cloudsmith Would Have Contained the Blast Radius

Regulatory compliance in the software supply chain is a moving target that shifts with every dependency, security advisory, and regulatory update. Cloudsmith’s EPM puts control back in your hands by enabling development and operations teams to create real-time policy enforcement, right where it matters: at the package level.

By leveraging OPA and Rego, EPM lets you define precise, programmatic policies that determine how packages are evaluated, tagged, or quarantined before they’re ever promoted downstream. That means compliance policy enforcement is built directly into your distribution pipeline rather than being left to chance, or worse, post-release audits.

For development teams out there, the last thing we want to do is slowing you down with red tape security features. We want to help shift compliance left in the supply chain so issues are caught early, consistently, and transparently. Whether it’s blocking unlicensed packages, quarantining vulnerable builds, or ensuring artifacts meet naming conventions, EPM ensures that policies are applied automatically and uniformly through your own unique policy-as-code configurations.


Copy-Left policy that matches license strings

This policy is important from a compliance perspective because the use of 

 in production environments can create significant legal and operational risks if not properly managed. Many of these licenses impose obligations, such as requirements to disclose source code, distribute derivative works under the same license, or provide attribution, that may in some cases be incompatible with an organisation’s business model, intellectual property strategy, or contractual commitments.

By proactively detecting both free-text and standardised System Package Data Exchange (

) variants of these licenses, the policy ensures that potentially problematic code is flagged before it reaches production, enabling the necessary legal review or approval. This not only reduces the risk of inadvertent license violations but also demonstrates due diligence in open-source governance, which is often a key expectation in audits, customer contracts, and regulatory environments.

The license trigger conditions are highlighted in our detailed schema which is available towards the bottom of 

 v.3.1.1 package that we know has a GNU Lesser General Public License (

) license that should trigger the policy:

 If you have a tagging response action attached to your policy, you could tag the package with 

This policy checks whether a package includes specific 

 descriptors in the filename. This could be the simplest way for an organisation to state whether a package is a debug package, and therefore should not be ingested into, say, the 

The policy will trigger on these kind of wildcard examples:


Cloudsmith EPM allows users to easily match package filename metadata based on Regular Expression (RE) string matching patterns. Once ready, you can download the 

 Python package and push it to Cloudsmith to cause the policy violation:

From a compliance perspective, preventing debug, test, or temporary builds from entering production is critical because these artifacts often contain unverified code, verbose logs, or experimental features that were never intended for public release. If deployed, they may expose sensitive internal information, introduce security vulnerabilities, or degrade system performance, any of which can result in regulatory noncompliance, contractual breaches, or audit findings. Enforcing this control at the ingestion point ensures that only vetted, production-ready packages flow downstream, reducing the likelihood of costly incidents while demonstrating due diligence in software governance.

The use of RegEx strengthens this control by providing a highly adaptable mechanism for detecting noncompliant naming conventions across diverse development and CI/CD practices. Instead of hardcoding rigid checks, RegEx allows compliance teams to define broad yet precise patterns that evolve alongside the organisation’s software ecosystem. This flexibility enables policy enforcement to remain effective without creating excessive operational overhead.

This policy exists to ensure that packages coming from upstream sources are explicitly reviewed and marked as "

" before being allowed to proceed in the pipeline.

You could think of this as an advanced use-case for tagging. When both conditions are true, the policy will trigger. Note: There is also a commented-out condition for restricting it to specific repositories, if you’d prefer to whitelist certain repositories that are not under the same level of regulatory scrutiny.

From a compliance perspective, this policy enforces a controlled workflow for handling externally sourced or upstream packages, which are often beyond the direct control of the security team. By requiring an explicit "

" tag before these packages are considered safe, it creates a checkpoint where security, licensing, and quality reviews can be performed. This helps prevent unverified or potentially malicious code from entering production systems. It also encourages consistent documentation of the approval process, which can be important for compliance frameworks such as SOC 2, ISO 27001, or internal governance policies.

From a risk management perspective, the policy reduces the chance of introducing vulnerabilities, licensing conflicts, or compatibility issues from upstream sources. Operationally, it gives teams the flexibility to integrate valuable external software while maintaining a robust safeguard against unvetted changes. Over time, this approach can significantly improve software supply chain security, maintain regulatory compliance, and protect the organisation’s reputation by ensuring only reviewed and trusted packages make it into critical environments.


 architecture packages and blocks others like 

To trigger the above policy (which blocks all architectures 

), you'd want to upload or sync a Python package that is built for a 

 architecture - like arm64. However, pip by default fetches packages built for your local system architecture, so you typically won't download architecture-specific wheels unless they're explicitly tagged.

This architecture-specific allow list policy plays a critical role in compliance by ensuring that only packages built for the approved amd64 architecture are permitted in production and testing environments. In organisations standardised on x86-based servers, containers, and CI/CD pipelines, introducing packages built for other architectures, such as the case with arm64, can create hidden risks such as runtime failures, inconsistent behaviour across platforms, or the inability to reproduce builds reliably.

From a compliance perspective, these risks undermine key principles of software assurance, reproducibility, and auditability, all of which are essential for demonstrating control over the software supply chain. Blocking non-amd64 packages at enforcement ensures that software deployed downstream aligns with documented infrastructure baselines, reducing the likelihood of noncompliant system configurations.

Additionally, different architectures may introduce unique vulnerabilities, require distinct patching procedures, or fall outside the scope of validated security tools and compliance checks. Allowing multiple architectures without proper governance complicates vulnerability management, weakens evidence for audit trails, and can create gaps in regulatory coverage. By restricting deployments to a single, vetted architecture, this policy simplifies compliance verification, strengthens the integrity of vulnerability scanning, and provides assurance that all deployed software is consistent with approved security and operational standards.

Build your own compliance policies with Cloudsmith EPM

These four examples illustrate just a handful of the ways Cloudsmith EPM can be applied to enforce regulatory compliance across your software supply chain. From licensing governance to architecture restrictions, debug-build quarantines to upstream approvals, each policy demonstrates how compliance controls can be codified, automated, and enforced consistently.

But this is only the beginning. Because EPM is powered by OPA and Rego, it offers almost limitless flexibility to address the unique compliance challenges your team is facing. Whether you’re aligning with industry standards like ISO 27001 or SOC 2, meeting customer contract requirements, or simply reducing operational risk, you can design policies as code that fit your exact environment.

The power lies in treating compliance as part of your pipeline rather than an afterthought. With Cloudsmith EPM, you can move fast without breaking trust, ultimately ensuring that every package that flows downstream has already been checked, validated, and approved against the rules that matter most to your business. Check out our official documentation on how to 

Compliance policies in EPM

Typosquatting is now a well-known exploit, whereby malicious actors register domains or package names that are visually similar to popular ones. Examples include misspelling 

 as “expresss” - a mistake we’ve all made when typing too fast under pressure. Normally, when you make a typo retrieving a software package, you just get a build error since the package doesn’t exist. However, adversaries pick up on these subtle behaviours and in the process publish package names, deliberately containing malware, knowing someone is inevitably going to make this mistake at some point.

We just saw this threat has escalated. Instead of just mimicking individual package names in ecosystems like npm or PyPI, attackers are squatting on 

An alarming post by Bruno Schaatsbergen on 

 highlights this issue. A user discovered an active container registry at 

, which is the GitHub Container Registry. The poster warns: “I'm not sure who owns it, but be careful”. And it makes sense, unless investigated further, it’s unclear what is currently being distributed via this fake registry. Funny side note, if you go to the fake (ghrc.io) instead of the correct Github Container Registry address, it displays one of those generic default Nginx web server pages instead of the expected Github redirect (

Again, simple typo, swapping the positions of “r” and “c” leads to a completely different registry. Given that container workflows often operate in scripts or automated pipelines, a single-character mistake can redirect your push or pull operations to an attacker-controlled endpoint.

While it might seem unlikely that this is happening right now in any organisation, a simple 

 would show you that this typo has been made on quite a number of occasions. If your CI/CD workflow is also scripted to push to 

, those images will never reach GitHub, and instead will end up elsewhere. In doing so, the adversaries operating 

 could intercept or modify container images. They might serve backdoored images, leak credentials, or inject exploits. But this stuff is easy to make mistakes with. In logs or configuration files, 

 basically look identical at a glance. Developers may not notice the swap until something breaks, or even worse, when the damage is already done.

But you can take action. As an immediate first step, you can carefully review your registry URLs, especially in automation files like Dockerfiles, CI pipelines, docker push or docker pull commands. Additionally, you could enforce DNS or host-level protections to prevent access to known malicious or typo versions like GHRC. Explicitly only allow the registries that you expect to work with.

 exists as a live container registry masquerading behind a one-letter typo of 

This reflects an escalation from typosquatting individual package names to targeting entire registries.

The implications are severe. As the story evolves, it is worth adopting some vigilance when working with your container registries.

 later clarified that while the 401 response and 

 header are standard parts of the OCI spec, in this case they’re being returned by a server that isn’t a registry at all. The fact that only the 

 endpoint mimics OCI behavior, while the rest of the site is a default nginx install, suggests the setup is intentionally crafted to lure OCI clients into sending credentials to a fake token API.

This scenario highlights why companies should prefer providing developers a registry within their organisation. Having a control plane (like Cloudsmith) in front of registries in which to verify and block things like this fake registry, backed-up by a powerful audit trail for post-incident forensics.

Typosquatting a package? How about typosquatting the whole registry!

Teams and Access Controls

A short video to show how to set up teams and configure access permissions in an organization on Cloudsmith.

Alan Carson

Co-founder and Chief Strategy Officer

Emojis are finally useful for more than sentiment or sass. Cloudsmith Engineering can now be raised in emergency situations via a single emoji - SOS.

And it’s been used for the first, and so far only, time.

At Cloudsmith, we pride ourselves on our reactive (and in many cases proactive) support. We architected and built the platform with monitoring in mind allowing us to provide transparency of internal operations to you and us. We utilize numerous tools to help us provide the best package logistics experience to our customers. All our customers, all the time. Statuspage, Datadog, Intercom, Slack are all critical components to the Cloudsmith Experience just as Cloudsmith is a critical component in your software lifecycle.

Up until a few months ago, we ran support on a fairly ad-hoc basis. We have a passionate team in Engineering willing to stay up late and get up early for the exigencies of the service.

However, it was time to formalize the support function. We evaluated a number of products but ended up going with Opsgenie (sidenote; some of the competitors missed out on a sale because of non-responsive support… all we wanted was a trial extension). We implemented a sane rota with primary and secondary levels and put it into force.

This had the nice side-effect that productivity in Engineering went up. Now, the team not on rota could relax from the burden of support and focus on building product. And those active on the rota could relax, talk to customers and fix bugs, or achieve small tasks in-between times. It was a win-win for everyone.

But we wanted more.

Now, we had the power and ability to raise and contact Engineering in off hours if we needed to. What if a customer, in distress, could do the same?

We added emoji support for all Ultra level customers via Slack. Our customers can now directly raise a Cloudsmith engineer if they feel the service is underpowered or having critical issues.

To date, our service uptime is 99.99% and the last two incidents were only degraded service, highlighted early by our monitoring and immediately managed by the team feverishly rerouting traffic across regions to prevent the vast majority of our customers and our customer’s customers from noticing anything was sub par.

Only once has the SOS emoji been used in anger. A 

 behavioral issue that was blocking pipeline builds. Our dutiful customer raised the alarm, we rolled back a change from the previous day, resolving the issue from bed to deployment within about 30 minutes.

We thanked them.

They still have three challenges remaining.

Support via Emoji

Getting started with R Packages and Cloudsmith

A short walkthrough of getting started with R packages and Cloudsmith, including uploading an R package and then installing it.

Dan McKinney

Solutions Engineer

Getting Started with R Packages and Cloudsmith

Custom EULA

It is simple to add a custom End User Licence Agreement for your package downloads in a Cloudsmith repository.


As a vendor, understanding your bandwidth usage is an invaluable insight into how packages are distributed across your user base and how specific users have grown over a timeframe.

As a user base grows from 10s, 100s, and 1000s of users and package downloads are many multiples of your total number of users, it's essential to understand the distribution of your bandwidth utilisation by a user (or more precisely, entitlement token's) to aid in the identification of token's that make up a large percentage of your overall traffic.

When providing an entitlement token to a user under a specific license, you trust an entitlement token will be used to download packages upon the agreed-upon terms. However, an increase in your total bandwidth may start off slow and continuously grow over several months until it's suddenly become a massive increase in your overall bandwidth. Understanding this usage and precisely where this growth originates helps identify where/where change occur and provides options to mitigate runaway bandwidth from specific entitlement tokens by changing how those specific users are managed.

Whenever a user downloads a package from a private repository using an entitlement token, the exact number of bytes transmitted from our servers to the user host is stored for that specific token as an individual log entry. At the end of each day, we calculate the total bandwidth for every user across all of our repositories containing one or more packages and store the result as a daily aggregated value representing bandwidth usage.