The European Cyber Resilience Act
The European Cyber Resilience Act
Posted Sep 20, 2023 3:58 UTC (Wed) by wtarreau (subscriber, #51152)Parent article: The European Cyber Resilience Act
Software development in EU might be living its last few years.
Posted Sep 20, 2023 12:16 UTC (Wed)
by corsac (subscriber, #49696)
[Link] (12 responses)
Posted Sep 20, 2023 22:51 UTC (Wed)
by neggles (subscriber, #153254)
[Link] (11 responses)
> Products provided as part of the delivery of a service for which a fee is charged solely to recover the actual costs directly related to the operation of that service [...] should not be considered on those grounds alone a commercial activity.
That sounds like an out for SaaS to me.
Posted Sep 21, 2023 6:15 UTC (Thu)
by znix (subscriber, #159961)
[Link]
Posted Sep 25, 2023 15:44 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (9 responses)
In other words, if I provide a bunch of download servers, which distribute stuff (product) other people supply, no liability attaches to me.
Think a delivery operation, like eg Federal Express. Okay, I guess they have a duty of care to avoid distributing illegal stuff like drugs, but for the most part they are the courier with no obligations beyond safely moving stuff around. Said "stuff" is for them an opaque box.
So if a distro merely packages upstream (yes I know distros typically do more :-) and distributes it, then they are free to run that as a business without incurring liability.
So what we need is the clear chain that says the writers are under no obligation because they provide it with no warranty. The distributors are under no obligation because they are merely aggregating everything into a convenient package.
Liability needs to start at the point a "manufacturer" includes this stuff in a PHYSICAL product. Because it's at that point the RISK also really starts.
Who cares if my pet project is vulnerable as hell? So long as it's just me, it's the same liability as the lone inventor tinkering in his shed with things like gas bottles. Any disaster will be localised, and I'll bear the brunt of it.
Even if I start distributing it, the user-base will be small, and the blast radius insignificant. But if a manufacturer spots my product and "places a product on the market" (as per the blue book, I think it is), this is where the blast radius becomes significant, and this is also where the CRA needs to bite.
One of the simplest ways to protect the small-time coder would be the rule "No contract? No transfer of liability!" Then in, let's say, pizza's case he can warrant that his software will behave to spec, and if it doesn't he'll fix it. If the spec is wrong, not pizza's problem. If there is a vulnerability, pizza gets to fix it. It's the product manufacturer's responsibility to get that bugfix to their customers in a timely manner - indeed - to have a manner of issuing bug-fixes!
(Oh, and I don't think pizza needs to worry about manufacturers saying "go download this software from over there". If the product needs the software to function, and the software malfunctions, that's "not fit for purpose", which brings a world of hurt on its own.)
If manufacturers want to graze the software commons, they accept the liability that comes with accidentally picking poison mushrooms ...
Cheers,
Posted Sep 25, 2023 15:59 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
SaaS *would* be covered by the CRA. They aren't just providing you with a copy of a piece of software that they got from someone else, They're providing you with a whole lot more. It's not a case of "you can get that from anywhere, we just provide it all neatly packaged".
Think the difference between an editor and a printer. Give your book to a printer, and you get back multiple copies of your book. all identical copies of the original you handed over. Give it to an editor, and you get *roughly* the same thing back, with (hopefully) the grammar and punctuation cleaned up, the layout redone, a nice professional cover, etc etc.
One company learned the difference between a printer and an editor the hard way. My English master sent the school magazine to them to PRINT. They promptly reset it in their own house style, and then expected to be paid. The English master had a fit and refused point blank. When the printers threatened to sue he pointed out they didn't stand a hope in hell of winning because, if they were PRINTing what he'd sent them, the goods were not what he asked for and not fit for purpose. And if - as they had - they took it upon themselves to edit it, they took upon themselves the risk it would be a flop, as it was, as the English master refused to pay.
Oh - and not fit for purpose. It was a SCHOOL magazine. And the School's definition of "correct" English was the relevant Local Exam Board - Oxford, as it happens. The printer's house style was, according to the exam board, "wrong", and would have cost the students marks had they copied it.
Cheers,
Posted Sep 25, 2023 22:51 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52022PC0454
You need BOTH documents on that page, they work together.
SaaS is NOT covered. The CRA defers to a new, yet-to-be-written, similar Regulation or Directive. That Regulation/Directive will be similar in spirit to the CRA.
Cheers,
Posted Sep 28, 2023 11:38 UTC (Thu)
by kleptog (subscriber, #1183)
[Link]
I do encourage people to do this. The original article above actually links directly to the original version (first link) and the amended versions by the Council[1] and Parliament[2] (under current state), so you can get an idea of where this is heading.
If nothing else, read just the recitals that come before the articles. While not explicitly legally binding they do provide guidance as to the how and why of the Act. They are written in straight-forward English and in the case of any ambiguity, the recitals make the difference. They also go into way more detail about how this is intended to work.
If you're into software design, the recitals are the equivalent of requirements & use cases.
Repeating the links in case people missed them.
[1] https://data.consilium.europa.eu/doc/document/ST-11726-20...
Posted Sep 25, 2023 16:13 UTC (Mon)
by pizza (subscriber, #46)
[Link] (5 responses)
So in other words, Microsoft will face zero liability for defects found in Windows, as long as they don't supply any hardware.
>Who cares if my pet project is vulnerable as hell? So long as it's just me, it's the same liability as the lone inventor tinkering in his shed with things like gas bottles. Any disaster will be localised, and I'll bear the brunt of it.
Are you really sure that you don't care that you "bear the brunt of it"? After all, we're talking about potential financial ruin here, with no upside.
> (Oh, and I don't think pizza needs to worry about manufacturers saying "go download this software from over there". If the product needs the software to function, and the software malfunctions, that's "not fit for purpose", which brings a world of hurt on its own.)
Are you sure about that? That just means the hardware "purpose" will get dialed way back until all it's legally "fit" for is along the lines of "it takes up space, blinks a couple of lights, and won't electrocute you." And if you want it to do anything more, you'll have to look elsewhere for the software. Not unlike today when you can buy a motherboard or even a complete barebones PC without any OS. It's no longer a "complete product" but a "kit" that requires the user to assemble or otherwise complete. And the user bears all responsibility for the consequences.
Posted Sep 25, 2023 17:17 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Liability starts at the point something is included in a physical product today. The point of the CRA is to push liability backwards down the chain until either you get to a creator, or you leave the world of commercial relationships, and to add liability for things that occur "in cyberspace".
So, in a CRA world, Microsoft is liable for defects in Windows, because you can't get Windows legally via any route other than a commercial deal with Microsoft. Similarly, hardware makers are liable for the software they include with the hardware, and for ensuring that the hardware is supplied with sufficient software to make the hardware useful for the claimed purposes of the system. This means that if I sell you a "car", it's got to function as a car - and if you have to install software to make it function as a car, then I'm required to bundle that software with the car (and thus be liable for it). I could sell you a "kit of parts" that you need to assemble, but then I can't do anything that might make you think I'm selling you a car, just a set of parts that don't work for any purpose.
Similarly, in the CRA as it currently stands, me putting my pet project up on GitHub, or publishing it on my website, or selling tapes with the source code on at the cost of the tape plus shipping, does not make me liable for flaws in it. Only the selling tapes is a commercial transaction, and the CRA as it stands has an exception where I'm doing that at cost. If it's awful, and blows up in my face because it's so vulnerable, that's my problem to deal with - I'm liable for the damage my systems do, and it's my code on my systems. But because you have no relationship with me that would make me liable to you for flaws in my code that I gave away for free, without so much as a service contract, if you take a copy of my code and run it, you're still liable for the damage your systems do, and you don't have a relationship that lets you push that liability back to me.
Posted Sep 25, 2023 17:50 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (3 responses)
> So in other words, Microsoft will face zero liability for defects found in Windows, as long as they don't supply any hardware.
So maybe I shouldn't have said "physical". I think MS is a manufacturer and Windows is a "product placed on the market" according to the Blue Book, so as things stand they're liable. And are you sure you don't want things to change? Because that could kill MS' pre-installed monopoly just like that, so that actually could be a good thing. It would mean all of a sudden people would start installing linux left right and centre because they would see the real cost of Windows. :-)
> >Who cares if my pet project is vulnerable as hell? So long as it's just me, it's the same liability as the lone inventor tinkering in his shed with things like gas bottles. Any disaster will be localised, and I'll bear the brunt of it.
> Are you really sure that you don't care that you "bear the brunt of it"? After all, we're talking about potential financial ruin here, with no upside.
And that's different to the current situation how? Given the current propensity of Americans to sue anybody (including foreigners) for anything, I think having a rich American take a dislike to you will leave you facing potential financial ruin whether you're a saint or a devil.
No I'm not downplaying the risks. But life is a game of Russian Roulette, and given that the CRA is a gun that probably won't fire, I've got rather more important things to worry about. Life is a fatal disease, don'cha'no?
> > (Oh, and I don't think pizza needs to worry about manufacturers saying "go download this software from over there". If the product needs the software to function, and the software malfunctions, that's "not fit for purpose", which brings a world of hurt on its own.)
> Are you sure about that? That just means the hardware "purpose" will get dialed way back until all it's legally "fit" for is along the lines of "it takes up space, blinks a couple of lights, and won't electrocute you." And if you want it to do anything more, you'll have to look elsewhere for the software. Not unlike today when you can buy a motherboard or even a complete barebones PC without any OS. It's no longer a "complete product" but a "kit" that requires the user to assemble or otherwise complete. And the user bears all responsibility for the consequences.
And nobody will buy it. Which might be a bloody good thing.
You said something about not being European. Well, Europe doesn't tend to indulge in all these nasty extra-territorial shenanigans that some other countries hint hint like to do. Keep out of Europe, and the CRA can't touch you. Even if it touches your software, the authorities will go after the people who recklessly imported it, not you.
Something I'd like to know. You said the CRA defines you as "offering a product" which makes you a "manufacturer". Where on earth did you find that in the CRA? Because when I was looking, I've mentioned the "Blue Book" before (which someone else here pointed me at), and if you're right and the CRA is trying to redefine the term, I think we're in for a far bigger world of hurt than just computer security. You're looking at this far too much in isolation. As others have said, this interacts with tax law. I've made repeated references to the Blue Book and Consumer Protection legislation.
Yes, there is no upside to being sued. And no there is no defence against some random guy trying to sue you. For ANYTHING. But in any jurisdiction where Equity is important, like the UK, like I suspect most of Western Europe, you'll get off much more lightly than anywhere else in the world.
If some random company sued me under the CRA, my reaction would be to ask the Judge what grounds do they have to sue me, because their suit should be illegal under the slavery acts. So what if that argument doesn't legally fly, if the Judge thinks yes I have a real case, that argument makes sense, said random company is pretty much certain to lose provided I line my ducks up properly. What's worse, they'll probably end up paying for my target practice.
You said your side business enabled you to keep a roof over your head when $dayjob let you down? In other words, your side business saved you from financial ruin? So there's a hell of a lot of historic upside - it's proven it can save you from financial ruin - TWICE. Don't you think a current score of 2-nil says it's worth the risk?
Or are you - like a lot of people actually - so focussed on the pessimistic downside that you'll actually happily ruin your life trying to avoid a possible imaginary disaster? What a STUPID waste.
I can't say there's no risk. But as it says in the Flanders & Swan song ... "here in a nuclear testing ground, is no place to bury your ..." Live for NOW, write PROPERLY DESIGNED software, and try and keep your nose clean. Unfortunately, we all have no control over being dragged into the legal sausage machine, so don't worry about what MIGHT happen (other than to watch out for really stupid laws).
Cheers,
Posted Sep 25, 2023 20:55 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
I don't consider it a good thing if it also destroys the ability for F/OSS projects to accept any sort of commercial funding.
>And that's different to the current situation how?
In my documentation, I explictly state: "This free software comes with ABSOLUTELY NO WARRANTY and is licensed under the GNU GPL (v3 or later); see the 'COPYING' file for more details." And later on, "[this software] may have half-developed features that don't quite work, with giant bugs that come out at midnight to eat your cat."
The social contract underpinning this is that I give this software away freely, but at the same time, you have no recompense if it doesn't work. The CRA changes this implicit contract so that you (and everyone else who downloads that software) *do* have grounds to demand recompense, without giving *me* some sort of proportional benefit.
> Well, Europe doesn't tend to indulge in all these nasty extra-territorial shenanigans that some other countries hint hint like to do.
I assume you've heard of the GPDR? That is explcitly extra-terroritoral. This will need to be as well, or it won't be worth the paper it's printed on.
(Meanwhile, my previous two employers were subsidiaries of European companies, and one involved a lot of travel to the EU. My current employer will probably be acquired by an EU company. So I'm probably not going to escape from this without ditching _something_)
> You said the CRA defines you as "offering a product" which makes you a "manufacturer". Where on earth did you find that in the CRA?
There are several blanket exemptions in the CRA for F/OSS activities, but the act of money changing hands eliminates most of them. Accepting donations to cover costs? That's fine, unless that donation is from a recurring corporate sponsor. (which hits quite a few larger F/OSS projects!) Accepting funds for anything other than covering costs, eg a feature or bug bounty? You're now commercial. Run an actual business that provides servive, support, and other such things? Bingo! It doesn't matter if the money is for software or services, if it's directly related, or even _how much_ revenue you take in that's related to that software. It only matters that you're conducting some sort of commercial activities while providing software, which makes you into a manufacturer with obligations enforced with massive punitive penalties.
Posted Sep 25, 2023 21:59 UTC (Mon)
by kleptog (subscriber, #1183)
[Link]
Eh, no. You're talking about liability and you can only have product liability with respect to someone you have a direct commercial relationship with. Just because you receive some money from someone, doesn't mean suddenly you suddenly have a commercial relationship with everyone in the world. If you don't want to provide any warranty, that's fine. Just tell them that any version not the latest may have security bugs and they must upgrade immediately when there's a bugfix. As an open-source project this is trivial to arrange.
> That's fine, unless that donation is from a recurring corporate sponsor. (which hits quite a few larger F/OSS projects!)
The thing is, most F/OSS projects are not delivering a product to market. They're publishing source code, which isn't a product by itself.
> It doesn't matter if the money is for software or services
Ofcourse it matters. Services are not covered by the CRA, products are. The normal approach with F/OSS is that the software is free and the services are not. So the software is delivered non-commercially as open-source download, together with commercial services. It's probably a good idea to make that clear in your contract.
Now, the Apache Project selling OpenOffice online, that sounds like it might be a problem. Isn't that supposed to be super buggy?
Posted Sep 25, 2023 21:59 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
> I assume you've heard of the GPDR? That is explcitly extra-terroritoral. This will need to be as well, or it won't be worth the paper it's printed on.
Extra-territorial in what sense? How is the EU going to prosecute an American company, or American people? They can prosecute them if they are based in the EU. And it's the EXPORT of the data that matters. (Which is why and how American companies get clobbered, if they export the data of the European employees / customers.) And even for American companies like Google, they are operating in the EU, therefore they have to abide by European law.
In order to break the law, you HAVE to be in possession of personal data belonging to Europeans.
It's like some British sexual abuse laws - they apply to all Brits, no matter where the offence took place. But you need that connection with Britain.
This is very unlike America, where they will extradite Brits for doing stuff - in Britain - that is perfectly legal under British law.
> (Meanwhile, my previous two employers were subsidiaries of European companies, and one involved a lot of travel to the EU. My current employer will probably be acquired by an EU company. So I'm probably not going to escape from this without ditching _something_)
> > You said the CRA defines you as "offering a product" which makes you a "manufacturer". Where on earth did you find that in the CRA?
> There are several blanket exemptions in the CRA for F/OSS activities, but the act of money changing hands eliminates most of them. Accepting donations to cover costs? That's fine, unless that donation is from a recurring corporate sponsor. (which hits quite a few larger F/OSS projects!) Accepting funds for anything other than covering costs, eg a feature or bug bounty? You're now commercial.
> Run an actual business that provides servive, support, and other such things? Bingo! It doesn't matter if the money is for software or services, if it's directly related, or even _how much_ revenue you take in that's related to that software. It only matters that you're conducting some sort of commercial activities while providing software, which makes you into a manufacturer with obligations enforced with massive punitive penalties.
But here you are taking *payment*, YOU HAVE A CONTRACT, because you have a mutual exchange of money for agreed benefits. Whereas if you were taking donations, where on earth does it say that's a commercial relationship? If there's no goods or services agreed going in the other direction, how on earth are they going pin anything on you.
And you STILL haven't pointed at where - in the draft CRA - all this stuff is. Is it because it isn't actually there?
I still can't believe the CRA is trying to redefining the meaning of "commercial transaction" or "offering a product". And if it isn't, then most of what you're worried about is scaremongering.
Cheers,
Posted Sep 20, 2023 12:40 UTC (Wed)
by pizza (subscriber, #46)
[Link]
This will be the most likely outcome, along with completely gutting F/OSS creation and general purpose computing in the EU.
This will increase software (and thus product) development costs by at least an order of magnitude, and will also effectively create a giant step from purely-as-a-hobby-with-no-obligations to manufacturer-under-the-CRA-with-full-obligations, with no middle ground.
Posted Sep 20, 2023 15:19 UTC (Wed)
by shemminger (subscriber, #5739)
[Link]
I remember when ISO9000 was going to solve all software quality problems through more process. And see how well that worked.
There is a real problem here, but this is not a solution.
Posted Sep 20, 2023 21:56 UTC (Wed)
by kleptog (subscriber, #1183)
[Link] (7 responses)
Notifications only apply to security issues found in deployed products, so not every bug needs notification. This actually ties into the discussion that was here recently about when CVEs should be allocated. This Act cannot solve this problem (nor does it try). If you want to reduce the impact of this Act, then it would be a good idea to stop assigning CVEs for issues that aren't important.
Posted Sep 21, 2023 2:25 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (6 responses)
The problem is that it's not the developer's job to try to figure if a bug may possibly have security ramifications or not. The developer makes a bug and fixes a bug.
> If you want to reduce the impact of this Act, then it would be a good idea to stop assigning CVEs for issues that aren't important.
That's one of the likely outcomes, that everyone strongly refuses to assign any CVE on the grounds that "no, it's not a security problem, in the worst case it's a misuse" at least to try to escape the CRA.
Posted Sep 21, 2023 11:35 UTC (Thu)
by kleptog (subscriber, #1183)
[Link]
Correct, which is why notifications are only required for vulnerabilities that are known to be actively being exploited. Potential vulnerabilities are of not interest here because as you point out, you just need to push the bug-fix out to people in a reasonable time-frame and spend no more time on it. The goal here is to prevent suppliers sitting on information about actively exploited vulnerabilities. You can voluntarily notify about other things your customers may be interested in. I don't see how this is a big change compared to what people are doing now.
Posted Sep 22, 2023 5:10 UTC (Fri)
by ebee_matteo (subscriber, #165284)
[Link] (4 responses)
I strongly disagree and I think this is at the root of the problem.
The CRA is written *exactly* because we see a severe uptick in exploitable vulnerabilities because developers do not care enough about security as part of project development.
In turn these are widespread enough that they are very juicy for a state-actor threat or rogue terrorist.
The spirit of the CRA is: you *need* to care about this. If you do not directly have the resources as an hobbyist, at least companies commercializing those products need to allocate proper resources and FTEs or face the consequences.
The free ride has ended.
You do not like this? Keep unreviewed software out of your commercial product that can have potential repercussions on the life of millions of people.
Unfortunately it is currently very visible for people on the cybersecurity area how open source is becoming an easy target for a plethora of attacks, esp. socially engineered and supply chain related.
Big companies certainly have resources to foot the bill for code reviews and the paperwork needed.
Now, the language in the CRA needs fixing, I agree. But the spirit is correct.
Posted Sep 22, 2023 21:00 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (3 responses)
> I strongly disagree and I think this is at the root of the problem.
I'd put it rather differently, but yes it's because developers don't do their job properly.
> The CRA is written *exactly* because we see a severe uptick in exploitable vulnerabilities because developers do not care enough about security as part of project development.
> In turn these are widespread enough that they are very juicy for a state-actor threat or rogue terrorist.
> The spirit of the CRA is: you *need* to care about this. If you do not directly have the resources as an hobbyist, at least companies commercializing those products need to allocate proper resources and FTEs or face the consequences.
If you care about doing a good job, a lot of this grief would just go away. What's the quote? "If they built buildings like we build software, the first woodpecker to come along would destroy civilisation"? Most software is held together with duck tape, string, and sealing wax.
I'm very much with Linus here - "a bug is a bug is a bug. It should be fixed". Security considerations are secondary. But as I see it, there are two problems ... and I'm with him with his other quote too - "the best programmers are lazy programmers, they get it right first time because they can't be bothered to do it twice".
Firstly, most software today is not designed. It's thrown together, it works, and that's that. Then it gets extended and extended and the parts don't work together. Etc etc.
The second thing is, a heck of a lot of our tools suffer the same problem. C is a massive offender, with all its undefined behaviour. Landmines everywhere. I've just been fighting conditional formatting with VBA. Badly documented, things blowing up when you think they should work, things only make sense AFTER you've debugged the problem, ...
Again, what's that saying? "Ten minutes extra in the design phase knocks an hour off the debugging". I'm probably loved and hated simultaneously at work, because I spend so much time fixing technical debt even in the middle of a fire fight.
That's why I hate Word. That's why I hate Relational/SQL. I've worked with programs that have a clear, simple design. Things "just work". Everything I do, I try to step back and have a clear design behind it. Even if I do a half-baked implementation, so long as the design is simple, clear, AND WELL COMMENTED IN THE CODE, things are far less likely to break. If somebody tries to do something I haven't implemented, they should crash into an error message that says "not implemented, please file a bug report". They shouldn't crash into an undefined, unanticipated state that causes all sorts of grief.
How much effort is it to check a variable that says "these are the states I know about and can handle. Anything else, raise an error"? Okay, if the previous guy didn't do it you're probably into a world of hurt. But if all your code does it, you're not going to be responsible for some obscure security problem because you didn't do your job (if that other guy's code drops you in it, well sorry ...)
Cheers,
Posted Sep 25, 2023 2:33 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link] (2 responses)
That's exactly my point. Figuring how a bug might be used to participate to an exploitation chain requires a different mind and set of skills. Many developers will not see how missing a line feed at the end of an error message might constitute a vulnerability, it's just a cosmetic error, but some upper layer wrapper might rely on this specific delimiter and might get confused enough to be fooled. That's what I mean by "it's not the developer's job". The developer cannot know *all* possible use cases and integration of their creation. Of course, writing a blatant buffer overflow does have immediately visible security implications, but a lot of security issues nowadays stem from a combination of small escalations, sometimes from different components.
Posted Sep 25, 2023 7:32 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
But this is what really pisses me off (not only with developers, but ...)
If the developer is not knowledgeable enough (I carefully didn't say "skilled") to know that there is SUPPOSED to be a line feed, this is a failure on oh so many levels. A badly designed tool (the compiler?), an inappropriate language (okay that's often management), a developer satisfied with "oh it appears to work", an analyst who didn't analyse the job properly ... the list goes on.
At the end of the day we should be aiming to do the best job we can, and that does NOT mean patching broken tactics on top of broken tactics. Banging on about Pick again, but it's noticeable with Pick that good software tends to be implemented by teams, with domain experts specifying the problem and helping in the programming, while the computer experts help in the specification and make sure the programming is done properly.
At the end of the day, far too many problems are caused by "ivory tower syndrome" - epitomised by typical computer split into analysts and programmers, where analysts understand neither the subject nor programming, and programmers implement the spec they're given. A recipe for disaster. I hope most of us don't work in those sorts of environments, but it's those embedded attitudes that are responsible for a lot of the problem. I guess that can be summed up as "bureaucracy" :-)
Cheers,
Posted Sep 25, 2023 10:17 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Right, and nothing about the CRA stops you saying that all commits (not just all bugfixes, but all commits, whether they're known to be bugfixes or not) are security relevant; if you do this, then your downstreams have to either keep up with development, or accept the risk of being liable for bugs in your software if you've fixed one and they haven't taken that patch. The whole thing only becomes an issue if you're (a) providing software in a commercial context, (b) not wanting to force your customers to upgrade all the time, and (c) don't want to be liable for security-relevant bugs in the software; at this point, the CRA forces you to choose which of those three you drop.
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
[2] https://www.europarl.europa.eu/meetdocs/2014_2019/plmrep/...
The European Cyber Resilience Act
And hardware makers face zero liability as long as it's the end-user that installs the software.
The European Cyber Resilience Act
The European Cyber Resilience Act
And hardware makers face zero liability as long as it's the end-user that installs the software.
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
> Firstly, most software today is not designed. It's thrown together, it works, and that's that. Then it gets extended and extended and the parts don't work together. Etc etc.
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act