Image of developer in front of screen writing secure code code
Only 1 in 3 Developers Confident They are Writing Secure Code

Only 1 in 3 Developers Confident They are Writing Secure Code

In a shock finding contained in an October 2017 survey (infographic) released by technology vendor Nodesource and software security company Sqreen, it appears that only approximately one out of three developers express any confidence that they are writing secure code. However, perhaps the most startling finding of the survey is that the developer community is aware of the risks of this approach, but are unwilling to take advantage of the tools available that would mitigate against potential threats.

Executives concerned with insecure applications

That is not to say that the threats are not taken seriously. Executives know that there is an urgent need to mitigate the risks involved in developing complex apps. The survey found that 85 percent of CTOs and CIOs believe that their job requires taking security seriously, and more than a third of all respondents (34 percent) believe there is a strong chance their organization will be the target of a large-scale attack in the next six months. But conversely fewer than half of developers are confident that the code they write and run does not have security vulnerabilities.

If developers are not writing secure code, why aren’t they taking greater responsibility to ensure that they are producing applications that are secure? Joe McCann, Founder and CEO of NodeSource, suggest, “It may be the case that developers expect downstream teams – DevOps, QA, security – to look for vulnerabilities or risky code.”

Worrying concerns about writing secure code

If those statistics were not worrying enough, the full results of the survey paint an extensively dismal picture around developer concerns about secure code. For instance, 60 percent of developers aren’t confident in the security of their applications.

As for code written using tools supplied by third parties, 40 percent of developers feel that third-party modules pose the greatest risk to application security. Given that third parties supply many of the tools used by developers this is a definite vulnerability when it comes to writing secure code.

So, the narrative becomes marginally worse when developers are dependent on tools supplied by third parties. In fact, 40% of the developers don’t even check for known vulnerabilities when using the tools supplied by third parties.

When asked about this seemingly contradictory behavior, McCann suggest that, “It’s entirely possible that developers are concerned about application security, and recognize that third-party packages can be vulnerable, but don’t readily connect the two concepts. As an example, I know I need to save money to buy a house, but I pick up a $4 latte most days without thinking about it in the context of this other, house-related savings goal. It’s not that I don’t want to invest in the house, it’s just that on a daily basis the latte is within easy reach.”

Developers not doing enough for code reviews

Developer skepticism may be called healthy – and clearly most developers are concerned, however what are they actually doing about the problem of writing secure code? The logical response would be to find tools that will assist them in secure software development. But as this survey indicates – that’s not happening. Extensive code reviews are only one approach that would mitigate the problems – but less than 30 percent of developers use a combination of manual and automatic code reviews to identify potential weak points.

The reason could be today’s accelerated development cycles. McCann commented, “Manual code reviews are more time consuming by far than automated checks, so it may be the case that developers are choosing speed over security.”

This is not a problem that is limited to smaller companies – where the excuse could be that they lack the resources for extensive checking. 35 Percent of companies with fewer than 1,000 employees combine both code reviews and automated tools to check for vulnerabilities. But can those organizations truly claim that their coders do not have the resources. That seems a tremendously weak excuse when producing what could, in many instances be ‘mission critical’ code. Larger companies take the issue a bit more seriously with 62 percent saying they perform reviews and use tools to check that writing secure code is a priority.

And the problem seems to be that there is insufficient knowledge among developers about secure design and the threats that insecure data can play in exposing information to hackers, as well as the fact that many of these developers would have no idea of how to spot when their applications come under attack. The survey revealed that a staggering 79 percent of developers have poor to no insight as to when their applications are under attack.

Is writing secure code being prioritized?

The reaction from C-Suite executives show that there is widespread concern about the problems of writing secure code, however this concern needs to trickle down to developers – many of whom may simply think that the problem of secure applications is above their paygrade. However, consider the fact that the pace of application releases is continually accelerating. What was in past years a typical turnaround time of months can now be measured in weeks – and code is sometimes updated several times in a 24-hour period. This means that without proper coding techniques, developers are more likely to produce security flaws in their code and the likelihood of security vulnerabilities finding their way into today’s applications is a lot higher.

The takeaway from this survey is that manual reviews of code vulnerabilities is still an absolute necessity, but developers need to start to take advantage of a new generation of AI driven tools to help them move on from the manual approach.

40% of #developers feel that 3rd party modules pose the greatest risk, yet do not check for #vulnerabilities.Click to Tweet

McCann recommends that, “To extend the latte example, the solution is at least partially to be found in giving developers a “coffee maker” as a tool. In other words, provide an extremely low-friction way to replace an un-desirable behavior with choices that are more in line with larger goals. Make it easy to check for vulnerabilities and raise awareness about the quality and risks of third-party code, and you nudge developers toward a more security-friendly approach.”