[DZone Research] AppSec, Secure Coding, and Security Testing

DZone 's Guide to

[DZone Research] AppSec, Secure Coding, and Security Testing

We take a look at some of the we collected in our 2018 Security Survey, looking at how developers secure and test their code.

· Security Zone ·
Free Resource

This article is part of the Key Research Findings from the 2018 DZone Guide to Security: Defending Your Code.

Secure Coding and DevSecOps

In our previous article, we established that security is becoming a greater concern among developers. Today, let’s explore how developers are approaching application security. When we asked at what stage of the SDLC respondents spend the most time implementing security measures, 33% said design, 28% said implementation, 14% said testing, and 13% said requirements gathering and analysis. The fact that a third of respondents implement security in their code in the design phase provides another indication that security is shifting left in the SDLC. This also means, however, that more effort is being put into securing new code than legacy code. In fact, 31% of respondents told us they spend more time per week securing new code, whereas 20% told us they spend more time securing legacy code. Another 31% reported spending equal amounts of time securing legacy and new code, but even with that demographic included, the security scales still tip toward new code.

When it comes to secure coding techniques, validating inputs proved the most popular option among respondents, with 74% of survey takers reporting to use this tactic. In 2017, however, 83% of our Security Survey respondents told us they validated inputs. Architecting and designing for security policies is a technique that seems to be on the rise, however. In 2017, 59% of respondents reported using this approach; this year, that number rose to 64%. Given the increased popularity of architecting and designing for security policies, let’s quickly examine the architectural patterns developers use to secure their code. The two most popular responses were roles and sessions, though these too saw a slight year-over-year decrease. 70% of respondents reported using roles as their architectural pattern, falling from 75% in 2017, and 62% reported using sessions as an architectural pattern, whereas 67% had told us they used sessions in 2017. Secure access layers came in a close third, with 61% of respondents telling us they use this pattern.

OpenSSL and Authentication Tokens

Within these larger architectural patterns, two means of securing code dominate. When we asked what APIs and implementations respondents use for encryption, 63% reported using OpenSSL. Interestingly, OpenSSL proved exceedingly more popular among respondents working as web application developers than those working as enterprise business application developers. Among web application developers, 87% reported using OpenSSL for their encryption purposes, whereas 52% of enterprise business application developers told us they use OpenSSL. Though OpenSSL dominated the responses, the Crypto package for Node.js saw an impressive year-over-year increase. 23% of this year’s respondents reported using Crypto, up from 16% in 2017.

The second means of securing code, which dominated responses, was the use of authentication tokens (including digital signatures) for verifying message integrity. 72% of survey takers said they use authentication tokens in their applications, while the second most popular option among respondents, the use of checksums, received only 34% of the responses. Unlike OpenSSL, however, the use of authentication tokens for securing application code proved relatively equal between web application developers and enterprise business application developers. 78% of respondents working as web app developers and 74% of enterprise business app developers use authentication tokens to secure their code.

Security Testing

Unlike the means by which developers secure their code, there’s no dominant form of testing. Among our respondents, 24% use penetration testing, 17% use security code review, 14% perform source code analysis, 13% do vulnerability assessments, and 12% have no formal security testing.

Given that the difference between the most and least popular form of testing is only 12%, let’s again use web app developers and enterprise business app developers as a point of comparison to get a more granular look at how respondents are using security testing. Penetration testing proved the most popular option among both web app and enterprise business app developers, receiving 27% of web app dev’s responses and 28% of business app dev’s responses. Interestingly, the second most popular option among web app developers was performing securing code reviews (18%), whereas for enterprise business app developers it was source code analysis (17%).

Despite the use of these testing techniques, 48% of respondents reported that among the applications they test for security, sufficient test coverage is never achieved. While that number is a bit troubling, it dropped from last year, when 54% of survey respondents reported inadequate test coverage. Additionally, 33% reported that the threat model is handled in an acceptable way, up from 27% in last year’s survey.


So, what's the common thread here? Among our respondents, no matter the type of applications they develop, there's a rather clear consensus on how best to approach application security. It begins in the design phase. Developers then work to validate inputs, integrate OpenSSL and authentication tokens, and, lastly, perform penetration testing. 

Indeed, this seems to be the process followed throughout the industry. Subject matter experts advocate secure coding practices in the architecting/design phase as a means of combating vulnerabilities. The Carnegie Mellon Software Engineering Institute ranks validating inputs as the number one means of securing data and nullifying potential harmful vulnerabilities. And, no less an organization than OWASP reports that penetration testing is the most popular for application security testing right now. 

That final point, however, comes with a caveat. According to OWASP

"While penetration testing has proven to be effective in network security, the technique does not naturally translate to applications. When penetration testing is performed on networks and operating systems, the majority of the work is involved in finding and then exploiting known vulnerabilities in specific technologies. As web applications are almost exclusively bespoke, penetration testing in the web application arena is more akin to pure research. Penetration testing tools have been developed that automate the process, but with the nature of web applications their effectiveness is usually poor."

Thus, as AppSec continues to evolve and security enters the SDLC earlier and earlier, looking to train developers and security professionals on testing techniques other than pen testing, such as threat modeling and source code review, will become necessary. 

This article is part of the Key Research Findings from the 2018 DZone Guide to Security: Defending Your Code.

appsec, devsecops, secure coding, security, security testing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}