Improving open source software governance stature

Scan open source libraries for vulnerabilities

Open source libraries in software development projects are incredibly popular. Taking advantage of open source projects has enabled the success of countless software projects. It's impossible to use the internet without relying on the collaboration of many open source projects. When developers use open source libraries, they can focus on features specific to an application, while pulling in well-tested, mature software to handle standardized protocols, such as secure sockets layer and HTTP.

However, there are rare cases where open source libraries have bugs and security vulnerabilities, which can have an enormous, and catastrophic, effect. For example, the Log4Shell vulnerability in Apache's Log4j open source logging library put millions of systems at risk. The sheer popularity of Log4j meant that overnight, organizations needed to scramble to patch their software to prevent unauthorized control of secure systems.

The first line of defense against vulnerable open source libraries is to scan a project's dependencies for libraries known to have security vulnerabilities. OWASP Dependency-Check is a tool that returns a report that identifies vulnerable dependencies, along with their common vulnerabilities and exposures (CVEs). There are different ways to run OWASP Dependency-Check, such as via a command-line interface, an Apache Maven plugin, an Ant task or a Jenkins plugin, which enables easy integration into any CI/CD pipeline.

Using a tool that creates actionable reports is only as useful as the process enforced around the tool. Run OWASP Dependency-Check on a consistent schedule to scan the codebase against the latest updates of newly discovered CVEs. Dedicate time and plan for identified CVEs.

Adhere to licenses

When using open source dependencies, consider the licenses that govern their use. Licenses for open source projects define how to use, copy and distribute the software.

Depending on the application's software and distribution types, the application's source code might not permit certain open source tools. For example, a license like the GNU General Public License version 3 specifies that any project that builds on another creator's work licensed with GPLv3 must be publicly available just like the original project.

Breaking the terms in these licenses poses an organization costly legal consequences. ScanCode Toolkit is a standalone command line tool that scans a project and creates a report of the various licenses that govern the open source components in a project's source code. ScanCode Toolkit is completely open source and is available on GitHub. ScanCode Toolkit simplifies the time-consuming process to understand a project's open source dependencies.

Understand that a project has not only direct dependencies, where the application's source code explicitly references certain third-party software projects, but also indirect dependencies. Indirect dependencies are third-party software projects the direct dependencies use.

Developers must obey licenses from direct dependencies, as their source code is built on these third-party software projects. And because the indirect dependencies are also part of a software's source code, developers must obey them, as well. ScanCode Toolkit is written in Python and designed to be extensible, with a plugin system to add functionality to scans.

Set up GitHub code owners

Use the "code owners" feature on GitHub to hold contributing developers accountable for new changes introduced to open source projects. With this feature in a GitHub repository, developers can designate specific users as reviewers for changes introduced to certain parts of their codebase. Reviewers receive a notification when a pull request opens to the corresponding parts of the repository assigned to them.

This feature, paired with branch protections, ensures developers can review all pull requests before they merge into the main branch. This combination produces a greater level of quality assurance, because the contributors who are most familiar with the modified files verify the changes.