Continuous Packaging (CP) is a term that we have coined here at Cloudsmith, and it is one that we think will become a cornerstone in a secure software development process.
Cloudsmith's Ciara Carey and Dan McKinney have partnered with O'Reilly to introduce the world to Continuous Packaging (CP), and how teams can implement CP into their software supply chains.
- Explore the current state of software supply chains.
- How developers can identify risks in their own supply chain.
- Why CP is critical to secure CI/CD pipelines.
Download the report: The Rise of Continuous Packaging
Otherwise, continue reading below to discover the fundamentals of Continuous Packaging!
What is Continuous Packaging?
When you think of modern software development workflows, you typically think of DevOps – and that involves continuous integration (CI) processes and continuous deployment or continuous delivery processes (CD).
These processes evolved to accelerate and improve the task of developing and delivering software at scale. They provide increased velocity, reliability and security through automation, controls and closing the gap between development and operations. Software isn’t “thrown over the fence” anymore when it goes into production. The process is end-to-end, from development right through to deployment or delivery.
As an industry, the adoption of modern DevOps processes like this has brought with it great rewards. Companies can grow faster, ship quicker, delivery of updates can be streamlined, and any issues, bugs or problems can be addressed with less delay.
Sounds great! Job done. Or is it?
Not quite! Let’s roll back a bit to the beginning.
Typically, you start with your source codebase. Your CI processes take this and build it into a set of artifacts, images or packages that your CD processes can then deploy to infrastructure or deliver to your customers.
So, there is something that CI and CD have in common, and that is software artifacts, images, or packages. These are the output of CI processes and the input for CD processes.
And this is where continuous packaging comes in. We see CP as a glue layer that sits between and overlaps CI and CD. To build secure software development pipelines using a DevOps methodology, you need the ability to universally store and deliver packages securely and efficiently across all package formats and languages.
It’s unlikely that you would use multiple source control tools or multiple CI or CD tools. You settle on the best-in-class tool for the task, and package management needs to be the same. CP should be a checkpoint - a layer that all packages, images, and artifacts used in and produced from your build processes and your deployments need to pass through. That layer is what empowers you and provides you with the control and visibility that you need.
And that is what it comes down to - At its core:
There is an ever-increasing focus on software supply chain security, and rightly so. Recent events have shown that attacks on the software supply chain are fast becoming the number one method that threat actors are employing to breach organizations and users’ security.
And why is this? Well, it’s because it’s a highly effective way to get malicious software distributed to many targets. These targets are increasingly aware of traditional attacks and have been educated to defend against them. What better way to gain entry to a target than through a legitimate update mechanism from a vendor or through a compromised software package that gets used in a build?
Software supply chain attacks manipulate the trust that users and companies place in vendors and the trust that developers place in code that they import or use from public registries and repositories.
Benefits of Continuous Packaging
So how exactly does CP provide you with that security, control, visibility and management? Well, to break things down a bit further, some of the key benefits of CP are:
- Isolation – which gives you control and visibility
- Provenance – Which provides you with security via a chain of trust
- Acceleration – Which gives you low latency performance for your teams
Let’s look at each of these in turn.
Provenance
Provenance is the ability to verifiably prove, using things like package checksums and cryptographic signatures, that software assets are what they say they are and are from who they say they are.
Continuous packaging is about providing a verifiable “Single Source of Truth” for all packages, images, or artifacts consumed or produced during your CI processes. It helps you protect your users and customers by building and shipping clean software only.
Up until now, at Deploy time, there are additional steps when pulling in other dependencies – there is a hole in the provenance chain, a gap to be filled, and having that single source of truth closes that gap.
Isolation
It’s generally accepted that a lot of the software you run is built by someone else; it’s open-source or built on open source.
It’s a widespread practice in software development to use and depend on public packages - packages from a public repository and by connecting directly to a public repository, you open the door to possible attacks. This has already been demonstrated as an attack vector through Dependency Confusion attacks and the Codecov breach.
Continuous Packaging gives you a protective layer between your teams and public repositories; it defines isolation as the ability to cache packages away from public upstreams. Just some of the benefits this provides are:
- You control package availability. In the event an upstream becomes unavailable, you can continue to build and deploy.
- Protection from Vulnerabilities. If a vulnerability appears in a new version of a package, you have previous versions you may be able to roll back.
- License Management. If a Licence changes, you have the current version, same licence, no immediate impact, gives you time to prepare.
Now, these upstream packages are held in your environment, which brings them under your control. They can form the backbone of your software bill of materials. It provides security teams with an overall view of how packages get used, where they come from and where they are deployed.
Acceleration
We now live in a remote-first, distributed world. Development teams are more distributed than ever before. And not just teams, individual team members are now distributed. Development, Operations, Security – these are all now work-from-home jobs, if not all of the time, then a lot of the time.
So now, more than ever, we need tools that promote strong collaboration and provide a uniform experience - no matter where in the world you are located.
Package Management is a very chatty interface from client tooling running on local machines or build hosts, to package repositories on servers located elsewhere. There is a real need to reduce and minimise the communication times between where you, or your distributed infrastructure, are located and where the artifacts reside.
So, the task is to implement package management globally, providing every team and team member with an optimal, normalized experience. And you need this while also providing universal support for all the artifact types and formats you use. No small task!
At Cloudsmith, we developed what we call the Package Delivery Network, or PDN. It’s like a highly customised version of a CDN because it’s more intelligent and more context-aware. It knows that it deals with packages, software artifacts, and client package management tooling and is built specifically for software distribution, not general content distribution, at the edge.
A PDN means that whatever your team’s location, they all get the same low latency experience. There is no optimal site or location. This helps to foster that collaboration and facilitates the distributed nature of software development today.
OK! So how do we implement CP?
Well, there is good news here. You have probably already started!
If you're still curious on uncovering more about CP, download our report: The Rise of Continuous Packaging which covers everything you need to know about CP, and how to start implementing it in your organization today.
Package management is the core component of Continuous Packaging, and you are likely doing this in some form already. Even if you don’t have a fully automated CI / CD pipeline in place just yet, developers will be pulling packages from repositories and creating packages when building (even locally).
What is essential is to bring all this together with a single source for software artifacts, a source that you control. You should employ a best-in-class, cloud-native tool for package management, one that provides universal package support, controls and availability, so that you can realise the benefits of Continuous Packaging.
Cloudsmith is the most cloud-native, universal package management service on the planet, but don't just take our word for it.
Join today with a 14 day free trial, and experience the benefits of introducing Continuous Packaging into your CI / CD pipeline.
Your development teams, security teams and perhaps most importantly your customers, will thank you for it.
