Hi everyone, and thanks for joining me for this talk. The future is continuous integration, packaging, and delivery. So what am I going to talk about today? Well, we will focus on package management, software supply chain security, and where and how continuous packaging fits. In a modern DevOps build and deployment or delivery pipeline.

But first, I'd like to take a moment to just introduce myself. So my name is Dan McKinney. I'm based in Belfast in the UK and Northern Ireland, and I'm part of the Developer Relations team at Cloudsmith. Now, I've been embedded with or working alongside software development teams for over 10 years now.

Actually, uh, approaching 13 years. And at Cloudsmith, It's my role to get out into the community and help and educate, but also to provide feedback from the community to our internal engineering and product teams. I'm passionate about all things focused on software supply chain security. As I believe that effective package management tools and processes are a cornerstone of a secure software supply chain.

I'm also very passionate about good documentation. It's, it's a super important part of any tool or product, and it really does go hand in hand with the, the education side of my DevRel world. And outside of package management and software supply chains, I'm slightly obsessed with Lego and music. I genuinely do go a bit over the top with my Lego collection.

I'm completely running out of space to store it all. And likewise, I actually work as a DJ at the weekends. So that's how I can get to flex my, you know, music muscle memory. That photo is actually a picture of me. DJing, I've cropped it and resized it to fit many purposes over the years. Now you can find me on Twitter at dev rel.

Dan, my dms are open and I'm always happy to chat, so please come follow along and reach out to me E, especially if it's about Lego. And now just a quick introduction to CL Smith. So, so what is Cloudsmith? Well, Cloudsmith is, is a fully managed package management as a service. We enable your team to quickly set up a private and secure delivery pipeline in just a few minutes.

Now, what does that mean? Well, it means that we provide the ability to create universal multi format repositories for over 28 package formats so that you can store, but more importantly, control access to all of your packages, artifacts, and container images. in one place. So it's a single source of truth for all the artifacts that you produce and dependencies that you consume.

And it's also the single pane of glass that provides you with the visibility, control, and, and security to protect your teams, your processes, and and your end users or customers from supply chain attacks, you know, enabling performance. Global secure package distribution. So let's kick things off by, by asking the question, what is continuous packaging?

Well, in a, in a statement, continuous packaging is the art and science of continuously building packages and containers to securely automate software pipelines. Now that's. I actually think that's a lovely summary statement, but what does it really mean? Well, it means that continuous packaging is a, it's a concept that at its heart is focused on the packages and containers that flow into and out of your CICD processes.

And it's there to help secure these. It's about, it's about building and automating processes that allow you to manage and control the flow of these throughout your build and deployment pipelines. Now, what, what is it not? Well, continuous packaging is, is not, it's not one specific tool or application, although it does make use of new Cloud native package management, a new security tooling that is being developed now in this space, but it's, it's the concept of treating all packages and software artifacts.

As, um, as specific units of value, continuous packaging helps to fill the gaps between continuous integration and continuous deployment or delivery. So I suppose another way to think about this is what, what does this look like?

Okay, so here we have an example, continuous integration, packaging and deployment or delivery process. So let's start with continuous integration on the left here. Now, this is where we take our source and continuously integrate it. And you'll be familiar with this. Many people are familiar with this. It's very well established.

And when I say we take our source and continuously integrate it, I mean, we, we scan it for vulnerabilities. We build it and therefore consuming dependencies from our, our universal package repository, not directly from public package sources. And we'll, we'll expand on that later. And then we package this build and we push it back to our centralized package store, our universal package repository service.

And you can see that the package repository service, it really is, of course, at the core of this process. So then in the center that this allows us to build a continuous packaging process where we can perform actions like isolating dependencies from from untrusted third party sources, like those upstream public package repositories we mentioned, and we can, we can also verify and.

Scan all packages, accepting or rejecting packages as needed. What we're doing here is effectively what we're building out our, our S bomb, our software bill of materials, which if we go back to just earlier is now really a, a verified list of our units of value. Now, this is the place that some of our new tooling comes into play a package management services with advanced features that enable and allow us to automate these workflows, then from from here, you know, on the right hand side, we can go on to continuously deploy these artifacts to our end users, customers, or production systems.

Using our existing continuous delivery and deployment tools and processes and a global package delivery network, which is another component of continuous packaging, and we will look at that in more detail in a moment as well. This is why we at Cloudsmith say continuous packaging, it sits in between, but it also overlaps continuous integration and continuous deployment or continuous delivery.

It sits in the middle of, but integrates with and enhances both sides of this process. So, I suppose to put it basically then, continuous packaging gives your team security, control, visibility, and management over built artifacts and incoming artifacts. Now some of the, the core benefits that you get from implementing continuous packaging processes are provenance, isolation, and acceleration.

Now we'll discuss these. So let's think about them in a bit more detail and let's take each one in turn. We'll start with, with provenance. So, so provenance, what is Well, provenance is about building a verifiable chain of trust for all packages and artifacts that you consume, but also for those that you deploy with things like a single source of truth and package signatures and package checksums, and even an audit trail of package events.

That gives you the the life cycle of a package. Now, some things like package signatures have been available now in one form or another for for a long time, but it's only more recently and very much. Pushed on by the, the explosion of software supply chain attacks in recent years. But it's only recently that the tooling has improved to the point that things like package signatures are becoming the default.

So with tools like things from the SIGstore project, Cosign, for example, for, for container signatures, well, they've been explicitly designed to take the pain. Out of managing and verifying package and container provenance and to make it all more, more amenable to, to automation so that you can build provenance right into your continuous packaging processes.

That's a huge part of continuous packaging. And it's also things like vulnerability scanning so continuously scanning your artifacts and images, so that, say, in the event of another CV like log for shell being identified. You know, you can react very quickly and, and both block future use of affected artifacts, but also audit the previous use and deployment of affected artifacts.

So it works both ways. So speaking of, of blocking the use of specific artifacts. That brings me to the next benefit to my next point, which is isolation. So again, what do we mean by isolation? Well, we are specifically thinking here about packages consumed from public repositories repositories that are Outside of your control, typically open source packages and nearly all software development now uses open source packages in some form, somewhere down the dependency tree isolation, it's, it's the ability to to cache packages from public upstream repositories yourself.

So basically inserting a layer. between you and your processes and the public repositories. Now, this is valuable for several reasons. This really does have value. The first reason is, is package availability. Because, you know, securing the availability of your packages is a very important part of a secure software supply chain.

Now, when people think of software supply chain security, It's very typical, and they do typically think of CVs and malware and other traditional security and nasties. But the availability of the software components you rely on is also vital. If you can't access the items that are part of your software bill of materials, your SBOM, if you can't access those items that you need to build your software, your supply chain is broken and you can't build.

Thank you. or deploy. So isolation protects you from issues with upstream availability. So it's important to use tools that can cache packages from upstream sources and in doing so you effectively remove your reliance on the availability of that source. And this has knock on effects on your ability to control the consumption of artifacts that may have vulnerabilities.

It allows you to pull packages from public sources into, into a sort of quarantine where you can then run your scans and checks and all of your security processes against these packages. And once those checks and security processes pass, you can then promote those packages to another repository that only then contains approved, cleared packages.

At Cloudsmith, we call this a package promotion workflow. And again, the tooling needs to and should support this. and enable you to automate it as well. Automation is key. Now this does even extend to simpler cases like take for example, if, if If the licensing terms just change for a package again, that isolation, it protects you from this until you can respond appropriately.

And with those cash packages, you'll still have previous older versions of a package. It won't last forever, but maybe buy you some time to put a process in place where you can address that. So I suppose in short, isolation, it really enables you to be a curator of packages, not just a consumer of packages.

So what then does that leave us with? After you can control and prove package provenance, after you have isolated yourself from public package repositories, You then need to effectively deliver these artifacts and packages to your users, processes, and systems. And that brings us to our next point.

Acceleration.

So acceleration, what is acceleration? That's being able to accommodate all users and build systems in an equally performant way, regardless of geographic location. So cloud native tooling here is all about. It's all about leveling that playing field for all participants, enabling the processes to work effectively for all involved.

That means systems and processes that support all the different package and artifact types natively. integrating with native client package management tooling in a performant and efficient way. Now, not all package, not all package formats or package management tools are equal in this regard. Some package protocols are, are very noticeably chattier and less efficient than others.

So you need things like the ability to accelerate. index creation in repositories. I, I need, you know, ideally done dynamically to deliver packages to the edge at speed. Then what is the edge? Well, the edge is what we at Cloudsmith have termed a package delivery network. It's effectively a smart CDN. It's built specifically for the distribution of software packages, artifacts, and container images.

It's context aware. It knows that handling specific package protocols, uh, it knows that it is handling those package protocols and it deploys as much logic to the edge nodes themselves. as possible. And maybe the best example here is authentication and authorization. So by performing authentication and authorization at the edge nodes themselves, pushing that application logic out there, this accelerates the delivery of packages from the edge cache, meaning that globally distributed development teams.

And users or customers or deployment processes all get efficient, low latency performance. And it's a vital component of a continuous packaging process at scale. So if this has sounded interesting, you're interested in continuous packaging and some of the benefits. How do you actually get started? What steps do you need to take?

Well, the good. No, I'll rephrase that. The great news here. Is that you have likely already started without even realizing it. You're not starting from a blank page. And that's because package management itself is the foundation. And if you have any kind of CI or CD processes in place, then you are, of course, already consuming and producing packages all the time.

Continuous packaging itself. It's an extension or evolution of package management. It brings package management forward into the era of increased focus on supply chain security. So how you progress from where you are now is by employing new tooling to build upon the foundations you already have in place.

Modern cloud native package management tooling that should enable you. To build these continuous packaging workflows and processes.

So in summary, and as I mentioned earlier in the talk, continuous packaging gives your team security, control, visibility, and management over incoming assets and built assets. And I think the key takeaways here today are that continuous packaging enables provenance. It provides that chain of trust.

Isolation. That gives you control and visibility and acceleration with a package delivery network that cloud native acceleration to accommodate distributed teams, users, and processes. Now, this is only going to become more, not less important. Software supply chain security is more important now than it ever was before.

And it was always important even to begin with. And with that, I'll finish. Thanks so much for taking the time to watch and listen. If you'd like to learn more about Continuous Packaging, do please feel free to reach out to me or come and chat to the team at Cloudsmith. We're always happy to discuss software supply chain security, continuous packaging, and package management in general.

And we would love to hear your thoughts, input, and feedback. So thanks again, and I hope that you enjoy the rest of your day.