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

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. 
Microsoft Patches Wormable RCE Vulns in Remote Desktop Services
Kelly Sheridan, Staff Editor, Dark Reading,  8/13/2019
The Mainframe Is Seeing a Resurgence. Is Security Keeping Pace?
Ray Overby, Co-Founder & President at Key Resources, Inc.,  8/15/2019
GitHub Named in Capital One Breach Lawsuit
Dark Reading Staff 8/14/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-0173
PUBLISHED: 2019-08-19
Authentication bypass in the web console for Intel(R) Raid Web Console 2 all versions may allow an unauthenticated attacker to potentially enable disclosure of information via network access.
CVE-2019-11140
PUBLISHED: 2019-08-19
Insufficient session validation in system firmware for Intel(R) NUC may allow a privileged user to potentially enable escalation of privilege, denial of service and/or information disclosure via local access.
CVE-2019-11143
PUBLISHED: 2019-08-19
Improper permissions in the software installer for Intel(R) Authenticate before 3.8 may allow an authenticated user to potentially enable escalation of privilege via local access.
CVE-2019-11145
PUBLISHED: 2019-08-19
Improper file verification in Intel? Driver & Support Assistant before 19.7.30.2 may allow an authenticated user to potentially enable escalation of privilege via local access.
CVE-2019-11146
PUBLISHED: 2019-08-19
Improper file verification in Intel? Driver & Support Assistant before 19.7.30.2 may allow an authenticated user to potentially enable escalation of privilege via local access.