The importance of being updated

The importance of being updated
The importance of being updated 

By Steven J. Vaughan-Nichols
Linux Watch
March 25, 2008

Palamida, an open-source risk management company, believes in open 
source. But at the same time, its corporate code audits of more than 500 
million lines of code has found time and again "specific open-source 
projects inside mission critical systems that had not been patched" with 
most recent updates.

Part of the problem? Many companies are unclear both about what programs 
they're using, never mind when and how to update them.

As Palamida pointed out in a statement shared with Linux-Watch, "nine 
out of 10 open-source projects do not have commercial services behind 
them (such as Red Hat, Novell, etc.) that can push the updates as they 
appear." Besides that, even companies that do a good job of tracking 
their open-source software can miss things. Palamida gave an example of 
one company, which thought it was doing a good job, but it turned out 
that instead of using 300 open-source projects, they were actually using 
835 programs.

The point? Even if you are using an open-source program, like the 
popular data compression library zlib which does a good job of patching 
problems, but you don't know that you're using zlib, how are you going 
to keep it up to date? Well, clearly, you're not.

In the case of some of these programs, you may not actually have a 
problem. For example, if you're running Linux from a major distributor 
such as Ubuntu, you don't need to worry much about keeping OpenSSH, the 
secure shell remote control program, current. Ubuntu will do that for 

On the other hand, Palamida pointed out that you may be using other 
open-source programs, such as Apache Geronimo, the open-source Java 
Enterprise Edition server, the BusyBox embedded tool kit or Freetype, a 
font-rendering engine, and you may be missing their updates.

So what do you do? According to Theresa Bui-Friday, co-founder of 
Palamida, in an e-mail interview, education comes first, "coupled with 
an in-house policy that is easy to understand and enforce. While many 
companies do a good job of tracking some of their open source through 
various means (from spreadsheets to e-mails), these methods aren't able 
to capture the breadth and scope of actual open-source use. Thus, 
undocumented code is left in the code base which leaves the organization 
open to vulnerabilities. If you don't know what you have, you don't know 
if it needs patching and can't effectively mitigate app sec risks."

Next, businesses should "implement an automated solution to regularly 
audit code." Palamida has several programs that can help with this.

These are IP Amplifier, which is a code-auditing tool and IP Authorizer, 
which helps ISVs (independent software vendors) make sure they're using 
approved code with the right licenses.

For ISVs, "We recommend at each build as the software dev process is so 
dynamic and fluid. Additionally, once a process has been put into place, 
we recommend that companies adopt a means for developers to register 
their open-source code use by receiving approval to use a specific 
project, say, Zlib, and then downloading the 'gold version' of that 
project, the most stable, up-to-date version, and adding it to what 
we've termed the 'Golden Vault' of open source. These would be the 
approved projects, in their most stable form, collected in a database 
wherein all of your developers can quickly and easily go to retrieve 
what they need without trolling the Web for a version that might be 
vulnerable and might not be on the approved use list," explained 

If a company is an ISV and facing an emergency, "such as product going 
to market and a serious flaw may have been found last minute, or an 
acquisition or a data breach has occurred and you're trying to find out 
why," Bui-Friday said "bringing in professionals is the quickest and 
easiest way to perform a thorough code audit. Due to their high level of 
expertise and knowledge of the audit process, the professional services 
arm of our organization can do an audit in three weeks that may take a 
company three months to handle on [its] own."

"Ideally, though," Bui-Friday continued, "organizations will be equipped 
to handle audits and we recommend that they start with the applications 
that mean the most to them, i.e., the areas that cause the most 
financial, security and business strain if it's not handled. You do not 
need to audit everything all at once. You need to prioritize based on 
business need. It's important to have a policy in place that outlines 
regular and complete code audits."

When all is said and done, Bui-Friday said, "We want organizations to be 
able to do away with incomplete manual processes and protect themselves 
against app security risks."

While obviously Palamida has its own business interest here, the points 
the company makes are excellent ones. A company needs to track its 
open-source programs, both for its own sake and for the sake of its 
customers. Otherwise it will eventually face a serious operations 
problem without even being able to understand exactly where the 
underlying software problem lies.

Subscribe to InfoSec News 

Site design & layout copyright © 1986-2014 CodeGods