A Plea for Simplicity – You can't secure what you don't understand. (1999)
schneier.comThis was written in 1999, I wonder if his opinion on software engineering practices have changed. I've never worked in industry, but based on what I've read there are some pretty good processes that are supposed to have some empirical support, just not many people adopt them. Like I read a paper from 2002 in which basically no companies would consistently use good processes.
Most of the material in my Software Engineering course is outdated, but I imagine most companies still try to get away with minimum security and slack on good software engineering practices, like code reviews and static analysis and thorough security requirements, or what have you. Using these processes in general tends to force simpler systems. Iterative development with clear thought out implementation per iteration etc.
It's worth remembering in recent times many companies that write software are not software companies and ones that are don't focus on the quality of software but rather the amount of revenue that can be derived from it.
The only industries that have good software practices are those that are regulated heavily enough for it to matter, see here medical, aviation, military etc.
Unfortunately the vast majority of software is not regulated in this way despite handling data that is potentially just as sensitive from a personal or even financial perspective.
At the end of the day most companies are motivated to produce software quickly and quality is second unless it's causing a reduction in velocity, even then this is simply treated as a debt that is paid down periodically to maintain velocity.
There are exceptions for things like banks that rely on the quality of software to avoid losing money, but we are talking in general here.
A brilliant example of what happens when you have sloppy security/bad incentives AND you underestimate the damage a breach would cause is the Ashley Madison situation. Many companies are in the same situation and have just been lucky enough to avoid a catastrophic data breach.
Sadly velocity is going to be valued over quality (which in turn means security) for the foreseeable future.
The automobile industry has heavy regulation for their engine (and similar) software, and their code seems to be pretty poor.
The big internet companies, like Google, Facebook etc, have no regulation on their code, yet adopt practices like code review.
Banks have pretty bad software quality, too. (I worked for one bank, and talked to lots of people.) Though that's a generalization: there's lots of places for software in a bank. The parts that directly handle the money tend to have less bugs emerging day to day, but that's more because of low velocity and operating within known parameters (so as not to trigger any lurking bugs in the edge cases).
I think it has more to do with the fact that in the case of Google, Facebook, etc, i.e. everyone that takes software practices seriously, software is their product. They live and die by the quality of their software: how fast it runs, how bug-free it is, how easy it is to change and extend, how well the reputation of their software practices can attract the most talented software developers, etc.
For everyone else, software is an expense: it's something to be minimized and gotten over with as quickly as possible so they can direct their resources towards solving business problems in some other domain that actually brings in the cash.
I've never heard of any regulations governing software in ECUs in automotive. Do these exists anywhere? Does anyone actually regulate this? Because ECU software is typically very bad.
There are general road safety standards like ISO 26262 that car cover electronics and software.