Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-regulatory-compliance] Now that technical standards work has been initiated - some material for consideration
Luis is correct, yes.

The work has started already in 2023 when the JTC 13 WG 9 was formed. I wasn't part of it back then but from what I gathered the work back then was mostly discussions and clarifications etc. and not actual writing of documents.
In "summer 2024"  the work kicked off by splitting into three project teams to focus on different things (risk assessment, generic security requirements and vulnebality handling).

I have not yet received an official answer on whether I'm allowed to share any documents but I assume the answer is going to be "no" anyway.

As far as I can tell the standards will not contain any major surprises.
There will be a public enquiry around the standards later this year where everyone has a chance to comment via their national bodies.

One thing you might want to do ist to prepare for that commenting period. At least in Germany it requires you to sign up for an account and send a physical letter to DIN to finish your registration. So, if you're interested it may be worth to set up accounts etc. ahead of time. This'll be different in every country: https://www.din.de/de/mitwirken/entwuerfe

Cheers,
Lars

On Sun, Feb 9, 2025 at 6:56 AM Luis Villa via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
Somewhat high-level comments, Dick:
  • My understanding is that despite formalities only having been completed this week, the work is already well underway for at least some of the standards (i.e., there are drafts already being circulated and worked on). Others here are on some of the relevant committees and may be able to provide more detail.
  • The working groups for the standards are through various EU standards bodies, so while nominally "open" it is hard for non-EU companies/individuals to participate. I opened a question/issue to reflect this; no answer yet in GH but I know some of the knowledge is in the heads of list members: https://github.com/orcwg/cra-hub/issues/61
  • I am not sure if it makes sense to use this list to coordinate on feedback from non-participants—there's a lot of feedback to give and I wonder if it might overwhelm other list efforts.

On Sat, Feb 8, 2025 at 9:07 AM Dick Brooks via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:

Hello Everyone,

 

Now that the EU CRA Technical Standards work has begun I wanted to share some information for consideration.

 

This is not a proposal, it is simply to raise awareness of some existing technical recommendations for software manufacturers to follow when selling products to the US Government produced in a public-private partnership under DHS CISA by the ICT_SCRM Task Force membership;

https://www.cisa.gov/ict-scrm-task-force-members

 

Guide: https://www.cisa.gov/sites/default/files/2024-07/PDM24050%20Software%20Acquisition%20Guide%20for%20Government%20Enterprise%20ConsumersV2_508c.pdf

Spreadsheet: https://www.cisa.gov/sites/default/files/2024-08/PDM24064%20Software%20Acquisition%20Guide%20for%20Government%20Enterprise%20Consumers%20Final-%2020240710_v19.xlsx

FAQ: https://www.cisa.gov/sites/default/files/2024-10/ICT%20SCRM%20Task%20Force%20Software%20Acquisition%20Guide%20Fact%20Sheet%20%28508%29.pdf

 

Additional information is provided by the US NASA regarding their SCRM software risk assessment processing expectations:

https://www.nasa.gov/secure-software-development-self-attestation-resources-and-knowledge/

 

The EU CRA identifies technical expectations such as SBOM and vulnerability disclosure reporting, which overlap with expectations identified by the US CISA organization for Secure by Design and Secure by Default implementations in its Software Acquisition Guide for US Federal Agencies to procure and use only trustworthy software products. https://cisa.gov/sag

 

With regard to SBOM requirements:

 

With regard to Vulnerability Management requirements, including before a product is released to market and ongoing notifications:

 

The CISA spreadsheet artifact was designed to acquire software vendor insights into Secure by Design and Secure by Default technical practices followed by a software supplier.

 

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

 

 

_______________________________________________
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