Brian, IMO, you have identified the xyzzy that we all seek – please tell us what evidence is required to comply with the EU-CRA as an open-source steward. THEN, if we are “classified” as an open-source steward we will know what is expected. If the following artifacts are sufficient evidence for an open-source software steward to comply, then Business Cyber Guardian (BCG) is ok being classified an open-source software steward with regard to the EU-CRA: - An SBOM in a standard format (SPDX or CycloneDX), ideally JSON representation
- An open source living “Vulnerability Disclosure Report” (VDR) showing that a party is checking for vulnerabilities before market release and throughout the life cycle of a product; NIST VDR preferred
- An artifact containing vendor and product information, i.e. a Vendor Response File (VRF) containing Support status and commercial status, demonstrated at an IETF hackathon in 2023
- An attestation showing adherence to secure software development practices that implement “Secure by Design” and “Secure by Default” practices, per EU-CRA requirements
- A final Risk Assessment Report
If this represents the “entire set of expectations/obligations” for an open-source software steward, per open-source product, then BCG can accept being classified as an open-source software steward. 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: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Brian Fox via open-regulatory-compliance
Sent: Tuesday, January 7, 2025 9:27 AM
To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Brian Fox <brianf@xxxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] A more positive take on CRA FAQs and flowcharts I'm sorry too. I'm getting a bit touchy because I see no progress.
Everybody is asking questions but this group is supposed to prepare the
answers - "to guide and support compliance". At least that's what I read
on the website. We will not get any answers about compliance by asking
the same questions over and over again.
Dirk-Willem gave answers by proposing a FAQ text and I gave answers by
proposing a different text (which, understandably, nobody liked).
Everybody else is just asking variants of the same question. But all of
us need to work on answers!
I think many people understand this, but watching the back and forth, I feel the need to say this "out loud": Many parts of the legislation are very unclear, especially around open source and commercial intersections, and further, there are new definitions of who plays what role when (manufacturer vs steward). This isn't new information, and, as was discussed a lot during the drafting phases, somewhat misinformed and somewhat intentional... trying to close loopholes that, IMO, didn't need to be closed. As a result, it's likely impossible to give the definitive answers that engineering types want until lawsuits and subsequent case law define things more clearly. In other words, we can look at the words of things and "know" that they are illogical and substitute our sensible judgment on what they're supposed to mean, but until cases are filed and settled, they will remain murky. That murkiness will ultimately harm the community, as we've seen with some of these contributors "opting out." Very little can be done in the interim to clarify these ambiguities. Now, what we can be more precise about is if you assume the worst case and you are a manufacturer, how can you be compliant? What standards are used to measure? These things are tractable, IMO, and can be a short-circuit evaluation. E.g., Even if you can't figure out if you are "out of scope" or a steward or a manufacturer if you assume the worst, do these things, you're covered, and then it doesn't matter what role you are in. We should be able to do this part of the work. Am 06.01.25 um 07:55 schrieb Marta Rybczynska:
> Dear Ilu,
> It looks like I have touched a sensitive subject, sorry for that.
I'm sorry too. I'm getting a bit touchy because I see no progress.
Everybody is asking questions but this group is supposed to prepare the
answers - "to guide and support compliance". At least that's what I read
on the website. We will not get any answers about compliance by asking
the same questions over and over again.
Dirk-Willem gave answers by proposing a FAQ text and I gave answers by
proposing a different text (which, understandably, nobody liked).
Everybody else is just asking variants of the same question. But all of
us need to work on answers!
Agreed. Hopefully our move to GitHub will help facilitate this. > I was thinking *only* about the situation of a project without a formal
> organization behind it,
> that does not have stable funding, developers doing their work mostly on
> volunteer basics.
> Every single one of us knows such projects.
>
> My impression was that this was the main subject that has been discussed
> over the last few days.
>
> For me personally, it seems to put all the manufacturer obligations on
> those who use their
> code in commercial products.
Yes, that is the intention. But there is a big grey area around the
"commercial" criterium and we don't know the outcome yet. And PLD is on
the horizon. There is a lot of good security related best-practice stuff
in CRA which even small projects can start on, if they prioritize it -
no matter whether they are in or out of CRA. Sticking with best
practices is always good.
The intended high-level purpose of the CRA is to steer the overall industry towards healthier security practices. This is something we ought to be aligned with as a community. The message shared by the European Commission on a regular basis is that we can have substantial impact shaping how this plays out through various means. So it's really up to us to drive the implementation of the CRA towards outcomes that are both meaningful in terms of improving our overall security posture and reasonable given available resources and the nature of how open source is developed. An important aspect of the implementation of the CRA is the guidance described in Article 26 which must have a "particular focus" on "free and open-source software." The questions we collect in our FAQ and the answers we tentatively provide (as much as those where we don't have good answers and that we should clearly identify as such) is extremely valuable input for this guidance. These security related requirements are also those that are relevant for
software stewards. That's what we need to help with. F.e. with a list:
What stuff should I start with for compliance?
> And I wasn't talking about the 'beta' versions. I was talking about the
> 'intended purpose' as in
> Annex II.
Yes, that information has to be provided if you are in scope of CRA. But
it does not determine whether you are in scope or not.
> I think that the 'intended purpose' has a big role to play, because this is
> the way I envisaged
> use for educational software that contains security issues to be found and
> fixed by students.
I'm not exactly sure what type of "educational software" you mean but
I'm sure that schools and students are generally a group that CRA is not
intended for. But a teacher could also have a side business or the
university could have a startup incubator (I know several that have) and
suddenly you are back in grey area. It always needs careful assessment
of the individual situation.
Increasing legal certainty for economic actors is part of the goals of this legislation (see for example Recital 4). The kind of uncertainty described above goes against this goal. This needs to be clarified through guidance. Our best opportunity to have impact here is to (1) clearly spell-out the areas of uncertainty, (2) spell-out what the ideal outcome would be that is aligned with the intended overall purpose of the CRA, (3) provide this as input to the Commission for the Guidance, and (4) hopefully obtain clarification before the guidance is out so that we can increasingly proceed on firmer ground. > And I have read the CRA multiple times.
I'm sorry that I implied differently. I understand that it is an
extremely difficult read and in parts impossible to make sense of.
That's exactly why I'm warning to come to any conclusions of the "I'm
out of scope" type. Only time will tell who the EU authorities consider
to be in scope. And don't forget about PLD.
Regardless of whether you're formally in scope or out of scope of the CRA, the CRA (and other upcoming legislation worldwide) will impact your project if said project is used in products or services that end up in the hands of consumers and businesses. Indeed, manufacturers have a due diligence obligation here, defined in Article 13(5), and so facilitating this requirement will quickly become a standard practice (much like adding a license to your repo is) or a differentiator between projects. Worth noting that the CRA also offers an opportunity for manufacturers to foot part of the cost of shifting security left through the attestation program defined in Article 25.
Our best bet here is to make sure that the impact of the CRA is minimal in terms or resources, sound in terms of improving project's security posture, and potentially a vector of improved resourcing for the projects that do.
In summary, we need to: - Improve our collective understanding of the CRA and spread that understanding across the community. This is best done through our FAQ effort.
- Identify areas that lack legal certainty and flag them with the Commission. Tracking a way to do so here: https://github.com/orcwg/cra-hub/issues/5
- Identify the elements that manufacturers will rely on to exercise their due diligence requirements defined in Article 13(5) and collect relevant best practices. As a start, I suggest leveraging the dedicated section I just added to our inventory.
- Explore the opportunities provided by the attestation program described in Article 25 and identify related efforts (like FreeBSD's SSDF attestation program). Here again, I believe collecting relevant resources in the inventory is a good first step.
Hopefully these suggestions will help address our shared desire to make progress and stand on firmer ground. Happy to discuss all or any of the above further. _______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
-- Brian Fox Chief Technology Officer | 
| |
|
