[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
