Why Do Developers Continue to Write Vulnerable Code?
It’s been 18 years since OWASP first published their list of Top 10 Web Application Security Risks in 2003. It wouldn’t be unreasonable to think it would have been possible to solve web application security problems in that time frame. Yet, attacks continue to happen, and successfully target vulnerabilities in web applications. It would be easy to blame the success of these continued cyber attacks directly on the software developers who write the code. After all, if developers all wrote secure code, then most of the problem with cyber attacks on vulnerabilities would already be solved, since there would be no more vulnerabilities. We have to believe that software developers are not intentionally writing vulnerable code, either out of malice or laziness. It would be hard to imagine that anyone would want their names or professional reputations associated with a high-profile security breach. One has to wonder then, what causes the ongoing issue of developers writing and developing code with vulnerabilities? Problem 1: The Project Management Triangle
If you ask most coders and developers about the Project Management Triangle , they’d probably be able to tell you they’ve heard of it. The triangle refers to a project management maxim that states any job can be done “ fast, cheap, or good — pick two,” essentially it’s possible to get: fast and cheap, but not good; fast and good, but not cheap; or cheap and good, but not fast. It’s not unusual for software development organizations to focus on two primary goals: minimizing development expenses and releasing the product quickly. Software applications and services are often scheduled on tight deadlines, preventing developers from performing exhaustive security checks on their code. Many organizations opt for fast and cheap , at the expense of good — perhaps hoping any problems can be resolved with future updates, or that the code will be sufficiently protected by their security defenses. In fact we know that 79% of organizations knowingly push code to production that with existing vulnerabilities , a side effect of the need to get to production quickly. Problem 2: Undiscovered Vulnerabilities
Another significant issue is that code vulnerabilities may go undiscovered for a significant period of time. In fact a study found that vulnerabilities in open source code existed for four years before being detected . By the time a critical flaw is discovered in some code the original developer may have already moved on to other opportunities and companies. The net effect of this delay between the writing of vulnerable code and its exploitation means many developers may never discover their errors, meaning they never learn from their mistakes. In fact, they may go on writing code for years, in several different organizations, making the same coding errors and mistakes. Problem 3: Misplaced Incentives
One final issue contributing to developers continuing to write vulnerable code is the problem of misplaced incentives. Incentives often play a role in creating vulnerable software as well. Pretty much everyone knows the axiom about reward and […]
