Analysis and Compliance Strategy for New Cyber Resilience Act

[camilamacedo86]

Issue Description:

We need to conduct a thorough analysis of the new Cyber Resilience Act to understand its implications for the Kubebuilder project, particularly in terms of our release process, tooling, and dependencies.
We probably need to start to generate the SBOOMs.

Areas of Focus:

• We utilize goreleaser for automating releases, triggered by pushing a new tag.
• Goreleaser Configuration.

[camilamacedo86]

@varshaprasad96 @Kavinjsir @everettraven @rashmigottipati

[varshaprasad96]

Hi @camilamacedo86, thanks for brining this to attention. I took a dig at the Cyber Resilience Act and some of the implications it may have. A few thoughts on this:

1. Looks like the CRA is in the draft stage, and the current specifications are based on the initial draft published in September. The Act, if passed by EU would take effect in 2024 (end) - 2025: https://www.fmapprovals.com/product-alerts-and-news-events/Insights/eu-cyber-resilience-act
2. Kubebuilder - should be coming under non-critical project based on the criteria they have mentioned - but it would be nice if we can wait for the steps k8s takes as a whole. I hope there would be some guidance from their end.
3. Based on the article - looks like we fall in the second category (as specified under "Are you covered by the CRA?" section) - where we follow a de-centralized community driven model, where not just one company develops the software. Some of the requirements may probably change for us, given we can't explicitly evaluate how/where our consumers use the product. We may probably have to wait out to see how things turn out before taking an action.

[everettraven]

I also took a look at the shared article and I 100% agree with the breakdown @varshaprasad96 shared. My inclination is that we would be classified as a non-critical project based (since we are a dev tool for streamlining the building of software) on the information provided. I agree with waiting for more guidance from the Kubernetes orgs or CNCF as a whole before making any commitments.

[camilamacedo86]

Here are the actions we have taken to enhance security and ensure compliance:

• Updated the Security Policy.
• Enabled all automatic security checks available on GitHub.
• Began generating SBOMs (Software Bill of Materials):
  • See the assets.
  • See how we are doing it.

We tried to get guidance either:

• We raised for someone validate it: https://kubernetes.slack.com/archives/CCK68P2Q2/p1731659830630629
• We open a ticket for Cloud Native Computing Foundation
• Also: https://kubernetes.slack.com/archives/C1TU9EB9S/p1731660103481519
• Also: https://kubernetes.slack.com/archives/C019LFTGNQ3/p1731660326717879

It seems that:

KubeBuilder is a framework for building Kubernetes APIs using custom resource definitions (CRDs). As a development tool, it doesn't directly fall under the CRA's product categories. However, software products developed using KubeBuilder, especially if intended for the EU market, must comply with the CRA’s provisions. The criticality of these products depends on their functionality and potential impact on cybersecurity.

Anyway, it seems that the best approach is to ensure that all is done properly
So, due the all actions done above we might able to close this one for now,
If we have any answer from the requests in the channels done above and someone let us know that something is missing or is wrong we can re-open this one or a new issue to address the specifics.

[camilamacedo86]

It seems that this channel in CNFC can help us to validate:
https://cloud-native.slack.com/archives/CDJ7MLT8S/p1731722131580859

So, if any required for change came back from what was done we can create specific issues for each