Security talks at KubeCon + CloudNativeCon Europe 2026 in Amsterdam kept coming back to one law: the EU Cyber Resilience Act (CRA). Greg Kroah-Hartman, Linux kernel maintainer and Linux Foundation Fellow, spoke about it on stage, and he and OpenSSF CTO Christopher “CRob” Robinson also talked about a second pressure on maintainers: a flood of AI-found bug reports.
That was in March. On September 11, 2026, the first CRA obligation came into force. If you ship software into the EU, this is no longer a future problem.
The dates that matter
- September 11, 2026: Manufacturers must report actively exploited vulnerabilities and severe security incidents in their products.
- December 11, 2027: Full enforcement. Products with digital elements need to meet the CRA’s security requirements, including documented vulnerability handling and a software bill of materials (SBOM), plus a conformity assessment.
Who it applies to
This is the part of the CRA that people get wrong most often.
- Individual open source contributors are not the target. If you write code and publish it for free, the CRA does not treat you as a manufacturer.
- Companies that ship products are. If your company sells software, a SaaS-backed device, or a commercial distribution that includes open source, you carry the obligations for what you ship, including the open source inside it.
- Foundations and “open source stewards” have a lighter set of duties, mainly around having a security policy and working with authorities on vulnerabilities.
Kroah-Hartman compared the CRA to food labeling. It does not tell you how to cook. It tells you to say what is inside and to tell people when something is wrong. Seen that way, it is a transparency rule more than a burden.
The second problem: AI-found bugs
In an interview at the event, Robinson and Kroah-Hartman both said maintainers are seeing a big rise in vulnerability reports found with AI tools. Robinson said these tools do in minutes or hours what used to take much longer, and the traffic upstream has gone up sharply. Kroah-Hartman said many of these reports are real issues, not noise.
Put the two together and you get the picture for 2026: more real vulnerabilities found faster, and a legal duty for product makers to track and report them. Teams that cannot answer “which of our images contain this package?” in a few minutes will struggle.
A practical setup for Kubernetes teams
You do not need a big platform to start. Three steps cover most of what the CRA asks you to be able to show: know what is inside, find what is vulnerable, and prove where it came from.
1. Generate an SBOM for every image
Syft creates an SBOM from a container image:
syft nginx:1.27 -o spdx-json > sbom.spdx.json
If you build with Docker BuildKit, you can attach an SBOM and provenance at build time instead:
docker buildx build --sbom=true --provenance=mode=max \
-t registry.example.com/app:1.4.0 --push .
2. Scan the SBOM, not just the image
Scanning the SBOM means you can re-check old releases when a new CVE drops, without pulling every image again. Grype reads SBOMs directly:
grype sbom:./sbom.spdx.json --fail-on high
Run this in CI on every build, and run it again on a schedule against the SBOMs of everything in production. A new CVE against an old image is exactly the case the CRA reporting rules care about.
3. Sign images and attach the SBOM
Cosign from Sigstore can sign the image and attach the SBOM as an attestation:
cosign sign --yes registry.example.com/app:1.4.0
cosign attest --yes --type spdxjson \
--predicate sbom.spdx.json \
registry.example.com/app:1.4.0
Then make the cluster check it. A Kyverno verifyImages policy or the Sigstore policy controller can block unsigned images at admission time. Kyverno moved to CNCF graduated status during KubeCon EU 2026, so it is a safe long-term pick.
A short checklist
- Every image you ship has an SBOM stored next to it.
- CI fails on high or critical vulnerabilities, with a documented exception process.
- Production SBOMs are re-scanned daily.
- Images are signed, and the cluster rejects unsigned ones.
- You have a public security contact (a
SECURITY.mdand a security email) and a written process for reporting exploited vulnerabilities on time. - You start from minimal or hardened base images, so there is less to track in the first place.
Takeaways
- CRA vulnerability reporting has been live since September 11, 2026. Full enforcement follows on December 11, 2027.
- Hobby open source contributors are not the target. Companies shipping products are.
- AI tools are finding more real bugs, faster. Your inventory has to keep up.
- SBOM, scan, sign and verify is a setup any Kubernetes team can build in a week with CNCF and OpenSSF tools.
This post is a technical summary, not legal advice. Check with your legal team on how the CRA applies to your products.
Sources: KubeCon EU 2026 Day 2 recap, Virtualization Review, Open-source security leaders brace for AI bug surge, SiliconANGLE, KubeCon EU 2026 recap, Kubermatic