Developers Held Liable for Software Bugs?

Hold software developers liable for security defects in their products!

Well, that’s what former White House and Microsoft security advisor

Howard Schmidt says, anyway.

For sure, I’ve seen so many buffer overflow bugs that resulted in the

remote execution of arbitrary code — the penultimate software security

defect — I’ve wanted to scream. But hold the developers liable? That’s a

small word with huge ramifications in these United States.

No, I don’t believe we’re anywhere near ready to take such a drastic

step. Let’s make sure we point the car in the right direction before we

hit the gas.

Allow me to explain.

I’ll bet Mr. Schmidt was thinking about other engineering disciplines

when he made the suggestion at ISC2’s SecureLondon conference recently.

And it’s true in some engineering disciplines, we do hold the

professional engineers liable for their design failures, particularly

when public safety is involved. However, we mustn’t forget there’s a

world of difference between the practices in use in software engineering

than in, say, civil engineering.

When a civil engineer sets out to design a bridge, he calculates the

loads the bridge is likely to have to withstand (e.g., cars, trucks,

pedestrians, wind, temperature changes). At the end of the analysis, a

factor of safety is applied to the estimate and he looks up what size

beams and such to use for the structure. Neglecting to use the minimum

strength beams exposes the approving professional engineer to liability

for the structure’s failure.

In that engineering world, the beam sizes and such are published in the

form of structural codes — standards to which the engineers base their

designs on. These tables were developed over decades of use and analysis,

as well as trial and error. What physics student can forget the film

footage of the famous Tacoma Narrows Bridge that collapsed due to

harmonic loading generated by wind?

Even if one looks at the latest advances in software security best

practices — and there are several that are worthy of note — we’re a far

cry away from any sort of published standards that can hold a candle to

what civil engineers use.

And yes, as I said, there has been significant work done in the best

practices arena for software engineers to learn from. This includes the

Department of Homeland Security’s Build Security In

effort and the Open Web Application

Security Project. Each of these useful projects include actionable

guidance, and I believe they’ll go a long way to improving the overall

state of software security as they’re adopted.

But make no mistake about it: these are not standards, but best

practices. And there’s a vast difference between the two.

Let’s also not forget that civilization was building bridges for (no

doubt) centuries before it got to a point that it could hold engineers

liable for their failures. The best practice efforts cited here need to

be tested, used, and refined for at least several years before they’re

remotely ready for that sort of thing.

I also should add that it would be a mistake to interpret what I’m saying

here as defending shoddy software development practices in any way.

Indeed, I find it staggeringly frustrating to see the same mistakes made

time and time again, year after year. The 1988 Internet worm that Robert

Morris wrote and launched exploited, among other things, a buffer

overflow in the Berkeley UNIX finger daemon. From my perspective, that

greatly analyzed and publicized security failure should have marked the

end of the buffer overflow, but a quick glance at the headlines is all

that’s needed to correct that misguided expectation.

But, perhaps these repeated mistakes also are the fault of our

community’s reluctance to truly learn from its mistakes.

Here, I like to cite the transportation industry as a prime example. They

do a spectacular job at studying their failures in painstaking detail and

publishing their results for all to learn from. The software world needs

to do a much better job at emulating this practice.

Sure enough, shoddy software security is pervasive and we’ve got to

demand better from our product developers. It’s also a huge factor in

preventing us from really getting the most out of the incredible

technologies that have been developed recently. Secure software should be

perceived as a business enabler, not an inhibitor, in much the same way a

car’s brakes enable us to drive fast.

But we’re still a long way from even being able to seriously consider

holding developers liable. Instead, we should be considering other

measures, such as public embarrassment, ostracizing, and the like. Heck,

some bugs might even warrant public caning.

No, I’m just kidding… sort of. My patience buffer must have overflowed.