Skip to main content

Properly managing open source library risks

25 May 2024

A significant portion of the software we develop today relies on open source libraries. While leveraging these libraries offers substantial advantages in terms of efficient software development, it also introduces inherent risks. Many organisations try to minimize these risks primarily by checking the open source libraries they use for known vulnerabilities. While this represents a important step in risk management, it is merely one aspect of comprehensive open source library risk management. Good risk management should focus on all phases of the Software Development Lifecycle, paying attention to the people, process and technology aspects of the Software Development Lifecycle.

Proper open source library risk management should consider the following steps:

  1. Training
  2. Selection
  3. Scanning
  4. Registration
  5. Safeguards
  6. Monitoring

1. Training

Everything start with training. Train your developers in understanding the risks, educate them in how to select the safest libraries and make sure they are aware of relevant policies.

2. Selection

Make sure that any library being used goes through some form of selection process. This could be a simple checklist listing properties expected of a good library, using a library quality rating solution or even scanning or reviewing the entire library. The goal should be to select libraries which are expected to pose a minimum amount of risk for your organisation. Selection should go beyond mere known issues and vulnerabilities but also look at properties like how many active maintainers work on the library, how quick are fixes rolled out, and so on. There are some good library quality rating solutions (like OpenSSF Scorecard and the Sonatype Safety Rating) available which can help make library selection a lot easier and more objective.

3. Scanning

All code should be scanned for known vulnerabilities in the libraries being used. Scanning should preferably be automated and included in any CI/CD pipelines. There are many commercial and free Software Composition Analysis (SCA) solutions available for this.

4. Registration

To properly manage library risks you need to know what libraries you use and where they are being used. Generating Software Bill Of Materials (SBOM’s) for all software you develop is the preferred way to accomplish this. Try to automate the SBOM generation process so your SBOM’s are always up-to-date. Make sure your SBOM’s are stored in a manageable way so you can easily search them.

5. Safeguards

No matter how good your developers are trained and no matter how much you trust your people and your processes there is always the chance that issues are not properly caught or prevented because processes are not followed or tools are not properly used. Whether this happens by accident or on purpose, you will want to have some safeguards in place which will absolutely prevent at least some forms of high-risk issues from entering your development lifecycle altogether. These safeguards can take many forms but should be used in such a way they cannot be circumvented. Usually, technical solutions are used that somehow fully block code with unwanted vulnerabilities to be released to production (quality gates). Blocking any libraries with known (high-risk) vulnerabilities from entering your network is another good option. Depending on your release process you can also embed additional manual checks to releases of high value applications as a final safeguard.

6. Monitoring

Once your applications are released to production you should keep a close watch for any new (or zero-day) vulnerabilities in any of the libraries used in those applications. Make sure you have a process in place to quickly (and possibly automatically) get notifications about which applications use libraries with new vulnerabilities. Teams should also have processes in place to quickly update (hotfix) these libraries when needed. Lastly, make sure you have the ability (tooling) to monitor for possible exploits of vulnerabilities so you can act quickly in case of an actual exploit.