Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-regulatory-compliance] A more positive take on CRA FAQs and flowcharts

I'm hoping to receive confirmation that an open-source steward will satisfy their EU-CRA obligations by providing the following artifacts, per product:
- An SBOM
- A living, online Vulnerability Disclosure Report (VDR)
- A Vendor Response Form containing additional product info, i.e. Support Status and Commercial status and more
- A CISA Secure by Design Software Acquisition Guide spreadsheet showing adherence to Secure by Design and Secure by Default principles and practices ( https://cisa.gov/sag)
- A final risk assessment report (on request only)

Examples of these artifacts can be seen online at GitHub: https://github.com/rjb4standards/CISASAGReader

Any indication that these artifacts will not be sufficient to satisfy EU-CRA obligations would also be useful information to know.
Any feedback will help to provide clarity.

Thanks,

Dick Brooks
   
Active Member of the CISA Critical Manufacturing Sector, 
Sector Coordinating Council – A Public-Private Partnership

Never trust software, always verify and report! ™
Risk always exists, but trust must be earned and awarded.™ 
https://businesscyberguardian.com/ 
Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx
Tel: +1 978-696-1788


-----Original Message-----
From: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Olle E. Johansson via open-regulatory-compliance
Sent: Friday, January 3, 2025 8:59 AM
To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Olle E. Johansson <oej@xxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] A more positive take on CRA FAQs and flowcharts



> On 3 Jan 2025, at 14:28, Ilu via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
> 
> Both CRA and PLD have "commercial activity" as main criterium. I did 
> not write them. Ranting about their terminology does not help anybody. 
> It is what it is.
> 
> Am 03.01.25 um 09:57 schrieb Federico Leva via open-regulatory-compliance:
>> You suggested that individuals should decide whether to worry or not 
>> based on whether their activities are commercial
> 
> No. I said that CLEAR hobbyists do not need to worry. People that have 
> absolutely NOTHING to do with any kind of software business - for 
> example schools, students and universities. This is an extremely small 
> group. If you have any connection to anything business-like - for 
> example if you are working as a dev or anywhere in the software 
> business
> - you are most probably not a hobbyist.
> 
> In that case you have 3 options:
> 1. Decide that you are not under CRA and hope you are right.
> 2. Get legal advice and pay for it.
> 3. Assume that you are under CRA and comply.
> 
> I'm arguing against checklists and flowcharts and FAQs that sell the 
> illusion that there is an easy, reliable and cheap way out of CRA.
> Because, as you correctly observed, the text of the law and especially 
> the recitals is convoluted, barely understandable and the terminology 
> is tautological. Spending time on trying to make sense of it is futile.
> 
> I'm arguing for concentrating on point 3. We need to help projects 
> that are afraid of being in-scope to prepare. Telling them "you are 
> not in scope" will not stop any fears. They will think "that 
> information might be wrong - what then?" - "Better avoid the risk and 
> archive my project now." Like that python dev someone mentioned, they 
> had exactly that chain of thought.
> 
> If a project wants to play it safe, they should just assume to be in 
> scope of CRA. If it turns out later that they were actually out of 
> scope, they'd have "wasted" time on security, best practices and 
> documentation and I'd say that's bearable.
I do agree with you that the “in scope” discussion is not very helpful. The discussion should focus on what’s needed to comply and what are the liabilities. For most of open source projects I am guessing there is a very small liability and very small amount of work to be done - but we need to focus on finding out a proper answer here.

A complex part is those that have founded their own business around supporting and working with an Open Source project they are only a small part of. They’re not in control of it and don’t have the copyright, but still run a commercial business while contributing to the project. 

Whether they are stewards or not is something I still don’t understand.
> 
> We need to asure projects that being in scope is not a disaster.
+1

> That
> they are not alone but part of a community. That the communities are 
> working on guidelines how to comply. That not everything needs to be 
> immediately perfect. That there is still enough time and that time 
> will bring clarity. That the EU authorities will not immediately crack 
> down on FOSS in 2027, especially not on smaller projects. That 
> complying with CRA is the best way to prepare for PLD.

A lot of the discussion I’ve been part of has focused on foundation-related projects, which is a small amount. We do need to have all projects in scope.

> 
> We need to come up with these guidelines soon-ish. We need to get to 
> work. If we continue with the "in or out" discussions we will never 
> get anywhere.
Exactly.

/O
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org



Back to the top