Synopsys: Going the distance with open source vulnerabilities

This is a guest post for Computer Weekly Open Source Insider written by Jim Ivers in his capacity as vice president at Synopsys’ Software Integrity Group.

Essentially, Synopsys specialises in  silicon chip design, verification, IP integration and application security testing for deployment in areas including Internet of Things (IoT), autonomous cars, wearables, smart medical devices and secure financial services.

Ivers writes as follows…

As open source continues to grow in popularity, many organisations are in the wrong lane and underprepared to race, much less win. The cost of losing could put your organisation into sticky territory, publicity wise.

When developers in your organisation use open source, they are putting your neck on the line because that open source component may contain vulnerabilities, which puts your organisation into difficult territory.

Disclosure of a vulnerability kicks off an IT security race. Hackers begin to ping externally facing websites to see whether they can find it. Running parallel, IT security folks are determining whether any of their sites have that vulnerability, closing it before the hackers get there (if yes). The results of hackers winning this race, is likely a data breach.

To illustrate; In March, a vulnerability was disclosed for a popular and widely used open source web server, Apache. This vulnerability involved Apache Struts, a component of the Apache server that helps Apache users manage and deliver site content. The race was then on. In September, Equifax announced that it had been breached, and that the Apache Struts vulnerability was the entry point. In the case of Equifax, the hackers won the race.

Acceleration of open source software

As open source continues to grow, such scenarios will likely repeat with increasing frequency. Studies say that most new software is up to 60% open source so, as open source grows, so too will vulnerabilities.

Organisations are ill-equipped to run the race because they do not understand their use of open source. They don’t have the proper organisational policies, they don’t educate their developer teams or deploy the proper tools to help secure and manage open source software.

Exploring this, it’s important to ask how many organisations track their use of open source? For the organisations who do, how do they do it?

Tracking open source

Many organisations have no process for tracking open source and, even for those who do, it may not make for pleasant reading. Tools exist to help organisations track their use of open source components. These software composition analysis (SCA) tools are readily available and have progressed significantly to keep pace with open source. But for many organisations, Excel is the tool of choice.

One or more people in the design process are tasked with keeping track of open source usage by logging it into a spreadsheet. This process relies on communication…What could go wrong? A lot.

If a vulnerability is discovered and your organisation has no process in place for managing open source, you would be forced to go through your applications one by one to determine whether they used the offending component. Until then, you would have no idea as to the risk to your organisation.

The spreadsheet would help, but you would then be at the mercy of the keeper of the record—and the communication of the developers—regarding how accurate this information is. This may save you time, but will leave you no better than those with no process in the long run.

Composition analysis

Then, software composition analysis enters the race.

Applying a software composition analysis (SCA) tool to the process changes the picture dramatically. An SCA tool should be able to perform some basic tasks for any development organisation:

  • Identify the open source components in the code.
  • Catalogue them in a digital repository that can be readily queried.
  • Evaluate – There are multiple sources for open source vulnerability data. The most commonly used is the National Vulnerability Database (NVD). These data sources can be referenced to see whether any of the open source in use has known vulnerabilities.

With an SCA tool, you would be able to quickly scan the information repository and know where vulnerabilities were used, and additional information about the version. Furthermore, anyone who tried to use the offending version of Apache Struts after the vulnerability was disclosed should get a warning about that vulnerability from the SCA tool, so the problem is addressed before the code is deployed.

Open source is clearly useful, but organisations need to know the risks. If you are going to toe the line, be prepared to race.