Re: [open-regulatory-compliance] Maintainer considering removing project

["Dick Brooks" <dick@xxxxxxxxxxxxxxxxxxxxxxxxx>]

I concur with Dirk. Even though I am not located in the EU (I'm in
Westfield, Massachusetts, USA) my Company is committed to producing secure
software products, both commercial and open-source.

In the spirit of "making the software safer to prevent harm", it would be
beneficial for software producers to know what is expected to comply with
the EU-CRA and other regulations being introduced internationally under two
scenarios: as an open-source software steward and as a "manufacturer".

IF the expectations are as small as simply delivering 4 artifacts (SBOM,
VDR, Vendor Info (VRF) and Secure by Design attestation) then I'm not too
concerned. I tracked the time and effort it took to deliver these 4
artifacts for our CISASAGReader FOSS product; it was less than 4 hours total
- see table of tools used and time required on the CISASAGReader GitHub
repo:
https://github.com/rjb4standards/CISASAGReader

It does take longer to produce these same 4 artifacts for our commercial
offering, but it is still less than 12 hours per commercial release, in most
cases (depending on NIST NVD stability). 

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! T
Risk always exists, but trust must be earned and awarded.T 
https://businesscyberguardian.com/ 
Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx
Tel: +1 978-696-1788


-----Original Message-----
From: Dirk-Willem van Gulik <dirkx@xxxxxxxxxxxxxx> 
Sent: Friday, December 20, 2024 8:55 AM
To: Open Regulatory Compliance Working Group
<open-regulatory-compliance@xxxxxxxxxxx>
Cc: dick@xxxxxxxxxxxxxxxxxxxxxxxxx; Daniel Thompson-Yvetot
<denjell@xxxxxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] Maintainer considering removing
project due to CRA obligations and uncertainty

On 20 Dec 2024, at 14:35, Daniel Thompson-Yvetot via
open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
> 
> A little hack crossed my mind today:
> 
> What if everyone clearly labelled their OSS software as BETA and unfit for
any (commercial) purpose. There is a specific carveout that says that even
those that will be classified as Manufacturers can't put a CE marking on
Beta products (that are not sold / aka used for QA purposes)...
> 
> That might calm the OSS waters for a bit.


I think you want to lift the helicopter a bit - what is the intention of the
CRA ?

It is, basically, to make software safer - as to prevent harm. Or in more
economic terms - so that society does not pay the cost of bad security and
we all lose (i.e. prevent externalisation). The business case behind the CRA
is solid; even if all software / release engineering get 30% or 50% more
expensive - we probably make that back within the year.   Secondly - 95% of
any given (commercial) software stack or service is essentially open source.
If it is SaaS; probably more 99%.

So if above hack where to work - you'd be looking at a CRA-II in no time. As
the intention of all this is making software safe. Just like - over the
years - we've learned how to keep steam boilers from exploding, bridges from
collapsing, not have another Thalidomide scandal, prevent mass food
poisoning & bad water, prevent large outbreaks of diseases and so on. 

Secondly - if things quack like a duck, walk like a duck and look like a
duck - do not be surprised if the legal system (in Europe) treats them like
a duck. And in this it is not so much the regulators who are in control -
but the insurances and underwrites that cover mandatory/legal product
liability far downstream.

Because, in all fairness, popular open source a lot of `productisation' and
`release engineering' that often demonstrates an expectation, intend and
desire to make it easy to be used by others. Which is a far cry from code
developed by a hobbyist or an academic  for another hobbyist or researcher.
Or code that is intendend for inhouse use that happend to be shared on a
`your milage may vary' basis.

So I would urge us to not go down that path.

But instead - just like open source has done in the security field - where
responsible disclosure is now the _norm_ -- set the industry standards on
responsible release processes (version number, no known CVEs, release notes
with any residual CVEs, SBOMs, triage based bug & vulnerability processes
and so on). That list is not long.

With kind regards,

Dw