cross-posted from: https://feddit.org/post/19584461
This might not be obvious at first, but it is not only relevant for individual open source contributors, but highly relevant for any companies which sell open-source based software, or any other software, or software-based devices to with in the European Union: In future, they will have to guarantee the security of their products, regardless of which software supplies they use.
As long as a project is not organized as a legal or commercial entity, the CRA requires only a basic "readme" with a security contact. There is no legal risk for individual contributors simply sharing code online or in publications, even when they receive payment for writing an article, as long as the software itself is not monetized or organized.
[ ...] the CRA's focus is on commercial manufacturers and distributors. That means businesses that integrate open source code into EU products must fully comply with documentation, incident response, and lifecycle management requirements. This includes publishing Software Bills Of Materials (SBOMs), patching vulnerabilities within regulated timeframes, and responding proactively to security incident reports.
[...] manufacturers must act on vulnerabilities, even if the upstream maintainer does not fix the issue. Manufacturers selecting open source code for their products must understand the code, support it, and respond to regulatory reporting requirements. This may, Kroah-Hartman observed, increase pressure on companies to use actively supported open source projects or stick closer to mainstream, well-resourced communities."
[...] it's coming soon for companies. Manufacturers are going to care in September of next year. They're going to start panicking in the summer of next year, and things are going to start hitting the fan."
They'll want developers to shoulder the burden the CRA will place on them. But you don't have to do that. It's their problem, not yours as a programmer.
The overworked maintainers of Libxml2, ImageMagick, or contributors to such industry-wise important things as the real-time kernel patches, might enjoy to read this.
Practical example: Libxml2 is not a for-profit project with a sole unpaid developer as a maintainer. Its future license is GPLv3, so it is free to use for Linux users. But if, say, Apple continues to use libxml2 in products they sell, they have to provide security fixes (and, because of the license, they have to provide the fixes back to the project because it is GPLv3). It is not the responsibility of the libxml2 project to develop the fixes, because they are not selling a commercial product: The buck stops at the companies using it.
I think it makes sense that publishers are required to update or at least assess games when open security issues come to their attention.
The current state is that you may have 20 games installed and 10 have not been maintained for a long time, and 5 have open security issues that an attacker may use. For example, a game launcher with service installs to program files with admin permission. And suddenly, you have a privilege escalation.
Or a game, when run, pulls in some monitoring, and suddenly exfiltrates data because that service is defunct and was taken over, or hacked.
The necessity is quite clear.
Maybe this will also push us towards more stable software, that changes less, or has less attack or escalation surface. That could significantly reduce maintenance burden - even if it ends up only assessing reported open vulnerabilities not affecting your product (because you don't make use of or open up the vulnerable functionality).