🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.
Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!
Overview
📖 AWS re:Invent 2025 - Fast and compliant CI/CD pipelines in the financial industry (IND217)
In this video, James Chatmas from Octopus Deploy demonstrates building CI/CD pipelines that are both fast and compliant for banks. He explains that 75% of enterprises experienced supply chain attacks in the past 12 months, making the "drift window" between build and deploy a critical vulnerability. The session showcases a zero trust deployment pipeline using GitHub Actions and Octopus Deploy, featuring SBOM generation, provenance tracking, and attestation verification. Through a live demo of deploying a containerized application to EKS, he illustrates how GitHub handles CI (building, scanning, generating attestations) while Octopus Deploy manages CD (verifying SBOMs, validating attestations, enforcing policies, and maintaining audit trails). The approach ensures artifact integrity and compliance governance required by regulated financial institutions.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
The Supply Chain Security Crisis: Why Banks Need Zero Trust CI/CD Pipelines
Hi everyone. Thanks for coming to my session today. I really appreciate it. I'm James Chatmas, Principal Solutions Engineer at Octopus Deploy. I'm genuinely excited to be here today. Today we're diving into a challenge that every bank on the planet is wrestling with: How do I deploy software faster without breaking compliance and without failing my audit? My session is all about building CI/CD pipelines that are both genuinely fast and 100% compliant, which is a true North Star that most banks are looking towards in this current day and age.
In my role at Octopus Deploy, I work with some of the largest banks in the world, helping them automate their CI/CD pipelines. Everything that we're going to be looking at today is based on patterns that I've seen time and time again. Here's the game plan for the next 18 minutes. We're going to start by talking about why supply chain attacks are the number one risk for banks in 2025 and why all automated software delivery pipelines are susceptible to them. Then I'll fire up a live demo and walk you through a true zero trust deployment pipeline end to end using GitHub Actions and Octopus Deploy, which is the exact pattern that a lot of banks are moving towards to deploy their production workloads.
Finally, we'll look at how Octopus Deploy enforces governance around things like verifying attestations, checking SBOMs, and validating vulnerabilities at deploy time. So let's set the stage with a statistic that's pretty eye-opening. 75% of enterprise organizations, that's 3 out of 4, have experienced some sort of supply chain attack in the past 12 months. Pretty wild, right? I mean, if I'm an attacker, it kind of makes sense. I could spend time trying to hack into a hardened production environment, but why would I do that? Why wouldn't I just slip some malicious code into the CI/CD pipeline and let my target just deploy it out to production themselves?
And what if you're a bank or a payments processing company or some other regulated financial institution? All of a sudden, that malicious code that makes it out into production could turn into eight-figure fines for your company. It could turn into your CISO or CEO on the evening news. Not a great look. That's exactly why supply chain security has quickly bubbled up to the top of the list of priorities for organizations over the past 12 months.
So let's talk about the true reality of modern pipelines. You kick off a build, your unit tests run, you code scan your repo, your artifacts get created, get pushed out to your package repository, and you're ready to deploy, and then nothing. The artifact just sits there, sometimes for hours, sometimes for days. In a lot of the companies that I've spoken with recently, those artifacts just sit there for weeks before they get deployed. And that time gap between the build and the deploy, that's called the drift window, or as I like to call it, that's the danger zone.
A lot of things can happen in there, anything from a configuration drift to a new zero day being published, or in the worst case scenario, a bad actor decides to replace the artifact with one that has malicious code in it. Point being, the longer that drift window exists, the bigger the blast radius for any sort of changes. The scary part though is that most organizations have multiple drift windows within any release cycle. You've deployed to dev, you're waiting for your QA team to promote it out to their environment before they can test it, could be a few days.
Maybe you've made it to your stage environment, but you're waiting on CAB approval to go to production. That could be weeks. I've worked with some companies that get everything approved, they're ready to deploy to production, but they only do deployments once per quarter, so you're sitting around, that artifact is just sitting there essentially going stale during that drift window.
So how do we make that drift window something that's safe and not something that's a constant risk when it exists? So we can make that safe by putting together three key pieces that work in harmony to make that drift window safer.
The first one is the Software Bill of Materials. You might have heard the term SBOM. This is the ingredient list of what went into building our artifact. So it's a complete list of the third-party libraries and components that were used to create the application. The second piece is our provenance. So this is the who, what, when, where, and how of that artifact getting created. So everything from the commits that are in it to the workflow file that was used to build it to the runner that the build was run on, everything around the creation of that artifact is the provenance.
And then finally, the third piece is our attestation. This is the cryptographic glue that holds everything together. It's a signed statement or a certificate that's saying, hey, this SBOM belongs to the package that I created, and this is the provenance that was used to create it. And ideally, all three of these are generated automatically, and they're verified at each stage of your software delivery lifecycle. When these three work together in unison, that's how you get a drift window that doesn't rely on luck to be safe. You're putting controls in place to make it a safe time.
Building a Zero Trust Pipeline: Live Demo with GitHub Actions and Octopus Deploy
So the Zero Trust pipeline only works with a clear separation of duties and a clear segregation of responsibilities. So let's talk about who does what. On the left we have GitHub, exactly where it should be with our code, and that's doing everything on the CI side of the house. So we're building our code, running our unit tests and scans, generating our SBOM and attestations, scanning for vulnerabilities, and then ultimately we're publishing our artifacts out to our package repository, those immutable artifacts.
Once the CI process is complete, that's when Octopus comes into play. Now think of Octopus Deploy as your single source of truth for everything deployment related and the final gatekeeper when it comes to deploying your applications safely. So Octopus, what are you responsible for? Verifying our SBOM, validating our attestations, enforcing any sort of policies that your organization has, maybe around approvals or vulnerability checks or configuration drift. Once those quality gates pass, then Octopus carries on with the rest of the deployment process out to EKS or ECS or serverless, EC2s, what have you. On top of that, we keep a rolling audit of everything that's happened leading up to the deployment, and Octopus makes it easy to roll back when necessary.
Perfect. Slides are done. I've got a real pipeline ready to roll here. Let's fire it off real quick and watch this whole Zero Trust flow in action. Perfect. So we're going to start in GitHub where our code lives. The project that we're going to be working with today is our account registry project. It's a containerized application that we're deploying out to EKS.
So I'll hop over to my actions tab and we have two actions workflows ready. So we're going to be focused on the Supply Chain Verified Build Pipeline GitHub Actions workflow. So I'm going to click on it. This workflow is doing a ton behind the scenes, and I'll walk you through that, but let's kick it off and get it going. So we'll run the workflow, refresh the page, and take a look at this GitHub action in action. I'm not going to walk through the YAML file, not a lot of value there, but we will look at this GitHub graph around what's happening.
First, this pipeline is built for speed. We're trying to deploy software faster while keeping it safe. After our pipeline initialization, we're running a couple of steps in parallel. We're scanning our repository at the same time that we're building our image and publishing our SBOM. That repository scan is a quality gate that takes about 20 seconds, not a huge time sink, but it's running in parallel with our Docker container build anyway. So we're not losing anything in our total time of the workflow running.
We're also building our container, scanning it, and publishing that SBOM, that list of ingredients that we'll use later in the deployment process. Once both of those quality gates pass, we're publishing our GitHub release, and then we're signing and generating our attestation. On the CI side of things, this is the critical piece of this workflow. When we're signing and generating the attestation, we're tying that SBOM and our Docker container together, and we're essentially getting signed metadata that we'll use in the deployment process to validate that the container I'm about to deploy is the exact one that I built earlier in my pipeline.
Finally, back to that separation of duties that we talked about, this is where we're handing off the deployment to Octopus Deploy to continue with the CD part of our CI/CD pipeline. So let's hop over to Octopus now and see what that looks like. This is the Octopus Deploy dashboard for those of you that haven't seen it. It's a single control plane, kind of like your air traffic control tower for everything deployment related in your organization. We have a list of our projects or our applications, our services down the left side, our environments across the top, and we can see exactly which version has been deployed out to which environment.
As you can see, our account registry project has already started deploying to development. That happened automatically at the end of our GitHub Actions workflow. I'm going to click on this deployment, and it's going to bring me to our task log. We'll take a look at the task summary screen. There's a lot going on as far as the Kubernetes deployment is concerned, but as far as this presentation is concerned, we're going to focus on the first four steps and how they relate to the zero trust pipeline.
In step one, we're grabbing our packages, we're grabbing our SBOM, grabbing our build information from GitHub and gathering that all together for the subsequent steps. In step two, we're verifying that SBOM, so we're looking through that list of ingredients and cross-checking it with what was in GitHub. We're making sure that none of those ingredients have changed and that software bill of materials is still sound.
Now step three, I talked about that critical stage in our GitHub Actions workflow. This is that critical stage in our deployment process. We are taking our SBOM, we're taking our container, we're calculating the SHA-256 hashes for each of those, and then we're comparing them to what GitHub says they should be in the attestation. If they match, we know that the container that we're about to deploy is the exact one that we built. If there is something off between them, we know that there's been some sort of tampering along the way in our pipeline.
I've mentioned attestations a few times. Quick detour back to GitHub, and if we scroll down a little bit, for those of you that haven't seen GitHub Advanced Security, we'll take a quick look at our attestation. In the top section, we have our provenance. Remember this is all the build information, our commits, our workflow file, and so on and so forth. The middle section has a number of certificate keys that are used to verify, but the key of this attestation that we're working with are the subjects down at the bottom. So you can see our Docker container and our SBOM file along with their subject digest.
So when we calculate those in Octopus, we're comparing those to these values and making sure that they match. And then finally, step four, we're checking GitHub for open vulnerabilities using the GitHub API. This doesn't make a ton of sense on this automatic deployment to development because we just built it, you know, three and a half minutes ago. But if you remember that drift window, maybe that artifact's been sitting there for three or four weeks. It's always a good idea to do a final scan of our repository to make sure nothing's been published, no zero days exist, and no vulnerabilities have made their way into what we're about to send out to our production environment.
Enforcing Deployment Governance and Verifying Artifact Integrity
From there, we're continuing with the standard Kubernetes deployment, creating our namespace, config maps, and so on and so forth. So that's what that zero trust pipeline looks like. A few other pieces that I'll key in on just when we're talking about deployments for regulated industries. You'll notice this top step says apply compliance policies. I clicked on that. In Octopus, we have the ability to define policies using Rego that span across your entire instance. This allows platform teams to standardize the governance around all deployments in their organization and create standards for any deployment that goes out.
Another piece that we'll key in on is our Kubernetes tab over here in the upper right. So we're deploying to EKS, and at deploy time, Octopus is pulling back a snapshot of all the different Kubernetes objects that are getting deployed along with their status. So first off, if any of these were unhealthy, we would see that here in our object status screen. But as a developer, maybe I don't have direct access to my cluster. This is a great way for me to figure out, hey, what is going on in my cluster without having to get into the hardened environment or without having to give out access to a wide array of people.
The last piece we'll look at is our build information. So we're pushing this build information to Octopus from GitHub, and it's kind of a sanity check, an extra link that goes back to our build where we can get at those SBOM files, our attestations, our provenance, and so on and so forth. So back to the dashboard, that's our zero trust pipeline signed by GitHub and verified and deployed with governance through Octopus Deploy.
Let me head back here. So kind of wrapping things up, what did we accomplish today? We established a chain of trust from build to deploy. GitHub generated the SBOM, the provenance, and the attestation, and Octopus verified all of those before anything was deployed. Second, we enforced deployment governance. So our deployment went through policy evaluation, it went through vulnerability checks, it went through validation of the attestation. All these controls are exactly what regulated financial organizations need when deploying out to production. And then finally, we verified our artifact integrity. We verified that the artifacts that we deployed were the exact ones that we built and that they hadn't been tampered with.
So thank you for coming out. I really appreciate you being here at five o'clock, end of the first day. Thanks for coming out and joining me. Again, we're at booth 678, kind of right there, right in front of Qualcomm. Happy to chat with you, answer any questions, and continue the conversation. Thanks so much.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)