| Re: [open-regulatory-compliance] Maintainer considering removing project due to CRA obligations and uncertainty |
|
Thanks Dick. I'm glad that the maintenance of your project is not a burden and that the obligations (and regulatory demands are light.
For the Eclipse Ecosystem, and it's extensible architecture:
a) Who qualifies as an open source steward? And who decides who is and who isn't a steward?
b) What process-and-communication-wise will happen when vulnerabilities that involve multiple projects, multiple bundles/plugins, multiple orgs/committers/project leads are received?
c) Who decides who's legally responsible for expending resources to diagnose and address any detected vulnerabilities?
d) How are new features/enhancements or even whole products (e.g. on Eclipse) handled in terms of vulnerabilities?
e) What about projects (like ECF) with tech that spans/depends upon multiple OS communities (e.g. Java, Eclipse, Python, Apache, etc).
Anyway, I thought that this group might be a good source of answers or discussion to some of these questions.
Scott
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?
Artifact
Duration
Tool Used
10 minutes
sbom4python
15 minutes
SAG-PM and open source VDR schema
45 minutes
notepad++ and open source VRF schema
50 minutes
Excel
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
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org