By submitting this form, you agree to our 

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.

Nigel Douglas

Head of Developer Relations

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.

Multi-format repositories allow you to store artifacts of different formats in the same place. Organize your packages by environment, project, package type, or whatever way you see fit- we are not opinionated about how you organize your packages or containers.

Cloudsmith is the most flexible, universal package manager on the market, with Multi-format repositories and support for all package formats.

In the not-too-distant past, it was common to see organizations characterize themselves as Java or C# houses- it’s rare nowadays to find a project that is developed entirely in a single language.

A common project may use React for server-side rendering, Kubernetes, and Docker for orchestrating microservices and have microservices built using Python, Java, and Node.js. Different frameworks and languages are used depending on the expertise and problem they are tackling- backend, frontend, containerization- there are loads of good reasons to have multiple languages in your project- Who are we to judge your tech stack!

Many package managers don’t support a broad range of packages. That means you’ll require several repositories (Public or Private) and therefore several places that you need to manage, several places that you’ll need to integrate with your build processes, and several places that you’ll have to ensure your team has reliable, performant access to.

Other package managers don’t let you store different packages in the same repository. They make you create a repository for all your NPM packages, another for your Maven packages, and another for your Docker images. At Cloudsmith, you can do this no problem, but you don’t have to 😊

What exactly is a Multi-format Repository? Cloudsmith’s Multi-format repositories can house all your packages in one single location- no matter what package format you are dealing with!

You can throw your Docker images in with your NPM packages, your NuGets with your Helm Charts- if it makes sense for your project and your team, go for it.

Your Multi-format repository will still work as expected with your native packages management tooling. You can use the native tooling for all supported packages- ‘docker pull’, ‘pip install’, or ‘npm install’ for example- all from the one single repository!

So while you have a single repository and a single set of processes for managing, sharing, and controlling your software assets, you lose absolutely nothing when it comes to functionality.

The benefits of Multi-format repositories aren’t just limited to development environments either. If you are distributing your software to your own customers, and you provide it in a number of different formats, wouldn’t it be nice to offer all those formats to your customers from a single location? You no longer have to worry about pushing/publishing to multiple different repositories.

Multi-format repositories make it easy to develop, deploy, and distribute software.

If you are worried about losing some information by changing your repository structure, don’t worry- you can enrich your packages with Universal Package Tagging.

Cloudsmith Multi-format repositories mean you can apply these tags across all the package formats you use, all in one repository.

With universal package tagging, you now have the ability to add your own searchable attributes to your packages without complicating the repository structure.

We are not opinionated around how you organize your repositories. There are many ways to organize your repositories- below, we explore how you can structure your repositories around logical groupings of environments, projects, or package type.

A popular structure for customers in Cloudsmith is to have your repositories mirror your production pipeline and then use webhooks to automate deployment and promote assets.

A typical setup is to have a development, test, staging, and production repository. Once you upload an asset, you can promote it through the repositories: development -> test -> staging -> production. This structure helps keep the integrity of the asset, a provenance trail, and without the bandwidth cost of downloading from staging then re-uploading to production.

Nice and simple, easy to automate against- it’s a classic!

I love seeing all the packages associated with a project in the same place, especially when working on a project which uses a microservices architecture with a diverse tech stack. Use your repository to help Developers visualize how the project works together.

Storing all your packages associated with a project in the same repository is a simple and practical way to organize your packages.

Of course, if you want to create a repository for each format you use, you absolutely can do that - there is nothing about Cloudsmith’s Multi-format repositories that would prevent you from doing so.
We like this structure, and it fits beautifully into many DevOps processes, but we don’t like that other providers limit you only to use this structure.

Multi-format is the best fit for modern tech stacks

Modern tech stacks use multiple languages, frameworks, and tools. Cloudsmith’s Multi-format repositories are ideally suited to this environment- a flexible universal package manager that can store any package format in whatever repository structure you choose fit.

Reduce the complexity of deploying software and gain the flexibility to structure your repositories to suit your team and processes using Multi-format repositories.

Modern Tech Stacks need Multi-Format Repositories

The movement away from on-premise and towards the Cloud is unstoppable. Even the 

 government is on board with their plans to “accelerate movement to secure cloud services, including Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS).”

There's many types of infrastructure to consider when selecting software. We aim to uncover the true difference of the key two, being on-premise software and cloud-native software below.

Cloud-native software and technologies are an approach to architecting, building, and managing workloads built in the cloud. This means that cloud-native software has the Cloud inherently built into its DNA, taking full advantage of all the technology that Cloud provider platforms offer. This results in the ability to scale for global performance.

On-premises (or on-prem) software uses IT infrastructure hardware and software applications that are hosted on-site, and relies on constant maintenance and upkeep from dedicated resources. On-prem is quickly becoming the legacy approach in artifct, as organizations are realizing the power of the Cloud.

What exactly is the difference between on-premise and cloud-native?

On-premise (on-prem) software is deployed, hosted, and maintained by your organization. While you can host your on-prem software in the cloud to remove some infrastructure and maintenance costs, you really need cloud-native software to take full advantage of the Cloud.

Cloud-native software is designed, developed, and deployed to take advantage of modern cloud computing, using techniques like micro-services, modularity, containerization, continuous integration, and continuous deployment.

When you access your software over the cloud, that usually means using the SaaS licensing and delivery model. You access your software over a browser or via an API, and you pay for what you use, like a utility bill.

Cloud-native software using SaaS licensing empowers you to focus on growing your business while only paying for the services you use.

Advantages of Cloud-Native Software over On-Premise Software

Many new companies today are choosing to offload the overhead of maintaining the tools and infrastructure they rely on to cloud-native services. The use of on-prem software is mainly due to legacy or regulatory reasons.

For example, the innovation coming out of Cloud-first FinTech companies compared to the risk-averse old-school banking industry shows what you can do when unshackled from your on-prem mindset. Now you see older banks like 

 accelerating their use of the cloud to remain competitive.

There are many advantages of cloud-native over on-premise software:

Cloud software is hosted for you. You don’t have to worry about maintaining your “on-prem” software or infrastructure- No updates, no security patches, no replacing obsolete hardware. Cloud-native technologies allow businesses to reduce the total cost of ownership for businesses, especially when you factor in the staff costs of maintaining “on-prem,” never mind just the licensing fees.

Scalability is another area where the cloud excels. Cloud-native software can quickly re-adjust its resources to meet demand. A company experiencing rapid growth can use the cloud to expand its infrastructure and computing power. In contrast, the same company using on-prem infrastructure would have to quickly invest in more hardware, software, and Engineers to keep up with rapid growth. On-prem software cannot compete with Cloud-native software in terms of scalability and flexibility.

“On-prem” software solutions tend to be faster the closer you are to the infrastructure. It’s no longer acceptable for everyone near the company headquarters to have a responsive low latency experience, while other geographically distributed teams have to put up with significant replication lag. This lag stifles collaboration and productivity.

Cloud software can use techniques like content delivery networks (CDN) and edge caching to provide better performance for distributed teams without requiring you to implement complex global replication or maintain globally distributed infrastructure.

A secure system needs a secure building, training, constant security updates, high availability, monitoring, and disaster recovery infrastructure. Although many companies that host their software on-prem take security very seriously, it is expensive and consumes many working hours.

Cloud providers are driven to focus on security as their business and reputation depend on providing a robust and secure service. As a result, cloud providers use highly sophisticated security tools and resources beyond the reach of most in-house teams.

 projects that from 2019 to 2029, there will be a 22% increase in the number of jobs available to Software Developers. It’s already hard to find Software Engineers, and the best ones want to work with the latest technologies. We need to embrace tooling that takes advantage of the automation and scalability of cloud-native technologies- freeing up your engineering and server resources to build your products.

When moving from “on-prem,” it’s crucial to select cloud-native tools, like 

Some vendors offer their on-prem software on Cloud platforms. However, these legacy offerings were not designed to run on a Cloud platform or architected to take advantage of the paradigm shift that cloud computing enables. You are left with effectively paying on the double for the same on-prem software, just running in a virtual machine in the Cloud. These Frankenstein hybrid software solutions inherit the same scale and distribution problems as their on-prem alternatives.

Cloud-native software works in tandem with Cloud Infrastructure- secure, fully distributed workloads, fault tolerance, and thanks to containers, it can move from cloud to cloud with ease and scale in or out rapidly.

Cloudsmith- your very own Cloud-Native packaging tool

Package management is an example of a tool that would benefit from being Cloud Native. Package management tools develop, deploy and distribute software packages.

Cloudsmith is a Cloud-native package management tool that makes life simpler for your engineers. Don’t worry about infrastructure, patching, upgrades, replications, or scaling. Our cloud-native architecture enabled us to develop a smart CDN for software packages- or our Package Delivery Network (PDN). The PDN is optimized to ensure lightning-fast delivery for deploying or shipping licensed software to your customers.

We believe that the elasticity, flexibility, security, and scalability of the Cloud allow us to support infrastructure and service beyond the capability of traditionally provided “on-prem” tools.

Shift to the cloud away from on-prem software by choosing Cloud-native software to empower innovation, stay secure, reduce costs, and scale as your business needs change.

Go Cloud-Native or Go Home

In early 2020, threat actors breached the build systems of SolarWinds and used this access to add malicious code into one of SolarWinds products. The product, called “Orion”, is very widely used and deployed by tens of thousands of companies, including many Fortune 500 companies.

Then, from around March 2020, when SolarWinds’ customers updated their installations of Orion, the malicious code embedded gave the threat actors a backdoor which they could then use to install additional malware, spy on, and exfiltrate data.

By now, this is a very well-known, maybe even the most famous, example of a software supply chain attack.

In short – a lot! Unfortunately, the SolarWinds’ incident was not the last time a software supply chain was breached. Software supply chain attacks have been continuing and could be accelerating.

In February, it was discovered by security researchers that many public package repositories and registries could be used to implement a 

, which allowed the insertion of malicious code or packages into several major companies’ build and development processes, including Apple and Tesla.

threat actors had breached a very commonly used development tool, CodeCov

. And just a few days ago, it was revealed that the primary public registry for Winget, Microsoft’s new Windows 10 package manager, was being filled with 

corrupt, duplicate, or possibly malicious

Despite the amount of news that these incidents have generated recently, unfortunately, software supply chain attacks are not new.

 development environment was distributed, which, when used to develop software for iOS, inserted malicious code into dozens of iPhone apps. And in 2019, the same thing happened to Microsoft’s Visual Studio, which resulted in 

In 2017, another software supply chain breach launched the 

. The software updates for a Ukrainian accounting product were compromised and caused an estimated $10 billion of damages.

And also, in 2018, a group of threat actors compromised software updates from the manufacturer ASUS and the computer cleanup tool CCleaner. These particular attacks are believed to be 

 successful supply chain attacks perpetrated by this group.

Overall, these attacks have affected thousands, if not hundreds of thousands, of users and systems. And often, the difficult part is determining exactly how large the blast radius is.

There are a few reasons why we see an increase in software supply chain attacks, so let’s just touch on a couple of the most important ones.

The first reason is that software security is not new. For years now, we have been conditioning users to “not click links in unsolicited emails”, “Check that the site you are using is genuine and secure”, “protect username/password/credentials”, etc. As users, we have started to implement better opsec; we are more aware of threats and how to combat them.

So, as a result, the threat actors have had to move up the chain. Rather than target individual users and systems, they target the very processes by which users obtain their software. After all, who wouldn’t trust a software update that has been delivered from a software vendor's distribution platform and signed by the said vendor? Everything we have been conditioned to question and check passes in this case.

The second reason is that the blast radius is potentially so much greater. Rather than targeting thousands of users or systems and compromising just a few, an attack like that on Solarwinds results in a single compromise expanding to many thousands of compromised systems and networks.

The threat actors can leverage the distribution networks of a software vendor to do the dirty work for them. To let thousands of Trojan horses out into the wild and run wild. The payoff is just so much greater for a successful supply chain attack, that it represents a significantly larger return on investment to an attacker.

At Cloudsmith, we believe that the solution comes in the form of Continuous Packaging.

Continuous Packaging is a development methodology that offers the observability and control to ensure that software is always verified, packaged, and ready to deliver.

We have talked about this before, and you can watch our talks on continuous packaging on 

. We think that continuous packaging is the missing link between continuous integration and continuous deployment – The cornerstones of a modern DevOps software development process.

It really comes down to using new best-in-class tools to help you have visibility and management over all packages and code used in your environments—providing trust, isolation, and performance.

· Minimise trust. Scan at source, during build and at packaging.

· Implement and own a single source of truth for packages.

· Be a curator of software packages, not just a consumer.

· Draw a thread from build to deployment.

We will dig a bit deeper into continuous packaging in an upcoming blog, so check back soon and watch this space.

 have recently announced efforts to improve the security of software supply chains. These efforts should result in guidelines for best practices and minimum standards that vendors should meet.

At its core, this is what Cloudsmith does. Cloudsmith provides a single source of truth for all packages and containers you consume as part of your development process. It enables you to isolate yourself from public upstream package sources and take back control over your software supply chain.

It’s time for a change. It’s time for an overhaul of how we securely develop software, and it’s time to get ready.

SolarWinds and the Secure Software Supply Chain

Today, almost every service now is offered in a “Cloud” variant. But what does that really mean? Are all clouds services equal?

It’s easy to see why so many vendors rush to add a Cloud edition/variant of established software they sell. Undoubtedly, there has been a move to Cloud services across the industry, as more and more organizations seek to take advantage of the higher reliability and lower total cost of ownership that Cloud platforms promise.

The thing to watch out for is the major difference between Cloud Hosted and Cloud-Native.

When Cloud providers started to emerge; spearheaded by AWS who saw the opportunity to monetise the tooling and spare capacity they had in their data centres. We began to see other vendors jump to offer their software (which had previously been sold for on-prem use) on these Cloud platforms, hoping to capitalize on the emerging trend.

A lot of “enterprise” software was never designed to run on a Cloud platform. It was never architected to take advantage of the paradigm shift that cloud computing enables, and you are left with effectively paying (a premium, in some cases) for the same software, just running on a virtual machine on a Cloud platform. This is Cloud hosted. A self-contained software solution, typically cannot take advantage of what the Cloud offers - for instance, how would it know to load balance requests? Or scale up. Most of the time, it is limited by the resources it has to hand. The fixed cpu and memory it has been allocated.

On the other end of the spectrum, you have software that has Cloud built into its DNA. Software that relies on features that are only possible on Cloud platforms in order to work as it does - think fully distributed workloads, fault tolerance, and scaling for global performance.

Every superhero has an origin story. This is ours.

Cloudsmith Blog

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

Universal Package Tagging

For Vendors: No-code software distribution using Zapier and Cloudsmith

Create a Repository in Under 60 Seconds