Prepare Inventory for V1 release

[tobie]

With the changes in #227 merged, the @orcwg/inventory-task-force-leads believe the Inventory is ready for a V1 release and requests a review from the members of the Cyber Resilience SIG for approval.

The final version of the document is visible here: https://github.com/orcwg/cra-hub/blob/tobie-inventory-v1-release/inventory.md

Please review the whole document and approve this pull request if you're ready to endorse it as a V1 or suggest modifications otherwise.

Thank you!

[maximbaele]

Looks good!

[maertsen]

Hi!

I'm not a member of the steering committee, but I do have opinions. My apologies for not chiming in earlier.

In general, coming from ORCWG, I feel that summaries should critically reflect on the extent to which documents have content tailored for dealing with FOSS. If they don't, but are still seen as industry standards, this should be noted. If they do, this should be emphasized as an inspiration for the CRA-standards where approriate.

I have specific concerns about both sections 5 and 6, as follows:

• Section 5 lists documents that have a pretty traditional view towards securing supply chains, that seem to assume the existence of relationships (contractual, monetary) that would make it appropriate to shift compliance costs upstream. What is notably lacking, at least in the summaries, are means to interact with upstreams in a productive way considering they are not suppliers and in particular in ways conducive to sustaining and improving security upstream. This 'assuming supplier' is evident in the summaries, for example:

The guide suggests structuring the vendor selection process to include security questionnaires or assessments and to prefer vendors who can demonstrate secure-by-design approaches (perhaps via certifications or past performance).

• Section 6 is inconsistent with our FAQ-answer on security attestations, in particular "any resemblence with concepts elsewhere by the name of 'attestation' is coincidental and should not restrict their future design in the CRA"
  • At a minimum, I suggest mentioning that the documents in this category describe other concepts that use the same name, and that they should not constrain the design space for a security attestations in the CRA.
  • In absense of such nuance, casual readers could be mislead into thinking that they are the same thing and that this group believes this should be so. I for one do not believe that should be the case.

[maximbaele]

Hi Maarten, thanks for weighing in!

I agree that the resources in section 5 are biased towards a "traditional view" on supplier relationships, but I am not aware of resources that focus more on the relationship of organizations with upstream projects. Are there other resources that you can think of, that would be more relevant for this category and that do have this focus?

In this first iteration, the summaries are taking the documents at face value, describing the intent of the documents that were submitted. I'll do a second pass to see if there's mentions of interacting with upstream in a productive way for the resources currently in the list, but if it's not in the document I don't think the information would belong in a summary.
We could write down an opinion on how resources can be used as-is or amended for dealing in a positive way with upstream projects, but perhaps this information is better placed in a "ORC-WG advice" section for each resource? @tobie WDYT?

Regarding the inconsistency for section 6, do you suggest we copy over the FAQ answer as a disclaimer to the section?

[felixreda]

I see two possible ways forward here:

• One is to take a restrictive interpretation of the document's purpose as stated in the first paragraph, which is to collect resources that are relevant "when it comes to the development and integration of open source under the Cyber Resilience Act (CRA)". Consequently, resources that are relevant for manufacturers when integrating third-party components provided by traditional suppliers, where those resources don't include any guidance on integrating open source components, should be removed from the list, because they cannot be considered "documented industry and community best practices" for the development and integration of open source components.
• The other possible approach is to take a broad, inclusive interpretation of the purpose of the document, where documents are included that do not constitute industry or community best practices for development and integration of open source under the CRA, but that are relevant for compliance with the CRA outside of the area of open source. In this case, instead of including a neutral, LLM-generated summary of each document, the summary should be replaced with a normative statement why the ORC working group thinks it is useful to raise awareness among the open source community for the existence of those documents in the context of the CRA. In this case, the summary should definitely highlight the document's shortcomings when trying to apply it to an open source context.

I think both approaches are viable, the first one is probably easier to implement to arrive at an MVP.

[tobie]

Love the input, @maertsen, thank you! We're striving for community consensus, not steering committee approval, so your input is absolutely relevant.

I pondered referencing relevant future ORC deliverables in the inventory where we have such concerns and I like @maximbaele's suggestion to add an "ORC comment" note where relevant.

For example, what if we added to section 5 something along the lines of:

Note

The due diligence obligation of manufacturers outlined in Article 13(5) of the CRA is the cornerstone of the relationship between manufacturers and the open source ecosystem. The CRA finally formalizes the long-held understanding that manufacturers are responsible for the security of the open source components that they integrate in their products. Yet the relationship between manufacturers and the open source projects they integrate remains underspecified. Most of the references we have collected assume the existence of a contractual relationship between a manufacturer and a supplier that addresses compliance obligations.

This is of course different when integrating open source components, as no such agreement exists. Neither open source software stewards nor the maintainers of open source projects are suppliers. Open source software is provided as is. Not only do manufacturers need to exercise due diligence when they decide to integrate open source projects in their products. They also need to support and contribute to these projects to ensure that they meet their own compliance requirements.

ORC plans to examine this relationship in an upcoming white paper on the due diligence obligations of manufacturers.

[tobie]

@felixreda thanks for framing this so clearly. I believe the intent is to collect the references in this inventory in a fairly neutral way, and then to dig into the specifics in our various white papers. I'm attempting to bridge that gap with the note in my above comment. Does it help?

[maertsen]

Thanks for all the thoughtful responses. I think this discussion is quite likely to lead to a suitable solution to my concerns and I appreciate that a lot. I like Tobie's note, but would firm up its conclusion should we indeed believe it to be the case, as Maxim noted, that no suitable resources are available. I believe that would be a useful finding, both to identify the gap and to point it out in related policy discussions.

@maximbaele wrote:

Regarding the inconsistency for section 6, do you suggest we copy over the FAQ answer as a disclaimer to the section?

Yes, I think it can serve as a useful starting point for another note in the style Tobie is suggesting. But I do note this is also an opportunity to provide examples of resources that the group feels would be useful to encapsulated by the CRA's notion of attestation. There's no reason why that concept in the future could not say, give a code review some level of status within the CRA. Just one example, this is obviously to be explored (elsewhere?), which is why I'm trying to avoid the impression of a foregone connection between these similarly named concepts.

[tobie]

Added an example of what this could look like in situ here: https://github.com/orcwg/cra-hub/blob/tobie-inventory-callouts/inventory.md#5-due-diligence-requirements.

[tobie]

Your latest comment, @maertsen, makes me more confortable referencing our upcoming deliverables, as they're specifically designed to address the holes you've been pointing out. For example, we have a planned deliverable on security attestations that's described here: https://github.com/orcwg/orcwg/blob/main/cyber-resilience-sig/deliverables.md#33-white-paper-on-security-attestations

[dirkx]

+1 for a v1

[mrybczyn]

I propose to merge #244 with Eclipse Foundation policies and practices added to the appropriate section as examples.