Securing the Supply Chain Together: Security Concepts Every Ansible Contributor Should Know
Hello, Ansible Community!
Welcome back to our ongoing series on the EU Cyber Resilience Act (CRA) and what it means for Ansible. If you are just joining us, we recommend checking out the previous posts first:
-
EU Cyber Resilience Act (CRA) and what it means for Ansible? We introduced the CRA, Red Hat’s role as an Open Source Software Steward, and the key timelines ahead.
-
Security as Default, Not an Afterthought: The CRA’s Real Message We explored the cultural shift the CRA demands: security isn’t a feature you bolt on, it’s a property your software must have from the start.
In this post, we want to get practical. We’ll walk through key security concepts that align with the CRA’s expectations and that matter to anyone building, maintaining, or using Ansible content. Whether you are a seasoned collection maintainer or someone who just submitted their first PR, these ideas are relevant to your work. Let’s dig in.
TL;DR
This is where you come in. The CRA is not something that happens to us, it’s something we can shape together. Here is how you can get involved right now :
Review and comment on the open PRs - we want your eyes on them:
Read them, leave comments, and suggest improvement by July 28th, 2026 AOE. Whether it’s a typo fix or a fundamental concern about the approach it all matters.
Supply Chain Security
When we talk about “supply chain” in the software world, we mean every step, tool, dependency, and process involved in getting code from a developer’s machine to the end user. That includes source code repositories, CI/CD pipelines, third-party libraries, build systems, and distribution channels.
Why does it matter to Ansible?
Ansible content depends on a web of upstream libraries and tools. If an attacker compromises any link in the chain, malicious code can end up in otherwise trusted software. High profile incidents like the SolarWinds and Log4j breaches showed the world that attackers don’t always come through the front door. Sometimes they slip in through a build server or a tiny dependency nobody was watching.
The CRA recognizes this. It requires that products with digital elements are designed and developed with cyber security in mind throughout the entire supply chain. For an open source community like ours, that means thinking carefully about where our code comes from, how it gets built, and how it reaches users.
SLSA (Supply-chain Levels for Software Artifacts)
SLSA (pronounced “salsa”) is a security framework that directly addresses supply chain integrity. Think of it as a food safety standard, but for code. Just as you’d want to know that a head of lettuce wasn’t contaminated at the farm or during shipping, SLSA helps ensure that a software artifact wasn’t quietly modified by an attacker during the build process.
Why does SLSA matter?
SLSA provides a graduated checklist of standards to make supply chain attacks much harder:
-
The Levels (1 through 3): Each level raises the bar. Level 1 requires basic build provenance. Level 2 adds a hosted build service. Level 3 demands hardened, tamper-resistant build platforms. Teams can adopt SLSA incrementally, improving their security posture step by step.
-
The Concept of Provenance: At its heart, SLSA uses "provenance”, a digital paper trail, to prove exactly where a piece of software came from and how it was made. Who triggered the build? What source was used? What builder ran it? Provenance answers these questions in a verifiable way.
-
Real-World Threats It Stops: SLSA is designed to prevent attacks like build-time code injection, source tampering, and compromised build platforms, the exact kinds of attacks that have made headlines in recent years.
A real-world example
To see SLSA in action, look at Kubernetes. As one of the largest open-source projects in the world, Kubernetes started to adopt SLSA 5 years ago to ensure that the artifacts users download are exactly what the developers intended: no “middle-man” tampering, no silent modifications during the build pipeline.
Zero Trust Architecture
Zero Trust Architecture (ZTA) is a security model built on one core principle: “Never trust, always verify.”
Traditional security followed the “castle and moat” approach once you were inside the network, you were trusted. In a Zero Trust world, there is no “inside”. Every user, device, and service is considered a potential threat until they prove otherwise, every single time they try to access a resource.
The three core pillars
-
Verify Explicitly: Always authenticate based on all available data points identity, location, device health, workload context.
-
Use Least Privilege Access: Limit access with “just-in-time” and “just-enough” permissions. No one gets more access than they need, and only for as long as they need it.
-
Assume Breach: Minimize the “blast radius” of any compromise by segmenting networks and encrypting all communication. Plan as if an attacker is already inside.
Why it matters for Ansible users?
If you are writing automation that manages infrastructure, you are essentially holding the keys to the kingdom. Zero Trust principles remind us to apply least-privilege to service accounts, rotate credentials, verify endpoints before pushing configurations, and segment access so that a compromised playbook can’t reach everything.
SBOM (Software Bill of Materials)
An SBOM is a formal, machine-readable inventory of every software component, library, and dependency used to build a product. Think of it as a nutrition label for software.
A real-life CRA example: 8th September, 2025 a post from Aikido security about compromised npm packages created a panic in the software industry. As we see supply-chain attacks are now accelerated even more with AI, having SBOMs ready is no longer optional for enterprises and open source projects alike. Python decided to tackle this sort of security issues (especially post the Log4shell era) with publishing SBOMs. Python Software Foundation runs a project called sboms-for-python-packages. One of the primary goals for this project is to “Enable Python users that require SBOM documents (due to regulations like CRA or SSDF) to self-serve using existing SBOM generation tools.”
For Ansible, SBOMs mean collection maintainers and users alike can have a clear picture of what’s inside the software they depend on. When something breaks or a vulnerability surfaces, an SBOM turns a panicked search into a quick lookup.
CVE (Common Vulnerabilities and Exposures)
A CVE is a unique identifier assigned to a specific, publicly known cybersecurity vulnerability (e.g., CVE-2024-3094). CVEs give the security community a shared language for discussing and tracking vulnerabilities.
A real-life CRA example: If a security researcher finds a flaw in an Ansible Collection, they report it. Once confirmed, it gets a CVE ID.
For our community, this means having clear processes for how vulnerabilities get reported, triaged, and fixed. This is exactly what we are building right now (more on that below).
VEX (Vulnerability Exploitability eXchange)
VEX is a companion to SBOMs and CVEs. It’s a status report that tells users whether a specific CVE actually affects a given product. Sometimes software uses a library with a known vulnerability, but the software’s code never actually triggers the vulnerable code path.
A real-life CRA example: A Cloud Storage App’s SBOM shows it uses a library with a known CVE. However, the app only uses that library for image resizing, and the bug is in the video playback module. The company issues a VEX statement saying: “We see the CVE, but our app is NOT affected because we don’t use the vulnerable part of that library.” This prevents unnecessary alarm and helps users focus on the vulnerabilities that truly matter. CVE-2024-44204 is a good example in this context. Red Hat Product Security determined that this vulnerability does not affect any currently supported Red Hat product and issued a public machine-readable VEX file.
VEX is powerful because it adds context to raw vulnerability data. Not every CVE is a fire drill, and VEX helps maintainers and users make informed decisions.
Steps the Ansible Community Is Taking Right Now
We are not just talking about security, we are actively building the processes, policies, and documentation to put these concepts into practice. Here are three pull requests currently open on the ansible-documentation repository. They are all in draft status, and your input is welcome:
1. Security Policy (PR #3721)
This PR introduces a formal Ansible Security Policy. It covers how the project handles vulnerability reporting, response timelines, severity classification, and coordinated disclosure. It also provides guidance on hosting and maintaining a SECURITY.md file in project repositories. This is foundational, it’s the document that tells people, “Here is how security works in Ansible.”
2. Vulnerability Management Policy (PR #3734)
A companion to the security policy, this PR adds an initial draft of a vulnerability management policy. It describes how vulnerabilities are received, assessed, and addressed. It is proposed that we will handle responses on a case-by-case basis depending on impact and complexity.
3. Security Best Practices (PR #3735)
This PR adds a new document covering recommended security best practices for Ansible projects, access control, credential management, network hardening, monitoring, and secure software supply chain practices. It also links to excellent resources from the OpenSSF (Open Source Security Foundation), including their CRA Readiness Guide and Best Practices Badge program.
Follow-up discussions on released new practices
Beyond these PRs, the Ansible Community team is actively working on several fronts:
-
Updating and discussion on the community security policy to align with CRA expectations and industry best practices.
-
Working with Security Practices to tighten vulnerability management processes, expect positive changes on how vulnerabilities are reported, triaged, and resolved.
-
Future posts in this series will cover vulnerability disclosure workflows and detailed CRA timeline impacts.
This is an evolving effort, and we want to build it with the community, not just for the community.
Call to Action
This is where you come in. The CRA is not something that happens to us, it’s something we can shape together. Here is how you can get involved right now:
Review and comment on the open PRs
These documents are drafts for a reason. We want your eyes on them:
Read them, leave comments, and suggest improvement by July 28th, 2026 AOE. Whether it’s a typo fix or a fundamental concern about the approach it all matters.
Questions we’d love your input on
-
Does the security policy cover the right ground?
-
Are there scenarios or workflows missing that you’ve encountered in your own projects?
-
How should we handle vulnerability response timelines?
-
The current draft takes a case-by-case approach. Does that work for your use case, or do you need more predictable timelines?
-
What security best practices are most relevant to your work?
-
Are there areas where you’d like more guidance, credential management, CI/CD hardening, dependency pinning, or something else?
-
Are there areas where you see gaps in Ansible’s security posture today?
We’d rather hear about them now than discover them later. Do you want to help? Whether it’s contributing to documentation, reviewing policies, improving tooling, or just asking hard questions, there is a place for you in this work.
Stay connected
We will continue posting updates in this series under the infra-and-security and cra tags on the forum. Keep your eyes open for upcoming posts, and don’t hesitate to start a discussion if something is on your mind.
Security in open source is a community effort. The CRA gives us a framework, but the real work happens here, in conversations, in pull requests, and in the choices we make every day when we write and review code.
We look forward to hearing from you!