The European Cyber Resilience Act

Posted Sep 25, 2023 2:33 UTC (Mon) by wtarreau (subscriber, #51152)
In reply to: The European Cyber Resilience Act by Wol
Parent article: The European Cyber Resilience Act

> 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.

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.

to post comments

The European Cyber Resilience Act

Posted Sep 25, 2023 7:32 UTC (Mon) by Wol (subscriber, #4433) [Link]

> 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.

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,
Wol

The European Cyber Resilience Act

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.