| Re: [open-regulatory-compliance] Maintainer considering removing project due to CRA obligations and uncertainty |
There are cases where open source software, components, and artefacts are very clearly mature from both technological and cyber-resilient perspectives, and then should provide attestations, reports, etc. I didn't mean to suggest that OSS as a whole should adopt the "beta hack" I just proposed. It was more intended for those who don't know where they lie on the spectrum (and don't care).
I expect the issue introduced to us in this thread (the croniter github project) to be indicative of a nascent cottage industry of bike-shedded solutioning, as can be inferred from this comment:
https://github.com/kiorky/croniter/issues/144#issuecomment-2556304691
> This project is an open-source initiative and is provided "as-is" without any warranties or guarantees.
It does not comply with the EU Cyber Resilience Act (CRA) or any specific regulatory requirements.
> If you are using this project in a commercial product or a context where CRA compliance is required, we strongly advise against including it without conducting your own security assessments and ensuring compliance independently.
The maintainers accept no responsibility for regulatory or legal obligations arising from its use.
I know the CRA and the PLD were intended to protect the most vulnerable, but when I speak to stakeholders in the various OSS and Manufacturer communities where I am active, I see suffering, sadness, and frankly quite a bit of shock. We need to provide solid guidance and if one of the things we can offer our colleagues who are sad is a hack - well, then I think we should at least consider it when we formulate our handbook.
Cheers,DanielOn Fri, Dec 20, 2024 at 3:10 PM Dick Brooks <dick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: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