As open source projects proliferate, so does the risk of using these tools carelessly.
Open source governance is the practice of defining a detailed policy and process around an organization’s use of open source tools. It helps an organization understand the tools and their risks.
Open source software governance helps developers manage how they use open source tools to optimize open source software while reducing risk. Let’s explore some tips for reducing security risks and increasing accountability when using open source software.
Scan open source libraries for vulnerabilities
Open source libraries in software development projects are incredibly popular. Leveraging open source projects has led to the success of countless software projects. It is 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 application-specific functionality, while leveraging mature, well-tested software to handle standardized protocols, such as secure sockets layer and HTTP.
However, there are rare instances where open source libraries have bugs and security vulnerabilities, which can have a huge and catastrophic effect. For example, the Log4Shell Vulnerability in Apache’s Log4j open-source logging library puts millions of systems at risk. The very popularity of Log4j meant that overnight organizations had 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, for example via CLI, Apache Maven plugin, Ant task or Jenkins plugin, allowing easy integration into any CI/CD pipeline .
Using a tool that creates actionable reports is only as valuable as the process around the tool. Run OWASP Dependency-Check on a consistent schedule to scan the codebase against the latest updates of newly discovered CVEs. Spend 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 software and distribution types, the application source code may not allow certain open source tools. For example, a license such as the GNU General Public License version 3 specifies that any project that relies on the work of another creator under the GPLv3 license must be available to the public, just like the original project.
Failure to comply with the terms of these licenses results in costly legal consequences for the organization. ScanCode Toolkit is a standalone command-line tool that scans a project and creates a report of the various licenses that govern open source components in a project’s source code. ScanCode Toolkit is completely open source and is available on GitHub. ScanCode Toolkit simplifies the tedious process of understanding a project’s open source dependencies.
Understand that a project not only has direct dependencies, where the application source code explicitly references certain third-party software projects, but also indirect dependencies. Indirect dependencies are third-party software projects used by direct dependencies.
Developers must obey the licenses of direct dependencies, as their source code is built on these third-party software projects. And because indirect dependencies are also part of a software’s source code, developers must also comply with them. ScanCode Toolkit is written in Python and designed to be extensible, with a plugin system to add functionality to scans.
Configure GitHub Code Owners
Use the “code owners” feature on GitHub to hold contributing developers accountable for new changes 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 code base. Reviewers receive a notification when a pull request opens on the matching parts of the repository assigned to them.
This feature, combined with branch protections, ensures that developers can review all pull requests before they merge into the master branch. This combination produces a higher level of quality assurance, as the contributors who know the modified files best verify the changes.