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 punishment known as the carrot and the stick. Software developers receive the carrot at the completion of a project, often in the form of pay, praise, and satisfaction. But when completed software is eventually breached by attackers the stick often falls directly on the network and security operations team. Once again, the original authors of the code may no longer be with the company to witness the repercussions of their failed software. This disconnect between the authoring of faulty code and the negative consequences of the software’s failure disables a feedback loop critical for self-improvement. Put simply, many developers never get the opportunity to learn from their mistakes.

What’s the Solution?

Some of the problems talked about here aren’t going to be fixed easily.  But there are some ways for an organization to combat the problem of vulnerabilities in code, both in development and during runtime.  There are a number of simple measures an organization can take to improve their web application security stance.  First starts at the very beginning of application development, and that’s making sure developers take security into consideration when developing and coding applications.  Second, is making sure that software and operating systems are kept up to date, with the latest updates and patches to ensure known vulnerabilities that have patches are not exploited.

In addition to these two fundamental starts to application security, there’s still a need to ensure security for web applications running in production, especially against threats either missed or not typically secured by network or system level security.  The OWASP Top 10 Web Application Security Risks we talked about earlier are a great example of risks that aren’t typically protected with network or system level security.

Take a Page from NIST to Improve Application Security

It is important to remember to have a security framework that offers a defense-in-depth architecture.  Maybe it’s time to take a hint from the recent finalization of the National Institute of Standards and Technology (NIST)’s SP800-53 that was just released on September 23, 2020.  The new security and privacy framework standard now requires Runtime Application Self-Protection (RASP) and Interactive Application Security Testing (IAST) as added layers of security in the framework.  IAST can help developers find more serious and critical vulnerabilities during the testing phases of development, and RASP protects applications in production from having vulnerabilities exploited.

---

Here at K2 Cyber Security, we’d like to help out with your RASP and IAST requirements.  K2 offers an ideal runtime protection security solution that detects true zero-day attacks, while at the same time generates the least false positives and alerts.  Rather than rely on technologies like signatures, heuristics, fuzzy logic, machine learning or AI, we use a deterministic approach to detect true zero-day attacks, without being limited to detecting attacks based on prior attack knowledge.  Deterministic security uses application execution validation, and verifies the API calls are functioning the way the code intended.  There is no use of any prior knowledge about an attack or the underlying vulnerability, which gives our approach the true ability to detect new zero-day attacks. Our technology has 8 patents granted/pending, and has no false alerts.

We’ve also recently published a video, The Need for Deterministic Security.  The video explains why the technologies used in today’s security tools, including web application firewalls (WAFs) fail to prevent zero day attacks and how deterministic security fills the need for detecting zero day attacks.  The video covers why technologies like artificial intelligence, machine learning, heuristics, fuzzy logic, pattern and signature matching fail to detect true zero day attacks, giving very specific examples of attacks where these technologies work, and where  they fail to detect an attack.

The video also explains why deterministic security works against true zero day attacks and how K2 uses deterministic security.  Watch the video now.

Change how you protect your applications, include RASP and check out K2’s application workload security.

Find out more about K2 today by requesting a demo, or get your free trial.