Open source software is everywhere in modern applications — it’s estimated that OSS comprises upwards of 90% of the average codebase. If you’ve worked with OSS, you’re probably familiar with many of the licenses that govern the use of open source code. These include permissive licenses like the MIT License and Apache License 2.0, copyleft licenses like GPL v2 and GPL v3, and plenty more.

But every once in a while, you might come across an open source project covered by a license with unusual terms. Dapr, a “portable, event-driven runtime” with nearly 15,000 stars on GitHub, found itself in that situation when an issue was opened regarding one of its dependencies: “bouk/monkey,” which is a monkey patching program for Golang.

The problem for Dapr — and the hundreds of other projects that depend on bouk/monkey — is that bouk/monkey’s “license” reads as follows:

I do not give anyone permissions to use this tool for any purpose. Don't use it.
I’m not interested in changing this license. Please don’t ask.

In other words, not only does bouk/monkey’s license prohibit its use in an application that gets distributed (most OSS licenses kick in upon distribution of the licensed code) — it prevents internal use, as well. So, in theory, any entity that still uses bouk/monkey for any purpose would be on the hook for copyright infringement.

And, while this specific situation is quite unusual — we haven’t seen many projects covered by licenses that prohibit any and all use — it is a reminder of what can happen when organizations don’t have an up-to-date and accurate inventory of their dependencies.

bouk/monkey: A Brief Overview

bouk/monkey is a monkey-patching program for Golang that was published in 2015. Like other monkey-patching programs, bouk/monkey rewrites executables at runtime. Unlike other monkey-patching programs, however, bouk/monkey was never intended to be used.

In a recent interview with the esoteric.codes website, bouk/monkey author Bouke van der Bijl explained:

“I never intended to use it or for it to be used, I only created it to see how people would react and for my own enjoyment. And it has certainly been a great success in that regard. It is almost a piece of modern art in that way—the project is completely irrelevant at this point, only the reaction to it is what matters.”

Despite these functional issues and the terms of bouk/monkey’s license (not to mention the fact that van der Bijl actually archived it on GitHub last year), numerous projects still depend on bouk/monkey. At the time of writing, it’s a dependency for 474 projects, including ones belonging to AWS-Labs and Baidu, among others.

Knowing Your Dependencies: License Compliance

On the surface, the fact that hundreds of projects, including several maintained by large organizations, depend on bouk/monkey seems pretty surprising. But the reality of modern software development makes such an oversight understandable, if not ideal.

After all, the average application contains dozens of different open source components and licenses. In fact, a recent GitHub report noted that projects analyzed had close to 700 dependencies on average.

And, without the right policies and tooling in place, it can be quite difficult for organizations to maintain an accurate and up-to-date inventory of their dependencies and involved licenses. This can create a number of problems, including:

  • Open source project copyright holders may file suit against entities that use their code but don’t comply with license terms (such as in Stockfish vs. Chessbase)
  • OSS users may be forced to open source parts of their codebase if they have used certain copyleft licenses
  • Development teams may have to replace components covered by certain licenses, resulting in extra work and delayed releases

In the case of bouk/monkey — even though the projects that depend on it are by definition non-compliant with its license — there’s no indication that creator and copyright holder van der Bijl is currently pursuing action against the offenders. But, as mentioned, that’s not always the case.

It is also important to note that, per van der Bijl in the aforementioned esoteric.codes article, many projects that depend on bouk/monkey use it only for testing. Consequently, it’s possible organizations that have effective license compliance policies and tools for distributed applications may have missed bouk/monkey because they use it only as part of an internal tool. We’ll discuss this in greater detail later in this post.

Knowing Your Dependencies: Vulnerability Management

License compliance violations aren’t the only issues that can arise when organizations aren’t aware of their dependencies. There can be major security concerns as well.

Per recent GitHub research, 59% of the projects on their platform are expected to receive a security alert in the coming year. Another recent report indicated that the vast majority of projects include open source dependencies that haven’t been updated for at least four years. This increases the chances that OSS users aren’t regularly applying new security patches/following version control best practices, raising the chances of an issue.

Common vulnerabilities affecting multiple open source projects include CWE-79 (Cross-Site Scripting), which was the most-found vulnerability in FOSSA’s 2020 analysis. CWE-20, which describes unvalidated inputs that alter the expected code output, was a close second.

Best Practices for Dependency Identification

Given the sheer volume of open source in modern applications, tracking dependencies, licenses, and potential security vulnerabilities via manual processes or legacy tools risks costly errors. Implementing a software composition analysis (SCA) tool like FOSSA automates dependency identification, license compliance, and vulnerability management, saving significant staff time and reducing compliance and security risk.

Also, as a general rule, it’s always helpful to conduct security and compliance testing as early as possible in the SDLC (software development lifecycle). This reduces the chances development teams will have to dedicate resources to replace problematic components.

Finally, while the most common use case for SCA is scanning code that will be part of a distributed application, the bouk/monkey incident does show the value of maintaining an accurate inventory of all dependencies — even those that are part of for-internal-use-only programs. While analyzing code in internal tools shouldn’t be a priority over distributed applications, risk-averse companies should consider using SCA on all software with open source components, even internal tools.

For more information on how FOSSA Software Composition Analysis can help your organization with dependency identification, license compliance, and vulnerability management, please reach out to our team.