Filling Java's security hole

Spotlight on: Coverity, solving Java’s security headache

Chris Mayer

We talk to Coverity co-founder Andy Chou about his company’s mission of bringing security testing back into the development phase.

If you’ve cast your eye over tech sites in recent months, you’ve probably the notice the barrage of bad press that Java’s been getting for security vulnerabilities.

Granted, we’re mostly talking about the client-side, but it’s particularly toxic for the entire Java brand, especially when Apple withdrew the Java applet from Mac browsers. While the more savvy tech lead is aware of the stark difference between the Java stack and Java’s relationship to the browser, the tech-novice executive making the calls might not be.

But is there actually a problem right at the heart of the development process, with how Java developers deal with security problems? Development testing experts Coverity argue that there needs to be a rethink entirely.

Co-founder Andy Chou believes that many vulnerabilities present in the Java stack are easily avoidable, through detecting them as early as possible, rather than passing the buck down to the security auditor in QA.

“Right now, if you ask a developer to test their software before they ship it, what do they say?  ‘Well, I’ve tested it.’ What does that mean exactly? It doesn’t mean much of anything really. There’s no measurement of whether that’s good enough,” Chou explains.

“What does the company say is a good enough level of testing for a new developer on the team? You don’t know. They come with their own practices, their own ideas of what testing means to them. If they’re not doing something consistent, it’s not going to be consistent across the company.”

There’s a feeling within some development environments, says Chou, that security testing is merely an afterthought, or something that the security team will deal with later on. The problem with this approach is that by the time your application reaches QA and you find a defect, the amount of work needed to solve the problem often wastes valuable time and money. It also likely makes the relationship between the two teams increasingly fractured.

Chou believes security testing ought to be baked into the development process to alleviate the problem, yet he also recognises that Java developers rightly avoid dealing with security because of its complexity.

“Our objective as a company to help organisations move detection of quality and security defects closer to the development stage. If you look at typical processes, you’ve got a security auditing team who will come in and maybe audit your application once a year or once every two years,” says Chou, deeming this as “inefficient”.

“It takes a retest of your entire software just to fix a defect. What we think is instead of that security should be baked into the development process – it should be done on a regular basis.”

To aid Java developers, Coverity’s trio of products hunt through source code and provide hints in how to patch up some of the most common vulnerabilities. Their flagship product, Quality Advisor, analyses the entire stack for potential crash-causing defects and offers guidance in solving the issue. Security Advisor is specifically tuned to finding defects such as cross-site scripting and SQL injection, and again provides remediation advice. The newest tool, Test Advisor, aims to improve unit testing efficiency by focusing on the most critical aspects of the code alone.

Chou explains that Coverity’s tools are designed to seamlessly integrate into their normal workflow, making it “easier for developers to go in and prioritise”. Yet he also believes that the fractured security testing culture is not solely down to the individual developer.

“Somebody in the organisation has to play the role of the lead or architect and decide the policy for what is important. Once they do that, they can set that up and automate that. Not necessarily individual developers making that judgement but rather the organisation as a whole.”

SQL injection and cross-site scripting remain the two most common vulnerabilities across Java web applications, which Chou puts down to two factors – developers not knowing how to deal with them correctly and also the interaction between Java and the Web.

“If you look at cross-site scripting for example, it’s partly because of the architecture of the web, in the way languages are used and the way the browser works. Rather than any particular problem with Java per se.” says Chou.

He adds: “What I’m saying is that Java treats the output of HTML just like any other data. It doesn’t really deeply understand it enough to help you. You have to know what you’re doing. Developers tend to not know what they are doing when it comes to security – that’s what it boils down to.”

Coverity are lending Java developers a hand by open sourcing a Java library of a dozen or so escaping routines. Importantly, it’s freely available without having to sign up to Coverity’s commercial products. Coverity Security Library is available to use via Github and Maven.

It’s logical to target the Java developers first and hopefully instigate a discussion between the development team and security auditors. But Coverity realise that for the approach of old to disappear entirely then the developers needs remove the “tendency to challenge” the auditor.

Chou adds: “I think that tendency rises because it’s at the wrong time. If they recognise that if we could just bake this into the process, if we could design the way in which we’re coding is done so we could avoid these vulnerabilities.

“I think that’s the wrong approach. It’s a very short-term approach. I think developers have a role to play in changing the conversation.”

Photo Courtesy of Moyan Brenn

Inline Feedbacks
View all comments