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
• Annex II

A quick look at Annex II reveals a few new metadata fields will be required by EU businesses using Open Source software (numbers below correspond to numbers in Annex II):

1. (1) Contact info for the "Manufacturer" - i.e. the module/component author;
   • This is already supported with the author field.
2. (2) Single point of contact where information about cybersecurity vulnerabilities for the product/module can be reported and received.
   • Maybe a new security field? Re-using author is a bad idea since vulnerability reports need to be private, and an author address may be a public mailing list.
   • This may also be solved by adding a link (URL) to the project's security policy file. (e.g. to SECURITY.md for a human-readable text, or possibly security-insights.yml for a machine-readable version of the same)
3. (3) Module name and version number
   • This is already supported with name and version
4. (4) Intended purpose of the product
   • Probably only relevant for Manufacturers, though since some CPAN projects may become one, this is relevant to add.
   • May be partially covered by the description field for simple modules, but there are more requirements this may warrant a separate SECURITY CONSIDERATIONS POD section.
   • For complex purposes, we may want to add a new metadata field with an URL; e.g. security_docs
   • Complex docs can also be handled by referring to an "Project SBOM" (This is an addition to CISA's SBOM Types PDF in PDF) file that contains this information.
5. (5) Possible misuses that can lead to significant cybersecurity risks.
   • An RFC-style "SECURITY CONSIDERATIONS" section in the POD may be sensible for this also.
   • For more complex situations, a security_docs field may be good here also.
6.  (6) Link to a CE declaration of conformity.
   • This is only relevant for Manufacturers, though if a CPAN project wishes to become one, we'll need a way for this to be included.
   • This can possibly be solved by adding a link an included (release-specific) "Source SBOM" file, in the same manner the Python folks have decided (see PEP 770, and discussion) to do.
7. (7) Technical security support offered by the Manufacturer and the end-date of the support period
   • This is relevant for Manufacturers (potential or real), so we may want to consider supporting this.
   • If the project isn't a Manufacturer, but intends for it's software (or a specific releases of it) to be used in a commercial environment, and has an Open Source Steward organization supporting it, then this may be relevant too.
   • Can probably be solved with a SUPPORT POD section, or a separate documentation link, either as a separate support field in the metadata, or via a link to a Project SBOM.
8. (8) Link to details instructions on the handling different product lifecycle events (most likely relevant only for Manufacturers that are integrators)
   • (a) correct deployment ("commissioning");
   • (b) how changes may influence the security of related user data
   • (c) how to install security updates
   • (d) how to decommission the product, including secure removal of related user data
   • (e) how to disable automatic security updates
   • (f) instructions on how integrators may comply with essential cybersecurity requirements set out in Annex I and the documentation requirements set out in Annex VII.
   • Maybe best handled by either a link to separate lifecycle documentation, or a link to an SBOM file containing links to this, or a separate POD section?
9. (9) Link to where the software bill of materials can be accessed
   • This may be a link to it's Release (Source) SBOM – e.g. an URL to either it's repository location for a given release, or a link to an SBOM hosted by the publishing platform (e.g. on MetaCPAN?)
   • …or a link to a Project SBOM – e.g. an URL to the SBOM hosted in the main repository branch.

(updated 2025-04-23)

[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: CycloneDX/specification#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! 😁

[sjn]

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.

[sjn]

I've updated the OP with most of what I know, so we can have a discussion on this topic at PTS; Hope this helps! 😅

[sjn]

Also because you can't include a hash of the package (or sign it) if the SBOM file is inside the package.

Yes, this is mostly true, though we have a few exceptions that need to be taken into account:

• SBOMs for vendored components have been included in the package.
  • e.g. Mojolicious includes bootstrap.js and a bunch of other javascript dependencies. Their metadata need to be put into a separate SBOM and included in the package.
• Components that Alien:: packages download during their build phase are also dependencies, and need therefore to be listed in a separate SBOM and linked to appropriately from the module's own SBOM.

[sjn]

Had a chat with @robrwo about security-related metadata, and landed on a few points for consideration.

1. We need some example SBOMs to play around with, and to help us figure out what metadata fields need to be added to the spec and which ones can be moved to an SBOM file. Repo for experimentation is here.
2. We're pretty confident that points 2, 4 and 9 in the OP are worth arguing for adding to the spec. The remaining points ought to find a place in the SBOM file in the form of pointers (e.g. URLs or bom-links) to relevant documentation, as needed.
3. We probably can't solve the problem stemming from the inability to match out-of-ecosystem requirements with resolved dependencies, until necessary updates are made to the PackageURL specs (e.g. see Do pkg and vers URIs need a third scheme? The case for "lib" URIs package-url/vers-spec#23).