Scott,
I think I may be in a similar position
to you. I am a co-developer along with another collaborator on
an open-source product that is maintained on GitHub and
distributed via PyPi;
https://github.com/rjb4standards/CISASAGReader
My Company, Business Cyber Guardian™,
supports the CISASAGReader open-source product but is not
receiving any economic benefits. It’s not a heavy lift to
maintain, except for the occasional VDR checking and updates
that may occur (about 10 minutes per week). No new feature
enhancements are planned so the other artifacts will remain
static at release 1.0.4.
I'm not too concerned about the EU-CRA
"open-source software steward" obligations IF it only
requires providing the following items to comply:
Could this group of artifacts provided with the CISASAGReader
open-source product (see tble below) also serve as a model for
what Open
Source Stewards should provide to
satisfy EU-CRA expectations for transparency and Secure by
Design/Default?
How long did it take to produce the CISASAGReader SBOM, VDR,
VRF and CISA Software Acquisition Guide Spreadsheet?
I’m hoping to receive confirmation of
this “set of artifact” as being sufficient to comply with
EU-CRA “open source software steward” obligations OR receive
guidance on what else is needed.
I can live with this set of artifacts
knowing how much time it takes to create them (shown above),
which occurs once per release, with ongoing checking for new
vulnerabilities (about 10 minutes per week and any time
required to update the VDR accordingly – usually zero minutes)
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 Scott Lewis via open-regulatory-compliance
Sent: Thursday, December 19, 2024 3: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
Howdy,
On 12/19/2024 9:32 AM, Seth Michael
Larson via open-regulatory-compliance wrote:
> Thanks all for the replies, here
are some thoughts from me:
>
> > I'd be particularly interested
in a description of the minimum steps
> required to transfer CRA
responsibilities to a FLOSS steward, say
> hypothetically the PSF or a
cooperative of Python consultants.
>
> I'm not sure the PSF or any other
foundation like it is in a position
> to absorb all projects under, in
our example, PyPI. However, we still
> have our eyes on lowering the bar,
for example I have plans this
> upcoming year to make complying
with the "vulnerability reporting" and
> "market surveillance compliance"
easier for maintainers.
Although I support every desire and
effort to make things easier for maintainers, I can tell you:
1) The Eclipse project I maintain (ECF)
is independent committer led (me)
2) Is a -1 dependency for the Eclipse
IDE...we provide the file transfer (e.g. https/ssl) api for
Eclipse implemented by multiple third-party provided impls
(e.g. httpclient).
3) As part of the Eclipse Platform, ECF
filetransfer (at least) will likely be subject to
vulnerabilities and regulations applying to the Eclipse IDE
install/update mechanism (called equinox p2) and our
third-party dependencies (equinox, provider impls, Eclipse
Platform).
> Things like an official location
for a security policy, report a
> vulnerability, and a process for
contacting all relevant market
> surveillance groups (CISA, ENISA,
etc) in the case of actively
> exploited vulnerabilities. I think
these sorts of developments are
> much more within our resourcing.
That doesn't provide the resourcing
> and time it takes to operate those
facilities (so is still a burden on
> solo-and-low-maintainer projects),
but at least there's more clarity
> about what is actually needed from
folks and for external groups to
> not "spook" maintainers with
official and legalese-sounding emails
> that you are now legally obligated
not to ignore.
Although I have only read some of the
DCA and am not a lawyer, and appreciate the efforts that went
into having a category of open source 'steward' recognized in
the DCA, currently there is every reason to expect that if
faced with the burdens under discussion, I would be/am
'spooked' in a way similar to Seth's colleague.
I know that I do not have the personal
resources even to continue as the project steward, cannot
absorb the additional maintenance burden (e.g.
responding to and addressing
vulnerabilities or procedure), and certainly cannot/will not
absorb new legal risk.
FWIW, I do think that there should be
additional thought in this group to the 'open source steward
spooking' problem identified by Seth.
Scott
https://eclipse.org/ecf
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
