Security is critical to maintaining high-quality software. With the rise of library dependencies and supply chain attacks across languages and frameworks, the ability to inspect the third-party code you rely on to make sure your software isn’t compromising your users is more important than ever.
One potential challenge developers face when performing this work is the US Digital Millennium Copyright Act (DMCA)’s anti-circumvention provisions. A 23 year old law created to protect copyright holders in a digital world, the DMCA can create potential legal liability for developers who need to circumvent technological protection measures (TPMs) on copyrighted works, including software, in order to test for vulnerabilities and patch holes in vulnerable software.
Though the DMCA has always had an exemption for developers performing “good faith” security research, in practice there have been many questions raised about what activities fall under this umbrella. This has led to many calls to update the exception to eliminate fear, uncertainty, and doubt (FUD) when developers engage in this vital work.
Recently, the Copyright Office responded to the calls to clarify the scope of protected security research. The Office provided much-needed clarity in both revisions to the current exemptions and comments to existing exemptions in ways that acknowledged the ambiguity and sought to eliminate it. These comments should give developers more confidence when working to secure the software supply chain.
How we got here
Every three years, the Copyright Office hears requests for explicit exemptions to DMCA anti-circumvention liability, beyond those already provided in the DMCA. In this round, there were two proposed expansions of the security research exemption.
The first, from Halderman et al., sought to create brighter lines around the exemption–including clarification that the DMCA’s exemption would not be conditioned upon compliance with other laws. Developers needed certainty that they would not risk DMCA liability merely because of ambiguity in whether their actions were compliant with other laws, such as the Computer Fraud and Abuse Act (which has sometimes been used by copyright owners as a weapon against activity they dislike).
The second exemption, from Software Freedom Conservancy, sought to clarify that “good faith” security research included work to uncover privacy issues. GitHub filed comments in support of expanding the security research exemption, explaining the importance of good security and quality assurance work in modern software development to the Copyright Office.
What the Copyright Office did
Security research
The Copyright Office clarified the exemption for security research, and its comments expand on the scope of activities previously understood to fall within the current exemption. First, the Office noted that the exemption that defines what falls within security research is construed “broadly” and that it “is not limited to specific subjects or issues within security flaws or vulnerabilities.” Given this breadth, the Copyright Office noted that the privacy research exemption sought by Software Freedom Conservancy was already covered by the current exemption, even without a specific mention of “privacy” research. These comments demonstrate the breadth of the exemption in ways that should give developers confidence that researching, testing, and developing measures aiming to uncover and ultimately resolve a wide range of security issues and vulnerabilities falls within the scope of “good faith” security research, though it is worth noting that the exemptions do not apply to the distribution of tools for carrying out circumvention.
Second, regarding the Halderman et al. proposal, the Copyright Office recommended removing the requirement that the research not violate other laws. Before, violation of other laws like the Computer Fraud and Abuse Act, would subject you to DMCA liability even if your work was otherwise exempted as good faith security research. Now, you are exempt from the DMCA liability under this exemption even if you are in direct violation of other laws. This expansion removes an arrow in the quiver of those who may misuse 1201 to create FUD around security research.The DMCA exemption is no longer contingent on developers dotting all “i”s and crossing “t”s across the entire United States legal code. That said, developers still need to independently consider whether their work is permitted under other laws.
Other exemptions
Wins for developers did not stop there. The Office permitted developers to jailbreak routers and TV streaming devices. Circumvention is now permitted for diagnosis, maintenance, or repair of many consumer devices. Developers can now circumvent TPMs to investigate potential open source license violations. For more details, check out the full set of exemptions published in the final rule.
What this means for developers
The Copyright Office’s final rule recognizes the importance of security research in modern software development. By describing the expansive breadth of the exemption–including privacy research–developers should have more confidence that they can secure their stack by probing dependencies, deobfuscating code written by third parties to see what it does, or many of the other activities that fall under the general heading of good faith quality assurance and testing. Moreover, the final rule eliminates the specter that research must first be determined to comply with all other laws in order to enjoy the security research exemption. Overall, the Office’s comments more broadly recognize the “importance of providing clarity” to developers using the security research exemption.
That said, there remains room for improvement. Distributing tools that enable circumvention is prohibited, even if their use by developers falls under the exemption. Also, many valid exemptions are temporary, unless renewed (though Office procedure has made renewal easier). The next rulemaking process will begin in less than three years.
GitHub is committed to ensuring that copyright laws, including Section 1201 of the DMCA, don’t unfairly block developers from engaging in legitimate innovation so that the software ecosystem can continue to thrive. The rulemaking process depends on evidence, and your experience and the challenges that you confront can help inform future rulemakings and enhance our policy advocacy. Please get in touch.
Follow GitHub Policy on Twitter for updates about the laws and regulations that impact developers.
Tags:
Written by
Related posts
Execute commands by sending JSON? Learn how unsafe deserialization vulnerabilities work in Ruby projects
Can an attacker execute arbitrary commands on a remote server just by sending JSON? Yes, if the running code contains unsafe deserialization vulnerabilities. But how is that possible? In this blog post, we’ll describe how unsafe deserialization vulnerabilities work and how you can detect them in Ruby projects.
10 years of the GitHub Security Bug Bounty Program
Let’s take a look at 10 key moments from the first decade of the GitHub Security Bug Bounty program.
Where does your software (really) come from?
GitHub is working with the OSS community to bring new supply chain security capabilities to the platform.