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.
Hopefully this will have the side effect of pushing companies to offer payment to maintain and develop projects they depend on.
Hmm.
So for some software, you can just increase the price.
But…I wonder what that will do to the cost of video games. Typically, those are closer to one-off releases, not packages where new releases exist and are regularly purchased or subscriptions are in place.
I’d expect this to increase the cost of maintenance, if there are legal obligations on publishers to monitor, notify, and deploy security fixes for their software and upstream. You’d think that it might encourage vendors to EOL software sooner; pull it off Steam or the like, mark as no longer supported.
Maybe there are some exemptions somewhere that affect those.
The requirements on security of course depend on the application. It makes a difference whether defects in software can cause the electric grid to fail, cause a car to crash, cause a hospital’s surgery room to stop working, or a factories assembly line, cause payment systems or the entirety of public life to stop, or merely crash your gaming PC.
Still, the trend is clear: Software is a product like any other, and if you pay for it, the vendor has to guarantee it works.
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).
Sounds like a win for FOSS, but I shudder to think how they* will manage to twist this.
* corporate they
Who is ‘they’?
It’s certainly easy to imagine various companies and people demanding FOSS maintainers handle this stuff for them. Like the article suggests, as well.
It’s certainly easy to imagine various companies and people demanding FOSS maintainers handle this stuff for them. Like the article suggests, as well.
Yeah but nobody has to do that. And why should one?
