Scott, This text comes directly from the EU-CRA text in Article 3(14) available here: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202402847 From: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Scott Lewis via open-regulatory-compliance
Sent: Friday, December 20, 2024 12:28 PM
To: open-regulatory-compliance@xxxxxxxxxxx
Cc: Scott Lewis <slewis@xxxxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] Maintainer considering removing project due to CRA obligations and uncertainty Hi Brian, On 12/20/2024 6:47 AM, Dick Brooks via open-regulatory-compliance wrote: Brian, You make some excellent points. Actually it’s the definition that gives me pause to think that BCG may be an open-source software steward. Business Cyber Guardian (BCG) is a legal entity in the US. (14) ‘open-source software steward’ means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products;
I'm assuming this definition of steward is from the DCA itself. Could you please provide a reference to where in that document? Thanksinadvance, Scott BCG is not the manufacturer of CISASAGReader, bit it does ensure the viability of the product, i.e. monitoring and reporting on vulnerabilities and working with independent developers on fixes. 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 There's clearly work to be done to tighten the understanding. The flow chart shared earlier doesn't quite map to what I had understood. It seemed like the Steward category was created to generally cover more of the umbrella organizations that assist/sponsor/host many oss projects. Things like Eclipse, LF, ASF, Github and also things like Maven Central, Pypi etc. However, based on all the hand wrangling in the CRA around commercial terms, an entity producing a single (maybe a few) oss projects probably is closer to a manufacturer. We know orgs like Mozilla were in the targets of the CRA. So Dick, your example for me doesn't clearly look like a Steward, but that's just my fuzzy mental model. I think the difference is something like: does your activity exist to support Open Source generally or is it for a more pointed purpose that happens to be delivered as Open Source? 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
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
-- Brian Fox Chief Technology Officer | 
| |
_______________________________________________ open-regulatory-compliance mailing list open-regulatory-compliance@xxxxxxxxxxx To unsubscribe from this list, visit https://accounts.eclipse.org
|
