Are the actions listed in Recital 34 a comprehensive list of manufacturers' due diligence obligations?

[tobie]

Asked by @MathiasSchindler in the ORC mailing list:

Regarding the due diligence obligations under Article 13(5), is the list of actions in Recital 34—such as checking conformity, reviewing update history, and scanning vulnerability databases—generally understood to represent the typical scope of a manufacturer's duty?

[tobie]

My reading of Article 13(5):

"so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating"

and of Article 25:

"In order to facilitate the due diligence obligation set out in Article 13(5), [the Commission can establish] voluntary security attestation programmes allowing [anyone] to assess the conformity […] with all or certain essential cybersecurity requirements or other obligations […]"

… lead me to believe that the expectations are that open source components need to meet all of the essential requirements of Annex I. And that security attestations are there to bridge the gap between the light-touch regime of stewards (or the absence of obligations of out-of-scope projects), and the essential cybersecurity requirements of Annex I.

As such, and as described in our deliverables plan, security attestations are a near equivalent of the CE-mark. While it's important to note that even if you're integrating CE-marked components, you still need to do due diligence (see Blue Guide and PT1 standard), a CE-marked product used as intended gets you a long way.

That said, I don't believe that that level of due diligence is reasonable to expect from manufacturers for FOSS components today (because of the transitive nature of open source dependencies which means that manufacturers would need to meet those requirements across their whole FOSS dependencies, unlike for non-FOSS components where this is just one layer down), and is way beyond current industry best practices.

That's why I believe we should be writing white papers on due diligence for FOSS and advocating for more reasonable and effective practices at this stage (e.g. adopting S2C2F as @AevaOnline suggested).

[jmaris]

My two cent (based on previous discussions in parliament) on this is as follows: due diligence means the relevant level of care to ensure compliance with the law.

In my personal view that means:

• If you are using a Open Source library run as a one-person project with unstable maintenance, as a manufacturer you should audit the code.
• If you are using a well-maintained Open Source library run by one person, consider auditing the code, or the developers practices ( easiest way is with an attestation )
• If you are using a well-maintained large community Open Source project, audit the developers practices (best way is with an attestation)
• If you are using a well-maintained large project with a steward, you are probably okay doing similar due diligence you'd do for if you were buying the component from another manufacturer, however you should keep an eye on the software to ensure it is still well supported and maintained. Attestations are ideal.

[tobie]

This is somewhat circular, no? The attestations needs to attest of a number of things that the manufacturer needs to check in order to meet their due diligence obligations. The question is: what are those things?

[jmaris]

Those things are the essential cybersecurity requirements (at least that is what the CRA says the attestations are supposed to attest to)

[tobie]

@jmaris that's precisely the point I'm making in the comment above ("the expectations are that open source components need to meet all of the essential requirements of Annex I"), and that I believe seems unreasonable at this stage (see 2nd half of the same comment).