Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-regulatory-compliance] Vulnerability reporting Re: CRA Standardisation request


On 18/02/2025 10:44, Olle E. Johansson wrote:


On 18 Feb 2025, at 10:21, Alex J Lennon via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

Hi all,

Just dipping in - for me as a minor maintainer I can see that there's almost certainly going to be a requirement to spend time on this even if just to be a good opensource actor.

It also worries me  what the (legal and other) ramifications of opensource project stewards getting something wrong on this would look like and what best practice should be.

We can rest assured that getting things wrong will happen quite frequently - what the CRA wants to encourage is a process to fix things as 
we discover them and be transparent about it. File CVEs and if needed, update VEX files. CRA does not ban having security issues in code
but will act strongly if a manufacturer does not fix it in due time.

Also note that stewards != developers. Most open source projects will not have a steward at all, but those that have will have some
sort of support from them and the law includes them in the protection of open source projects.

/O


Very interesting indeed. Thanks very much for the thoughts, insights, and advice Olle, Daniel, Jordan. Lots to think about here.

(I also clocked the comment about not top-posting just in time...)

Thanks all,

Alex


We're out at Embedded World in coming weeks. Is there something like a birds of a feather meeting being organised out there to discuss?

KR, Alex

On 18/02/2025 09:15, Olle E. Johansson via open-regulatory-compliance wrote:
Marta,

I think we need a meeting where we discuss how we think the requirements on reporting affects Open Source and
if there’s a missing mechanism here. Do we need to get engaged in coordinated disclosure and how? 

Do we need to report anything to the ENISA or CSIRT and how? 

If commercial products downstream are certified - how will this affect a project?

For all these issues I think we need to agree on something to communicate to ENISA/Commission. 

In the meeting we had there was also a discussion about abandoned or half-abandoned projects. How do we handle
them if there’s a vulnerability - for a project with a steward and projects without? CISA had a very generous attitude 
that they communicated in the meeting.

So there are a lot of issues to sort out in my point of view.

/O


On 17 Feb 2025, at 17:50, Marta Rybczynska <marta.rybczynska@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Hello all,
I've changed the thread title so that we can distinguish this stream.

Following today's SIG meetings, what are the points of concern of the EUCC today? 

We have listed the massive coordinated vulnerability disclosure between multiple projects (aka log4j case). Anything else?

From my perspective, there's the whole recommended delay timeline and of course it includes all notifications and loops with the certification authority. However IMO overall this is not worse than the BSI document.

Kind regards,
Marta

On Mon, Feb 17, 2025 at 12:56 PM Steffen Zimmermann <steffen.zimmermann@xxxxxxxx> wrote:
Hi all,

the Commission stated last week that a study by ENISA will soon be published on how EUCC can work with the CRA. 

Viele Grüße,
Best Regards,

Steffen Zimmermann
Industrial Security @ VDMA

…sent from my mobile phone, please excuse any typos

Am 17.02.2025 um 10:50 schrieb Marta Rybczynska via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>:




On Mon, Feb 17, 2025 at 9:25 AM Olle E. Johansson <oej@xxxxxxxxxx> wrote:


On 17 Feb 2025, at 09:19, Marta Rybczynska <marta.rybczynska@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Yes, the EUCC applies to third party certification, but it mentions the CRA. Also it makes sense to have the vulnerability reporting process the same in both cases, as there is no reason (IMO) to make them different.
I think the requirements are different. For certified products (in this document) there seems to me like there’s a requirement to report all vulnerabilities. For the rest of products there’s a requirement to report exploited vulnerabilities. I have to read this doc again to understand the details, but there’s discussions about re-certification. I remember discussions with Enisa a long time ago where they clamed that all vulnerabilities in an SBOM would be non-compliance. The doc doesn’t discuss VEX files where a vendor can report their triage results either.

Again, clarification would be good. I may be totally wrong :-)

You're right, in the CC (Common Criteria) scheme there's a need to report vulnerabilities to the certification issuer. There are also expected timelines for various severities. I find it also interesting that they describe in detail the process of confirmation of a vulnerability: not everything reported is considered a vulnerability. This could be useful as an example for the CRA-related processes.

However, the general flow of the process is what we see in security processes typical to open source projects.

One thing I'm missing in the EUCC vs CRA is the clear mention of notifying the upstream, if the issue is in a different product.
 

Also, some open source components with their processes may (and do) end up as components of certified solutions. Common requirement would make the process easier for everyone.
Yes, that’s a concern. How would that affect the relationship between the vendor and the project? 
<room for discussion>

This is something that is already happening. CC certifications have been there for years and of course they include products with open source components.

The innovation of the CRA is that it forces reporting upstream. From what I know, this is not the case with CC.

Kind regards,
Marta
 

/O

Kind regards,
Marta


On Fri, Feb 14, 2025 at 9:03 AM Olle E. Johansson via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
Note that this does not apply to all products affected by the CRA, only the small percentage that are in the classes important and critical and need third party certification. 

/O

On 13 Feb 2025, at 20:10, Dick Brooks via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

FYI: February 2025 EUCC endorsement of vulnerability disclosure management practices is consistent with US adoption of IEC 29147:2018. Harmonization of cybersecurity vulnerability management practices following IEC 29147:2018 would be good, IMO; https://certification.enisa.europa.eu/publications/eucc-guidelines-vulnerability-management-and-disclosure-and-eccg-opinion_en
 
FYI: The CISA Software Acquisition Guide recommendations for vulnerability management are consistent with this latest guidance from Europe (February 2025): 
 
The holders of EUCC certificates should use the following standard for the general guidelines related to vulnerability disclosure: 
• ISO/IEC 29147:2018 Information technology - Security techniques - Vulnerability disclosure.
 
Here is the CISA Software Acquisition Guide language that aligns with this EUCC guidance: (https://cisa.gov/sag) 
 
NIST SP 800-161r1 RA-5 and “NIST Guidance” as specified in OMB M-22-18, call for the issuance of vulnerability disclosure reports (VDR) as an attestation showing that a software supplier has checked each component in a software product SBOM for vulnerabilities and reports the status of each vulnerability discovered, following recommendations for coordinate vulnerability disclosure programs contained in IEC 29147:2018. A VDR is a machine-readable artifact and is considered a “product centric” artifact. A VDR is issued simultaneously with a SBOM at product release and remains online as a living document. It is updated by the software supplier when new vulnerabilities affect the product to which the VDR is attesting. This enables a consumer to know if the software product is affected when a new vulnerability is reported.
 
NOTE: NIST has renamed “Vulnerability Disclosure Report” to “Vulnerability Advisory Report” in SP 800-161r1-upd1 to align more closely with IEC 29147:2018 vernacular and eliminate any confusion with a “vulnerability report” that researchers produce and submit to software suppliers. NIST VDR/VAR are produced by software suppliers and provided to software customers to inform of any vulnerabilities in a software product. NIST recommends that software suppliers ensure that SBOM’s and vulnerability advisory reports are maintained and aligned:

Enhancing Capabilities

  • Ensure that third-party suppliers continuously enrich SBOM data with a VAR.
  • Acquiring entities should develop risk management and measurement capabilities to dynamically monitor the impacts of SBOM-related VARs. Acquiring organizations should align with asset inventories for further risk exposure and criticality calculations.[5]
 
 
Thanks,
 
Dick Brooks
<image007.png>
  
<image008.png>
 
<image009.png>
Active Member of the CISA Critical Manufacturing Sector, 
Sector Coordinating Council – A Public-Private Partnership
 
Risk always exists, but trust must be earned and awarded.™
Tel: +1 978-696-1788
 
 
From: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Tobie Langel via open-regulatory-compliance
Sent: Thursday, February 6, 2025 6:23 PM
To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Tobie Langel <tobie@xxxxxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] CRA Standardisation request
 
The final request has been published by the Commission and is available here: https://ec.europa.eu/transparency/documents-register/detail?ref=C(2025)618&lang=en
 
--tobie
 
On Mon, Feb 3, 2025 at 12:08 PM Steffen Zimmermann via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
Hi all, 
 
look here for the CRA SReq (not yet published):
 
 
Mit den besten Grüßen,
 
Steffen Zimmermann
Industrial Security @ VDMA
 
 
Von: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> Im Auftrag von Simon Phipps via open-regulatory-compliance
Gesendet: Montag, 3. Februar 2025 11:07
An: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Simon Phipps <webmink@xxxxxxxxxxxxxx>
Betreff: Re: [open-regulatory-compliance] CRA Standardisation request
 
Yes, Felipe mentioned the OSR was due to be published today.
 
{Terse? Mobile! Typo? Dictated!}
 
On Mon, 3 Feb 2025, 10:57 Lars Francke via open-regulatory-compliance, <open-regulatory-compliance@xxxxxxxxxxx> wrote:
A representative from the commission said at FOSDEM yesterday that they hope for the final request to be published this week.
 

I think he mentioned it is on the agenda today but I might misremember that part.

Lars Francke <lars.francke@xxxxxxxxx> schrieb am Di., 28. Jan. 2025, 20:33:
Hi Steffen, everyone,

yes, that's the latest draft that was circulated in December which
could be commented on until January 20. It also said "This is a formal
step to endorse the draft standardisation request, and as such
modifications are not expected during this process." so I don't expect
any differences but the final one has not been published as far as I
can tell.

Cheers,
Lars

On Mon, Jan 27, 2025 at 3:42 PM Steffen Zimmermann via
open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>
wrote:
>
> Hi,
>
>
>
> find the SReq here (published in December):
>
>
>
> https://draftable.com/compare/CUdwceoGvyYS
>
>
>
> Mit den besten Grüßen,
>
>
>
> Steffen Zimmermann
>
> Industrial Security @ VDMA
>
>
>
>
>
> Von: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> Im Auftrag von Tobie Langel via open-regulatory-compliance
> Gesendet: Samstag, 25. Januar 2025 14:44
> An: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
> Cc: Tobie Langel <tobie@xxxxxxxxxxxxxx>
> Betreff: Re: [open-regulatory-compliance] CRA Standardisation request
>
>
>
> Thanks Lars,
>
>
>
> That matches my understanding too: afaik, things are moving forward but an updated draft hasn't been made publicly available nor has the finalized text been published.
>
>
>
> --tobie
>
>
>
> On Sat, Jan 25, 2025 at 2:36 PM Lars Francke via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
>
> I don't have time to go to all the meetings and read all the documents but from my understanding we (ESOs) had until 20 January to comment/vote on the last draft item.
>
> Some work has already been distributed between CEN and ETSI, not all of it is clear yet as far as I know. Some experts are still missing for some of the vertical standards I think.
>
> But we got to vote on a few NWIs already (New Work Items): https://boss.cen.eu/reference-material/guidancedoc/pages/tcnewwi/
>
>
>
> I honestly have trouble navigating the whole process still but the summary is: No final "SReq" yet but it's all going according to plan.
>
>
>
> Simon Phipps via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> schrieb am Sa., 25. Jan. 2025, 14:17:
>
> As far as I am aware it has still not actually been finalised and issued to the ESOs, but someone may know better than me.
>
>
>
> S.
>
>
>
>
>
> On Sat, Jan 25, 2025 at 1:11 PM Andrew Katz via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
>
> Hi All
>
>
>
> A quick question: I’ve managed to the find the draft standardisation request from the European Commission for the 41 (?) standards under the CRA. Presumably this text was finalised at around the same time as the Act was published in the OJ. I’ve tried looking, but have yet to find it. Does anyone have a copy or a link?
>
>
>
> This is all I have: https://ec.europa.eu/docsroom/documents/58974
>
>
>
> All the best
>
>
>
>
>
> Andrew
>
>
>
>
>
>
>
>
> Andrew Katz
> Orcro Limited
> +44 20 7170 5943
> +44 7970 835001
> orcro.co.uk
>
> 86-90 Paul Street, London, EC2A 4NE, UK
>
>
> Orcro Limited is a limited company registered in England and Wales under Number 11173406. Registered office is c/o Saffery, St John’s Court, Easton Street, High Wycombe, Buckinghamshire, England, HP11 1JX. VAT number: GB 289 7831 32. Orcro Limited is not regulated as a law firm and does not provide legal advice. Individuals’ qualifications are as set out in their bio page. Reference to an individual as a lawyer, solicitor or paralegal does not mean that they are acting in that capacity as an Orcro staff member.
>
> Data protection: we process your personal data to keep in touch with you, to carry out work for you or your organisation, for internal administration (including employment) for regulatory purposes and for limited marketing purposes (for which you can require us to stop at any time). For more information see https://orcro.co.uk/privacy-summary/ or contact team@xxxxxxxxxxx
>
>
>
> _______________________________________________
> open-regulatory-compliance mailing list
> open-regulatory-compliance@xxxxxxxxxxx
> To unsubscribe from this list, visit https://accounts.eclipse.org
>
>
>
>
> --
>
> Simon Phipps
>
> Supporting Software Heritage at ORC
>
> Meshed Insights Ltd.
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
_______________________________________________
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

_______________________________________________
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


_______________________________________________
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

Back to the top