Trust in OSS Libraries – Are you worried enough?

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 3^rd 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:

• Software Bugs. Even assuming that there is no malicious intent involved in creating the software, an OSS Library may contain bugs or defects which leave it open to attack.
• Undetected Malware. In some cases, malware has been intentionally introduced into an OSS library. This means that if the library is then used in an application, the malware is now embedded in that system to be exploited. Remember there is often no one owner of an OSS library, and many different people and organisations may contribute to the code base. As such it may not be immediately obvious that malware has been introduced.
• Legitimate looking libraries. In other cases, threat actors have themselves created innocent looking libraries, that provide useful features, with the sole intent of fooling developers into integrating these libraries into their own code.
• Library Dependencies. One library often depends on one or more other libraries. In turn these sub libraries may well depend on further libraries etc. These transitive dependencies can result in an otherwise trustworthy library hierarchy relying on a weak or compromised library hidden deep down in the dependency hierarchy. The end result is that the overall system may expose issues or weaknesses that an attacker can exploit.

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:

• Review all OSS libraries. Don't just download libraries from the internet; instead have a process where a library (and versions of that library) can be requested. This process should then review the library to consider:

• Who are the authors and maintainers? Are they reputable? Are they known?
• Are there any current or reported security concerns related to the library?
• Are there any remediation steps to be taken to limit the effect of an issue or concern?
• Does the code pass review? This could involve manual or automated review processes. For example, many organisations use static code analysis tools or Software Composition Analysis which comprises a set of tools used for securing OSS components, to help identify malicious code or security weaknesses.

• Maintain a record of library usage. Ensure that a central record of library usage (and any dependencies to sub libraries) is explicitly maintained. This may be part of a Software Bill of Materials (SBOM) maintained for each project. This SBOM should list all of the libraries (whether OSS or not) that are used by that project.
• Monitor OSS libraries. Ensure that information relating to the OSS libraries being used is centrally monitored. This will ensure that when a vulnerability is reported the organization can react in a timely manner. This is particularly important as the State of Application Security report suggests that a vulnerability identified in OSS will be exploited within 3 days. It is thus critical that organisations are able to respond as quickly as possible to ensure that they do not become victims. For example on April 29^th 2020, F-Secure research announced a set of vulnerabilities for the open source SaltStack (aka Salt) platform. Simultaneously a fixed version of the platform was also released. However, within 3 days 26 organizations who had failed to update SaltStack had succumbed to malicious attacks.
• Have a remediation process. It is imperative that once a problem has been identified; organisations have a process that ensures all applications that use the library are considered and appropriate action is taken. Whether this action is to update the application with a new version of the library or to suspend use of the application may depend on the organisation. However, if this is not done then there is potential for far more damage to be done than may otherwise be incurred due to the inconvenience of update one or more libraries.

Here at Framework Training we have a number of Security Courses as well as a Web App Security and OWASP Training Course.