Red Hat turns CRA readiness into an open source project checklist

The EU Cyber Resilience Act is beginning to change what commercial software teams need from their open source dependencies. A new Red Hat post argues that the useful response is not a new compliance badge, but better project hygiene: know the components in a product, document how vulnerabilities are handled, and keep fixes flowing upstream.

That matters now because Red Hat says the CRA’s first vulnerability and incident-reporting obligations took effect on September 11, 2026, while the broader regulation applies from December 11, 2027. The post is aimed at companies selling software or hardware into the EU, but its most useful artifact for platform and supply-chain teams is a concrete maintainer checklist linked from OpenSSF.

What teams can implement

The OpenSSF CRA Readiness Guide translates “secure by design” into repository-level controls. Its voluntary baseline asks projects to publish a cybersecurity and vulnerability-management policy, distinguish ordinary bug reporting from private security reporting, document contribution and release processes, enforce multi-factor authentication, protect branches, provide an explicit license, and target Open Source Project Security Baseline Level 1.

None of those controls is novel. Together, however, they produce the evidence that downstream product teams need for component due diligence: whether a project is maintained, how long releases are supported, how security updates are communicated, and where a vulnerability report will go. For a platform team operating an internal developer portal or approved-component catalog, those fields are also a practical schema for admission and lifecycle reviews.

Keep responsibility in the right place

The guide draws an important boundary. Volunteer developers and non-commercial maintainers do not become responsible for a manufacturer’s CRA compliance simply because their code is embedded in a commercial product. It describes “CRA readiness” as a voluntary transparency practice, not a certification, and warns maintainers not to sign declarations that transfer downstream compliance or product-security obligations upstream.

Red Hat’s own stewardship guidelines show what a larger supporting organization can add. Red Hat identifies itself as an Open Source Software Steward for 15 projects, including Ansible, Fedora, CentOS Stream, Konflux, Quay, StackRox and OKD. The guidelines separate that process-and-cooperation role from Red Hat’s manufacturer obligations for commercial products such as RHEL, OpenShift and Ansible Automation Platform.

What to do next

Commercial product teams should inventory the open source components they ship, map each one to a vulnerability-reporting path and support expectation, and make upstream contribution of fixes part of the incident workflow. Maintainers can publish the OpenSSF checklist artifacts without claiming legal compliance. Platform teams can then surface those artifacts beside component versions and ownership data, turning a regulatory deadline into a repeatable supply-chain control rather than a last-minute questionnaire exercise.