> At this point, I have to wonder what is even the point of missives like this. ...It's all just mindless blather unless you're actually talking about ways that software vendors will be held liable for bugs in their products.

I think that liability for bugs is exactly where she's going with this. I'm not an expert, but it sounds from a few things I've heard on some Lawfare podcasts (e.g,. [1][2]) like the idea of software liability has been discussed for quite a while now in government policy circles. This sort of public statement may be laying the groundwork for building the political will to make it happen.

[1] https://www.youtube.com/watch?v=9UneL5-Q98E&pp=ygUQbGF3ZmFyZ...

[2] https://www.youtube.com/watch?v=zyNft-IZm_A&pp=ygUQbGF3ZmFyZ...

EDIT:

> Making truly secure software products is incredibly hard in this day and age, which is one reason why demanding software product liability is so scary.

Loads of companies already are liable for bugs software that runs on their products: this includes cars, airplanes, and I would presume medical devices, and so on. The response has been what's called "safety certification": as an industry, you define a process which, if followed, you can in court say "we were reasonably careful", and then you hire an evaluator to confirm that you have followed that process.

These processes don't prevent all bugs, naturally, but they certainly go a long way towards reducing them. Liability for companies who don't follow appropriate standard processes would essentially prevent cloud companies cutting security to get an edge in time-to-market or cost.

I agree with her about blaming developers, not hackers. Though not to the point of liability for all developers, but maybe for a few specialist professionals who take on that responsibility and are paid appropriately for it.

Hackers are essentially a force of nature that will always exist and always be unstoppable by law enforcement because they can be in whatever country doesn't enforce such laws. You wouldn't blame the wind for destroying a bridge - it's up to the engineer to expect the wind and make it secure against that. Viewing them this way makes it clear that the people responsible for hacks are the developers in the same way developers are responsible for non-security bugs. Blame is only useful if you can actually use it to alter people's behavior - which you can't for international hackers, or the wind.

Banging this drum could be effective if it leads to a culture change. We already see criticism of developers of software that has obvious vulnerabilities all the time on HN, so there's already some sense that developers shouldn't be extremely negligent/incompetent around security. You can't guarantee security 100% of course, but you can have a general awareness that it's wrong to make the stupid decisions that developers keep making and are generally known to be bad practice.

A third option is to empower security researchers and hope the good guys find the security holes before the bad guys.

Currently, we threaten the good guys, security researchers, with jail way to quickly. If someone presses F12 and finds a bunch of SSNs in the raw HTML of the State's web page the Governor personally threatens to send them to jail[0]. The good security researchers tip-tow around, timidly asking permission to run pentests while the bad guys do whatever they want.

Protect security researchers, change the laws to empower them and give them the benefit of the doubt.

I think a big reason we don't do this is it would be a burden and an embarrassment to wealthy companies. It's literally a matter of national security and we current sacrifice national security for the convenience of companies.

As you say, security is hard, and putting liability for security issues on anyone is probably unreasonable. The problem is companies can have their cake and eat it too. The companies get full control over their software, and they get to pick and choose who tests the security of their systems, while at the same time having no liability. The companies are basically saying "trust me to take care of the security, also, I accept no liability"; that doesn't inspire confidence. If the liability is too much to bear, then the companies should give up control over who can test the security of their systems.

[0]: https://techcrunch.com/2021/10/15/f12-isnt-hacking-missouri-...

> But with software security the complexity is nearly infinitely higher, and making it secure is much harder to guarantee.

The other thing is that software, especially software connected software (which these days is most software) has to have a much higher level of security than most other industries. When a structural engineer builds a bridge they don't have to worry abou a large number of criminals from all over the world trying to find weaknesses that can be exploited to cause the bridge to collapse.

But software engineers do have to worry about hackers, including state sponsored ones, constantly trying to find and exploit weaknesses in their software.

I think it absurd to put blame on software engineers for failing to make flawless software instead of the bad actors that exploit bugs that would never be noticed during normal operation, or the law enforcement that is ineffective at stopping such exploitation.

Now, I do think that there should be more liability if you don't take security seriously. But there is a delicate balance there. If a single simple mistake has the potential to cause devastating liability, that will seriously slow down the software industry and substantially increase the cost.

You can also choose to avoid complexity.

Often a shorter computer program that is easy to understand can do exactly what a more complicated program can. We can simplify interfaces between systems and ensure that their specifications are short, readable and implementable without allocation, buffers or other things that can be implemented incorrectly. We can ensure that program code is stored separately from data.

Now that LLMs are getting better we could probably have them go through all our code and introduce invariants, etc. to make sure it does exactly what it's supposed to, and if it can't then a human expert can intervene for the function for which the LLM can't find the proof.

I think hardware manufacturers could help too. More isolation, Harvard architectures etc. would be quite appealing.

3. Legal incentives. When somebody dies or fails to receive critical care at a hospital because a Windows XP machined got owned, somebody should probably face something along the lines of criminal negligence.

> economic incentives

EU CRA incoming, https://ubuntu.com/blog/the-cyber-resilience-act-what-it-mea...

How will the US version differ?

> Making truly secure software products is incredibly hard in this day and age

I politely disagree. Writing secure software is easier than ever.

For example, there are several mainstream and full-featured web frameworks that use managed virtual machine runtimes. Node.js and ASP.NET come to mind, but there are many other examples. These are largely immune to memory safety attacks and the like that plague older languages.

Most popular languages also have a wide variety of ORMs available that prevent SQL injection by default. Don't like heavyweight ORMs? No problem! There's like a dozen micro-ORMs like Dapper that do nothing to your SQL other than block injection vulnerabilities and eliminate the boilerplate.

Similarly, web templating frameworks like Razor pages prevent script injection by default.

Cloud app platforms, containerisation, or even just virtual machines make it trivial to provide hardware enforced isolation on a per-app basis instead of relying on the much weaker process isolation within an OS with shared app hosting.

TLS 1.3 has essentially eliminated cryptographic vulnerabilities in network protocols. You no longer have to "think" about this concern in normal circumstances. What's even better is that back end protocols have also uniformly adopted TLS 1.3. Even Microsoft Windows has started using for the wire protocol of Microsoft SQL Server and for the SMB file sharing protocol! Most modern queues, databases, and the like use at least TLS 1.2 or the equivalent. It's now safe to have SQL[1] and SMB shares[2] exposed to the Internet. Try telling that to someone in sec-ops twenty years ago!

Most modern PaaS platforms such as cloud-native databases have very fine-grained RBAC, built-in auditing, read-only modes, and other security features on by default. Developers are spoiled with features such as SAS tokens that can be used to trivially generate signed URLs with the absolute bare minimum access required.

Speaking of PaaS platforms like Azure App Service, these have completely eliminated the OS management aspect of security. Developers never again need to think about operating system security updates or OS-level configuration. Just deploy your code and go.

Etc...

You have to be deliberately making bad choices to end up writing insecure software in 2025. Purposefully staring at the smörgåsbord of secure options and saying: "I really don't care about security, I'm doing something else instead... just because."

I know that might be controversial, but seriously, the writing has been on the wall for nearly a decade now for large swaths of the IT industry.

If you're picking C or even C++ in 2025 for anything you're almost certainly making a mistake. Rust is available now even in the Linux kernel, and I hear the Windows kernel is not far behind. Don't like Rust? Use Go. Don't like Go? Use .NET 9. Seriously! It's open-source, supports AOT compilation, works on Linux just fine, and is within spitting distance of C++ for performance!

[1] https://learn.microsoft.com/en-us/azure/azure-sql/database/n...

[2] https://learn.microsoft.com/en-us/azure/storage/files/files-...

That is important context, but I still agree with what she's said in this article. It's also rich that Cisco especially -- a company known for hard-coding backdoors into their products for decades -- is "taking a pledge" to do better.

I see it as the opposite: as ex Deputy Head of TAO Easterly is no retard.

And there's a difference between defective software that leads to vulns exploited by crime gangs and NOBUS backdoors that the good guys use to keep you safe. Sounds bullshit, right?

That's how far the public discourse on cyber has diverged from the reality, which is part of the issue. Easterly's push for renaming cyber actors and flaws is smart. Bad quality comes from mindset, attitude. And names are important, as programmers should know! :)

I would prefer it if she had a GitHub profile tho. Always cool if you do that.

So I'm aware she worked for the NSA but this is the first I'm hearing of her working for TAO.

I had thought she worked at the NSA's IAD (defensive side) pre-merge of the offensive and defensive sides.

One thing is software development is not really focused on secure software. If Microsoft ca n manage to call recall a engineered product feature where those M$ folks get payed stacks to work on, can't even both securing the data in rest, and then decide its a great idea to use cloud computing for recall, then I can totally see "security software engineer" becoming a separate field.

Securing software seems to be hard especially in web development. You got to worry about regular development, then all these crazy different exploit methods like xss,SQL injection, data sanitation, etc....and then you got to get this site working for multiple browsers, you need to jugle all of this. And if an api or some 3rd party tool gets compromised how do you prevent that except a crystal ball a bottle of burbon and a clairvoyant chant?

Also their was iirc people submitting bogus CVE reports to increase the mental drain on people and overwhelm the human link which is always the weakest.

Conspiracy theory: creating new bugs they can always fix later is a good source of continued employment.

That is absolutely a thing [1]. There are hardware devices that can be fixed illegally fixed using 3rd party software for this reason. The people making a work around to the scam then get sued. The video is worth a watch in my opinion. It was created 3 years ago and the problem is still ongoing.

[1] - https://www.youtube.com/watch?v=SrDEtSlqJC4 [video][29min]

It isn't malice dude. Unfortunately, it really is just that 70% of developers are utterly incompetent.

As someone who thinks the industry should professionalize, I actually agree with you somewhat; we pushed too far, too fast, and into territory that software has no business being in.

What's the definition of truly secure?

This seems like a very pat dismissal of what upon reading further seems like a very reasonable critique of the industry. Vendors have been seriously exploiting their ability to decline responsibility for their product development decisions and that often has significant negatives for affected users.

I don't know how meaningful those countermeasures really are. Like, you're basically looking at the space of Linux kernel LPEs, and you're bringing it down to maybe 1/3rd the "native" rate of vulnerabilities --- but how does that change your planning and the promises you can make to customers?

Government agencies have got their hands tied just getting people to use MFA and not click on phishing emails. You're decades ahead of the herd if you're thinking about coding in SECCOMP-BPF.

Search MasterLock on Youtube and you'll see that people blame the lock maker rather than the burglars. That's because the lock maker is notorious for making insecure locks.

Social engineering is also something that can be protected against by developers, at least to some extent. Yubikey type 2FA is more resistant to that than user-input TOTP codes, for example. Nothing's bulletproof but it could certainly be improved in many cases. Wasn't some company that experienced a credential stuffing attack recently sued for not requiring 2FA for its users?

We don't tolerate house builders who says "well there's always some way water might get into the framing, so we don't need to bother installing flashings properly - a bit of caulking will do instead."

Hint: she didn’t say that they were building them intentionally. Skimping is building a problem even if nobody had a Jira ticket saying they had to leave out bounds checking.

Liability for a defective product is a “radical restructuring”? It’s something we have in almost every other category of business - not perfectly but pervasive enough that software is really conspicuous as an outlier.

I think in certain ways you are right we need those standards and stamps. But also colleges need to be very clear and cease calling it software engineering as it implies the expertise of a engineer.

Computer engineering degrees can sorta get away with this, as they have quite a bit of engineering classes they have to take, but I'm not sure if they can call themselves engineers legally.

Its hard because I believe certain titles are protected like doctor,lawyer,engineer, but last I check it varied by state in the USA at least.

Sidenote: sometimes people get a computer science degree, or they he a cyber security degree, or even cyber warefare degree. All three seem to be used interchangeably in the security field.

On one hand I get how formal protected titles help uphold standards and create trust, but it also enforces the grip colleges have and it creates more barriers to entering a field. Some States require 3 years experience to get a state permit for certain activities, when a federal permit is already needed so in that case its just more paperwork.

Imagine if we started demanding people who build houses, not the guy who designed it but the builders to be an engineer, so we can trust their work and ability to do a job in the correct manner?

At what point do we sacrifice and pass legislation in the name of reliability and safety?

Ok, so overnight all programmers stop calling themselves Engineers. [1] What problem does that solve? I fix bugs all day, but I don't call myself a Software Doctor.

Frankly whether software people call themselves engineers or not matters to pretty much no-one (except actual engineers who have stamps and liabilities.)

Creating a bunch of requirements and liability won't suddenly result in more programmers getting certified and taking on liability. It'll just mean they stop using that title. I'm not sure that achieves anything useful. We'd still have the exact same software coming from the exact same people.

[1] for the record I think 'software engineer' is a daft title anyway, and I don't use it. I don't have an engineering degree. On the other hand I have a science degree and I don't go around calling myself a data scientist either.

> As long as "SWEs" do not have stamps and legal liability, they are not real (professional) engineers

When and if that happens I’ll move to carpentry. Good luck. Tech is already full of *it. The only thing short of making it even worse is stamps and a mafia-like org issuing the stamps and asking for contributions in return, like it happens in the fields of medical care, law, book keeping, architecture or civil engineering.

The companies should certify the products which require certification instead and get liability insurance.

Crowdstrike also provided software for Linux systems. It's something you install to satisfy auditors and they would demand the same of any OS unless such functionality was built-in.

But wait... most Windows runs on Intel, we should shutdown Intel.

Of course shutting down Windows will have zero effect on security. There are plenty of exploits for Linux, and most data leaks are hosted on Linux (but have nothing to do with the OS.)

To the degree to which software is a failure at the coding level (like every SQL injection, phishing, social engineering , sim swap, php, attack ever) the OS is irrelevant.)

In truth most all security has to do with people; programmers and users. The OS might be a nice scapegoat but it's not the root of the problem. Blaming it though helps to deflect attention away from ourselves though.

> If we truly want secure products, we should shutdown all Windows machines?

There should be a period where you put a question mark.

Running the world's critical infrastructure on verified, small, readable codebases rather than a diaspora of unvetted closed-source programs sprinkled across Windows and Linux systems sounds like a good start.

Precisely.