Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-regulatory-compliance] CRA Standardisation request
On Mon, Feb 17, 2025 at 1:36 PM Dick Brooks via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

Olle,

 

People have expressed concerns while attempting to implement VEX. See this 5 minute video clip from Cassie Crossley regarding Schneiders attempts to use VEX:

226000 VEX records would have to be issued just to respond to the  Log4J vulnerabilities:

https://www.youtube.com/watch?v=j9MB7oaq8aI&t=3634s


If they have found out that 226.000 of their product versions are not affected then that's awesome and I'd love to know that as a customer. I don't see the issue to be honest.
What am I missing?
 

VEX would be problematic to implement.


For some maybe, but that is not a generally true statement.
If you did the work to evaluate that you are not affected by a vulnerability you can publish a VEX stating so. It's not that difficult.

"Absence of evidence is not evidence of absence."
And if possible I'd absolutely love to have evidence of absence. Some of that I can gather myself by e.g. using SBOMs

If I were somehow forced to issue a not-affected statement for EVERY CVE that is out there then...yes, that'd be a lot of work but if you get a CVE for something you have in your SBOM, you check, find you're not affected and put out a not-affected VEX then that shouldn't be too hard.

Cheers,
Lars


 

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 Olle E. Johansson via open-regulatory-compliance
Sent: Monday, February 17, 2025 3:26 AM
To: Marta Rybczynska <marta.rybczynska@xxxxxxxxxxxxxxxxxxxxxx>
Cc: Olle E. Johansson <oej@xxxxxxxxxx>; Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] CRA Standardisation request

 

 



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 :-)

 

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>

 

/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

   

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

Back to the top