-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add fields required by Cyber Resiliency Act Annex II #137
Comments
Oh, and I do get it that these are optional and use the x_ prefix. What I'm looking for are some documentation or examples (or whatever) that we can point to when people start asking questions on how to represent these new fields they are required to keep track of, if their business is in the EU/EEA |
These fields might be a good excuse to establish a spec v3.1 or perhaps 4.0. |
I wonder if OSI or FSF have a stand or a recommendation on how FOSS communities are supposed to respond to that. |
OSI are busy interacting with legislators to reduce any damage, and Simon Phipps is their guy. Check out this video to get an idea of what's going on (123 minutes) FSFE is also aware, apparently, but they are focusing on the policy side too, I think. I have no idea if this is even on FSF's radar. If we want some practical and relevant recommendations (e.g. on naming fields), then we might want to have a look at what other ecosystems have done; The OWASP CycloneDX community (slack invite) has some tooling that consumes the data provided by these ecosystems. I think it's probably better to check out what's happening there, than trying to lean on OSI and FSFE. |
I suspect the most sensible route is to add all this information to the META file, and then have MetaCPAN convert that into a standard SBOM format. That way MetaCPAN can link to itself. Also because you can't include a hash of the package (or sign it) if the SBOM file is inside the package. |
Yeah, I'm also not sure what the best approach is here. In a sense, I'm wondering if this should be generated by the PAUSE indexer, and be available for download too, though at that point we may be trying to solve package signatures too… |
I've opened a related issue in the CycloneDX specification repo: CycloneDX/specification#400 |
Good news! This issue has just been accepted to become a feature in next year's 1.7 release of the CycloneDX specification! 😁 |
For anyone following this topic – the CRA goes into effect on December 11th 2024, and from then we'll have a short time to get something implemented. My hope is that we can land this topic before PTS 2025. |
There are a couple EU laws coming, that require users to gather information of all their software dependencies in order to conduct cyber security assessments, and use this as part of managing their software security landscape. There's quite a bit more to this than this short summary can convey, so if you're interested in getting an idea the scope and relevance of these laws, I recommend checking out Bert Huber's articles on the CRA, as they give a good (and free of lawyerese language) overview of the issues.
Bert Huber's overview
Annexes PDF can be retrieved from the download section in this page
A quick look at Annex II reveals a few new metadata fields will be required by EU businesses using Open Source software:
product/module can be reported and received; Maybe an RSS feed and accompanying webpage on metacpan?
If I understand Annex II correctly, it seems fields 2, 6, 7, and 8 are relevant to establish in the spec.
What do you guys think?
The text was updated successfully, but these errors were encountered: