Developers Can Do More to Up Their Security Game: Report

Developers can play a vital role in accelerating the adoption of AppSec practices, security vendor says.

Data from a new study suggests that there are several measures developers can take to accelerate the adoption of formalized application security practices at their organizations.

This includes developers thinking more like attackers when writing code, being more careful about third-party and open source component use, and being willing to use security experts as consultants rather than adversaries.

Security vendor Veracode recently analyzed data from some 400,000 scans of applications written in Java, .Net, Android, iOS, PHP, and several other languages at large, medium, and small organizations.

The analysis showed that many organizations are making progress integrating security into the software development lifecycle. For instance, more applications are being scanned for security vulnerabilities on a monthly or a more frequent basis than ever before, suggesting increased adoption of DevSecOps practices.

Compared to last year, 18% more of the applications in Veracode's study were scanned on a monthly basis, while the number of applications being scanned weekly jumped by nearly 50%. Veracode found that organizations are scanning more applications written in Java and .Net in particular. The increased scanning activity is, not surprisingly, leading to better error fix rates at these organizations.

Significantly, Veracode found that applications written in popular Web scripting languages such as JavaScript and PHP are not scanned as frequently and had a higher prevalence of major flaw categories like SQL injection (SQLi), cross-site scripting, cryptographic errors, and credentials. Some 47% of applications written in PHP, for instance, had a SQLi flaw, and 43% had a cross-site scripting flaw, while a relatively lower 31% of .Net applications had SQLi flaws and just 14% had XSS flaws.

Veracode's analysis also showed that organizations are making headway in terms of reducing the number of applications in their portfolio with very high severity flaws. Compared to last year, the ratio of applications with high and very high severity vulnerabilities declined by 26%.

While such data indicates that the long talked about trend toward DevOps and DevSecOps is finally happening, developers still can do more to accelerate AppSec practices, according to Veracode.

"Our scan data offers quantitative proof that those trends are happening," says Pete Chestna, director of developer engagement at Veracode. "Our scanning data indicates that applications are being scanned more frequently on average, and there's been a big growth over the past two years in applications that are scanned monthly or more often, which we think indicates a shift to more frequent code releases in DevOps."

But developers are being let down by a lack of security training in the education system and on the job, he says. "Developers are creating great code and secure code when they have the right training and security tools that work for them," Chestna notes.

For example, Veracode's analysis showed that developers who receive some online security training on the job fix, on average, 19% more flaws than developers who don't receive such training. Similarly, developers who receive remediation coaching from security experts fix an average of 88% more flaws, he says.

"Developers are responsible for remediating flaws. More and more, responsibility for security is shifting left to the developer," Chestna says. While implementing a formalized AppSec practice requires multi-stakeholder support, developers can take the initiative in accelerating the trend.

For instance, developers should begin to think more like an attacker would, Chestna says. "Consider whether your API or error messages are leaking information that an attacker could use to learn more about the application or user. Returning different errors in different situations — for example, "invalid user" vs. "invalid password" on authentication errors — can also help attackers find their way in," he says.

Developers also need to get a lot smarter about component use, Chestna notes. One of the startling findings in the Veracode study was the sheer number of Java applications — 88% — with at least one vulnerable component in them. "Developers frequently aren't tracking, or simply don’t know to begin with, what components are in the open source or third-party code they're using in their applications," Chestna says.

In addition to doing software composition analysis, developers need to make it a best practice to keep an up-to-date inventory of the components in their applications and use the most recent version. "Security teams and vulnerability managers need to update the components as soon as new vulnerabilities are discovered," he notes.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

An exploitable command injection vulnerability exists in the measurementBitrateExec functionality of Sony IPELA E Series Network Camera G5 firmware 1.87.00. A specially crafted GET request can cause arbitrary commands to be executed. An attacker can send an HTTP request to trigger this vulnerability...

In Eclipse Vert.x version 3.0 to 3.5.1, the HttpServer response headers and HttpClient request headers do not filter carriage return and line feed characters from the header value. This allow unfiltered values to inject a new header in the client request or server response.

In Eclipse OpenJ9 version 0.8, users other than the process owner may be able to use Java Attach API to connect to an Eclipse OpenJ9 or IBM JVM on the same machine and use Attach API operations, which includes the ability to execute untrusted native code. Attach API is enabled by default on Windows,...

Systems with microprocessors utilizing speculative execution and Intel software guard extensions (Intel SGX) may allow unauthorized disclosure of information residing in the L1 data cache from an enclave to an attacker with local user access via a side-channel analysis.