Library Dependencies and the Open Source Supply Chain Nightmare


It’s a bigger problem than is immediately apparent, and has the potential for hacks as big as Equifax and as widespread as SolarWinds.


The universal need for speed and lack of resource in commercial app development requires developers to use free open-source software libraries. The difficulty is that there is no easy way to manage the open-source vulnerabilities that get included via the libraries into the finished commercial app.


The size of this problem has been analyzed in the new Contrast Labs 2021 Open-Source Security Report. The study looked at tens of thousands of real-world applications and APIs from Contrast’s own telemetry – and found a potentially serious problem.


First of all, the average application contains 118 open-source libraries. Many of these contain vulnerabilities, but many of the vulnerabilities afford no risk since only 38 percent of the libraries included in an app are actually used by the app.


Inside the library, the vulnerability may be found in just one class. However, in Java libraries, for instance, only 32 percent of the classes contained are invoked by the application. It is more than possible, then, that the finished app uses a library containing a known vulnerability that is of zero risk.


This is complicated by ‘transitive dependencies’, where a function consciously required from one library might actually rely on different additional libraries – which may inadvertently, and possibly unknowingly, be called and included in the shipped app.


DOWNSTREAM ISSUES


The result is that under-resourced teams need to manage vulnerabilities that may or may not be relevant within hundreds of libraries, possibly within many different apps, and always with the possibility that library updates may cause further downstream issues.


Teams have a choice between spending many precious hou ..

Support the originator by clicking the read the rest link below.