Cyber Resilience Act

[Gregor Mückl]

Hi!

I want to quickly bring up a topic that is certain to annoy 
everybody. I'm sure of it.

The European Union has passed the Cyber Resilience Act (CRA) a 
while ago, which imposes regulatory requirements on software 
distributed in the European Union. The implementation is in 
phases and right now, only the mandatory reporting of exploitable 
vulnerabilities in effect since 11. September. But starting 11. 
December 2027, software distributed in the EU may need to undergo 
a certification process to ensure that the product fulfills 
certain minimum security standards.

The whole thing is described in detail here: 
https://www.cyberresilienceact.eu/index.html

The short version, as I (not a lawyer!) understand it, is as 
follows:

Software falls under the certification requirement as soon as 
certain features are present. For example, the mere ability to 
communicate over a network triggers the requirement. So, if your 
software contacts a server to check if a new version is 
available, you've overstepped that boundary already. There are 
other criteria, and they split software into four broad 
categories:

- Critical: secure hardware with "digital elements" like smart 
cards, card readers etc.
- Important, class 2: firewalls, hypervisors, tamper-resistant 
microcontrollers/microprocessors
- Important, class 1: operating systems, browsers, identity and 
access management, password managers, malware scanners, network 
management and a couple more categories
- Default: most business software, games, etc...

The default category of software, which is the broadest category, 
is allowed to undergo a self-certification process. The other 
categories must be certified by an external named body.

Certification is only possible with a bunch of documentation 
describing how security is achieved and maintained in the 
product. This stuff needs to be written, even when 
self-certifying. There are some requirements for what that 
documentation has to cover. There are both technical and 
non-technical (process) parts.

Open source software is not fully exempt, although the 
requirements are very different and, arguably, much more lax. I 
think that for most serious open source projects, this should 
come down to providing a solid reporting and handling process for 
security vulnerabilities. Many other requirements shift to 
whatever commercial entity makes use of open source components.

It seems really, really hard to avoid the CRA entirely while 
retaining to the right to distribute software in EU member 
states. The implications of this, as I understand them, are 
twofold:

- The D Language Foundation may be potentially subject to the 
rules for open source stewardship. This should be checked before 
the deadline, probably by persons that are more knowledgeable 
than I am right now.

- Commercially distributed software that uses D is very likely to 
fall under the certification requirement. Those developers will 
have to document how they use D and its libraries to make a 
secure product.

Are there already plans in place to evaluate how the D Language 
Foundation is affected and how to adjust? I suspect that this 
will require a whole lot of reading and a few minor policy 
changes at most.

Finally, and probably more controversially, is there any interest 
in building documentation that helps users of D go through 
certification? This could be in the form of a brief manual that 
outlines how D code can be written and compiled to avoid certain 
classes of security vulnerabilities (GC: no use after free, 
bounds checking: no buffer overflows, etc.) as well as outlining 
how e.g. the networking features in Phobos are implemented 
securely. Doing this collaboratively in the open may help lessen 
the load for each individual team out there a little.

Gregor

PS: please keep this discussion focused. Complaining about things 
like "EU overregulation" is not a productive contribution. If you 
feel the urge to vent, please start a separate thread.