Application Security Trend Report

+ Full Text

AppSec Trend Report Defending the end-to-end lifecycle



Key Research Findings By Jordan Baker, Publications Associate at DZone

Demographics For this first-ever Trend Report, we received 1,870 responses to our community survey on the topic of Application Security (AppSec), with a 51% completion rating. The following is the basic demographic information of this group of respondents.

ence in the IT industry.

fight against vulnerabilities will continue to

▶▶ Source code analysis is growing as an

AppSec testing technique

-- Respondents work for companies that develop three main kinds of

• 87% develop web applications

▶▶ The role of application developers in the

gain visibility

-- Over half (65%) of respondents have 10 or more years of experi-



▶▶ Regulatory requirements will be the main

factor shaping AppSec policy over the next 12 months

• 60% develop enterprise business applications • 44% develop native mobile apps -- Within these organizations, respondents fill

three main roles:

In your personal opinion, who (or what) should be primarily accountable for application security?

• 38% are developers/engineers • 22% work as developer team leads • 19% are architects -- A majority of respondents work for enter-

prise-level organizations:


• 27% work for organizations sized 100-999 • 22% work for organizations sized 10,000+ • 19% work for organizations sized 1,000-

9,999 -- Despite working for such large organiza-



tions, most respondents tend to work in immediate teams of under 10 people.



• 35% work in 2-5 person teams

How familiar are you personally with the OWASP Top 10?

• 31% work in 6-10 person teams • 13% work in 11-15 person teams


-- Respondents’ organizations tend to use at

least one of four main programming language




• 81% use Java • 74% use client-side JavaScript

• 48% work with the Node.js (server-side

JavaScript) ecosystem • 42% work in the Python ecosystem -- Despite the wide variance in language ecosystems used by respondents’ organizations, 57% reported using Java as their

primary programming language at work.

Security and Developers Developers as the First Line of Defense

With the advent and continuing influence of the shift-left movement among the AppSec community, the role of application developers in the fight against vulnerabilities has increased steadily over the past several years. This year proved no exception. In our 2018 security survey, we found that 42% of respondents thought developers ought to be primarily accountable for application security; in our 2019 survey, this number rose to 46%. Interestingly, the number of respondents who believe security teams should be primarily responsible for AppSec fell from 31% in 2018 to 24% in 2019. Clearly developers have been placed square in the middle of the AppSec conversation. And, for the most part, developers seem to have taken up this banner rather seamlessly. Of those respondents who currently work as developers, 32% consider themselves to be familiar with, and 7% say they are very familiar with, the OWASP Top 10. There is still work to be done in the developer community in becoming more aware of the top vulnerabilities that exist in the wild, as 40% of respondents who identified as developers told us they have simply heard of the OWASP Top 10, but cannot claim any proficiency in it, while another 20% said they have never heard of the OWASP Top 10. Ultimately, these developer-specific responses matched the overall pattern of familiarity with the OWASP Top 10 among the general survey population. Among all respondents, 33% claim familiarity with the OWASP Top 10, 33% said they have heard of it, 23% told us they have never heard of it (down from 37% in 2018), and 11% said they are very familiar with the OWASP Top 10 (up from 8% in 2018). Which security threat is your organization planning on allocationg the most resources to in the next 12 months?

Writing Secure Code

As we’ve seen, developers are more frequently


becoming the de facto security experts for their

cyberattacks. But what techniques are they using in






organization and the first line of defense against their AppSec efforts? When we asked survey takers what secure coding techniques their organizations use, a variety of answers proved popular. These secure coding techniques included: • Validating inputs (75%) • Architecting and designing for security policies (64%) • Making permission explicit and denial default (47%)


How is sufficient testing determined for applications at your organization?

• Using a secure coding standard (44%) • Executing all processes with the least set of privi-


leges necessary to do the job (41%) • Sanitizing data before sending it to other sys-

tems (41%)


While most of these answers are fairly precise techniques, let’s explore the two more vague options, architecting and designing for security policies and using secure coding


standards, a little further. Beginning our examination at the architectural level, we find that over half of respondents use the following patterns when enabling

security protocols in their applications: authentication/ authorization protocols (81%); roles (70%); sessions (54%); secure access layers (53%). As we can see, auth protocols proved the most popular means of building security into an application’s architecture. This point was hammered home when we asked respondents how they personally verify message integrity in their application code, and 75% reported that they use authentication tokens (including digital signatures). Another important secure coding technique reported by respondents is the avoidance of buffer overflows. According to OWASP, a buffer overflow is defined as follows: “A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold or when a program attempts to put data in a memory area past a buffer. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers. Writing outside the bounds of a block of allocated memory can corrupt data, crash the program, or cause the execution of malicious code.” At which stage of the application development lifecycle does your organization spend the most time on application security? 






As a vast majority of modern applications use, have access to, and produce large amounts of data, this is a good problem to avoid. Among the techniques used to avoid buffer overflows, survey takers reported the following as the most popular: code auditing (35%); bounds checking (31%); the use of compiler tools (29%); only coding in strongly-typed languages with no DMA, including libraries (23%). To ensure that their applications are safe from malicious code and contain no vulnerabilities, respondents reported using four main testing strategies to determine just how safe their code is. Interestingly, we saw some variance of these practices’ adoption rates over last

year. Source code analysis proved the most popular AppSec testing technique among survey takers, with a 22% adoption rating; in our 2018 security survey, source code analysis had a 14% adoption rate among respondents. Additionally, in this year’s survey we found that 16% of respondents use penetration testing, also known as pentesting; this, however, constituted a rather large drop in the usage of this technique among our survey takers, as pentesting had a 24% adoption rating in our 2018 security survey.

Security and Enterprises Defending at Scale

For defending large-scale applications such as the ones our respondents develop, having a well-defined application development lifecycle is crucial. And, for AppSec, knowing when in this lifecycle to implement security protocols can seriously affect the efficacy



of your security efforts. For over a quarter of respondents (29%), their organizations spend the most time on application security during the design phase of the SDLC. Another 26% of survey takers told us that their organizations tend to spend the most time on security during the implementation (i.e. actual coding) phase of their software development. This trend of working heavily with AppSec in the first half of the SDLC among respondents’ organizations could well be caused by the popularity of the shift left movement discussed earlier in this report. To learn how, on an organizational level, enterprises attempt to determine the effectiveness of their AppSec, we asked respondents how their organizations determine sufficient security testing for their applications. Alarmingly, 42% of respondents reported that security testing is never sufficiently covered. But, for those who do perform a high degree of security testing, two options proved the most popular: addressing the attack surface (37%) and handling the threat model (35%). Perhaps as a consequence of the lack of security testing noted above, 12% of respondents reported that one-in-five deployments, or more, contain known security vulnerabilities. Looking Ahead

When it comes to defending software at scale, enterprises must be forward-looking. As such, we asked respondents what their organizations will be doing and/or prioritizing over the next 12 months. We began by asking survey takers which threats their organizations are planning on allocating the most resources. 23% said phishing attacks, 10% said they’ll focus on DDoS, 8% reported ransomware, and another 8% said SQL injection. To understand how they mean to defend against these threats, we asked what APIs and implementations organizations planned on using for encryption. Three main responses prevailed here: 63% reported they plan on using OpenSSL; 24% told us they will be using Bouncy Castle; 19% said they’ll use the Crypto package for Node.js. What percent of your organization’s deployments contain known security vulnerablities?

Following these questions about more technical decisions, we asked respondents what will have the highest impact on their organizations’ AppSec decisions over the next


12 months. Over half (58%) reported that regulatory requirements will be the main factor shaping AppSec policy moving forward. Other popular responses were customer requirements (49%) and the findings/work of security awareness organizations like OWASP and SANS (43%). To better understand the software factors effected by these decisions, we asked respondents to select one of four factors that affects AppSec that their organization plans to prioritize. The results are as follows: 38% will prioritize security; 25% will prioritize performance; 21% will prioritize scalability; and 16% will prioritize maintainability.



Diving Deeper Into AppSec Books

Zones Security Zone The goal of the Zone is to help

Agile Application Security Application security

prepare the people who make and support those appli-

and agile methodology don’t in-

cations stay up to date on industry best practices, remain

herently play well together, but this

aware of new and omnipresent threats, and help them to

book shows how to successfully

think “security-first.”

integrate the two worlds.

The Web Application Hacker’s Handbook, Second Edition The second — and most recent — edition of this

Integration Zone The Integration Zone focuses on communication architectures, message brokers, enterprise applications, ESBs, integration protocols, web services, service-oriented architecture (SOA), message-oriented middleware (MOM), and API management.

book was published in 2011, but don’t be alarmed. The architecture

Web Dev Zone Web professionals make up one

of the web is still basically the same, and this is one of

of the largest sections of IT audiences; we are collecting

the best foundational books out there.

content that helps Web professionals navigate in a world

Security Automation with Ansible 2 Learn how to

of quickly changing language protocols, trending frameworks, and new standards for UX.

leverage the open-source automation tool Ansible 2 to automate tasks like application security, network security, and malware analysis.



IoT Security Best Practices In this Refcard,

Security Voices Fascinating people are flying

we’ll look to define risk profiles for the most common

under the radar in the security industry. Listen to conver-

elements of an IoT system.

sations with them here.

Introduction to DNS Security In this Refcard we’ll look at how authoritative DNS’s ubiquity and critical position in application infrastructure create opportunities to dodge downtime and defend against threats.

Java Application Vulnerabilities Java

Application Security Podcast Appsec folks can enjoy topic breakdowns, interviews with appsec thought leaders, and coverage of a wide variety of technologies.

Applications, like any other, are susceptible to gaps in se-

Down the Security Rabbithole News from

curity. This Refcard focuses on the top vulnerabilities that

the security world, debates on hot topics, and debriefs

can affect Java applications and how to combat them.

from major security conferences.




Solutions for DevOps Challenges By Ivan Novikov, CEO at Wallarm

Comprehensive security for modern environments is no longer a fool’s paradise. There was a time when businesses had to choose between staying apace with development competition and slowing down for security. Now, security no longer has to run slow, or slow anyone else down. Modern security tech can solve the problems jeopardizing DevOps. Today’s application security teams face an accelerating pace of hacker attacks, diverse APIs, and rapidly changing code base. APIs, web applications, and microservices help DevOps but complicate application security. Processes—like code freezes for security testing and version control—have unfairly portrayed our protectors as pests mucking up the works. DevOps presents a seemingly impossible problem. New solutions specialize in areas where security struggles and DevOps blooms.

Goodbye Old Solutions Outdated security tools can clog up CI/CD pipeline—and overlook vulnerabilities, code anomalies, and attack payloads. Take legacy WAFs. Today, APIs needs to flow freely through more dynamic environments despite enormous and complex data loads. Traditional WAFs—based on signatures and regular expressions—cannot parse complex modern protocols. Nor can they keep pace with daily new hacker attacks. Similarly, resource-heavy legacy static analysis tools clog CI/CD pipelines. They scan indiscriminately, including previously scanned data. Traditional solutions simply don’t work for DevOps. It’s time for security to ‘shift left’ via automation and machine learning.

Superpower Existing Workflows Do not reinvent the pipeline. The only way security can work in tandem with the DevOps environment is to work inside it. That’s why we have designed solutions that plug into your architecture and workflows. Designed for continuous coverage, Wallarm works at the application level to provide stronger protection over diverse and scaling payloads. In development, Wallarm plugs into your workflow to transform existing tests into baselines that automatically run security testing. Post-release, we protect at the API level, applying machine learning and expanded intelligence. And all solutions deploy easy and stay that way. They start stronger out of the box and get better as you grow—no duplicative tests, super high false positives, nor manual rule configuration. We want to make security easy. With automation, there is no more heavy lifting. We run where you run: in public, private, or hybrid clouds. DZONE TREND REPORT: APPLICATION SECURIT Y


Secure your entire DevOps environment, not just parts of it Automate end-to-end application coverage with an adaptive security platform Wallarm delivers continuous protection with: Focused app, API, and serverless security Active threat verification & streamlined analysis Automated security testing in your CI/CD pipeline Native to any cloud—public, hybrid, or private

Featured integrations:

DZONE TREND REPORT: SECURIT Y Azure Google Cloud APPLICATION Amazon Web Kubernetes Platform Services