In this webinar, we demonstrate how to integrate automated governance with a GitHub-hosted AutoGov toolset. This approach streamlines governance, automating compliance checks and security policies so developers can focus on coding without manual overhead or disruptions.
Automated governance has traditionally required enterprises to set up and manage a complex ecosystem of tools. Now, organizations using GitHub can streamline governance without standing up an extensive infrastructure. In a recent demo, we showcased how GitHub’s native attestation features eliminate the need for self-hosted solutions, lowering the barrier to entry for teams looking to secure their software delivery pipelines.
Historically, automated governance required hosting multiple services like Sigstore, Fulcio, and Recore to generate and verify attestations. While effective, these setups required significant operational overhead.
With GitHub’s built-in attestation capabilities, teams can now create and verify attestations using GitHub attest commands, eliminating the need for external tooling. This means security and compliance checks can be integrated directly into CI/CD pipelines without the complexity of managing a self-hosted governance framework. Instead of maintaining custom infrastructure, organizations can rely on GitHub’s native attestation framework to generate cryptographic proofs for key pipeline events such as builds, security scans, and releases.
A key challenge with automated governance is making attestation results easily accessible. Without a centralized view, teams must manually search through repository pipelines to find compliance details. To solve this, we developed a Backstage plugin that integrates with GitHub’s attestation framework, providing a clear and structured way to view governance results.
With the AutoGov plugin, teams can see compliance data directly in Backstage’s Code Insights section, making it easier to validate security policies at a glance. If an attestation fails, the system provides immediate feedback, highlighting whether an SBOM is missing, a build type is incorrect, or a required scan wasn’t performed. Instead of navigating through repositories, developers and security teams can quickly access attestation data in one place, reducing friction and improving compliance oversight.
The goal of this initiative is to make automated governance as simple as possible. If an organization already uses GitHub and Backstage, adding governance controls requires minimal effort. By using GitHub’s attestation feature, teams can implement policy-driven security without needing to deploy additional tooling.
This approach enables organizations to enforce security and compliance efficiently while keeping governance lightweight and developer-friendly. Instead of complex infrastructure setups, teams can focus on building, securing, and delivering software with confidence.
By leveraging GitHub’s native attestations and integrating results into Backstage, organizations can enforce compliance and security policies without slowing down development. Governance should enhance software delivery—not create bottlenecks.
If your team is looking for a seamless way to implement automated governance, contact us today to explore how GitHub’s attestation features can simplify compliance and security in your CI/CD pipelines.
Out of the automated governance workstream, I guess you could say we're kind of working on a different offering than what was previously offered. Before, there was a self-hosted version of automated governance where you had to stand up instances of a variety of tools to make AutoGov work, create attestations, get them signed, etc. We are proving out—or have proved out—basically what GitHub will give you for free if you use GitHub to make attestations. This is a lower-barrier version of what we previously proved out in a self-hosted scenario. In this one, you basically just have to use GitHub attest commands, and you'll get attestations for a variety of events or RFX, whatever you want to call them. I'm not going to go into the full details of how this works, but I’m getting the demos of these documented, and I’m keeping them separated. We do have a demo for the actual GitHub attestation feature out of GitHub. It’s got three components, all of them documented in the system and Backstage. So you'll get to see the workflow you’ll need to design and host as a company or a client, and then how you’ll get to write up the policies to actually have governance over those attestations. And then I think we have an example caller workflow. That would be like a sample app dev repo. This is kind of designed to be a "here’s what you can do for free out of GitHub" demo. That way, you don’t have to stand up a giant team to host all of these services like Sigstore, Fulcio, Recore, etc. We also have a Backstage plugin so people can view the results from AutoGov somewhere. Because right now, you can go to a pipeline and view the results, but you’re still having to get into the weeds of the repositories, hoping you have access, hoping you know exactly where to look. What the demo—or the showcase—is hoping to show is just a real quick, "here’s how you can get a hold of something demoable to a client," or even if you wanted to spin it up yourself, we can offer that. You can get a plain Backstage instance running, and it doesn’t have the actual AutoGov info, which is what I’m showing right now. This is a very plain Backstage instance—it’s just hooked up to GitHub. So if you already have a Backstage instance and you use GitHub, this is something you could add for free. And if you go to Code Insights for each release, you don’t get much more information except for knowing this is a release, and if you click on it, it’ll take you to GitHub to the specific release. When we add the AutoGov plugin, it’ll go and grab the AutoGov results and actually show them in the releases. I’m just showing this as an example—it should be this easy if you want to go demo it to a client. Sorry, this is my local instance running of this Backstage instance. If you go to our actual Liatrio Backstage right now, it’s already implemented. I wanted to show a before-and-after, which is why I’m not showing it out of ours. It should be as easy as adding the plugins needed. I’m just going to copy and paste some of these README commands. Let’s see—whoops, I’m missing a hat sign. Oh no, DevOps gods hate me this morning. That’s okay, we’ll use the backup. In our actual Backstage, this is working. If I go to our example caller workflow, when I go to Code Insights, I’ll actually get the results from AutoGov. There’s an actual file from the policy evaluation. It’ll tell you if it passed or failed. If it does fail, we’ll get to see the different policies that individually failed. Our past runs of our demo workflow have all passed because it’s our model project, but I’m going to go to one where I know we have some sample failed results. That way, you can see—oh, this one’s missing an SBOM. I can easily see that this version of this code failed the AutoGov check because it’s missing an SBOM and didn’t have the correct build type. We can build out a variety of failure reasons just to show a client some examples of how you can use policy to identify what’s going wrong in these particular repos and why they’re not passing. It should be as easy as that. Obviously, I’ve got some work to do to make sure the demo passes a little more easily. The goal of the current workstream effort is to lower the barrier to getting AutoGov added. So if you already use GitHub and if you already use Backstage, it’s as easy as just having a workflow that uses the GitHub attest actions to create them and then having policies run in a pipeline. If you’re using Backstage and it’s already hooked up to GitHub, you can show those results for free. Instead of having to build up this giant architecture of tools, if they’re already using GitHub, they could alternately just use the out-of-the-box GitHub solution to create attestations and AutoGov solutions. That’s kind of it. Any questions?