CRA Deadline: September 11, 2026

What the EU Cyber Resilience Act Means for Your GitHub Repo

By Sydney Parker — Starcaller Intelligence Platform

Published July 18, 2026 · 6 min read

If you maintain an open-source library that could end up in a product sold in the EU — even indirectly — the Cyber Resilience Act (CRA) changes your obligations. The law takes full effect on September 11, 2026, and it applies to anyone who ships software "with digital elements" into the European market. That includes you.

Here's the part most maintainers miss: you don't have to sell anything in the EU yourself. If your library gets pulled into a product that someone else sells in the EU, the manufacturer is responsible — but they're going to demand things from you that you may not be prepared to provide.

The CRA in One Paragraph

The Cyber Resilience Act (Regulation 2024/2847) requires manufacturers of products with digital elements to:

Produce a Software Bill of Materials (SBOM) for every product release
Monitor for actively exploited vulnerabilities (CISA KEV catalog minimum)
Report actively exploited vulnerabilities to ENISA within 24 hours
Issue Vulnerability Exploitability eXchange (VEX) documents stating affected/not-affected status
Provide security updates for the product's expected lifetime (minimum 5 years)

If you're an open-source maintainer, you're not directly regulated — unless you monetise your software. But here's the cascade: manufacturers need your SBOM to build theirs. They need your vulnerability disclosures to meet their 24-hour ENISA reporting window. They need your VEX statements. If you can't provide these, you become a supply chain risk — and manufacturers will route around you.

What Changes for Your Repo

1. You Need an SBOM Pipeline

An SBOM is a machine-readable inventory of every component in your software — libraries, transitive dependencies, version numbers, hashes. CycloneDX 1.5 and SPDX 2.3 are the accepted formats. If you publish a Python package, you should generate an SBOM with each release and make it available alongside your distribution.

# Generate a CycloneDX 1.5 SBOM from your Python project
pip install cra-compliance-kit
python -m cra_compliance.sbom --format cyclonedx1.5 --output sbom.json

2. You Need to Watch the CISA KEV Catalog

The CISA Known Exploited Vulnerabilities catalog is the baseline. If any component in your software matches a KEV entry, and that software ships in an EU product, the manufacturer has 24 hours to notify ENISA. They'll look to you to tell them. The free tier of the CRA Watch API does this automatically:

# Daily CISA KEV matching against your SBOM — free
curl -X POST https://cra-watch.starcaller-teq.workers.dev/check \
  -H "Content-Type: application/json" \
  -d @sbom.json

3. Vulnerability Disclosure Needs a Process

A SECURITY.md file in your repo isn't enough anymore. You need a documented vulnerability disclosure policy with clear timelines. The CRA expects manufacturers to issue fixes for actively exploited vulnerabilities "without undue delay" — and if you're a dependency, their clock starts when you're notified.

Add to your repo:

SECURITY.md with a clear reporting email and expected response times
VEX documents with each release declaring affected/not-affected status for known CVEs
A published SBOM with each release tag

4. Commercial vs. Non-Commercial Matters

The CRA distinguishes between software placed on the market "in the course of a commercial activity" and genuine open-source stewardship. If your repo is MIT-licensed and you don't sell support, consulting, or SaaS around it, you're likely in the exempt category. But the line is blurry — and manufacturers downstream of you will still pressure you for SBOMs and vulnerability data regardless of your status.

The GitHub-Specific Impact

GitHub has been preparing for the CRA, but their compliance doesn't equal your compliance. GitHub's dependency graph and Dependabot alerts help you find vulnerable dependencies, but they don't:

Generate compliant CycloneDX 1.5 SBOMs for your project
Monitor the CISA KEV catalog specifically (they use the broader NVD)
Produce VEX documents for your releases
Draft ENISA notification templates for the 24-hour reporting window

These are gaps you need to fill — with tooling, process, or both.

What to Do This Week

Generate your first SBOM. Run the command above on your most popular repo. It takes 2 minutes.
Run a KEV check. Hit the free API with your SBOM. Know what's in your dependency tree that's actively being exploited.
Add SECURITY.md. If you don't have one, create it today. Include a reporting email, expected response time (we recommend 48 hours for critical), and a link to your SBOM.
Join the community. Other maintainers are navigating the same questions. The Starcaller Security Commons Discord has a #cra-interpretation channel where we're working through this together.

Get CRA-Ready Before the Deadline

The CRA Compliance Kit is open-source (MIT). SBOM generation, CISA KEV matching, VEX generation — free tier available.

Get the Kit Join Discord