By submitting this form, you agree to our 

Explores AI-driven development, rising supply chain attacks, and new regulatory requirements.

2026 Artifact Management Report

AI-generated code often emerges as the villain in conversations about AI and software supply chain security. Hallucinated package names. Slopsquatting attacks. Insecure patterns lifted from training data of unknown provenance. These are real problems, and security researchers are right to name them.

But for platform engineers and DevEx leads, that conversation is also a distraction. The governance failure that will actually bite your team isn't about what AI writes. It's about what AI pulls, how fast, and whether your stack can keep up.

The dependency problem is a throughput problem

Developers make explicit dependency decisions at human speed. They choose a package, consider the version, and pull it with enough friction that a review process can, in theory, keep pace. AI coding assistants don't operate this way. They suggest, scaffold, and resolve dependencies as a background function of doing their job – and they do it with enough confidence that their recommendations land without the friction that would normally prompt a second look.

The result isn't just more dependencies. It's a qualitatively different kind of ingestion: a continuous, high-volume stream of packages entering the environment at a speed and scale that outpaces any review process your team designed before AI tools entered the picture. The governance controls you put in place when developers were the bottleneck now face a different constraint entirely – your ability to evaluate what's coming in before it's already inside.

To be fair, AI tools inherited this problem; they didn't invent it. Developers reached for the 

, grabbing the newest version on the logic that newer releases patch known CVEs, so newer meant safer. It was a reasonable shortcut that quietly traded reproducibility and stability for the assumption that upstream maintainers had things under control. Teams tolerated it because the pace of ingestion was slow enough that the risk felt abstract. What AI coding assistants do is adopt that same default behavior and execute it at a scale no human developer could match – across multiple ecosystems, for every file in a scaffold, without the occasional pause that made a developer reconsider. The mental model was already loose. AI just removed the friction that kept the consequences manageable.

 found that nearly 20% of packages recommended by large language models didn't exist in any public registry. More troubling: 43% of those hallucinated packages appeared repeatedly across multiple prompts. This is a pattern predictable enough that a malicious actor could register those packages in advance and wait for a developer to pull. This is the 

 attack surface, and it expands in direct proportion to AI adoption.

The signal from the field matches the research. One engineering team, already running their artifact repository significantly beyond its designed capacity, named AI-driven dependency explosion as the risk they were actively trying to get ahead of. Not a breach. Not a named vulnerability. The sheer volume of what AI coding tools would pull into their environment as adoption scaled. Their infrastructure had held up under human-speed development. AI-speed ingestion hadn't fully arrived yet – and they were already worried.

That's the right instinct. For teams with meaningful AI coding tool adoption, the governance problem is already compounding.

Three ways your current governance breaks at AI speed

The failure isn't dramatic and doesn't announce itself with an incident. It accumulates across three specific breakdowns, each one a consequence of governance controls calibrated for a different kind of throughput.

Volume creates an attack surface nobody owns.

 More packages mean more CVE exposure, more policy exceptions, and more surface area for a malicious or compromised package to hide inside. When dependency ingestion was slow and deliberate, a team could maintain a reasonable mental model of what lived in their environment. AI-assisted development eliminates that. Packages accumulate faster than any manual review can track, and exceptions that were once edge cases become business as usual.

Endor Labs 2025 State of Dependency Management Report

 found that only 1 in 5 dependency versions AI coding assistants recommended were safe to use – containing neither hallucinations nor known vulnerabilities. The reality of the situation is that with AI-generated code, more packages enter your environment than your current controls can evaluate.

Velocity breaks the timing assumptions your controls depend on.

 Most teams have security controls that activate at the build: scanning that runs after a package enters the environment, policies that evaluate after the pull happens. At human-speed ingestion, the gap between a package entering and a build running was small enough to manage. At AI speed, it isn't. A malicious or compromised package can move from first pull to build artifact before any downstream control flags it. The window that periodic scanning assumed would always exist has closed.

Opacity removes the human review that your policy controls assumed.

 Governance frameworks rest on an implicit assumption: a developer made a deliberate choice to pull each dependency, and that choice is reviewable and auditable. That assumption doesn't hold with AI coding tools. Ask a developer why version 2.3.1 of a specific package is in their project, and they may have no clear answer – the assistant chose it, they accepted the suggestion, and the reasoning never surfaced. The provenance trail that would normally anchor a trust decision is absent. Policy controls that gate explicit human decisions don't account for the implicit decisions AI tools make on a developer's behalf.

What governance built for AI speed actually requires

The three failure modes above share a common root: governance controls calibrated for human-speed dependency management running against AI-speed ingestion. The fix isn't better scanning or more thorough reviews. It's a different architecture for enforcement – one that matches the actual throughput of how your team now works.

Three requirements follow directly from the failure modes.

Enforcement has to happen at the point of first pull – not at the build, not post-merge. The moment a package arrives as a request is the only moment you can intercept it before it enters the environment. Every control that activates later operates on a package that's already inside. Quarantine and block capabilities that evaluate against your policies at request time close the gap that build-time scanning leaves open by design.

Re-evaluation has to be continuous, not periodic. Threat intelligence doesn't freeze when your weekly scan finishes. A package that passes on Tuesday may be flagged by Wednesday – because researchers publish a new CVE, because a maintainer account falls to credential stuffing, because a malicious version propagates through transitive dependencies before anyone notices. Continuous re-evaluation against evolving threat intelligence catches what point-in-time scanning cannot.

Coverage has to span all package formats, not just the ones your team uses most. AI coding tools pull across ecosystems without discrimination. A governance layer that covers npm but not PyPI, or Python but not Go, carries a structural gap that AI-assisted development will find. Unified enforcement across all formats – packages, containers, machine learning models – is the only way to apply consistent policy across the full surface area AI actually introduces.

Cloudsmith enforces policy at the point of first pull: when an open source package arrives as a request, it evaluates against your policies before it reaches the developer. Packages that have already cleared your policies deliver immediately; new packages clear checks before delivery. Artifacts in the platform re-evaluate continuously – as new threat intelligence arrives, and when policies change. With support for 30+ package formats in multi-format repositories, that enforcement applies across the full surface area AI-assisted development introduces – not a curated subset of it.

This isn't the argument that Cloudsmith stops AI from writing bad code. Code quality is a separate problem with its own tooling. The argument is more specific: Cloudsmith gives your governance controls the throughput and continuity they need to keep pace with AI-speed development. The controls your team built weren't wrong. They were calibrated for a volume and velocity that no longer reflects how your developers actually work.

The teams already feeling this problem are the ones with the highest AI coding tool adoption. They're a leading indicator, not an outlier. As AI-assisted development becomes the default, dependency ingestion volume scales with it. Governance controls that hold today may not hold next quarter.

The teams that get ahead of this don't run better scans at the build. They move enforcement earlier, automate re-evaluation, and put a platform in place that can handle what AI-speed development actually generates.

If your team has adopted AI coding tools and you haven't yet pressure-tested your artifact governance against the throughput they produce, that's the conversation worth having now.

Book a demo to get the conversation started and to see how Cloudsmith enforces policy at the point of pull.

Jason Myers

Technical Content Marketer

AI is breaking your artifact governance – and not by writing bad code

Many engineering teams treat PyPI, npm, Maven Central, and other upstream registries as trustworthy by default. They're not. These registries have no admission controls, no malware guarantees, and no obligation to notify downstream consumers when a vulnerability emerges for a previously clean package. While they offer convenience and availability, teams need to be careful not to conflate ease with safety.

Every time a developer pulls a dependency, they’re making a trust decision. But who vets that trust decision, especially with transitive dependencies? What often happens is the package enters the environment unchecked, moves into the build, gets stored in an artifact repo, and is assumed safe indefinitely. No one explicitly decided to trust it. It just arrived.

This is the structural vulnerability in modern software supply chains and better scanning alone won’t close the gap. The problem isn't just that teams occasionally pull bad packages. It's that teams delegate the decision to trust anything at all to the registry, with no policy enforcement at the moment that actually matters.

The cooldown period: A governance posture, not a product feature

 period is one response to this problem gaining traction in DevSecOps.

The concept is straightforward. A newly published package, or a new version of an existing package, doesn't go straight to your development environment. It enters a controlled holding state for a defined period, where it undergoes continuous evaluation against evolving threat intelligence before any build can consume it. Ideally, teams can set the length of that window in customizable policies, calibrated to the risk window for their organization and/or a given ecosystem.

A cooldown is distinct from quarantine, which is an open-ended hold triggered by a specific CVE or malware indicator on a known-bad package. A cooldown period is time-based and preventive. The cooldown policy exists because the highest-risk window for a newly published package is in the first few days, when a compromised or malicious package is most likely to surface and when threat intelligence is still trying to catch up to it.

Enforced intake holds are standard practice in regulated industries, like pharmaceuticals, food manufacturing, and medical devices. You don't distribute what you haven't cleared. The software industry is arriving at the same conclusion, just later, under more duress (thanks to AI), and with considerably more attack surface.

The difference between a cooldown policy and the vague notion of "we'll scan before we use it" is precision. Cooldown policies are written as code. Teams define the threshold, the scope – which package formats, which registries, which versions, etc. – and what happens when a package triggers the policy: hold it, tag it for review, block it with a message. The parameters are custom because the risk tolerance, regulatory context, and build velocity are different for every organization.

The anatomy of a modern supply chain attack

 campaign made the failure mode visible at scale.

Shai-Hulud is a self-replicating worm that spread through compromised npm developer accounts, inserting malicious code into legitimate packages belonging to those developers. The mechanism that Shai-Hulud used is what matters here: it didn't introduce obviously malicious 

 packages. It compromised packages that were previously legitimate, with real publishing histories and real downstream users. Those packages would have passed a point-in-time scan at first pull.

The second wave, detected in November 2025, escalated the technique – executing during the pre-install phase rather than post-install, which moved execution ahead of most pipeline scanning controls. Within hours of detection, the campaign compromised over 700 npm packages, created more than 27,000 malicious GitHub repositories, and exposed approximately 14,000 secrets across 487 organizations.

A cooldown period, combined with continuous re-evaluation against new threat intelligence, changes the exposure window. Not because it catches everything at intake – it doesn't – but because the hold creates a window in which intelligence can catch up. A package that passed on Monday may be flagged by Wednesday. Without a cooldown policy, your build already consumed it on Monday.

 ran the same playbook on a package with an even larger blast radius. Axios is the dominant HTTP client library in the JavaScript ecosystem – present in roughly 

 of cloud and code environments and downloaded approximately 100 million times per week. The attacker compromised the npm account of the project's primary maintainer and published two backdoored versions within a 39-minute window. Both versions introduced a hidden dependency that deployed a cross-platform remote access trojan to macOS, Windows, and Linux, targeting developer secrets, cloud credentials, SSH keys, and CI/CD pipeline tokens. The malicious versions were live for roughly three hours. Due to the short exposure window but high prevalence of axios, even limited availability resulted in measurable execution across environments.

, compromised by a separate threat group in the same period, demonstrated what that blast radius looks like in the AI stack specifically. LiteLLM is a unified proxy layer used to route requests across over 100 LLM providers, like OpenAI, Anthropic, AWS Bedrock, Google Vertex, etc. Compromising LiteLLM didn't just expose a build environment, it could provide attackers with credentials that span an organization's entire AI infrastructure. The attack reached LiteLLM indirectly, through another attack event against Trivy, a security scanner that LiteLLM's CI/CD pipeline trusted. The attacker poisoned that trusted dependency, harvested PyPI publishing credentials through it, and published malicious versions from there.

The vector changes across every one of these campaigns. The tactic – compromise something the ecosystem already trusts and weaponize dependency resolution – does not. The scope, speed, and cross-registry reach of these attacks show the limits of manual review in the Age of AI. When attackers can weaponize 100 million weekly downloads inside a three-hour window, the response requires automation and enforcement at the point of pull.

Cooldown policies and developer experience

Security teams that propose cooldown policies consistently encounter the same pushback: they add delays to developer workflows, create friction in the build process, and slow down teams already under delivery pressure.

These are legitimate concerns from engineering teams, even when they buy into a tighter risk posture. Fortunately, the right tooling provides a real solution.

The goal of a cooldown policy isn't to hard-stop every new dependency. It's to introduce a controlled hold with a clear, automated release path. Done correctly, a cooldown policy is largely invisible to developers working with packages that already cleared policy. The friction targets new packages in their highest-risk window, not on the entirety of the dependency graph on every build. For packages that pass continuously without incident, the cooldown period is a one-time delay on first use.

There's also a practical counterargument that often goes unmade: most engineering teams aren't looking to upgrade packages on zero-day. Unless teams configure a pipeline to pull the latest version automatically – an explicit choice, not a universal default – a developer may not know an update is available for days or weeks after publication. For those teams, a cooldown period introduces no meaningful delay. The package sits in its hold state and when it clears policy it is available when the team is ready to consume it. In this case, the friction becomes largely theoretical.

The objection to cooldown policies becomes harder to sustain when considering the alternative. The delay from a cooldown period is likely hours or days when first pulling a new package. Compare that to the blast radius from a compromised dependency that entered your environment unchecked. Teams measure the impact in incident response hours, remediation scope, and, increasingly, regulatory exposure under compliance frameworks, like DORA, CRA, and SOC 2, that treat supply chain controls as auditable requirements, not optional best practices.

The friction argument also assumes that the 

 alternative is speed. It isn't. Uncertainty is a significant factor as well. A supply chain where teams can answer the "are we affected?" question when a CVE drops because they tracked everything on entry mitigates the uncertainty factor drastically.

Building a mature supply chain governance posture

Cooldown policies are one layer in an enforcement stack, not a standalone fix. A mature posture has four components:

 Evaluate every package against policy before it reaches the developer – not after the build, not in a separate scanning tool downstream, but at the moment the request occurs. This is where cooldown and quarantine policies activate.

Today’s threat intelligence is different from that of last week so packages need on-going re-evaluation to stay up-to-date. CVEs don't announce themselves in advance. Malware indicators evolve. The assumption that a package is safe because it passed once is precisely the assumption that Shai-Hulud exploited.

 Context matters. Block with a message. Hold with a tag. Allow with a warning. Developers need clear, actionable answers – not a silent failure that sends them looking for a workaround that bypasses your controls entirely.

Unified visibility across formats and registries:

 "Are we affected?" needs a fast, authoritative answer. That's only possible if there's a single source of truth for what's in the environment and what state it's in based on policy.

Making cooldown policies operationally viable at scale

The conceptual case for cooldown periods isn't difficult to make to a CISO. The operational challenge is implementing them in a way that doesn't break builds, generate alert fatigue, or require a dedicated team to manage exceptions.

This is where the underlying platform matters. Cloudsmith prioritizes enforcement. It evaluates packages against your policies at the point of first pull, before it reaches the environment or developer. Cooldown policies, quarantine actions, and blocking responses are configurable and written as code, giving security teams precise control over parameters without creating blanket friction for engineering.

The critical piece is what happens after intake: continuous re-evaluation. A cooldown period without ongoing re-evaluation is still a point-in-time scan – just one with a delay attached. Cloudsmith’s vulnerability data sources update multiple times per hour. The platform uses a lightweight matching process to associate new vulnerability data with existing packages in your registry continuously. When the threat landscape changes for one of your packages, this triggers your policies to run and take action on the impacted package(s). That combination – policy enforcement at intake plus continuous monitoring after the fact – is what narrows the exposure window.

For organizations with DORA, CRA, or SOC 2 obligations, this also produces the audit trail that auditors will ask for: a traceable record of what entered the environment, when, under what policy conditions, and whether it is still safe.

The gate doesn't protect you if it only checks once. Supply chain governance is not a point-in-time moment – it's a discipline. Cooldown periods are one piece of that discipline: a concrete, policy-driven practice that treats trust as something that has to be earned constantly, not assumed at the point of first pull.

Want to talk through what supply chain governance looks like for your organization?

 Whether you're building the case internally or evaluating tooling, we're happy to help you tackle the problem. 

Your upstream registry is not your friend: Why security teams are demanding package cooldown policies

The threat research team at Socket have today identified over 84 malicious 

 package artifacts across 42 packages in the 

 has over 12 million weekly downloads - giving you an idea of the global impact of these software dependencies. 

 have attributed the behaviour to an ongoing TeamPCP supply chain attack called “

”. The self-propagating malware, which has been seen in other supply chain attacks, spreads by stealing CI/CD secrets.

Thankfully all of these compromised packages were identified only minutes after the packages were published. The problem for the industry is whether organisations had inadvertently consumed those malicious software artifacts before they were removed from the 

 upstream registry. As always a way that 

 registry users can stay ahead of this type of attack is by defining a 

 registry. In Cloudsmith, we solve this problem through automated 

. Cloudsmith also tracks the malicious packages under the 


Match new packages for a specific period (for example a couple of days) after the package was initially released. By enforcing a time lag before consuming a new package or package version, we are enforcing an effective safeguard to protect against zero-day attacks such as the compromised 


This simple policy checks if a package was part of a supply chain attack. If OSV.dev identifies the package as malicious in their advisories, for example, 

, Cloudsmith registries can automatically quarantine packages that start with the "

 by the TanStack team, the attackers successfully released 84 compromised versions of 42 different 

 packages. The breach was achieved through a multi-step exploit involving "

 workflows, GitHub Actions cache poisoning, and the extraction of OIDC tokens directly from the runner's process memory. Unfortunately, we expect to see more of this style of campaign from groups like TeamPCP in the coming months. As always, there are steps that we can take to stay safe.

Talk to Cloudsmith about protecting your software supply chain →

Nigel Douglas

Head of Developer Relations

TanStack npm packages compromised in Mini Shai-Hulud attack

On April 30, 2026, the Mini Shai-Hulud campaign moved beyond npm and into Packagist. Attackers replaced the contents of 

, Intercom's official PHP client, with over 20.7 million lifetime installs, with a credential-stealing payload that executed at install time, before any application code ever called the library. PHP teams, Laravel applications, and continuous integration (CI) pipelines that updated to that version may need to treat affected environments as compromised.

The attack exploited two properties of Packagist that most PHP developers have little reason to question.

Packagist versions are not immutable. The registry mirrors tags from upstream Git repositories, and those tags allow force-updates to point to a different commit. The attacker force-pushed a malicious commit behind the existing 

 tag, replacing a known-good release without changing its version number. Any developer or CI system that ran 

 after 20:53 UTC on April 30 received the compromised artifact, even with an explicit version pin.

 as a Composer plugin, subscribing it to the 

 hooks. Composer ran attacker-controlled code as a natural part of installation so it didn’t require an import. The plugin executed a shell script that downloaded Bun 1.3.13 from GitHub Releases and ran an 11.7 MB obfuscated JavaScript payload called 

 as a background daemon. A legitimate PHP SDK has no business doing any of that.

 harvests credentials broadly: GitHub CLI tokens, npm tokens, SSH private keys, cloud credentials across AWS, Azure, and Google Cloud Platform (GCP), Docker registry credentials, Kubernetes configuration, HashiCorp Vault tokens, and 

 files. It also queries cloud secret-management services directly, e.g., AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and Kubernetes Secrets.

The payload encrypts stolen data with AES-256-GCM before exfiltrating it to a hardcoded endpoint at 

. If that channel fails, it falls back to GitHub-based exfiltration using any GitHub credentials it has already harvested.

It also carries supply chain propagation logic. Stolen npm tokens let it republish modified packages with injected install-time scripts. It writes payload files into GitHub repositories using commit messages like 

, designed to disappear into normal developer workflows.

The Mini Shai-Hulud Packagist attack follows the same pattern as the 

: a trusted package, a payload injected silently at install time, and a detection window too narrow for teams pulling directly from public registries to rely on.

Cloudsmith sits between your teams and public registries, applying security controls before packages reach build environments or developer machines. Age-based (

) policies would have identified the compromised 

 artifact immediately on publication, blocking it from entering any build until it cleared a configured minimum age threshold. According to internal data, in 2025, 99% of malicious npm packages received official verification within 72 hours. A cooldown policy buys exactly that kind of margin.

Cloudsmith continuously ingests threat intelligence from OSV.dev and the OpenSSF Malicious Packages project. Continuous package enrichment matches cached packages to malicious identifiers. A positive match triggers security policies, which automatically take the prescribed action that users define, e.g., block, quarantine, tag, etc., without requiring manual triage. Routing all Composer requests through Cloudsmith as an upstream proxy also gives your team a full audit trail of which package versions entered your artifact store and when. These are the first questions you need to answer when scoping an incident like this.

If you want to understand how these controls apply to your current Packagist and Composer setup, 

Mini Shai-Hulud reaches Packagist: the intercom/intercom-php compromise explained

In the current landscape of software development, the primary threat to the supply chain isn’t necessarily a lack of information – it’s a lack of action. Our 

 reveals a growing "enforcement gap": the dangerous interval between identifying a vulnerability and successfully applying a security policy.

While organizations are getting better at generating security data, they are struggling to operationalize it. Visibility without automated enforcement is a front-row seat to disaster.

The manual audit trap: Visibility without velocity

 they are vulnerable, but they struggle to tell you 

 is affected. While our report shows that identification speeds are improving, legacy infrastructure and manual processes hamper teams’ ability to act on that information.

One of the first questions after discovering a malicious artifact may be: “Who downloaded this and where did it go?”

The answer for many teams is far from instantaneous. Our survey found that 

 find it difficult to identify exactly which users or systems have accessed a specific compromised artifact, often requiring manual deep-dives into logs and system data for answers.

This manual toil is more than an inconvenience; it is a security risk. In a world of automated, AI-driven attacks, relying on human-speed investigations is a losing strategy.

Fragmented scanning: The “CVE-only” blind spot

Another major challenge contributing to the enforcement gap is toolchain fragmentation. Many organizations treat different types of threats as separate problems, using separate tools that don't talk to each other.

Our data indicates that while CVE scanning is becoming standard, many organizations are still missing logic-based threats and malicious package injections. In fact, 

 have a fully automated process for verifying the chain of custody or cryptographic origin of their artifacts.

When your security stack is a patchwork of third-party scanners and manual spreadsheets, deny-by-default governance is impossible to maintain.

The 24-hour countdown: Why the CRA changes everything

The enforcement gap is no longer just a security concern, it’s becoming a legal liability. The 

 introduces strict reporting mandates for any company selling digital products in the EU. Reporting requirements for the CRA begin in September 2026.

The notification windows for CRA compliance are narrow, requiring an “early warning” within just 24 hours of discovering an active vulnerability. If your team relies on manual effort to quarantine and remediate threats, meeting these legal timelines becomes a statistical improbability. To remain compliant, organizations must move away from static, compliance-only SBOMs and toward real-time, automated gatekeeping.

Cloudsmith was built to eliminate the friction between identifying a threat and stopping it. By providing a unified, cloud-native control plane for all your artifacts, we help you transition from reactive remediation to proactive governance.

 Don't wait for a scan to finish to decide on a package. Cloudsmith lets you write policies that can automatically quarantine any new dependency at the point of ingestion, ensuring nothing reaches your developers until it clears your specific security hurdles.

 We consolidate CVE scanning, malicious package detection, and license compliance into a single source of truth. No more parsing server logs; you get granular audit trails that show exactly who, when, and where every artifact was accessed.

 Cloudsmith automates the verification of digital signatures and maintains a cryptographically secure chain of custody for every binary. This ensures that what you build is what you deploy.

The velocity of modern software development demands infrastructure that can scale security as fast as it scales code. By automating the enforcement of your security policies, you don't just close the gap; you build a more resilient foundation for everything your team creates.

Get all the data on software supply chain security.

This post highlights a few of the challenges facing modern DevOps and Security teams. Download the 

, which contains data and analysis on the state of software supply chain security.

Closing the enforcement gap: Why visibility isn’t enough for supply chain security

 have identified a new software supply chain attack on the 

”. A series of malicious packages are masquerading as a new AI coding agent called 

, the malicious package was reported minutes after being identified as containing a malicious payload on the 

 community did a great job in removing these suspicious packages from the registry so quickly, the 

 advisories weren’t able to classify these packages in time. But that’s okay, since they have successfully been removed and pose no threat right now.

OSM scanned the binaries, and the payload appears to be infostealers focused on cloud and AI credential harvesting across 

 storage. These payloads are adjusted for Windows and MacOS environments. A list of 

As always, if you’re a Cloudsmith user, you can apply age-based (

) policies to block newly published packages. In the case of the stardrop campaign, the malicious npm packages were all removed less than a day after the campaign began.

 is one of the most effective ways to stop this class of attack, giving security researchers (like our friends at OSM) time to identify the suspicious payload. In 2025, 

99% of malicious npm packages were identified and officially verified within 72 hours

, so implementing a simple cooldown policy significantly reduces this kind of attack vector.

Stardrop: New cross-industry npm campaign

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.

The easiest way to get started exploring these metrics is to check out the metrics command within the Cloudsmith CLI. Alternatively, to get more fine-grained metrics, you can implement a programmatic solution using our API or one of the API binding libraries published in various languages.



Using the Cloudsmith CLI you can quickly and easily query the total bandwidth usage for your repository by running the following command with your organisation/repository.

The following screenshot shows an example repository contain a number of active and inactive entitlement tokens alongside the total bandwidth used. The statistics table provides a simple insight into min/max/average token usage.

You can also retrieve usage metrics for one or more specific tokens by providing a comma separated list of Entitlement token (identifiers)

cloudsmith metrics tokens cloudsmith/example --tokens=ZGCV58VqT8Sl

If you wish to drill down further into a specific period of usage for a token, you can supply am epoch timestamp for the 

 parameters to include only usage within that period. In this example, a single token is displayed for all of 2019.

Vendors Rejoice! Analyse your Bandwidth Usage

Using Cloudsmith to store and distribute any type of file

A quick walkthrough of how you can use a private Cloudsmith repository to store and then distribute any type of file.

At Cloudsmith, we want to be your “one central source of truth” for your dependencies and package management needs. And in keeping with this ideal, we are extremely pleased to announce that we have added fully configurable transparent Proxying and Caching support for Debian packages.

Well, in short, it means that you can now use your private Cloudsmith repository for all of your Debian package needs – whether that is your own private packages or packages that you need from public upstream sources. Your private Cloudsmith repository is all that you need to handle both.

If you request a package from your Cloudsmith repository, and that package isn’t present in the repo, then Cloudsmith will automatically check any upstream repos that you have configured and will then fetch (and optionally cache the package for future requests) from the upstream.

This brings you several important benefits:

. Your Cloudsmith repository is the only repository you need to configure on your clients. No more need to configure multiple repos, and handle multiple authentication credentials etc. Configure the upstreams once in Cloudsmith, and that’s it done.

. If you have cached packages and dependencies that you require in your Cloudsmith repository, then if the upstream repo goes down, is otherwise unavailable, or if the packages are removed then you can still access your cached versions. No more breaking of build or deployment process due to an unreliable upstream.