Re: Might take a while
First, let me start out by saying that I agree we do need to learn to be better and safer as devs. And, yes, engineering has some things to teach us, because it is a technical discipline in problem-solving like ours. On that we don't disagree.
However, I think we could also learn from the medical profession in how to problem-solve in conditions of uncertainty, complex interactions, evolving threats and emerging base of knowledge. Sounds less like a fit than engineering so, just maybe we wouldn't be gulled into thinking that it was THE answer.
>Each bridge (or ship) is its own development
A bridge engineer will design many bridges in her life, but she won't necessarily switch to building airports. Yet, devs are mostly expected to switch subject matter and languages quite quickly.
>We most certainly do and they are getting better.
I took a quick looksee at wikipedia for formal methods, just to make sure I hadn't missed any new development about those and I found, as expected, that they are very costly and very limited in use. Hardly a solution for the average dev, is it? A bit like arguing that the design technique, funding and sheer expertise applied to building the Burj Khalifa are available to your local house builder.
They could be, if cost was no constraint.
On the other hand, the Reg has had several recent articles about applying automated analysis of software behavior in order to highlight possible security weak points. Now, the prospect of getting that to work gets me all hot and bothered, not your formal methods, sorry.
>I'm a developer, not a mathematician
Before becoming a dev I graduated with a BS in Electrical Engineering. What you don't get is how intrinsic math is to engineering. You start out building a solid foundation of math and then you learn how to apply the equations relevant to your particular field. Engineering is a combination of applied mathematics and then creativity/skill in the field, but math is foundational to any engineering field and the formalism that the mathematical underpinning allows is what gives engineering the qualities which the OP suggests we borrow from civil engineering.
There is no such underpinning mathematical foundation in general software.
So, no, we agree to disagree on that too.
Also, to be fair, many of the big hacks wouldn't be helped just by better coding. Heartbleed? Yes. Apples Yosemite root hack? Definitely.
Bradley Manning, copying hundreds of MB for classified docs? The system was working as designed. OPM hack, 22M profiles hacked? How many IT subsystems in the US Federal needed to trawl through 22M records? Shouldn't access on that scale have raised alarm bells? Shouldn't those records have been guarded like Fort Knox? Ditto Targets 40m cc hacks. What about Ashley Madison? Why did those morons really need to have the CC info on such a lucrative and publicity-shy bunch of users? What about all security issues due to compromised and reused passwords?
Better coders, yes. But how about deploying systems with better heuristics about normal vs anomalous use? Rate limiting access to sensitive data? Watch-dogging the networks to see when data flow from particular sensitive nodes are unexpectedly high? Most of all, how about borrowing, from the military, not the engineers, the notion of need-to-know. As in, limit which systems can access which data, at what rate. And, even more so, limit the data that your own organization retains in the first place. If you don't have some info, then getting hacked will not have compromised that info. The marketing gals will hate you for it, but it should be our first line of defense.
>Friends don't let friends code in flash
Extremely good point, but that is not a dev call. That is a system architect call, and to be frank, if all IT security weaknesses had as simple a solution as not using obviously unfit tools like Flash, then we wouldn't be in the shit storm we are in.