The Challenge
The European Union's draft of the Cyber Resilience Act (CRA) initially treated open source software like commercial products, imposing liability on community maintainers—volunteers often without legal support. This posed a risk for projects like OpenSSL or Log4j, exposing them to legal issues for vulnerabilities discovered long after release.
The compliance demands were significant. The CRA required conformity assessments, CE marking, and ongoing vulnerability management—processes suited for enterprises with dedicated security teams. For a maintainer working independently, this threatened the open source ecosystem.
Strategic Constraints
Red Hat faced a strategic challenge. As an enterprise relying on open source foundations, they couldn't ignore the CRA. Their EU customers would demand CRA-compliant software. However, if the regulation harmed community projects, Red Hat's supply chain would be at risk.
Two constraints were evident:
Regulatory timelines are slow. The CRA couldn't be quickly amended like software code. It required ongoing engagement with the European Commission and other stakeholders.
Red Hat needed to advocate for the broader open source community, not just its interests. Solutions had to benefit both small maintainers and large foundations.
Red Hat's Approach
Red Hat took a leadership role in the regulatory process. Instead of relying on industry associations, they engaged directly with the European Commission to advocate for open source development models.
Their argument was clear: open source security differs from commercial software security. Volunteers can't provide the same documentation as vendors, but compliance requirements can align with existing open source security frameworks.
Red Hat collaborated with the OpenSSF to position two frameworks as standards for CRA compliance:
OpenSSF Scorecard and OpenSSF Package Analysis System (OSPS): These frameworks became recognized for demonstrating security practices. Projects could use Scorecard metrics—automated checks for branch protection, dependency pinning, and signed releases—instead of formal assessments.
Supply Chain Levels for Software Artifacts (SLSA): This maturity model aligns with CRA requirements without imposing enterprise-style processes. A project at SLSA Build Level 2 shows provenance and build integrity, meeting CRA compliance needs without a dedicated compliance team.
Red Hat's key move was making these frameworks recognizable to regulators, providing concrete technical standards for EU officials to reference.
Results and Metrics
The revised CRA now acknowledges open source development models, distinguishing between commercial exploitation and community contribution. This reduces liability for maintainers not monetizing their work.
OpenSSF frameworks are now part of the compliance landscape. When an EU-based company asks about CRA compliance, the answer points to OSPS and SLSA—not costly audits.
Your team can now:
- Run OpenSSF Scorecard on dependencies for a security assessment.
- Require SLSA Build Level 2+ for critical components.
- Reference these frameworks in compliance documentation for CRA readiness.
The compliance burden has shifted from "hire lawyers for every dependency" to "implement automated tools that check framework alignment."
Lessons Learned
Timing is crucial. Red Hat's early engagement influenced the regulation before it was finalized. Waiting until a regulation is published means dealing with compliance costs instead of shaping requirements.
For your team:
Monitor draft regulations in target markets. The CRA isn't the last supply chain security regulation. Engage during the comment period for more impact than post-enforcement legal fees.
Build relationships with standard-setting bodies. Organizations like OpenSSF, CISA, NIST, and ENISA influence regulations. Contributing to these frameworks shapes compliance before it becomes mandatory.
Document security practices using recognized frameworks. Don't wait for regulations to force you. If you're already generating SLSA provenance or publishing Scorecard results, you're ahead of the compliance curve.
Takeaways for Your Team
The CRA case study shows that influencing compliance happens before regulations are finalized. Once the text is set, you're implementing whatever requirements remain.
Your practical next steps:
Inventory your open source dependencies and their security posture. Use OpenSSF Scorecard on critical components to identify strong security practices and potential compliance challenges.
Require SLSA attestations from your build pipeline. Start generating provenance now, so you're prepared when auditors ask.
Participate in framework development. OpenSSF working groups welcome contributors. If your team has supply chain security expertise, your input can shape the frameworks regulators reference.
Track regulatory drafts in your compliance roadmap. Treat proposed regulations like technical debt—address them early to reduce costs. Set alerts for comment periods on relevant regulations.
Shifting from compliance-as-burden to compliance-as-strategy requires proactive engagement before regulations land on your desk. Red Hat succeeded by engaging early, offering technical solutions, and aligning open source practices with regulatory needs.
Your team can do the same. The next regulation affecting your stack is likely in draft form right now.
