Every business, from startups to established enterprises, feels the urgency to scale their software delivery. Why? Because scaling ensures that as a business grows, its software delivery mechanisms can handle increased demands without compromising on quality or speed. A fast delivery cycle is especially crucial for businesses that experience spikes in traffic, and they must respond to user needs promptly, ensuring timely assistance and resolution.

However, scaling isn't just about handling increased demand. It's about agility, security, and efficiency. Businesses that can't scale effectively risk security breaches, delayed product launches, and operational inefficiencies.

Let’s take a look at some of the challenges behind scaling software delivery, best practices when it comes to scaling, and see how Cloudsmith stands out as first-in-class as an industry leader.

Continuous Delivery (CD) is a culmination of years of refining software development practices. It's not just a methodology; it's a culture. From the days of the Waterfall model, where software development was linear and often rigid, to the Agile era, where flexibility and adaptability became the focus, we've come a long way. CD takes it a step further. It's about ensuring that software is always in a deployable state.

This adaptability means businesses can swiftly respond to market changes, customer feedback, or any unforeseen challenges. The essence of CD is to reduce the gap between development and deployment, ensuring a seamless flow of software updates to the end-users.

Scaling software delivery is like preparing a business for growth spurts. It's about foresight and readiness. When software delivery is scaled effectively:

: Businesses can roll out features or fixes in response to market trends or demands swiftly. This agility can be a competitive advantage, allowing companies to stay ahead of the curve.

: With frequent updates and improvements, customers feel heard and valued. It leads to better user experiences and can significantly boost brand loyalty.

: A faster time-to-market means businesses can tap into new revenue streams quicker than competitors. Whether it's a new feature that users are willing to pay for or an entirely new product line, scaling ensures that businesses are always ready to monetize their innovations.

Challenges in Delivering Software at Scale

Of course nothing in life comes without its hurdles, and scaling software delivery isn’t any different. The following are some common issues that companies face everywhere:

 An inefficient system can push developers to the brink. Imagine a critical bug discovered just before a major release. The pressure to troubleshoot and rectify before the deadline can be immense, leading to overworked and stressed developers.

: In the rush to deliver, teams might opt for quick fixes. These "band-aid" solutions might address the immediate issue but can accumulate as technical debt, leading to bigger problems down the line.

: Speed should never come at the cost of quality. Yet, some teams, in their bid to release rapidly, might overlook crucial quality checks, leading to sub-par software releases.

: Every software release carries a degree of unpredictability. Without a robust system in place, these releases can lead to increased production costs, missed deadlines, and more.

 Errors in the production environment can have dire consequences. From minor glitches to major system crashes, production failures can erode user trust and impact the bottom line.

: Manual monitoring in a high-velocity release environment can lead to increased turnaround times for error resolution.

: Inefficient scaling can slow down product launches, depriving businesses of potential revenue and competitive advantage.


Leveraging Cloudsmith for DevOps Excellence

In the quest to scale software delivery, the tools and platforms you choose play a pivotal role. Cloudsmith emerges as a comprehensive solution, addressing multiple facets of the DevOps journey.

At the heart of any successful DevOps initiative is a culture that allows for collaboration and knowledge sharing. Cloudsmith enhances the developer experience throughout the software development lifecycle. When developers are deeply invested in their work, the entire software delivery process benefits.

Prioritizing security in Continuous Delivery cannot be an afterthought, and it certainly isn’t for Cloudsmith. The platform’s universal, cloud-native solution ensures robust software artifact management and supply chain security. From automated security configurations to tools that detect vulnerabilities, Cloudsmith ensures that security remains front and center.

Simplifying your tech stack is one of the most beneficial things you can do for your organization and team as a whole. Cloudsmith offers a multifunctional platform that streamlines the technology stack, allowing businesses to focus on one comprehensive solution that meets multiple needs, without compromising on quality, security, or control.

Scaling software delivery is a journey, one filled with challenges but also immense opportunities. With Cloudsmith as your partner, businesses can navigate this journey with confidence, ensuring that their software delivery processes are agile, secure, and efficient. After all, building products doesn’t really have an ‘end’— we are constantly learning, evolving, and expanding our knowledge of how to build great products. But with precision and purpose, we can build products that truly matter.

Lee Skillen

Chief Technology Officer

Scaling Software Delivery: Continuous Delivery, Overcoming Challenges, and the Power of Cloudsmith

, the open-source software foundation that seeks to improve the world’s capacity to deliver software with security and speed, today announced its State of CD Report in 2022, a new project called CDEvents building a vendor-neutral specification for defining the format of event data, new members, and more.

Cloudsmith, Spacelift, Stackhawk and Tenable are joining the CD Foundation as new members, helping to strengthen the growth and evolution of continuous delivery models.

Our co-founder and CTO, Lee Skillen, commented:

“We are delighted to join the CD Foundation. How companies deliver software securely and quickly is key to their success, and we believe joining will provide even more value to our customers by connecting us to the broader community of continuous delivery companies and developers around the world. The future of cloud-native software delivery, artifact management and the whole supply chain is critical to industries everywhere, so we are excited to contribute our knowledge of continuous packaging to it.”

CD Foundation Announces Cloudsmith as a New Member

You know you need to secure your software supply chain. Everyone’s telling you that these days - your executives, your vendors, even 

. Your organization has an initiative to do so, or maybe they’ve brought in an expert to help you achieve this goal. But hold on a minute - do we have a shared understanding of what a software supply chain is, and what exactly makes it secure?

Hopefully, you were able to join the Linux Foundation webinar Cloudsmith hosted last week with 

. The focus was getting back to the basics of what a software supply chain is, and why it needs to be secure. If you weren’t able to attend, or if you want reference material to share with others, here’s our recap.

The webinar addressed the following topics:

What does a secure software supply chain look like?

What are Cloudsmith and Chainguard doing to help solve this problem?

In the most basic terms, what is a software supply chain?

Simply put, a software supply chain includes 

 everything that contributes to making your product - the source code, dependencies, systems, tooling, environments, processes, and even the users who contribute along the way.

, Developer Relations at Cloudsmith, said that a good analogy for understanding the software supply chain is to look at another industry that also deals with supply chains - manufacturing. The manufacturing industry has a standardized way - a Bill of Materials - to detail all of the inputs into their final product. They need that because they need to ensure they have the materials required to build the physical product and that they have met safety and security standards along the way.

The software industry doesn’t have the same regulatory controls as manufacturing, though. There is no centralized authority ensuring provenance and traceability are enforced (though we may see this in the future). This gap has made space for the rise of many interesting projects designed to help make safety and security so easy, it becomes the default. Projects like Sigstore, The Update Framework, in-toto, and SLSA are just a few examples. We’ll touch more on these projects later in this post.


Why are we securing our supply chains now?

As Dan Lorenc said in the webinar, there have been voices advocating for securing software supply chains for years now. But a handful of events in the last 24 months have caused organizations to wonder why they’ve waited so long to get started.


In the spring of 2020, SolarWinds unknowingly started to send out software updates that contained hacked code. This is the event that really got everyone talking about “software supply chains”.

SolarWinds is an IT management tools company that helps businesses manage their networks, systems, and infrastructure. In early 2020, threat actors found a way into the build system at SolarWinds and managed to add malicious code into one of its products, a performance monitoring platform called Orion. Subsequently, when Orion customers updated their installations, the malicious code was included in the update, giving the threat actors a backdoor they could use to install additional malicious software, exfiltrate sensitive data, or spy on the companies themselves.

Big organizations found themselves impacted - Microsoft and Intel for example. Overnight, everyone was talking about software supply chains and what needed to be done to secure them.


In February 2021, security researcher Alex Birsan 

 were found to be vulnerable to the injection of malicious packages, via public sources, into their software supply chains.

, and it relies on package management software to download the malicious version of a package being used as a dependency. The key is to create an external library with the same name as a private internal library that a particular company uses in its development pipeline. There are then several ways that a package manager can end up accessing the malicious external version of the library.

This incident shows why it is so important to make security so easy, it happens by default. It only takes one developer with a poorly configured system for the malicious library to gain entry to the organization.

Executive Order on Improving the Nation’s Cybersecurity

On May 12, 2021, President Joe Biden issued an executive order to begin creating federal standards for security of the software supply chain. 

The Executive Order on Improving the Nation’s Cybersecurity

 orders the Department of Commerce and the National Telecommunications and Information Administration to publish minimum requirements for a 

 (SBOM). The SBOM is a record of the components and packages used in building software, whether open-source or commercial, intended to help software end-users to analyze vulnerabilities or issues with the licenses.


In February 2022, The National Institute of Standards and Technology released Special Publication (SP) 800-218, 

Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities

. At the start of 2022, the White House brought together government employees, private sector stakeholders, and members of the open-source community to discuss how to improve the security of open-source software and software supply chains. This publication is the result of those discussions, and it recommends a core set of high-level secure software development practices called the SSDF that can be integrated into each SDLC implementation.

Why is this a hard problem for organizations to solve?

One challenge is that open-source software is foundational to software development, and so for an organization to secure their supply chain, they will need all open-source software they use to also be secure. Realistically, open-source code is in every supply chain. Now, it’s important to note that the way to solve this problem 

 to remove open-source software from your supply chain. In fact, open-source software can often be more secure than proprietary software as its widespread use means it’s usually well tested. The challenge is in how to make adhering to security best practices so easy, they are not burdensome for the open-source community to adopt.

Along the same lines, for one organization’s software supply chain to be secure, the supply chain of any vendor they use also needs to be secure. You need provenance from top to bottom. To quote Paddy Carey, Senior Staff Engineer, Cloudsmith, “

.” And if no one is requiring you to adopt secure software development practices, and it’s overly burdensome to do so, what’s your motivation? So again, designing standards, tools, and solutions that make it easy to be secure will be key to the widespread adoption of secure software development practices.

As Dan Lorenc said, it will be slow until the first person adopts these practices, but then we’ll see it ripple across the industry.


First, it’s important to acknowledge that there is no one thing you can do to secure your supply chain. There are many best practices that come together to create a secure software supply chain. But it’s also important not to let that overwhelm you.

One project that is designed to help organizations understand what makes a supply chain secure and provide guidance on how to get started is 

. It’s a security framework, a checklist of standards and controls to secure packages and infrastructure in your organization. And there are SLSA levels - Level 1 is designed to be easy to achieve to help motivate folks to start the process of securing their supply chain.

NIST organizes the Secure Software Development Framework practices into four groups:

: Ensure that the organization’s people, processes, and technology are prepared to perform secure software development.

: Protect all components of the software from tampering and unauthorized access.

: Produce well-secured software with minimal security vulnerabilities in its releases.

: Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

Both the SLSA framework and NIST’s SSDF are good starting points for organizations on the journey to a secure software supply chain. And if you want the tl;dr on NIST’s SSDF, 

Dan Lorenc read NIST 800-218 so you don’t have to

Chainguard was founded in 2021 with the mission to 

make the software supply chains secure by default

. The team is working on this goal with a strong commitment to open-source projects and communities, and a willingness to take on large-scale industry-wide changes. Some key projects they are involved in:

As mentioned earlier, SLSA is a checklist of standards and controls to secure packages and infrastructure within an organization. SLSA levels are a common language to talk about how secure software, supply chains, and their components really are. From source to system, the levels blend together best practices to create four compliance levels of increasing assurance.

A new standard for signing, verifying, and protecting software, sigstore automates how you digitally sign and check components, for a safer chain of custody tracing software back to the source, removing the effort, time, and risk of error this usually comes with this.

As Dan McKinney said, Cloudsmith is excited that securing the software supply chain is now at the forefront of people’s minds, as it’s been close to our hearts for a while now. We believe that 

 - the strategy of ensuring all packages produced or consumed are scanned, verified and isolated from untrusted sources - improves security through isolation, automation, and universal hosting. Our platform enables organizations to add continuous packaging to their modern software development workflow.

Provide a single source of truth of software assets

 with support for over 28 formats, allowing organizations to manage packages across languages and formats in one place. This centralized source of truth provides visibility, control and management consistently for all packages produced or consumed by the build process, and gives organizations a single checkpoint that all packages pass through.

The goal of provenance is an unbroken chain of traceability, all the way back to the host machine that built the package. And we want to meet our users where they are when it comes to provenance. We will implement support for the signatures and attestations that our customers are adopting across all the formats we support, including but not limited to sigstore, cosign, in-toto, The Update Framework and more.

users can cache their open-source packages

 away from public upstreams. By caching packages from public upstream repositories and other external sources, you can protect yourself from issues with package availability, license changes, and emerging vulnerabilities.

First and foremost, we must acknowledge that we are a chain in our customers’ software supply chains. We are taking steps to ensure that we employ high-level secure software development practices, and exposing that information to our customers to prove to them that we are secure. Customers need to be able to trust, and verify, that their providers are securing their software supply chains, too.

Hopefully, that helps demystify software supply chains and why securing them is paramount to the software industry as a whole, and why the time to do so is now.

We’d also like to thank Dan Lorenc, the founder and CEO of Chainguard for joining us for the webinar.

Dan McKinney

Solutions Engineer

Everything You Wanted To Know About Securing The Software Supply Chain

 of our package repositories series, important terms like packages, metadata, dependencies, and upstreams were explained. In this part 2, we will take it further, diving into trends within the software landscape that have changed what developers and organizations want from a package repository.

In recent years we’ve seen a push to use managed services in the cloud, automation, supply chain security. These practices and challenges have influenced what package repositories and package management means in 2021 and what it will mean for the future of software delivery.

The movement towards the cloud is one of the most significant changes in computing for organizations over the last ten years. At a minimum, cloud infrastructure and development has created new package formats such as Docker, Terraform, Helm Charts.

Much more than that, developers and organizations don’t just want package management software- they want a ‘managed’ package management service. A managed package management service will eliminate the cost of supporting an in-house system while improving the reliability of accessing those packages that can scale as they grow.

Organizations and developers don’t want to worry about infrastructure, patching, upgrades, replications, or scaling. They want their package repository service to have high availability and be managed and accessed on the cloud securely. In order for a package management solution to exploit the flexibility, scalability, and resilience of cloud computing, it needs to be architectured to be 

Continuous integration and continuous delivery (CI/CD) is a method to frequently deliver builds by introducing automation into the stages of software development. The whole purpose of this is to release quality code faster.

CI achieves continuous flow for code. CD achieves continuous flow for delivery. But what glues them together? Continuous packaging (CP) is the term to describe maximizing process and flow in software packaging using automation. Without CP, CI/CD is missing continuous flow for the process of packaging (creating, fetching, inspecting, and managing packages). CP means that assets are always traceable, deployable, and built in the same way.

The process of packaging includes creating packages, assembling external packages, inspecting/managing artifacts, token creation, downloading, installing artifacts, event logging, and metadata extraction. For CP to work, developers, CI/CD systems, and scanning tools need to be able to interact with the process of packaging easily and programmatically using well-documented APIs, CLIs, and integrations.

Adding CP to your software process avoids the ad hoc construction or retrieval of assets, and gives a traceable and visible history of promotion from the source (developers and external) right through to delivery (whether internal or external).

Distributed teams were always quite common in Software Development, but Covid has supercharged its adoption even in small companies.

How does this affect package repositories? Before joining Cloudsmith, I worked in a few distributed teams where I experienced serious lag when pushing/pulling packages compared to my colleagues in other regions. A typical problem would be having a limited number of licenses for our private repository- the private repository might be deployed on servers in the US, but not in Europe. It was frustrating, affected collaboration, and slowed down testing and building.

It’s not acceptable for some teams to experience low latency while other geographically distributed teams have to put up with significant delays. Package repository tools in the past dealt with this by implementing global replications on servers, but this becomes difficult to manage and troubleshoot as the number of regions increases. Package repositories that are cloud-native deal with this problem more elegantly as they can use techniques such as PDNs with edge caching to store commonly used packages as close to the users as possible - anywhere in the world.

The software supply chain (SSC) is all of the steps that go into deploying or distributing your software from the initial development stage, to testing, packaging, and deployment. It includes your code, scripts, environmental variables, IDEs, plugins, source code repositories, CI/CD tools, scanning tools, and of course package repositories. The attack surface for the software supply chain is vast. Recent attacks like SolarWinds and CodeCov, for example, prompted 

efforts to improve the security of software supply chains

. Where you push and pull your software artifacts from is intrinsic to securing the supply chain and it has highlighted the importance of package repositories.

First things first- package repositories need strong security features to prove they are trustworthy:

Robust access control with 2FA for distribution and development

All communication and storage should be encrypted in-transit and at-rest

Private repositories that support many formats provide one single place to track, manage, distribute and understand all software pulled into your stack. A central trusted store forces you to apply processes and controls to that ingress/egress of software packages.

Package repositories can secure your packages and interrogate the provenance of packages:

Package metadata includes information on dependencies, licenses, versions, who wrote the code, results from vulnerability scans, information from CI tools. Package repositories need to extract, store and surface all of this data as it is intrinsic to resolving the provenance of software packages.

Attest (prove to outside parties) to the provenance of all the software assets and their dependencies, by signing and verifying every package uploaded.

Provide upstreams for outside packages hosted elsewhere to protect from outages from 3rd party repositories

Package repositories should promote automation by applying

(CP) techniques to integrate programmatically with CI, CD, and scanning tools. Automating as much of the software supply chain as possible and making automation easy can significantly reduce the possibility of human error, improve quality, traceability and help make builds more reproducible.

Your package repository can help you build trust in your software supply chain by giving you visibility and control over every single package in your software in an automated way- the single source of truth for all your software artifacts. Even in situations where the supply chain has been compromised, if you have visibility and control, you’ll be in a much better place to identify the who, how, where, why and what of what is affected, plus a much greater potential of fixing the issue or minimizing impact.

Languages with Community-Based Package Management

Before the adoption of community-based package managers, public language repositories, e.g., PEAR for PHP, were slow to include new packages and subject to a review board populated by a few of the language's elder statesmen. Languages with community-based package management, e.g., npm for javascript and PyPI for Python, make publishing and consuming packages easy. This ease of use has made them popular and accelerated the development process and use of OSS, but it has introduced some security issues.

Popular package repositories such as npm, PyPI, RubyGems, Go, and others have been impacted by malicious attacks such as 

. In addition, these public repositories that host the packages can’t guarantee uptime; private repositories with upstreams can protect against outages. These issues are related to the previous section on securing the supply chain.

Node and NPM were the first time I had used a community-hosted OSS package repository. When vetting new NPM packages, I was always worried about adding an unmaintained package or code that could damage the wider project- Is it enough to check the git link, license type, date last updated, the number of downloads, and the listed dependencies? Not really. There needs to be a way to trust that a package and its dependencies are not malicious in an automated, reproducible way.

Signing can be used to build up trust in packages but we discussed in Part 1 of this blog series how signing OSS packages has problems. 

 to sign OSS packages in a transparent way. But currently, community-hosted OSS packages are not commonly signed. In the absence of using a trusted signed OSS package, package repositories can scan OSS packages for known vulnerabilities and extract metadata information like version, who wrote the code, results from scans, or license information which can provide insight into the provenance of the software package.

Design patterns such as REST encouraged developing a strong interface for other programs to use over HTTP. RESTful services made using other web services easy and more reliable. Each web service could potentially be written in a different language as long as the interface was maintained.

More recently, the microservices design pattern gave more teams or individual software developers the confidence to use new languages to develop new services within the same product. One of the possible downsides of the microservices design pattern is that it can produce many packages in different formats. Having many package formats is only a downside if your package repository doesn’t support your chosen package type and you need to manage another repository.

Modern package repositories need to be able to manage and host multiple package formats.

What do I want from a Package Repository?

Package repositories had to evolve as software development changed and has been influenced by cloud adoption, DevOps, OSS, changing software practices, new security threats, and the rise of new package formats.

So, what do I want from a Package repository tool? I want it to:

Store all formats of my packages for languages, OSs, and containers.

Be easy to automated with and integrate with CI/CD and security tools

Help me attest to the packages in the software supply chain

Have no loss of speed no matter where my team is

Oh, and be simple to use with great docs and support.

To do this I need a package management solution that:

Is universal - can host any package around the world

Can work with dependencies located in other repositories and help make what goes into your software more transparent

Applies Continuous packaging techniques to improve your CI/CD pipeline

Is a central, trusted store that forces you to apply process and controls to that ingress/egress of software packages

Is built by a company that values support.

Ciara Carey

Private Package Repositories Part 2: The Influencers

Getting Started with Helm and Cloudsmith

A short demo of how to get started with Helm and Cloudsmith, including pushing a Helm Chart to private Cloudsmith repository and then pulling and installing the Chart on a Kubernetes Cluster.

Cloudsmith's documentation on creating a Helm repository

Create a Repository in 60 seconds with Cloudsmith

A crucial part of effective package management is package distribution. Whether you are dealing with distributed development teams, deploying a distributed application or even if you are a software vendor, you need efficient, performant and reliable delivery of your software packages or artifacts.

And for that, you need infrastructure. Lots of infrastructure. To deliver software globally, at low latencies, you’ll need infrastructure in many regions, preferably as many as possible. There is no beating the laws of physics; it still takes a finite amount of time for packets to travel a distance, which means that the closer your users/systems are to where your infrastructure is, the better.

So, to accommodate all these distributed users and systems, you’ll need infrastructure in as many data centers or points of presence as you can, ideally co-located alongside or within internet exchange points, giving you the best possible network access.

A Content Delivery Network (CDN) is precisely that. It is servers and infrastructure at many locations globally which are used to deliver content quickly. Many websites and services use a CDN to deliver assets such as pictures, HTML and javascript files to users, without the request for these assets having to go back to the primary hosting infrastructure.

A CDN caches this content at the network edge; it doesn’t host it. And typically, the CDN infrastructure has direct connectivity to internet backbones and exchanges, delivering these assets in the most performant way possible.

So instead of building out, managing and maintaining all this infrastructure yourself, you can use a CDN to distribute your software artifacts and packages, right? Yes, you can, but that’s only going to get you so far.

Well, software package management can be a “mucky” business. Each language, OS, framework or platform has its own package format, client tooling, APIs and communication protocols. It’s not unusual for a modern software development process to use many of these package types, which introduces the problem of managing all these different concerns.

Simply dropping a CDN in front of your package hosting will not accommodate all these differences effectively. It may help, but it’s not optimal. Distributing packages to client tooling is very different from distributing JPEGs or HTML via plain old HTTP.

Introducing the Package Delivery Network: a CDN evolved.

It’s a problem that Cloudsmith was built to solve. From the beginning, Cloudsmith was made with package distribution in mind. We don’t believe that package distribution is a different problem from package management – it’s an essential part of it.

The ability to efficiently distribute software artifacts globally is a fundamental core component of effective package management. It’s more important now than ever, with the rise of distributed teams, working from home, and distributed cloud-native applications.

It’s simply no longer acceptable that your geographic region determines the performance of your development, deployment, or commercial distribution processes. The world has moved on, and we need to adapt to keep up.

And that’s where the Package Delivery Network (PDN) comes in.

Well, the TL:DR is that it’s a highly customized CDN. It’s a CDN that is specialized in the delivery of software artifacts. It knows that it is serving software packages, it’s context-aware, it’s not just blindly serving assets and treating them all as equals. It’s an intelligent CDN.

A primary example of this is our edge caching rules feature.

The first benefit of our package delivery network is that your software packages and artifacts are cached at the edge, reducing the need to retrieve them from primary storage locations and then deliver them to the consumers.

Of course, that’s great that your artifacts and packages are cached at the PDN edge nodes; it’s straightforward to understand how that can improve performance. But what about control? Who decides how this caching is performed? What level of caching do you need? You are best placed to make these decisions, and edge caching rules give you the ability to do so.

You get to define the Time-To-Live (TTL) for packages cached at the edge, and you can cache packages and metadata differently. Maybe you want a very short TTL for something frequently updated, like a Maven snapshot repository. Conversely, you can set a very high TTL for packages that infrequently change, perhaps a new software release or update.

And you can do this on a per-package-format basis as well – as we said previously, the PDN is context-aware.

Also, thanks to the continued improvements in CDN offerings, we can now run some of our application logic directly on the CDN edge nodes themselves. This effectively means that Cloudsmith, as a distributed cloud-native application, is distributed right out to the network edge. Our code can run next to our users and across all the CDN points of presence, giving us greater reach than would be possible with multiple cloud provider regions alone.

This goes above and beyond the basics of caching software packages and metadata at the edge nodes and has brought particular benefits, like authentication at the edge (among others).

Securely storing packages and controlling access to those packages is of paramount importance. With the focus now on software supply chain security, you must ensure that your package repositories are secure and tightly controlled. Private repositories and reducing your reliance on public package repositories are an absolute must.

This brings us to the issue of authentication. Now, authentication in and of itself may seem like a solved problem, and in many ways, it is. What changes things is scale. The problem again is the globally distributed nature of the package use. You need to handle authentication requests from users and consumers anywhere and still deliver the same performance for all.

Some package protocols are extremely “Chatty” - NuGet and Maven, to name just a couple. Authentication requests and responses can add significant overhead if they need to be routed back to infrastructure in a cloud region. At Cloudsmith, we handle this authentication “at the edge”, with application code deployed to the edge nodes.

This significantly reduces the round trip times for these requests, and the difference adds up with the more requests you have.

For example, If two users with different API keys request the same package and have permission to access that package, we can determine that at the edge node and serve the package directly from the PDN cache. No trips back to primary storage, no multiple auth requests back to other infrastructure. Those milliseconds all add up at scale!

Modern software development and distribution processes require modern package storage and delivery methods.

Traditional CDNs have evolved, and secure package management solutions have evolved right along with them.

By taking advantage of the latest developments in CDN technology, Cloudsmith has developed a Package Delivery Network (PDN) - a highly customized, smart CDN specializing in delivering your software artifacts.

Gone are the days of blindly serving assets and treating them as equals. As far as software artifacts are concerned, the PDN is here to stay.

Package Delivery Networks: How They Differ From CDNs

LF Live Webinar: Continuous...Everything? Integration, Packaging, Delivery, and Security All in One!

Application delivery pipelines share many traits with any assembly line.

Open source libraries, runtimes, databases, and base images are raw materials to be inspected to ensure they meet quality and security standards. Modern applications combine these raw materials with custom code to create dynamic and complex environments, opening up an extremely effective attack vector.

While not new, software supply chain attacks are on the rise with changes in how applications are built. With open source components making up more than 80% of modern codebases, having a reliable “source of truth” for the security, compliance, and provenance of software and its dependencies is critical.

In this webinar, Snyk, CircleCI and Cloudsmith will share practices and tools that are helping developers create applications with integrity, quality, and security.

Find and fix known vulnerabilities in app dependencies and container images

Build a source of truth for open source packages to avoid malicious packages

Combine continuous packaging and security into a CircleCI delivery pipeline Create provenance and security quality gates as part of deployment workflows

Join Ryan Pedersen (CircleCI), Tom Gibson (Cloudsmith), and Tomas Gonzalez (Snyk) to learn how to manage and mitigate this new risk profile and create a more holistic application security approach.

Tom Gibson

Principal Engineer

Continuous...Everything? Integration, Packaging, Delivery, and Security All in One!

Cloudsmith provides a way for vendors to sell, license and distribute software as packages. To any customer, anywhere in the world, across a reliable and performant infrastructure, and handling all licensing and invoicing / billing challenges.

As most of the readership of this blog will know, a huge proportion of the software developed around the world is dependent upon the third-party packages and libraries we integrate into our projects.

And whilst a lot of that will be open-source, a surprisingly large amount will be distributed on a commercial basis. Plenty of organizations generate revenue by selling packages and libraries, almost always on a business-to-business (B2B) basis, to clients looking to speed up their own development processes and deliver better software, faster.

Just by way of example, consider the following common use cases:

The creator of fonts, icons or other similar libraries that may be integrated into web projects

Creators and/or distributors of core network libraries

Hardware companies needing to distribute drivers to customers

These organizations have a challenge. They need to sell and distribute the packages they create to customers all over the world, and they need to do so in a way that:

Cloudsmith Blog

Scaling Software Delivery: Continuous Delivery, Overcoming Challenges, and the Power of Cloudsmith

CD Foundation Announces Cloudsmith as a New Member

Everything You Wanted To Know About Securing The Software Supply Chain

Private Package Repositories Part 2: The Influencers

Getting Started with Helm and Cloudsmith

Package Delivery Networks: How They Differ From CDNs

Continuous...Everything? Integration, Packaging, Delivery, and Security All in One!

Managing Commercial Package Distribution: A Better Way

Getting Started with Go and Cloudsmith

Missing Infrastructure: Accelerated Worldwide Delivery

Cloudsmith, the JFrog Bintray Alternative & Replacement

Getting Started with Docker and Cloudsmith