Add fields required by Cyber Resiliency Act Annex II

[sjn]

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:

1. Email address (or other contact info for the "manufacturer" - i.e. the module/component author. Already supported)
2. The point of contact where information about cybersecurity vulnerabilities for the product/module can be reported and received; Maybe an RSS feed and accompanying webpage on metacpan?
3. Module name and version number (– already supported)
4. Intended use (– unsure about this; probably only relevant for vendors)
5. Possible misuses. (Not sure if this has any meaning being placed in metadata; An RFC-style "Security considerations" section in the documentation may be more sensible)
6. Link to an SBOM describing the package (this is also requires an SBOM object being supplied with the package, and findable after installation in/around whatever environment the software runs under)
7. EU declaration of conformity statement (CE mark for the software – this field is useful for any author that wishes to show they conform to EU laws)
8. Security updates information (this may just be a link where one might find security patches?)
9. (a) to (d) around security lifecycle management seems to be mostly relevant for application vendors. (Unsure about module/component authors)

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?

[sjn]

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

[karenetheridge]

These fields might be a good excuse to establish a spec v3.1 or perhaps 4.0.

[garu]

I wonder if OSI or FSF have a stand or a recommendation on how FOSS communities are supposed to respond to that.

[sjn]

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.

[Leont]

Link to an SBOM describing the package (this is also requires an SBOM object being supplied with the package, and findable after installation in/around whatever environment the software runs under)

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.

[sjn]

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…

[sjn]

I've opened a related issue in the CycloneDX specification repo: https://github.com/CycloneDX/specification/issues/400

[sjn]

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! :grin: