Part 1 of an as yet indeterminate number of posts about why application security has historically been broken, and what to do about it.
Software runs everything that is valuable for companies or governments. Software is written by companies and purchased by companies to solve business problems. Companies depend on customer data and intellectual property that software manages, stores, and safeguards.
Companies and governments are under attack. Competitors and foreign powers seek access to sensitive data. Criminals seek to access customer records for phishing purposes or for simple theft. Online vigilante groups express displeasure with companies’ actions by seeking to expose or embarrass the company via weaknesses in public facing applications.
Software is vulnerable. All software has bugs, and some bugs introduce weaknesses in the software that an attacker can use to impact the confidentiality, integrity, or availability of software and the data it safeguards.
The resources required to fix software vulnerabilities are in contention with other development priorities, including user features, functional bugs, and industry compliance requirements. Because software vulnerabilities are less directly visible to customers than the other items, fixing them gets a lower priority from the application’s business owner so fixing them comes last. As a result, most software suppliers produce insecure software.
Historically, software buyers have not considered security as a purchase criterion for software. Analyst firms including Gartner do not discuss application security when covering software firms and their products. Software vendors do not have a market incentive to create secure software or advertise the security quality of their applications. And software buyers have no leverage to get security fixes from a vendor once they have purchased the software. The marketplace is not currently acting to correct this information asymmetry; this is a classic market failure, specifically a moral hazard failure, in which the buyer does not have any information about the level of risk in the product they are purchasing.
So the challenge for those who would make software more secure is how to create a new dynamic, one in which software becomes more secure over time rather than less. We’ll talk about some ideas that have been tried, without much success, tomorrow.