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. 
Higher Education: 15 Books to Help Cybersecurity Pros Be Better
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
Worst Password Blunders of 2018 Hit Organizations East and West
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
2019 Attacker Playbook
Ericka Chickowski, Contributing Writer, Dark Reading,  12/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security 2018
This Dark Reading Tech Digest explores the biggest news stories of 2018 that shaped the cybersecurity landscape.
Flash Poll
[Sponsored Content] The State of Encryption and How to Improve It
[Sponsored Content] The State of Encryption and How to Improve It
Encryption and access controls are considered to be the ultimate safeguards to ensure the security and confidentiality of data, which is why they're mandated in so many compliance and regulatory standards. While the cybersecurity market boasts a wide variety of encryption technologies, many data breaches reveal that sensitive and personal data has often been left unencrypted and, therefore, vulnerable.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-19790
PUBLISHED: 2018-12-18
An open redirect was discovered in Symfony 2.7.x before 2.7.50, 2.8.x before 2.8.49, 3.x before 3.4.20, 4.0.x before 4.0.15, 4.1.x before 4.1.9 and 4.2.x before 4.2.1. By using backslashes in the `_failure_path` input field of login forms, an attacker can work around the redirection target restricti...
CVE-2018-19829
PUBLISHED: 2018-12-18
Artica Integria IMS 5.0.83 has CSRF in godmode/usuarios/lista_usuarios, resulting in the ability to delete an arbitrary user when the ID number is known.
CVE-2018-16884
PUBLISHED: 2018-12-18
A flaw was found in the Linux kernel in the NFS41+ subsystem. NFS41+ shares mounted in different network namespaces at the same time can make bc_svc_process() use wrong back-channel id and cause a use-after-free. Thus a malicious container user can cause a host kernel memory corruption and a system ...
CVE-2018-17777
PUBLISHED: 2018-12-18
An issue was discovered on D-Link DVA-5592 A1_WI_20180823 devices. If the PIN of the page "/ui/cbpc/login" is the default Parental Control PIN (0000), it is possible to bypass the login form by editing the path of the cookie "sid" generated by the page. The attacker will have acc...
CVE-2018-18921
PUBLISHED: 2018-12-18
PHP Server Monitor before 3.3.2 has CSRF, as demonstrated by a Delete action.