Assuming the level of certification will be proportionate the potential risk/harm, then this is actually totally ok. Like would you want to fly in a plane built but a bootstrap startup that had no certifications? Or go in a submarine to extremely deep ocean tours of the titanic? Or put in a heart device? Or transfer all of your savings to a startup's financial software that had no proof of being resilient to even the most basic of attacks?

For me, its a hard no. The idea of risk/harm based certification and liability is overdue.

Technically yes, since it depends on the kind of liability.

In particular, liability for negligence depends on somebody doing stupid-things or stupidly-not-doing the right things, and there's an ongoing struggle to define where that envelope lies.

The ‘compliance theater’ often is filled with things which seem inane to your product, but the requirements themselves are often broad so that they cover many different types of products. Sure, we could add further granularity, but there is usually a ton of pushback and many people need to come to some compromise on what is relevant.

Ask Boeing.

Software has tons of bugs. A fraction of those bugs are security vulnerabilities.

Any type of bug can be considered a defect, and thus can be considered to make the product defective. By using the terminology "defective" instead of "vulnerable" we lose the distinction between security bugs and other bugs. I don't think we want to lose that distinction.

Empathic agreement.

Source: Was QA/test manager for a bit. Also, recovering election integrity activist.

TIL: The conversation is just easier when bugs, security holes, fraud, abuse, chicanery, etc are treated as kinds of defects.

Phrases like "fraud" and "exploit" are insta-stop conversation killers. Politicians and managers (director level and above) simply can't hear or see or reason about those kinds of things. (I can't even guess why not. CYA? Somebody else's problem? Hear no evil...?)

QA/Test rarely receives its needed attention and resources. Now less than ever. But advocating for "fixing bugs" isn't a total bust.

> Also, why haven't those so called security researchers jointly criticized EDR yet? A third-party closed source kernel driver which behave like, practically same as malware.

They have been, for years. Some very prominent voices in the security community have been criticizing the level of engineering prowess in security tools for ages - Travis Ormandy ripped into the AV industry for Project Zero over a decade ago and found critical problems in things like FireEye, too. The problem is that without penalties, the companies just keep repeating the cycle of “trust us” without improving their levels of craft or transparency.

In terms of shaming bad products, motivating executives, etc, maybe... However I don't think you can easily combine general QA and security stuff under one roof, because they demand different approaches and knowledge sets.

>Imagine a mechanical engineer making industrial robots complaining about how unfair it is that they are held liable for single simple mistakes like pulping people. What injustice! If you want to make single simple mistakes, you can work on tasks where that is unlikely to cause harm like, I don't know, designing door handles? Nothing wrong with making door handles, the stakes are just different.

This is a truly absurd comparison. In the first place, yes, it is in fact much easier to make physical products safer, as anyone who's ever seen a warning line or safety guard could tell you. The manufacturers of CNC mills don't accept liability by making it impossible to run a bad batch that could kill someone, they just put the whole machine in a steel box and call it a day. The software consumers want has no equivalent solution. What's worse, in the second place, these engineers aren't actually held responsible for the equivalent of most software breaches already. There pretty much is zero liability for tampering or misuse, thus the instruction booklet of 70% legal warnings that still comes with everything you buy even in this age of cutting costs. Arguing software should be held to the same standard as physical products, when software has no equivalent of safety lockouts, is just to argue it should include acceptable use sections in its terms and conditions, which is no real improvement to people's security in the face of malicious actors.

Do you think that the mechanical engineer should be held liable if, say a criminal breaks into the factory, and sabatoges the robot to damage property or injure workers, because they didn't make the robot sufficiently resistent to sabatoge attempts?

That's the only thing that'll Microsoft chill with the reboots

Yes.

I wanted to avoid writing war & peace, but to be fair, some gaps remain at the highest levels of abstraction. For example, SPA apps are a security pit of doom because developers can easily forget that the code they're writing will be running on untrusted endpoints.

Similarly, high-level integration with third-party APIs via protocols such as OIDC have a lot of sharp edges and haven't yet settled on the equivalent of TLS 1.3 where the only possible configurations are all secure.

The point is that secure software is easier to write, not that it's impossible to have security vulnerabilities.

Your specific example is a good one: interacting with Postgres is one of those things I said people choose despite it being riddled with security issues due to its age and choice of implementation language.

Postgres is written in C and uses a complicated and bespoke network protocol. This is the root cause of that vulnerability.

If Postgres was a modern RDBMS platform, it would use something like gRPC and there wouldn't be any need to hand-craft the code to perform binary encoding of its packet format.

The security issue stems from a choice to use a legacy protocol, which in turn stems from the use of an old system written in C.

Collectively, we need to start saying "no" to this legacy.

Meanwhile, I just saw a video clip of an auditorium full of Linux kernel developers berating the one guy trying to fix their security issues by switching to Rust saying that Rust will be a second class citizen for the foreseeable future.

That is why other industries have bill of materials and supplier chain validation.

Bill of materials is already a reality in high critical computing deployments.

Yes, that's what I meant too, sorry.

> They are clearly called "villains".

As readers of the article know, they are not:

> The truth is: Technology vendors are the characters who are building problems" into their products, which then "open the doors for villains to attack their victims,"

She’s talking about companies, not individual developers, and she didn’t call them villains but rather creators of the problems actual villains exploit. The company focus is important: it’s always easy to find who committed a problematic line of code - say a kernel driver which doesn’t validate all 21 of its arguments properly - but the person who typed that in doesn’t work alone. The company sets their incentives, provides training (or not), and most importantly should be pairing the initial author of that code with reviewers, testers, and quality tools. When a company makes a $50 toaster, they don’t just ask the designer whether they think it’s safe, they actually test it in a variety of ways to get that UL certification, and we have far fewer fires than we had a hundred years ago.

One key to understanding this is to remember CISA’s scope and mission. They’re looking at a world where every week has new ransomware attacks shutting down important businesses, even things like hospitals, industrial espionage is on the rise and the industry has largely tried to stay in the cheaper reactive mode of shipping patches after problems are discovered rather than reducing the rate of creating them. This is fundamentally not a technical issue but an economic one and she’s trying to change the incentive structure to get out of the cycle which really isn’t working.

> put blame on those actively exploiting that

To some extent hackers are like the wind. They're a nebulous cloud of unidentifiable possible-people that you can't influence through shaming or laws or anything else. I think we should see them that way to make it clear that it's primarily the developer's responsibility.

Of course blame hackers when they're within reach too.

If you defined it as absence of runtime errors, it exists.

I wouldn’t say that. There are some not obvious things like timing attacks that you probably shouldn’t feel bad about.

If you’re still writing sql injections though, yeah, you’re terrible.

>> That's fine, it just means that devs without stamps can't sign off on anything actually important

For some definition of important.

But let's follow your thought through. Who decides what is important? You? Me? The developer? Yhe end-user? Some regulatory body?

Is Tetris important? OpenSSL? Notepad ++? My side project on github?

If my OSS project becomes important, and I now need to find one of your expensive engineers to sign off on it, take liability for it, do you think I can afford her? How could they be remotely sure that the code is OK? How would they begin to determine if its safe or not?

>> Software did in-fact eat the world. Why shouldn't it have any legal/professional liability like civil and structural engineering?

Because those professions have shown us why that model doesn't scale. How many bridges, dams etc are built by engineers every year? How does that compare to the millions of software projects started every year?

In the last 30 years we've pretty much written all the code, on all the platforms, in use today. Linux, Windows, the web, phones, it's all less than 35 years old. What civil engineering projects have been completed in the same time scale? A handful of new skyscrapers?

You are basically suggesting we throw away all software ever written and rebuild the world based on individual's prepared to take on responsibility and legal liability for any bugs they create along the way?

I would suggest that not only would this be impossible, not only would it be meaningless, but it would take centuries to get to where we are right now. With just as many bugs as there are now. But, yay, we can bankrupt an engineer every time a bug is exploited.

There have long been multiple forms of professional software engineering in aerospace, rail, medical instrumentation and national security industries such as ISO 26262, DO-178B/DO-178C/ED-12C, IEC-61508, EN-50128, FDA-1997-D-0029 and CC EAL/PP.

DO-178B DAL A (software whose failure would result in a plane crashing) was estimated at [1] to be writable at 3 SLOC/day for a newbie and 12 SLOC/day for a professional software engineer with experience writing code to this standard. Writing software to DO-178B standards was estimated in [1] to double project costs. DO-178C (newer standard from 2012) is much more onerous and costly.

I pick DO-178 deliberately because the level of engineering effort required in security terms is probably closest to that applied to seL4, which is stated to have cost ~USD$500/SLOC (adjusted for inflation to 2024).[2] This is a level higher than CC EAL7 as CC EAL7 only requires formal verification of design, not the actual implementation.[3] DO-178C goes as far as requiring every software tool used to verify software automatically has been formally verified otherwise one must rely upon manual (human) verification. Naturally, formally verified systems such as flight computer software and seL4 are deliberately quite small. Scaling of costs to much larger software projects would most likely be prohibitive as complexity of a code base and fault tree (all possible ways the software could fail) would obviously not scale in a friendly way.

[1] https://web.archive.org/web/20131030061433/http://www.euroco...

[2] https://en.wikipedia.org/wiki/L4_microkernel_family#High_ass...

[3] https://cgi.cse.unsw.edu.au/~cs9242/21/lectures/10a-sel4.pdf

As a header, there's clearly a liability problem in modern software, which I'll get to later.

[pre-posting comment: I've moved the semi-rant portion to the bottom, because I realized I should start with the more direct issues first, lest the ranty-ness cause you to not read the less ranty portion :D ] <snip and paste below> Now getting to the point: there is a real problem in that companies can advertise products to do a certain thing, and they can then have a license agreement that says "we're not liable if it fails to do what we said it would do", but generally despite those licenses (which to be clear are a requirement for open source to exist as a concept), the law has found companies are liable for unreasonable losses.

So the question is just how liable should a company be for a bug in their software (or hardware I guess depending on where you place the hardware vs firmware vs software lines) that can be exploited, and your position is that in addition to liability bought about by their own actions (Again despite the "we have no liability" EULAs plenty of companies have ended up with penalties for bugs in their software causing a variety of different awful outcomes.

But you're going a step further, you're now saying, in addition to liability for your errors, you're also liable for other people causing failures due to those errors, either accidentally or intentionally.

I am curious, and I would be interested in the responses from your Real Engineer coworkers.

Who is responsible if a bridge collapses when a ship crashes into it? An engineer can reasonably predict that that would happen, and should design to defend against it.

Let's say an engineer designs a building, and a person is able to bomb the building and cause it to collapse with only a small amount of fertilizer? What happens to the liability if the only reason the plot succeeded was because they were able to break past a security barrier?

Because here is the thing: we are not talking about liability if a product/project/construction fails to do what it says it will do (despite EULAs, companies generally lose in court when their product causes harm even if there's a license precluding liability). The question is who is liable if a product fails to stand up to a malicious actor.

At its heart, the problem we're discussing is not about liability for "the engine failed in normal use", it's "the engine failed after someone poured sugar into the gas tank", not "the wall collapsed in the wind" it's "the wall collapsed after someone intentionally drove their truck into it", not "the plane crashed when landing due to the tires bursting", it's "the plane crashed when landing as someone had slashed the tires".

What you're saying, is that a Professional Engineer signing off on a design is saying not only "this product will work as intended", they're saying "this product will even under active attack outside of its design window".

That's an argument that seems to go either way: I don't recall ever hearing about a lawsuit against door manufacturers due to burglars being able to break through the doors or locks, but on the other hand Kia is being sued due to the triviality of stealing their cars - and even then the liability claims seem to be due to the cost of handling the increased theft, not the damage from any individual theft.

[begin ranty portion: this is all I think fairly reasonable, but it's much more opinionated than the now initial point and I'm loathe to just discard it]

I'm curious what/who you think is signing off and what they are signing off on.

* First off, software is more complex than more or less any physical product, the only solution is to reduce that complexity down to something manageable to the same extent that, say, a car is. How many parts total are in your car? Cool that's how many expressions or statements your program can have. And because it's not governed by direct physical laws and similar interactions, then that's still more complex than a car.

* Second: no more open source code in commercial products - you can't use it in a product, because doing so requires sign off by your magical software engineers who can understand products more complex, again, than any single physical product

* Third: no more free development in what open source remains - signing off on a review now makes you legally liable for it. You might say that's great, I say that means no one is going to maintain anything for zero compensation and infinite liability.

* Fourth: no more learn development through open source contributions, as a variation of the above now every newbie that submits a change brings liability, so you're not accepting any changes from anyone you don't know, and who you don't have reason to believe is competent.

* Fifth: OSS licenses are out - they all explicitly state that there's no warrantee or fitness for purpose, but you've just said the engineer that signs off on them is liable for it, which necessarily means that your desire for liability trumps the license.

* Sixth: Free development tools are out - miscompilation is now a legal liability issue, so now a GCC bug opens whoever signed off on that code to liability.

The world you're describing is one in which the model of all software dev including free dev, now comes with liability that matches designing cars, or constructing buildings, both of which are much less complex and much more predictable than even the modest OSS projects, and those fields all come with significant cost based barriers to entry. The reason there are more software developers than there are civil or mechanical engineers is not because one is easier than the other, it's because you cannot learn civil or mechanical engineering (or most other engineering disciplines) as cheaply as software. The reason that software generally pays more than those positions is because the employer is taking on a bunch of the financial, legal, and insurance expenses required to do anything - the capital expenditure required to start a new civil or mechanical engineering companies is vastly higher than for software, and the basic overhead for just existing is higher, which means employers don't have to compete with employees deciding to start their own companies. A bunch of this is straight up capital costs, and capital, but the bulk of it is being able to have sufficient liability protection before even the smallest project is started. At that point, the company has insurance to cover the costs so the owners are generally fine, but the engineer that missed something - not the people forcing time crunches, short cuts, etc - is the one that will end up in jail. You've just said the same should apply to software: essentially the same as today company screws up and pays fine/settlement, but now with lowered pay rates for the developers, and they can go to jail.

All because you have decided to apply a liability model that is appropriate to an industry where the things that are signed off on have entirely self contained and mostly static behavior to a different industry where _by design_ the state changes constantly, so there is not, and cannot be, any equivalent "safety" model or system. Even in the industries that you're talking about, where analysis is overwhelmingly simpler and predictable, products and construction fails. Yet now you're saying the software development could just be the same as that. When developing a building, you can be paranoid in your design, and make it more expensive by overbuilding - civil engineering price competition is basically just a matter of "how much can I strip down the materials of construction" without it collapsing (noting that you can exactly model the entire behavior of anything in your design). Again, the software your new standards require are the same as that required by the space and airline industry that people routinely already berate for being "over priced".

You've made a point that there are engineers, and professional engineers, and the latter are the only ones who sign off on things. So it sounds like you're saying patches can only be reviewed by specific employees, who taken on liability for those changes, so now an OSS project has to employ a Professional Engineer to review contributions, who becomes liable for any errors they miss (out of curiosity, if a bug requires two different patches working together to create a vulnerability, which reviewer is now legally liable?). Those professional engineers now have to sign off on all software, so who is signing off on linux? You want to decode images, hopefully you can find someone to sign off on that. Actually it's probably best to have a smaller in-house product, or a commercial product from another company who have had their own professional engineers sign off, and who have sufficient insurance. Remember that you need to remind your employees not to contribute to any OSS projects, and don't release anything as OSS, because you would be liable if it goes wrong in a different product that you don't make money from now (remember your own Professional Engineers have signed off on the safety of the code you released, if they were wrong, you're now liable if someone downstream relied on that sign off).

This misses a few core details:

  Physical engineering is *not* software engineering (which yes as a title "software engineer" is not accurate in many/most cases as it does imply a degree of rigour absent in most software projects). Physical engineering does not employ the same degree of reuse and intermingling as occurs in software - the closest I can really think of is engine swaps in cars, but that's only really doable because the engine is essentially the most complex part of the car anyway (at least in an ICE), and even then the interaction with the rest of the car is extremely constrained, predictable, and can be physically minimized. For civil/structural engineering it's even more extreme: large construction (e.g. the complex cases) are not simply made by mashing together arbitrary parts of other projects - buildings fall into basically two categories: the exact same building with different dimensions and a different paint job, or entirely custom.

  Physical engineering has basically an entirely predictable state from which to work. The overwhelming majority of any physical design is completely static, the things that are dynamic have a functionally finite and directly modelable set of states and behaviors, and those states and behaviors vary in predictable ways in response to constrained options. Despite this, many (if not most, though quantifying this would be hard because there's also vastly more static engineering than dynamic) failures are in the dynamic parts of these projects than the static portions. Software is definitionally free of more or less any static behavior, the entire reason for software is the desire for constantly changing state.

I think that’s a good example of the problem with The Register, but I think we should try to focus more on Easterly’s quoted statements which accurately identify the problem as corporate.

Now imagine software priced like OEM car parts. We'd all be running some heirloom version of Turbo Pascal.

You don’t think the vendors who are years behind on dependency updates are skimping? Not the ones who are still struggling to ship patches on a better than quarterly cadence? Not the ones who still ship 90s-style C code to enterprise customers who are paying high prices for their security products? Not the ones still writing new code in memory unsafe languages? Not the ones who still tell customers to disable SELinux? Not the ones who still refuse to use the sandboxing features in modern operating systems?

Companies love the idea that you can’t hold the liable for any defect they didn’t intentionally build in, but software is the extreme outlier where they were able to avoid consumer safety regulations and thus the expense of hiring people who can even tell when something is risky. Shift the cost back to the supplier would restore the market feedback mechanism which is currently missing, greatly improving the health of the industry.