It’s a fairly common perception that a package repository is basically a file share or file storage, and perhaps for some of the most simple implementations, this is a reasonable analogy.

However, when thinking of Cloudsmith, this analogy misses a lot of important details that make Cloudsmith package repositories rather unique.

If you have used Cloudsmith, you may have noticed that when you publish/upload a package to Cloudsmith or fetch a package from a public package repository (Like Maven Central or PyPi) into Cloudsmith, the first thing that happens is that the package enters a “Synchronizing” state. What exactly is synchronizing?Put simply, synchronization is where Cloudsmith processes the uploaded/ingested package. But that still belies a lot of the detail. What possible processing could a package need? Well, quite a lot actually!

Some of the steps that synchronization/package processing involves are:

 - Setting up the initial state, tools and environment for synchronization.

 - Getting the package files from the upload storage location.

 - Extracting the package files and package assembly (layers and configs for Docker images, for example)

 - Once we have the complete package file set, we scan the files for trojans, malicious content etc.

 - Verify and generate package checksums and signatures, as well as parse and verify package metadata and licenses.

 - Local and Distributed Storage synchronization.

These processes are automatic, require no user interaction and run asynchronously on Cloudsmith's global infrastructure. They are a large part of what empowers Cloudsmith users to implement effective package controls. As they say, knowledge is power - and it’s by the process of synchronization that we gain the knowledge of packages.

Once a package has been synchronized, we can then use the metadata generated to apply things like Vulnerability, Licence and Package Deny policies, create a scoped access token, add tags to the package, or fire a webhook for specific packages/versions. The data generated from synchronization drives a lot of the subsequent actions and workflows that you can perform.

Also, you may encounter occasions where a package fails synchronization:

This is typically a good thing (contrary to initial impressions!) because it can alert you to a problem with the package itself such as invalid/missing/incorrect metadata (the package not meeting the specification for the package type, for example), the presence of Malware in the package, or that you are attempting to upload/publish a package that already exists in the repository (as above). Package synchronization is an essential step in verifying the “correctness” of a package and It’s always better to catch things earlier in your processes than later, as the cost of remediation rises dramatically the later issues are identified.

Cloudsmith Package Repositories do far more than just store your packages, and they have a lot more functionality than just storing your packages in an AWS S3 bucket or Azure Blob Storage, or spinning up a simplistic instance of a package repository. Packages in Cloudsmith repository are so much more than just “bits on disk”, and treating them as such is really doing them a disservice!

What happens when you upload a Package?

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.

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

Software development in the banking and finance industry can make you feel like you’re wearing chains. Regulation, compliance, upfront costs, privacy, legacy systems, fear of cyberattacks, and an “if it ain’t broke” approach can lead to a lack of innovation.

Despite these challenges, some technology-forward banks like Capital One, JP Morgan Chase, HSBC, and Wells Fargo have embraced the cloud and introduced DevSecOps and cloud-friendly architectural practices.

This change has been aided by the fact that cloud providers including 

 can now guarantee compliance to banking regulations, and the existence of new cloud-native core banking engines like 

 to help banks move off their legacy systems. This cloud transformation helps banks stay competitive, move away from batch processing towards real-time results, attract engineers, reduce costs and come up with new innovative products.

Part of this cloud transformation means updating the tech stack for developers working in banking- Getting rid of ‘on-prem’ applications and moving to their cloud-native tools.

Cloudsmith is seeing new interest from financial institutes that want to implement a cloud-native SaaS product - they are not demanding on-prem versions of our product anymore. Today, let’s dive into the benefits of cloud-native package management tools for the finance industry.

So what do developers working in banking need from their package management solution? They need to be able to:

In the next few sections, we’ll explore:

The banking industry has been slow to adopt the cloud, and many banks still run their own data centers to process huge workloads. Banks have long understood that using cloud infrastructure has cost-saving benefits but were reluctant to move from their ‘on-prem’ systems due to privacy and regulatory reasons. The distrust in the cloud is waning as the risks are understood, and the technology matures. Much of the push to 

 is driven by business-as-usual culture, upfront costs, and priority.

Banks have conflicting priorities, making it difficult to find the IT time when systems are happily working- but the pandemic gave many organizations space to relook and revive their IT strategies. Several large banks have undergone a cloud transformation during the pandemic, including:

“A key factor causing ‘core to the cloud’ to reach a tipping point is that cloud-native core banking software applications such as Thought Machine, Mambu, and Finxact are reaching a level of maturity where the journey is worth the effort, ”

, a senior industry director for Banking at Accenture. Maintaining data centers and staying ‘on-prem’ is not just a case of staying still but going backwards.

We've covered the many reasons to move to the cloud as a finance organisation below.

Banks need to innovate quickly to meet customers' ever-changing needs. 

 and Fintechs are putting banks under competitive pressure by offering financial products. Staying still is no longer an option to survive.

“Everything is moving to real-time,” Rohan Amin, the chief product officer at Chase. Customers want their services, like their balances, updated immediately in real-time. Cloud computing facilitates moving to real-time as a general model.

Resilience, scalability, and availability

Banks need to have high availability, resiliency, reliability, and scalability to serve the bank customers with minimum downtime. Cloud-native software can quickly re-adjust its resources to meet demand. When volumes spike in financial markets, traders can use extra computing power to analyze price movements and handle bursts of client activity.

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.

Banks are becoming less wary of the security of the cloud in part because cloud infrastructure providers and services have matured and can now offer controls validated by third-party auditors like ISO, PCI, and SOC, that 

 with privacy and banking regulations.

Cloud has security advantages over on-premise systems that rely on physical servers. A secure system needs a secure building, training, constant security updates, high availability, monitoring, and disaster recovery infrastructure.

Although banking organizations 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.

Security is a risk when moving to the cloud but by designing a system with security in mind and by incorporating security into your build and deploy process- your system can be more secure than a traditional on-prem system and stay compliant with regulations.

The upfront cost savings of not having loads of servers in a server farm and “doubling up” by maintaining remote locations for disaster recovery—which all banks require—is significant. 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.

Devs need a package management solution to handle a distributed workforce giving everyone similar low latency access speeds. Tools that don’t do this can lead to reduced collaboration, developer unhappiness, and lack of confidence in your software process.

Software engineers are hard to come by, COBOL and assembler specialists even more so. Engineers want to work with the latest technologies. Banks 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.

Migrating to the cloud has helped many banks and financial institutions compete, improve efficiencies, and lower costs. On-premise software cannot compete with cloud-native software in terms of scalability and flexibility.

Cloudsmith is a cloud-native package management tool that makes life simpler for 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, called the Package Delivery Network (PDN). The PDN is optimized to ensure lightning-fast delivery for deploying or shipping licensed software to your customers.

A package/artifact/image groups together files containing your software, along with the metadata about the software and dependencies in a well-defined format.

Packages promote code reuse, as code can be dropped into another application and used easily. Packages are created using a package manager and are usually stored in a repository, like Cloudsmith (Read our article for a more comprehensive 

The table below details some common software packages used in banking and fintech:

Cloud-Native Package Management for the Banking Industry

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?

. 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.

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.

Private Package Repositories Part 2: The Influencers

Cloud-Native Pipelines: Secure Software Delivery, Made Simple Dev Week Cloud Workshop Session

Your entire tech stack is likely in the Cloud - so why aren’t your software packages? Whether you’re currently on-premise, have your own in-house solution or have a bit of a hybrid set up, join us in this session to explore why the future is cloud-native, what the benefits of this are over cloud-hosted, and how to easily set up a secure, cloud-native software pipeline in 60 seconds.

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.

Cloudsmith blog

What happens when you upload a Package?

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

CD Foundation Announces Cloudsmith as a New Member

Cloud-Native Package Management for the Banking Industry

Everything You Wanted To Know About Securing The Software Supply Chain

Private Package Repositories Part 2: The Influencers

Cloud-Native Pipelines: Secure Software Delivery, Made Simple Dev Week Cloud Workshop Session

Getting Started with Helm and Cloudsmith

Package Delivery Networks: How They Differ From CDNs

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

Intercept Security Scans with Vulnerability Webhooks

Continuous Packaging: Securing end-to-end delivery, from build to production