By submitting this form, you agree to our 

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

2026 Artifact Management Report

 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.

Nigel Douglas

Head of Developer Relations

Stardrop: New cross-industry npm campaign

, an extremely popular HTTP client for JavaScript, suffered a malicious payload injection attack. While the malicious code was removed within a matter of hours, the package’s popularity means that millions of build systems may have been infected.

This attack is the latest in a growing list of software supply chain attacks, this time linked to 

, where the actors took advantage of the popularity of open source packages to serve malicious payloads to millions of victims. npm credentials have repeatedly emerged as a weak point that malicious actors attack.

The attack vector appears to have been a compromise of the

npm account of one of axios’s maintainers, giving a malicious actor the ability to publish new versions of axios to the 

 registry and add malicious dependencies to the payload.

The malicious payload was added to two branches of axios between 00:20 and 01:00 UTC on 31 March. The malicious version remained live on npm for around 2 hours, in part because the maintainer’s

npm account was the only admin account, preventing other collaborators from shutting down the attack until the case was picked up by npm’s administrators.

The attack appears designed to facilitate crypto-related fraud. The attacker modified 

, which is a new malicious software package that did not exist before yesterday.

 was published 18 hours before the axios updates. The compromised payload, in a new version of 

, deploys a remote access trojan that’s tailored for the host’s operating system. This is a textbook supply chain malware injection incident. Systems that configure their build managers to install the latest version by default are subject to compromise in this style of attack. That’s probably a huge number of systems, given that 

 is a popular project, with over 100 million weekly downloads on 

How to secure your supply chain against future attacks

The axios breach comes less than a week after another popular package, 

, the canonical Python public registry. Very popular open source packages are an attractive attack vector for malicious actors. Once a malicious payload like this enters your software supply chain, it can do irreversible damage almost immediately. Cleanup is often a slow and frustrating process, and regulations such as the EU's Digital Operational Resilience Act (DORA) and the Cyber Resilience Act (CRA) require companies to report these incidents within 24 hours, or face substantial fines.

Here’s how to protect your software supply chain:

Route all package requests through a private registry proxy, like Cloudsmith.

 Sitting between your developers and public registries, Cloudsmith creates a checkpoint, applying security policies before packages reach build environments or developers’ local machines.

This proxy buffer is a key component of Cloudsmith. With Cloudsmith as your control plane, every public package, and base Docker container image, is subject to scanning and security policies before anything reaches your build systems.

 was created less than a day before the attack. It was published specifically as part of a malicious payload before the compromised axios versions were published. Blocking package versions less than 7 days old (the specific age is configurable) is one of the most effective ways to stop this class of attack, giving security researchers time to identify the vulnerability.

In 2025, 99% of malicious npm packages were identified and officially verified within 72 hours – implementing a simple cooldown policy significantly reduces the attack vector.

Cloudsmith users with a cooldown policy in place would block 

 even before malicious behaviour was reported, protecting their software supply chain from this attack.

You can configure cooldown policies in many package managers, but Cloudsmith allows you to set the policy at an organisational level, so it’s enforced across formats, teams, and build systems consistently.

Subscribe to real-time threat intelligence feeds.

 Cloudsmith subscribes to databases like OSV.dev and the OpenSSF Malicious Packages project, which update in near real-time.

. Using a system like Cloudsmith to integrate these feeds into your package policies means you get automatic protection as new threats are identified.

 can act on these intelligence feeds, so anti-malware policies trigger even after the cooldown period ends. We’ve written before about how 

Cloudsmith’s policy manager protects your software supply chain

Creating a Malicious Package policy in Cloudsmith

. This one serves as a malware detection gate. EPM runs 

 the Cloudsmith security scan completes during package synchronisation, making scan results available as 

. In this case, the policy code loops over the 

 array, which is the OSV malware data from the scan. For each vulnerability object, it checks, “does the ID start with the string 

So what does this policy do in practice? It flags any package that has been reported as known malicious as part of the OpenSSF Malicious Packages project. "

" is used specifically in vulnerability feeds to indicate malware-related findings. Once a match is found, Cloudsmith will execute the 

 for this policy, such as to quarantine, tag, or block package promotion.


If you are interested in evaluating proactive security policies for poisoned/malicious software packages, 

 about protecting your software supply chain from attacks like the one on axios.

Axios NPM distribution compromised: What happened and how to prevent malicious packages from reaching your builds

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.

Software Supply Chain Security in the Age of AI

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

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!

Security into your software supply chain means visibility into how an artifact is built, packaged and signed.

A considerable part of the reason supply chain attacks are such a threat is that we are missing information to decide if the software we develop and use is safe.

Audit logs, SBOMs, automation, and package management are all essential aspects to bring visibility into your software supply chain so you can answer questions like:

Who wrote the code, who built that code, and who approved the code?

What 3rd party dependencies do I use in my software, how trustworthy are they, and am I up to date?

How do I trace my build from source to deployment?

More than inspecting, scanning, and monitoring historical data, this information can be ingested by observability tools that can help you gain insights, identify unusual behavior and possibly prevent a software supply chain attack.

I’ve listed 10 ways to make your software pipelines more transparent and generate the information needed to gain your observability insights:

Automate your builds using a CI/CD tool like Jenkins, CircleCI, or BuildKite. Make sure all the other tools you use in your build process, including your package repositories, tests and code scanners, facilitate automation using APIs, CLIs, and webhooks.

Having your build steps codified with no manual steps means they can be logged with timing and authentication information. You can gather unusual login attempts, policy changes, or build patterns. Using in-toto attestations at each build step can make this information verifiable and thus more trustworthy.

Audit logs capture all actions the system, users, and service accounts perform for compliance and troubleshooting purposes.

All your build tools should produce audit logs, including your CI/CD, packaging, deployment, and cloud infrastructure tools.

Audit logs can be forwarded to the Security Incident and Event Management (SIEM) for visibility, tracking, and managing of security incidents. SIEM tools also provide next-generation detection, analytics, and response.

It's much more difficult for people and scanners to figure out what is installed on a system when software is installed using scripts instead of a package manager.

A software package, artifact, or image is the output of building software- it groups files containing your software along with the metadata about the software and dependencies in a well-defined format.

A package manager is a software tool that uses the power of automation to create, upload, install, upgrade, and configure software packages. Most software languages, containers, or operating systems have a corresponding package manager, e.g., NPM, NuGet, Maven, or RPM.

Dependencies installed with a package manager ensure consistency and transparency in how software is included in your product and give a straightforward way to access your package's metadata, including version information, license information, dependencies, environment state, etc.

Let's make it easy to figure out what is on our system by installing software with a package manager.

4 Versioning Software and Version Control

Consistently versioning your software product releases, e.g., 

, lets you keep track of all the changes and progress you make. For consumers of your software, the version numbers should inform them of when it's imperative to update and if there are backward compatibility issues.

Mistakes in build can be a hassle, but if at all possible and avoid republishing your builds.

For visibility into your supply chain, we need to know all the 3rd party dependencies in your software. Some package managers, such as pip and npm, do their best to resolve package information look-ups when explicit guidance isn’t provided. This means that a different dependency can be included in your software depending on when you build it e.g. if a dependency has a new update.

If you pin your dependencies to an exact version in your manifest files, no matter when you build your code, the same top-level dependencies should be pulled in, making your build more transparent and consistent.

You need to know when your dependencies have updates for visibility into your software build.

The previous step recommended pinning your builds, but if you have many dependencies, it can be very difficult to update each one manually.

Several update tools help you check for updates in your code base, including Renovate and Dependabot (GitHub).

 is an automated tool that gives developers a score on how safe their dependencies are. Understanding the trustworthiness of your dependencies is vital to improving the security posture of your project.

Signing a package/artifact/image lets people know that this package was signed by a person or organization and proves that the code was not tampered with after it was signed.

There are issues with signing, including a lack of understanding of the signing process, cost, complexity of managing keys, implementation of code signing pipelines, and the lack of verification of signatures.

Recent developments in signing to reduce the complexity of signing and remove the cost barrier to signing with the 

 project have invigorated efforts to sign artifacts.

A Software Bill of Materials (SBOM) lists all the components in your software. The notion of the SBOM was popularized by the Whitehouse when it was namechecked in an 

 last year on improving software security.

An accurate SBOM would improve the transparency of your supply chain, which could allow for:

Earlier identification of potentially vulnerable systems

Support informed decisions for 3rd party dependencies

Incentivize secure software development practices.

 is still evolving, but hopefully, it will be integrated into build tools, making this process accurate and automatable.

It is no longer just about the published artifact at the end of your software pipeline. Instead, it is about providing the tools to ensure artifact integrity across the supply chain.

Information demonstrating the supply chain provenance of a built artifact includes a combination of the steps above, including signing, build attestations, and SBOMs.

Provenance allows you to know and prove the origin of your software.

Monitor and Observe your Software Supply Chain

Some of this information isn’t so easy to generate but will help us monitor and observe our software supply chain, which will ultimately help secure it. This information will help us:

Monitor software supply chain more effectively

Enable visibility for DevOps, security analysts, and developers into the entire build process

Find and connect events in our build and trace them back to the source

Detect and mitigate against vulnerabilities earlier

Detect and alert for unusual login activity or build activities

Observability tools are promising to answer questions relating to the information that your system is generating, even questions that are not currently anticipated- what could this do for our software supply chain?

Ciara Carey

Solutions Engineer

10 ways to make your software pipeline more observable

Deep in the woods, where trees are black and the air is thick, steam rises wistfully across the damp ground. A single dirt track, barely wide enough to pass, scars the terrain for what seems like an endless number of miles. It winds its way through the mountains and valleys, across a rickety bridge over a cavernous ravine, before plunging back into darkness, the trees bending over as if to grasp those passing through. Finally, in a small clearing, a lonely decrepit wooden cabin reveals itself.

The cabin sits unobtrusively in its setting, a small ranch porch makes it almost look inviting. The surrounding trees sway and creak in the wind as if whispering a foreboding message of warning. Evil lurks all around it.

But it is deep within that the problem lies.

In the rotting floor, a trap door reveals a rickety staircase which leads ominously down into the blackness below. A single candle is enough to illuminate a narrow claustrophobic path, deep into the tight bowels of the cellar. The stale air is suffocating. Down the passage, through an opening in the rock-built foundations, a small room houses an old oak desk sitting dusty and alone. The world has forgotten it. In the bottom drawer, locked with a key long lost, is a book wrapped in a thick, almost rigid cloth. Within this book are the incantations to unlock a devastating demonic possession.

A public software repository is the cabin. The book is the dependency you're not tracking. The aimless, unwitting temporary residents are the developers and processes used to build your software supply chain. Without knowledge. Without protection. Bad things will happen.

And without realizing it, the incantations are spoken, and the demonic possession is unleashed. You’ve opened a door, a conduit to another place. A scary and unrelenting place. Filled with demons that want your soul. And a vessel to infect the rest of your world. A host to do terrible, horrible things. Things that no one wants or expects. Control is lost.

So fire up the chainsaw and load your shotgun… tackle the demons head on.

Or better yet. Be smart and just don’t open the Necronomicon.

Alan Carson

Co-founder and Chief Strategy Officer

Dead Evil: A Software Supply Chain Possession

IoT is slowly, quietly taking over the world. A few years ago, self-ordering fridges, driverless cars, and fully automated homes seemed like the stuff of dreams. And while the technology exists, rollout and adoption is slower than anticipated, amidst security and privacy concerns. That said, IoT is the future, and growth is steady, as the challenges of building and maintaining hundreds of thousands of devices per vendor are getting solved.

Today, there are billions of devices online; with an ultra-wide and global dispersal pattern from the factories that built them. Each device runs firmware, or more commonly a light-weight embedded OS and software written in performant languages like C++ or Rust or more accessible languages like Java or Python.

A company building the latest smart TV, or Fridge, or Japanese-style automated toilet needs to ship their device, fully loaded with working software to control the device, connect to the internet to provide analytics back to HQ and get new versioned updates to introduce new features - or most importantly, to receive security patches.

Cloudsmith provides a distribution toolkit for IoT that helps to solve the issues with global rollout at scale.

If you need fast, reliable deployment infrastructure; look no further. Cloudsmith provides accelerated edge delivery of software to allow you to stay close to the sea of devices you want to manage. And what’s more, the caching of your packages and artifacts at the edge is configurable, because there is no one-size-fits-all solution. Your needs are bespoke, and Cloudsmith gives you the control to define a best-fit solution for your own needs.

Cloudsmith enables you to automate the rollout of software using a unique token to manage repository access for each device. Entitlement tokens are read-only access tokens for a Cloudsmith Repository and they can be created to nearly any secure standard.

You can attach metadata; allowing you to store additional information for the device. You can add restrictions to the token; such as a validity period, a specific allowable device IP address or a maximum number of downloads. Each token can be individually managed and filtered to provide tight control of your IP. All of which is accessible via the Cloudsmith first-class API.

Track and monitor which devices have received the latest update. You can attribute each download from Cloudsmith to the specific Entitlement Token used, and you can see when and from where it was used. You can also export this data for further ingest into your own big data or analytics platform of choice, giving you an unparalleled view over the status of your IoT fleet and their package/updates status.

Cloudsmith repositories are fully multi-tenant for package formats. This means you can store all of the package types that we support in one repository, and this repository still works as a native repo with all of the client-side tooling for each format. No more managing multiple repositories if your IoT devices need 

 and even more. Simplify your package management, and gain more control.

Cloudsmith provides a “low-gravity” launchpad for IoT software updates at scale. Let us worry about performance, delivery and scalability while you concentrate on building secure software your customers will love.

Dan McKinney

The Internet of Things - Why Cloudsmith Plays a Crucial Role

At Cloudsmith, using Multi-format repositories, we provide a simple and flexible solution to deploy and distribute your software artifacts.

Cloudsmith Blog

Stardrop: New cross-industry npm campaign

Axios NPM distribution compromised: What happened and how to prevent malicious packages from reaching your builds

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

Typosquatting a package? How about typosquatting the whole registry!

10 ways to make your software pipeline more observable

Dead Evil: A Software Supply Chain Possession

The Internet of Things - Why Cloudsmith Plays a Crucial Role

Modern Tech Stacks need Multi-Format Repositories

Go Cloud-Native or Go Home

SolarWinds and the Secure Software Supply Chain

Cloud-Hosted or Cloud-Native? Discover Why Cloudsmith Was Born in the Cloud

DockerHub vs Cloudsmith Private Docker Registry