I’ve created another (non-authoritative) VDR use case to consider based on the authoritative Python 3.13.3 product SBOM;
https://www.python.org/ftp/python/3.13.1/Python-3.13.1.tgz.spdx.json
NOTE: Only the original software producer is considered authoritative with regard to Vulnerability Disclosure Reports (VDR) creation as they are the only party that knows for certain which vulnerabilities affect their products:
A NON-Authoritative VDR baseline for the Python V 3.13.3 release in XML format is available here, to aid in this use case discussion:
https://raw.githubusercontent.com/rjb4standards/REA-Products/refs/heads/master/Python-V3.13.1-VDR.xml
VDR’s are typically signed by the party that creates (authors) the VDR,
https://github.com/rjb4standards/REA-Products/raw/refs/heads/master/Python-V3.13.1-VDR.xml.sig
As you will see from the Python VDR signature file, the VDR author/signer, Dick Brooks, is not an authorized party and cannot produce an authoritative VDR for the Python 3.13.3 product.
From: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Dick Brooks via open-regulatory-compliance
Sent: Saturday, December 21, 2024 8:44 AM
To: 'Daniel Thompson-Yvetot' <denjell@xxxxxxxxxxxxxx>; 'Open Regulatory Compliance Working Group' <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Dick Brooks <dick@xxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] Flowchart from a natural person's perspective -- straw man
Daniel,
Using the CISASAGReader SBOM as a use case; neither I nor Business Cyber Guardian can attest that each component used in the final product meets EU-CRA expectations.
https://raw.githubusercontent.com/rjb4standards/CISASAGReader/refs/heads/main/CISASAGReader-V1_0_4-SBOM.json
Business Cyber Guardian did create a “Vulnerability Disclosure Report” showing that each component in the SBOM was checked for vulnerabilities and the CISASAGReader FOSS product is viable and trustworthy, to the best of our knowledge.
Business Cyber Guardian, as the open-source steward, performs regular vulnerability scans based on the SBOM components and updates the VDR accordingly (usually about 10 minutes weekly).
There are no product changes resulting from the updated vulnerability scan and resulting VDR.
However, if a new vulnerability was reported Business Cyber Guardian would notify the developers and monitor for updates to address any issues (patched updates of the CISA SAGReader FOSS product)
Business Cyber Guardian responsibilities are specifically to ensure the viability and trustworthiness of the product by producing an up to date Vulnerability Disclosure Report. The developers are responsible for producing secure software.
Consumers can answer the question “Is the CISASAGReader product free of exploitable vulnerabilities and trustworthy, as of right now?” by examining the living VDR document;
https://raw.githubusercontent.com/rjb4standards/CISASAGReader/refs/heads/main/CISASAGReader-V1_0_4-VDR.json
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
What I meant is - who in the case of 40 has the requirement of placing the declaration of conformity upon the common open source component… I don’t mean their “final” product, that it needs full compliance is a given…
Dirk,
I made it to step 70 and answered Yes as a legal person named Business Cyber Guardian.
As an independent legal person named Dick Brooks volunteering my time freely to create the CISASAGReader product, I believe I am personally exempt from CRA obligations.
Thanks for doing this.
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 Dirk-Willem van Gulik via open-regulatory-compliance
Sent: Friday, December 20, 2024 5:30 PM
To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Dirk-Willem van Gulik <dirkx@xxxxxxxxxxxxxx>
Subject: [open-regulatory-compliance] Flowchart from a natural person's perspective -- straw man
Here is my attempt at a more flowchart form for natural persons (mostly in reaction to some private questions).
Mainly to see if this teases out other questions/issues.
I’ve been a bit black and white/over the top in below; somewhat intentional to see if this helps us get better boundaries for the vague areas; and if there are things we can simply take as right — and we can focus on the ‘indicators’ for these.
Dw.
10: Do I personally contribute to an open source project ?
E.g. do I sent in patches or do I post bugfixes to an Open Source project ? Or do I do a pull request ?
No: Do I contribute to that open source project as part of job; because my boss wants it ?
I.e. in the boss his time (also if I am my own boss - where it is part of what I deliver to my customers) ?
Yes: Generally - the CRA is not your problem, but your bosses their problem.
This flowchart is not for them.
goto 20
No: goto 20
Yes: Do I have a committer license agreement (CLA) with that open source Project and do you contribute under that license ?
Or do you contribute to a project with an implied contribution agreement that is part of the projects open source license ?
Yes: While it depends on the minutiae; you are almost certainly fine if it is one of the many typical ASF variations of a CLA.
goto 20
No: you are probably fine; but would be good to introduce a CLA
goto 20
20: Are you maintaining or operating a public software repositories of open source ?
Yes: You are probably fine
goto 30
No: goto 30
30: Are you developing ppen source software in the course of a commercial activity ?
i.e. is it placed such that others (downstream) can use it in lasting ways as these downstream parties go about their lives or business ?
Yes: goto 40
No: You are probable fine
So you are a pure hobbyist; no one really uses your code; or others if so - and if they do so - it does not result on something lasting that exposes it to other people beyond the person who you directly shared it with.
END
40: Are you monetising the work you do on this open source ?
For example you XXXX?
Yes: Go read the CRA. This flow chart is not for you.
END
No: goto 50
50: Is there a group of people and/or legal persons that you are part of, where there is the shared objective or purpose to create, maintain, publish that open source licensed code ?
A typical indication is that you call yourself a group; have a website; have a SCM you all have access to; may have created a more formal legal vehicle; such as a foundation, society or similar, practice some software/release engineering and that you create some forms of processes and rules.
Yes: > hit the superset or either/or issue of legal/natural person <
goto 60
No: You are probable fine - depending a bit on the answer to above super/subset issue
END
60: Is the purpose of that open source such that it is intended; or quite possibly, to be used `downstream’, including by others in a commercial setting ?
Typical indications of this are things like a SCM, release notes, versions numbers, READMEs, makefiles, including in repositories, systemd scripts to start/stop, an FAQ, A manual, a bug database, non directly involved developers submitting bugs or asking questions, etc.
Yes: goto 70
No: You are probable fine - and you and a few mates are working on something very internal; such as the open source code for a large model transit you are building together
END
70 Is there an aspect of a sustained basis & ensuring longer term viability of the product.
So think proper release engineering, fixing bugs, doing risk-based triage, responsible disclosure, filing CVEs, disclosing unsolved vulnerabilities in the release notes, peer review of the releases, timely releases, etc ?
Yes: You are probably an open source steward.
END
No: You probably want to step up your organisational maturity. So that your software is generally `fit for purpose’; and some abandonware does not catch anyone of guard by accident. E.g. much like you would not leave a razorblade where a child could find it.
As the CRA was designed to clam down on exactly this type of situation.
END
_______________________________________________
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
