Filling Java's security hole

Spotlight on: Coverity, solving Java’s security headache

Chris Mayer
Coverity

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

Author
Comments
comments powered by Disqus