Channels ▼

Should software vendors be held more accountable for 'failures of imagination'?

Imagine what it would be like if airlines like ours operated the same way most software and hardware vendors do when they develop products. Instead of operational goals of clean, safe, and reliable, we'd focus on timely departures and arrivals ("time-to-market"), total cost of ownership (TCO), and extending the feature set of our products. Sounds great, right? Maybe the airline industry could learn something from the hardware and software vendors out there.

In an effort to ensure time-to-market, what if we cut out those preflight checks? We rarely find anything wrong anyway. Next, considering the ever-increasing cost of crude—part of TCO—why don't we simply do away with routine maintenance? We'll perform maintenance only when a passenger informs us that smoke is coming from one of the engines, or that the plane is making a loud, clunky noise during flight. And as far as extending our product, well, we don't have much capital to do that, but I assure you that on my airline, we'll continue to offer food at mealtime.

To suggest that an airline would put anything before safety and reliability is absurd. But this is the environment consumers of technology have been forced to operate in for years, and it's what they've come to expect from vendors. For an airline, safety and reliability are operational values that are integral to the product/service we deliver to our customers. Is it unreasonable to expect the same precision, quality, and accountability from technology vendors, which will be the first to say that their products are playing an increasingly critical role in the success of businesses? I don't think so.

Nevertheless, the imposition of onerous penalties for failing to meet minimum security levels is probably not the best answer, since it would primarily help the big vendors that can absorb the cost of accountability or pass it on as a price increase. Small vendors and open-source projects would undoubtedly suffer more from such an initiative.

Technology consumers can do their part in holding vendors accountable by not buying insecure products, but this might be unrealistic for most organizations.

A more plausible alternative is to demand visibility into how vendors address security throughout their software-development life cycle, and to require them to provide customers and third parties with a clear means of assessing whether the vendors are fulfilling their stated, and self-imposed, policies. I know at least one vendor, Microsoft, that does this.

We need vendors to state publicly what their security policies and processes are, and then handle security incidents in a transparent-enough manner to let third parties verify their compliance. This would make it possible for current or potential customers to view software-security vulnerabilities as part of their risk-management process, where they can identify the risk associated with the use of software from a vendor and deploy risk-mitigation strategies commensurate with that risk.

From a policy perspective, this would help organizations decide whether or not they could tolerate the risk of using a technology that may provide a competitive advantage when deployed, but could cost too much for them to continue to operate, manage, and remediate over time. And if customers decided the risks outweighed the benefits, vendors would be forced to develop more security-conscious products. At Continental Airlines we've done this, for both products and services. In some cases, we elected not to use the product. In others, the business accepted the risk.

André Gold is chief information security officer at Continental Airlines. Previously, he served as technical director of Internet and network services, also at Continental.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.