Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

11/13/2017
07:20 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Frequent Software Releases, Updates May Injure App Security

The more frequently you release apps, the more security vulnerabilities you are likely to introduce in the code, a new study confirms.

The frequency with which you release and update software has more of an impact on application security than factors like code size and whether you are developing your apps in-house or offshore, according to new research.

CAST Research Labs recently analyzed a total of 1,388 applications developed using either Java EE or .Net. The company ran some 67 million rule-checks against a combined 278 million lines of code and unearthed 1.3 million weaknesses in them.

The exercise showed once again—like many have been saying for years—that while agile practices can accelerate application delivery and make it easier for developers to adapt to changing requirements, they can also heighten security risks. 

Specifically, CAST Research found that Java EE applications released more than six times per year tended to have a significantly higher density of known security weakness (Common Weakness Enumeration—CWE) compared to code released less than six times per year.

CAST's analysis showed that CWE density in Java EE applications remained fairly consistent regardless of the development methodology itself. In other words, Java-EE Applications developed using an agile/iterative model had roughly the same vulnerability densities as applications developed using a hybrid waterfall and agile method or a pure waterfall approach. What really made a difference to security was the frequency of updates and releases.

Interestingly, the results were statistically different with .Net applications. With .Net, applications that were developed using a traditional waterfall approach had a much higher CWE density compared to applications developed with agile, hybrid and even no methods at all.

"In Java we found that financial services and telecom had the highest densities, and that applications released to production more than six times per year were particularly vulnerable," says Bill Curtis, SVP and Chief Scientist at CAST Research Labs.

Meanwhile, others factors like application size and where the development work is done had less of an impact on vulnerability density.

Generally, the larger the code set, the more opportunities developers have to make coding errors such as SQL injection and cross-site scripting issues. So larger applications generally tend to have more security vulnerabilities in absolute terms than smaller apps. But vulnerability density—or the number of errors per one thousand lines of code—remains the same regardless of application size, CAST's analysis showed. The same was also the case for the source of the code.

"Interestingly, we did not find that whether an application was developed onshore or offshore, or whether it was developed in-house versus outsourced made a difference in CWE density."

CAST's study showed .Net applications on average having a higher CWE density than Java-EE applications. Most of the Java-EE apps across industries that CAST examined averaged five errors, or less, per one thousand lines of code.

In contrast, CWE density scores were much higher in .Net applications, especially in certain industries such as energy, insurance, and IT consulting. Many .Net applications that CAST analyzed had vulnerability densities in the 20- to 30-per-thousand lines of code range.

"We did not expect to see differences between Java and .NET in the pattern of factors related to CWE density, but they emerged," Curtis says.

Appsec has become a hot topic. The adoption of agile and continuous release cycles has put pressure on organizations to integrate security testing and proceses earlier and throughout the software development lifecycle. The trend is driving new DevSecOps approaches focused on unifying development, security, and operations teams into one common goal. Studies such as those by CAST highlight the need for such efforts.

"IT organizations must accept responsibility for providing training in secure architectural and coding practices to those deficient in these skills," Curtis says. 

In addition, organizations need to ensure they are using sound static, dynamic, and penetration testing techniques through the development cycle and that all vulnerabilities are patched as soon as possible. Dependencies and interactions with other applications or third-party software should be investigated for potential security weaknesses.

"Executive management owns the responsibility for ensuring cybersecure capabilities and enforcing cybersecure practices," he says.

Related Content:

 

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
SchemaCzar
50%
50%
SchemaCzar,
User Rank: Strategist
11/16/2017 | 11:38:55 AM
Java EE and .NET? What about mobile?
This is important information, but the title does not make clear that it does not apply to all development/deployment platforms. 
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.