Software Composition Analysis

June 25, 2015 Ron Rymon

open source components management automated with WhiteSource

Software composition analysis researchers have shown that proprietary code portion has reduced from around 30%-50% at 2008 to around 20% at 2015. This due to the increased usage of open source components to increase software development and deployment rate.

How Does Your Software Composition Analysis Impact your Security?

It has long been practically impossible to develop software without relying substantially on publicly available open source components 1. Developers in all areas and all programming languages leverage open source components to develop better products, more quickly. Open source enables you to focus on your core tasks while basing on code developed by others, often over many years and involving substantial expertise.

Unfortunately, software security teams have been much more focused on securing their proprietary code, although their usage of open source components has skyrocketed.  Main technologies used for application security, like SAST and DAST, are not relevant when it comes to open source security. Add the fact that open source security vulnerabilities are known to all and you got yourself a problem.

On Average, Only 20% of Your Source Code Is Proprietary Code

A software composition analysis of a commercial software product typically shows at least 80% of the components being open source. Thus, whether you are a software vendor or an internal development team, upon releasing such software you take responsibility not only for the 20% proprietary code that your team wrote but also for all open source and other third-party components included in it. This responsibility goes beyond licensing issues and extends to bugs, performance issues, and yes – security vulnerabilities. The bottom line is that if your product includes a vulnerable open source component, then your entire product is vulnerable.

So should you be concerned about using open source components?

Absolutely not! It is more than reasonable to assume that your own code will not be safer than open source components. At least not until your own code matures substantially.

So what should you do?

We help you secure your open source components – download this guide to see how

Own up to the Responsibility That Comes with Open Source Usage

You simply need to own up to the fact that you need to manage your open source usage properly. In order to ensure the security and quality of the open source components in your software (license compliance is a different topic), you need to keep adhere to the following three principles:

#1 Know what you are using 

This software composition discovery is the most fundamental step. Without knowing EXACTLY what you use, you cannot know if any security vulnerability affects you and if a newly released version patches such vulnerability or addresses other important quality concerns.

There are several ways you can prepare and maintain an inventory list of all your open source components. In our experience, the manual Do-It-Yourself method simply does not work. You can ask your developers to keep a spreadsheet of all open source components and to update it every time they add or remove an open source component, but in all cases we have looked at we have identified significant gaps between what was documented and reality. You can read here to see why this method is very error prone.

Some large companies use source code scanning tools that search for snippets that resemble known open source libraries. This can work, but it is a costly and time consuming project, and, therefore, is usually not done continuously but only before a major release. This means you will only have an inventory list when the project is at its final stages, and if you’ll then discover components that do not meet your security and quality standards, the cost of replacing these components can be very high.

A much better option is to use a software composition analysis tool that integrates with your build tools. These tools automatically and immediately identify open source components, including all dependencies, as soon as they are adopted by one of the developers. Since its all automatic, your team no longer needs to waste time updating spreadsheets. This also ensures that your inventory list is always complete and accurate.

#2 Know when relevant security vulnerability are discovered

Newly discovered security vulnerabilities are routinely reported in the NIST database. Once you track your open source inventory, you will need to also track the NIST repository and check if any of the newly reported vulnerabilities apply to any of your open source components. This can be laborious of course since there are thousands of these published every month, and you will have to figure which ones affect the specific versions of the specific open source components you use. Unless you will make it a priority, you will only hear about the major CVEs, like Heartbleed  and Shellshock and this is obviously not enough.

Some of the modern software composition security analysis tools automate this process as well. They scan the NIST database continuously and proactively and immediately alert you whenever any of your products are affected by a vulnerable open source component. This enables you to act fast and decide how you wish to address these vulnerabilities (replace the problematic component, patch it, or add internal testing).

Download: The Main Application Security Technologies to Adopt in 2018

#3 Know when a security patch or new version are available 

Open source communities are often quick to fix vulnerabilities, and also bugs. But again, you need to follow their respective pages. Since a typical software product contains tens or even hundreds of open source components, this might be very problematic to handle manually.

Again, leading software composition analysis tools will automatically and immediately alert you on new versions, bug fixes, and security patches, so you do not need to have your team to waste time and efforts tracking databases.

‘Shift Left’ - Manage Security as Early as Possible in the Software Lifecycle

‘Shift-Left’ is the practice of addressing quality issues as early as possible in the software development process, from the notion that “Bugs are cheap when caught young.” This is applicable for both your proprietary and open source components.

As described above, manually tracking your open source usage, security vulnerability alerts and new patches or versions can be time-consuming and may detract your team from attaining their primary development goals in the best way. The only way to ensure the security and quality of your open source components without derailing your team is to automate the process.

‘Shift-Left’ practice can be implemented by integrating an automated management solution that alerts you during coding on any quality, security, and licensing issues. The more you wait, the greater the cost to replace or patch components and the greater is the risk that your product will be shipped with the security flaw.

Integrate an Automated Software Composition Analysis Tool into Your Build Process

WhiteSource is an open source composition analysis tool, which integrates into your build server or builds tools. It automates the entire process from the initial discovery of open source components, to ongoing tracking of inventory, enforcement of open source license policies, and proactively alerting on security vulnerability and bugs. Our solution is complete, covering all popular languages and development environments. It is effortless to deploy and use. Contact us to see how we can help you check the box on open source security: quickly, easily, and affordably.

For more details, please drop us a mail at or just request a free consultation to get full reports of your software’s open source. 

Previous Article
Clash of the Titans: Google, Apple and Microsoft Brace Themselves for Your Car’s Dashboard
Clash of the Titans: Google, Apple and Microsoft Brace Themselves for Your Car’s Dashboard

While the ideas of self-driving and connected cars sound tempting as ever, accessing even the basic mobile ...

Next Article
Leveraging Open Source to Step up the Automotive IVI Game
Leveraging Open Source to Step up the Automotive IVI Game

Fast forward a couple of years, and perhaps Linux will drive the IVI system in your car. And why not! The A...