...many Software Developers have come to implicitly trust OSS.
Our man-in-the-know Jack Card lifts the lid on Open Source Software libraries...
What is an OSS Library?
An Open Source Software (OSS) Library is a software library in which all the source code is available in the public domain. Such libraries are typically distributed in in source code form, but may also be made available in binary format to simplify their inclusion into software applications. As libraries they are therefore not complete application or solutions, but rather provide one or more features which an application might exploit.
The Growth in OSS Library usage
Over the last decade there has been a growing reliance on 3rd party OSS Libraries within many organisations. In fact the 2020 6th Annual Report on Open Source Software Development, carried out by Sonatype (an OSS oriented security company), indicated that 1.5 trillion OSS library download requests were made in the previous 12 months. As such these OSS Libraries typically provide the foundation upon which an application builds the business logic required by an organisation. Rarely, if ever nowadays, is a system built entirely from scratch.
Another report (the State of Application Security from Contrast Security) showed that in the more than 1,800 applications reviewed, OSS Libraries represented 79% of the code base of an application, with home grown custom code only representing 21%.
What is the issue with trust?
It is clear that modern software relies heavily on the use of OSS Libraries, however, this reliance may not always be obvious. As a short experiment we created a very basic Java Spring Boot 2 project. This project was configured using Spring Initializr and Maven. Initially only contained one explicit dependency (on the Spring Boot starter project). However, this one dependency brought in 18 separate library files, of which 8 were non-Spring, third-party, libraries. When the project was updated to include a second dependency, to support testing in a Spring Boot application, the number of libraries jumped to 46 of which 32 were non-Spring libraries.
The pervasive nature of OSS Libraries means that many software developers have come to implicitly trust such software. Here we mean trust in the sense of security rather than for example reliability. However, is this trust valid? The reports mentioned above include some sobering statistics such as 7 to 11% of all OSS Libraries possessed known vulnerabilities. In addition, the Sonatype survey indicates that there has been a 430% growth in Cyber-attacks that actively target weaknesses in OSS libraries. It is also worth noting that number 9 of the OWASP top ten web application security risks is ‘Using Components with Known Vulnerabilities’. This highlights just how common a problem this is.
These libraries are treated exactly the same as home grown, custom code. They are therefore placed inside any security bubble set up by an organisation or enterprise.
How trust in OSS Libraries can be undermined?
There are several ways in which trust in OSS libraries can be undermined including:
Do we really need to be worried?
To balance this discussion, we also need to look again at some of the statistics around the vulnerabilities in software applications.
Returning to the State of Application Security report it makes clear that although on average 79% of an applications code base is comprised of OSS, only 7% of the vulnerabilities found in an application originated in these libraries. Therefore 93% of the vulnerabilities found in applications originate in software created by an organisation’s developers.
How to rebuild confidence?
The key to maintaining confidence in OSS libraries is to be vigilant as an organisation. It is important to not blindly allow any and all libraries to be downloaded and used in applications without due care and consideration. Such governance of OSS Libraries can be based on several steps: