Stand on the shoulders of giants: About software composition analysis

More than 14 GiB worth of software depends on libpng! And that is only in the Arch Linux repositories, which is hardly the most popular Linux distribution. Also, this library is the official PNG reference library and is cross-platform, so certainly many other packages in other operating systems depend on it.

Now, back in 2015 when, libpng had not yet fixed the low-high palette bug, all the programs and libraries above were also automatically vulnerable to the same issue. Actually, this is what happened to Equifax with a vulnerability in Apache Struts. Same with many web services that use OpenSSL with Heartbleed.

If this could happen to such flagships as Bash, Qt, TeX and Xfce, it could happen to your organization. In fact, this problem is so common that it is part of the 2017 OWASP Top 10; they call it "A9: Using components with known vulnerabilities."

Given the rapid adoption of Free and Open Source Software (FOSS) by large companies, all of a sudden, dependency vulnerability appears to be one hell of a problem. Or rather, as yuppies would like to point out, a "business opportunity"?

Many providers of so-called software composition analysis (SCA) (don't google it) have since appeared in the security scene. Some of them are backed by long-standing companies; most are not. In fact, this business has gained such momentum that it is expected to grow more than 20% each year from now to 2022.

These companies, who owe so much to FOSS, tend to make it look bad when marketing their SCA. However, FOSS adoption is not slowing down. As we will try to show here, it is not FOSS's fault if applications use it with known vulnerabilities but rather that of the apps' owners.

Today’s applications use 30+ libraries on average, representing up to 80% of their code. Think of it as your code being only a thin layer upon a building of some tiny, some larger boxes. What SCA does then is look for vulnerabilities inside those boxes with information from external databases, which are then considered as vulnerabilities in your own app:

SCA scans all the blocks in your app building.

Instead of going from the alleged solution towards the source of the problem, let’s do it backwards.

The bad

FOSS is developed and used by thousands around the world. This can be a double-edged blade: On the one hand, according to "Linus's Law," bug-finding and patching should be easier as more eyes are involved. On the other hand, the lack of a centralized guide makes room for bugs.

One difference between FOSS and proprietary software is that, due to all its restrictions, bugs in the latter are “less likely” to become public as soon as in the case of the former. So all vulnerabilities in proprietary software are usually expected to be zero-day.

So if the source of the problem is not FOSS, what is it? The main reasons why so many companies suffer from A9:

• Not knowing used dependencies

• Ignorance of their vulnerabilities

• No continuous scanning for bugs

• Not testing for compatibility

• Component misconfiguration

In essence, it all boils down to a lack of communication between the user and the source of the components.

The good

So what can you do? OWASP recommends the following guidelines to prevent A9:

• Trim unnecessary dependencies, features, components etc. That way you have less to check.

• Continuously monitor components for updates and vulnerability reports.

• Only obtain components from trusted sources.

• Make these guidelines into a company policy.

There are specific tools that compare the version of the dependency you are using against both remote repositories (to check for updates) and vulnerability databases (to find out if any of your dependencies contain reported vulnerabilities that have not been fixed yet).

• For JavaScript you can use retire.js.

• Java users have the Versions plugin for Maven.

• Also for Java and .NET, you can use the OWASP Dependency-Check tool.

• There’s a Dependency check SonarQube plugin.

Note that the language-specific tools have to be integrated with the appropriate package manager, like npm or yarn with retire.

A bird’s eye view of how the process should integrate with your development flow is depicted by the following diagram provided by SourceClear.

Integrating SCA in your development flow.

We see that every time code is added, the whole system gets scanned for third-party software vulnerabilities and other issues easily identified by static analysis when code is not available. This is done by following this procedure:

1. Identify the dependencies on which your software is based.

2. Detect the versions of those dependencies.

3. Check the dependency master repository for updates.

4. Check one or several vulnerability databases, like CVE and NVD or your own.

5. Report the findings.

It is a simple process, really.

Notice that the integration is not fully automatic, and it should not be, since these tools could (and usually do) raise false alarms, so they are reviewed by human security experts.

Internally, the process of scanning for third-party software is the same for both proprietary software and FOSS, and it is a simple matter of querying the vulnerability databases as described above.

Speaking of integration, you may wonder: What if my app is deployed inside a container? "Over 30% of official images in Docker Hub contain high priority security vulnerabilities," according to PenTestIt. Fortunately, there are tools that go into your container and perform SCA inside of it (and more), like Anchore and Dockerscan.

The ugly

I know you did search for "software composition analysis" when I suggested you didn't. I just know you did. If you didn’t, good for you! Here’s what you’re missing out on:

"Software composition analysis" providers.

All of these industry-leading, award-winning, breakthrough-makers, oracles of the tech future want to sell you one thing: static code analysis plus the tools we discussed above.

While static analysis is a technique, it’s just a technique. It scans code and detects vulnerabilities and unhealthy practices but also encourages late detection and produces a lot of false positives.

You could try hiring such a service, and maybe even try to complement it with dynamic analysis tools like fuzzing and debuggers, but those have their own issues.

It’s worth noting that these are no replacement for good old-fashioned human code reviews. At least at the moment. According to Contrast Security,

The only way to deal with the risk of unknown vulnerabilities in libraries is to have someone who understands security analyze the source code. Static analysis of libraries is best thought of as providing hints where security vulnerabilities might be located in the code, not a replacement for experts.

In the future, we might see things like distributed on-demand security testing and machine learning algorithms using support vector machines to try to predict which commits are likely to open vulnerabilities, but in the meantime, stick to the tried-and-true.