Seth,
I participate in several groups working on vulnerability management and was a contributor to the CISA Secure by Design Software Acquisition Guide, Vulnerability Management chapter, available here:
https://www.cisa.gov/sites/default/files/2024-07/PDM24050%20Software%20Acquisition%20Guide%20for%20Government%20Enterprise%20ConsumersV2_508c.pdf
In two meetings software vendors acknowledged providing customers with product Vulnerability Disclosure Reports (VDR), originally described by NIST, which was renamed to Vulnerability Advisory Report (VAR) by NIST effective November 1, 2024.
Several software vendors already produce these “on demand” Vulnerability Disclosure Reports (VDR) through their customer portals. A VDR answers the consumer question: “Is my installed software product X affected by any vulnerabilities, as of tight now?”
I have posted an example of a living open-source Vulnerability Disclosure Report” (VDR) as part of an open-source project supported by BCG called the CISASAGReader:
https://github.com/rjb4standards/CISASAGReader
I plan to offer this open-source VDR schema as one possible method to meet EU-CRA obligations to communicate software product vulnerabilities before placing a product on the market and as a “living document” that can be linked to an SBOM, ref: SPDX V 2.3 as an example:
https://spdx.github.io/spdx-spec/v2.3/how-to-use/#k19-linking-to-an-sbom-vulnerability-report-for-a-software-product-per-nist-executive-order-14028
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
From: Seth Michael Larson <sethmichaellarson@xxxxxxxxx>
Sent: Thursday, December 19, 2024 12:32 PM
To: dick@xxxxxxxxxxxxxxxxxxxxxxxxx; Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] Maintainer considering removing project due to CRA obligations and uncertainty
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. 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.
I know it is possible to transfer a GitHub repo to another party, but I'm
not sure if this act would exempt a party from lawful requirements.
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: open-regulatory-compliance
<open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Olle E.
Johansson via open-regulatory-compliance
Sent: Thursday, December 19, 2024 11:30 AM
To: Open Regulatory Compliance Working Group
<open-regulatory-compliance@xxxxxxxxxxx>
Cc: Olle E. Johansson <oej@xxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] Maintainer considering removing
project due to CRA obligations and uncertainty
> On 19 Dec 2024, at 17:20, Maarten Aertsen via open-regulatory-compliance
<open-regulatory-compliance@xxxxxxxxxxx> wrote:
>
> On Thu Dec 19, 2024 at 17:08 CET, Federico Leva via
open-regulatory-compliance wrote:
>> 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. The
>> risks for individuals may be overstated, but it seems there's demand
>> for an "insurance" to absorb these risks, and pooling them should help.
>
> I am not at all sure if there is such a thing. If an individual meets the
criteria for Manufacturer, there is no transfer possible. If they don't meet
those criteria, they are out of scope and a transfer is unnecessary.
Surely there has to be a transfer possibility. Companies buy companies,
software changes ownership. There must be a possibility to retire here.
>
> My perspective on what's needed, is more accessible guidance from credible
sources and active outreach to get guidance to the right places. Individuals
who spend their spare time maintaining digital infrastructure should not
need to fear this law, but clearly, in some cases they do.
Agree fully.
/O
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
