|
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:
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
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
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
Hi all,
look here for the CRA SReq (not yet published):
Mit den besten Grüßen,
Steffen Zimmermann
Industrial Security @ VDMA
Yes, Felipe mentioned the OSR was due to be published today.
{Terse? Mobile! Typo? Dictated!}
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.
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
|
