Due Diligence is not clearly defined in EU law because the level of diligence depends on the situation. As a rule of thumb, within Parliament's legal affairs committee, we always considered that the adequate level of diligence is one that ensures the goals of the regulation are met.
It's also important to note that while recitals do provide context to support interpretation, they are not exhaustive. In my view, for some products, in particularly in lower-risk uses and for very popular libraries, they may suffice. However for higher risk products or use cases, in my view they are inadequate. The law creates Security attestations to address this problem (at least, that was the logic when it was written!)
I also think that we cannot afford to ignore consequences and issues that arise because of the CRA outside the framework of the CRA itself: for example, Liability under the Product Liability Directive, and insurance related to that Liability. As I see it the current wording of the PLD, and hence the position of insurers, will also be that what is in Recital 34 is not enough, especially in high risk use cases.
2. Given that a manufacturer can always fulfill their Article 13(5) due
diligence by conducting an internal assessment or by commissioning a
private one from any third party, what is the justification for
proposing to limit who gets to issue attestations under Article 25? This
refers both to the proposals I heard in the room allowing an open
source project to select who gets to issue article 25 attestations or
limiting it to - for example - stewards.
The CRA is as much an Open Source Sustainability law as it is a Cyber Resilience one, but Open Source Sustainability is vital to Cyber resilience. If we do not limit who can issue attestations, we will find ourself in a situation where dozens of companies pop up whose entire mission is to harass Open Source developers into providing them enough information to create an attestation, and then pocket the cash.That is an unacceptable but extremely likely outcome if we don't create some restrictions.
I also believe that allowing organisations with no affiliation or link with the developers to provide attestations would not result in those attestations being reliable or valuable.
You are right that companies can conduct internal assessments or commission private assessments from a third-party, however that, in my view, would likely involve in-depth auditing of code (to meet the requirements of insurance companies), which will be extremely costly, and again, those third parties do not necessarily have the information required to attest to the security of the supply chain.
This makes attestations the better choice for manufacturers.
3. Is an attestation issued as a voluntary security attestation under an
article 25 system bound to the software alone or *also* to the
recipient? For instance, if Manufacturer A gets an attestation for
libfoo 0.9.6c, can Manufacturer B, who uses the exact same component,
also use that attestation for their own due diligence (assuming for the
purpose of this question that B learned of the existence of this
attestation)? If the answer is 'no, it's recipient-bound,' could you
help me understand what law or rule creates that restriction?
It could be either. Attestations in their own right could just be a contractual relationship between the attestor and the manufacturer, not a document or object. It's also worth noting that the EU can write implementing regulations and delegated acts which set out such a system for the purposes of the CRA.
I hope these responses are useful!
Best Regards,
--
Jordan Maris
EU Policy Analyst, The Open Source Initiative
tel:
+33613141427