Analyzing the Impact of Open Source Dependencies

There are a few factors driving the increased use of open source—digital transformation, competitive pressures, and innovation, to name a few. All valid. What I want to talk about, however, is the role dependencies play in the elevated volumes of open source playing out in all companies in all industries everywhere.

In most cases, developers can freely choose whatever open source components they want and integrate it with their software. Likewise, they may be unmindful to the number of open source libraries they are using due to dependencies.

Each year Revenera’s audit practice analyzes the last 12 to 15 audit projects of the year looking at what the numbers tells us. Prior to audit start we capture information on the organization’s general awareness of how much third-party content do they believe is in their code. Once the audit is complete, using open source scanning coupled with manual analysis, we create a better picture of what is being used. What we’ve identified is that the level of initial disclosure has been relatively flat and for the most part insignificant. And in fact, if you look at it compared to the level of average items found in an audit, it’s actually, percentage-wise, going down. However, there is a big increase in the overall composition of codebases.

The average number of items we typically find in an audit is in the upper 600’s. In 2012, however, that number was around 200. Our deduction is that sometime between 2014 and 2015 the use of package managers became more popular. Package managers is a technology used to automatically pulldown dependencies based on what a software engineer has specified is required software for their code to function. The ecosystem around various programming languages and their corresponding repository manager has grown.

Additionally, a lot of package managers have become technology agnostic. It is just a repository of various types of open source material and engineers can very easily encourage their build cycle to go pull down a particular set of packages in order to not re-implement that code.

The result is that all of these packages will have their own dependencies and the transitive dependency chain can be extremely deep and long. What that means is although you may rely on a small set of packages, when a product is fully built, it ends up with hundreds of packages development teams may not be aware is there.

In brief, this represents a huge increase in open source use in addition to a large source of unmitigated code. If you aren’t tracking your open source dependencies, you’ve lost visibility, control, and transparency over your software. It’s an important step in your software development strategy to both manage and track all open source libraries in order to manage up to your accepted level of risk within your organization.

 

Leave a Reply

Your email address will not be published. Required fields are marked *