Updates to our policies regarding exploits, malware, and vulnerability research

One month ago, we started a discussion with the community about proposed revisions to clarify GitHub’s policies on security research, malware, and exploits with the goal to enable, welcome, and encourage dual-use security research and collaboration on GitHub. We want to thank the broader security research community, project maintainers, and developers who shared feedback with us publicly in the pull request (PR) and who reached out for deeper live discussions on this topic. The feedback and suggestions, both on the substantive content and proposed changes, as well as on how we communicated the changes, have been tremendously valuable throughout this process and helped us better clarify our policies. 

Today, as the comment period has closed, we have merged the latest revisions of the PR and, in response to community feedback, updated the policy with some key changes:

• We explicitly permit dual-use security technologies and content related to research into vulnerabilities, malware, and exploits. We understand that many security research projects on GitHub are dual-use and broadly beneficial to the security community. We assume positive intention and use of these projects to promote and drive improvements across the ecosystem. This change modifies previously broad language that could be misinterpreted as hostile toward projects with dual-use, clarifying that such projects are welcome.
• We have clarified how and when we may disrupt ongoing attacks that are leveraging the GitHub platform as an exploit or malware content delivery network (CDN). We do not allow use of GitHub in direct support of unlawful attacks that cause technical harm, which we’ve further defined as overconsumption of resources, physical damage, downtime, denial of service, or data loss.
• We made clear that we have an appeals and reinstatement process directly in this policy. We allow our users to appeal decisions to restrict their content or account access. This is especially important in the security research context, so we’ve very clearly and directly called out the ability for affected users to appeal action taken against their content.
• We’ve suggested a means by which parties may resolve disputes prior to escalating and reporting abuse to GitHub. This appears in the form of a recommendation to leverage an optional SECURITY.md file for the project to provide contact information to resolve abuse reports. This encourages members of our community to resolve conflicts directly with project maintainers without requiring formal GitHub abuse reports.

We want to again thank each of you for taking the time to consider, discuss, and share. The iterative process allowed us to improve the clarity of our intention through each round of changes based on the feedback of the community as well as establish clearer guidelines for ourselves on dual-use content moving forward. We continue to welcome feedback and improvements on our various site policies and look forward to working together with the community to continue to drive improvements in this space.