Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Exploits and malware policy updates #397

Merged
merged 12 commits into from
Jun 4, 2021
Merged

Exploits and malware policy updates #397

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
f220679
Update github-acceptable-use-policies.md
vollmera Apr 29, 2021
dc55f21
Update github-community-guidelines.md
vollmera Apr 29, 2021
e328034
Update github-community-guidelines.md
vollmera Apr 29, 2021
e31711b
move "Spam and Inauthentic Activity" section back to where it was
vollmera May 4, 2021
65cd592
Update github-acceptable-use-policies.md
vollmera May 4, 2021
21ca446
Update github-community-guidelines.md
vollmera May 4, 2021
55fd371
Update github-acceptable-use-policies.md
vollmera May 20, 2021
956f0f6
Update github-community-guidelines.md
vollmera May 20, 2021
9cc8c70
fix typos
vollmera Jun 1, 2021
f0740c7
update front matter
vollmera Jun 1, 2021
e14a27f
Merge branch 'main' into security-research-malware-exploits-policy-up…
vollmera Jun 1, 2021
6d87bd5
link to Community Guidelines section directly from AUP section on mal…
vollmera Jun 4, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 18 additions & 18 deletions Policies/github-acceptable-use-policies.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ Capitalized terms used but not defined in these Acceptable Use Policies have the
You are responsible for using the Service in compliance with all applicable laws, regulations, and all of our Acceptable Use Policies. These policies may be updated from time to time and are provided below, as well as in our [Terms of Service](/articles/github-terms-of-service) and [Corporate Terms of Service](/articles/github-corporate-terms-of-service).

### 2. Content Restrictions
Under no circumstances will Users upload, post, host, execute, or transmit any Content to any repositories that:
Under no circumstances will Users upload, post, host, execute, or transmit any Content that:
vollmera marked this conversation as resolved.
Show resolved Hide resolved

- is unlawful or promotes unlawful activities;

Expand All @@ -31,7 +31,7 @@ Under no circumstances will Users upload, post, host, execute, or transmit any C

- is or contains false, inaccurate, or intentionally deceptive information that is likely to adversely affect the public interest (including health, safety, election integrity, and civic participation);

- contains or installs any active malware or exploits, or uses our platform for exploit delivery (such as part of a command and control system); or
- contains or installs malware or exploits that are in support of ongoing and active attacks that are causing harm; or
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This statement should not be modified from the original.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. What "active attack" does even mean? Some viruses from the 90s are still attacking the few vulnerable devices that remain (like old industrial machines). Can it be considered "active attack"?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If your goal is to clarify, removing specifics and replacing with vague handwaving doesn't do it. Using github asa command-and-control system is a very specific example where it should be clear when somehow has violated the rule. But "support of ongoing and active attacks" is a vague catchall that's impossible to determine if somebody has violated. Hackers have already automated download of my code in their attacks, meaning that I'm violating the new rules technically. I wouldn't get canceled/censored, but those who you do choose to cancel/censor would not become an arbitrary and prejudicial decision, not one based upon facts.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How will you be the arbiters of what is, and is not causing harm? What will the threshold be? My local coffee shop (with online ordering) might see a simple exploit kit as something that could ruin their business completely, while my bank is likely to have an appropriate D&D strategy to defend against this.

When considering on-going attack, is there some sort of limitation, or is the expectation that GitHub will maintain it's own threat intelligence and make decisions on this basis ad-infinitum?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MSFT intentions are quite clear here, first they deleted the proof of concept for exchange, then now this policy.
Anything like Responder, CrackMapExec, Empire,etc can be banned tomorrow, because it's inconvenient for MSFT to have tools exploiting 35 years old vulnerabilities they don't want to patch removed from Github. When they bought Github, it was clear to me that it was not to promote open-source -they always complained about it and argued against it- but to control what kind of code is convenient, and which kind of code should be online and which not.
In anyways, it wont have any effects on malware, virus, spyware, ransomware, state sponsored malware, as they are all closed source ;)

Copy link

@KOLANICH KOLANICH Apr 30, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wouldn't get canceled/censored, but those who you do choose to cancel/censor would not become an arbitrary and prejudicial decision, not one based upon facts.

BTW, as an owner of the resource M$ ₲H has a right to block any user (even the one that even have never violated the rules) and repo from it on its own discretion (including criteria, like being a person whose political position and/or activity (i. e. being a proponent of free software or being a Stallman sympathizer or devsloping free software competing to M$ one or just not using Windows) is potentially harmful to the business in a long term, being not enough profitable ("free-rider") or being one of a specific nationality/religion/geographical location/political orientation/sexual orientation/induism caste/prison caste/occupation/age/employer/luck level (at random) ) without disclosing the actual criteria of discrimination. So de-facto the proposed terms are already active, just were not codified.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good change only in that the original text said:

 Under no circumstances will Users upload, post, host, execute, or transmit any Content that

[... SNIP ...]

- contains or installs any active malware or exploits [...]

This old text completely forbids the publication of malware and exploits via GitHub. On one hand this is a bad policy, as "malware and exploits" is a broad term that covers professional penetration testing tools such as Metasploit Framework. On the other hand, the old text was clearly not being enforced or policed. In light of the recent ProxyLogin incident and this policy change being put forth, we can expect that any policy (Either the old one, or a new one) will be more actively enforced.

The change to the text does not go far enough in fixing this issue, as raised by others. In my opinion, at the very least the proposed policy must be updated to provide clarity on:

  • What "ongoing and active attacks that are causing harm" means, who makes this determination, and how they make the determination
  • The transparency that GitHub will provide when removing content under this policy
  • The option for individuals and the community to appeal decisions made to remove content under this policy
  • An assurance (codified in policy) that a declaration of an "ongoing and active attack that [is] causing harm" will be short and sharp, and will be lifted as soon as possible so that professional security tooling can be made available to detect and mitigate the "harm"

For what it's worth, I am in support of a policy that forbids the use of GitHub as a direct malware delivery mechanism (i.e. a CDN) or as a malware command and control mechanism. In my opinion, GitHub should generally permit collaboration on and publication of exploit code and malware, and the original text as it relates to this activity should simply be struck from the policy entirely.

Copy link

@KOLANICH KOLANICH Apr 30, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "old" text disallowed to host on GH files that will infect users when a web page on GH is opened or when a repo is cloned. The proposed text forbids any code that can be potentially used in attacks, i.e. if some malware infects some machine, then downloads source code of, i.e. hashcat, builds it and then uses it to brute hashes on infected servers to advance attacks, then hashcat is forbidden too.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "old" text disallowed to host on GH files that will infect users when a web page on GH is opened or when a repo is cloned

The full text was:

Under no circumstances will Users upload, post, host, execute, or transmit any Content to any repositories that:
[...]
contains or installs any active malware or exploits, or uses our platform for exploit delivery (such as part of a command and control system); or
[...]

I disagree with your reading of the old text. Take for example Metasploit Framework. IMO it "contains" "active malware [and] exploits".

Granted I'm not a lawyer. If you aren't either, all we have is our own understandings of the text.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's worth considering some cases here. If we take GH at it's word that it's trying to protect the good pentesting and research tools, then the language should be clear to allow both of these:

  1. mimikatz - This tool has been instrumental towards helping to fix vulnerabilities in how Windows handles passwords. It's also used by basically every attacker out there. Will this be taken down? It's used in an active attack every day. This is where the "active attacks that are causing harm" language falls short.
  2. Repos like malware-samples or Phishing Kit Tracker. These host real world malware being used by live attackers to put light on them and enable defenders and researchers.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

active attacks that are causing harm

Tools written by pen tester and infosec research firms can and are abused.

Is there any provision for tools that are not inherently malicious that are being used for malicious purposes?

I think this clause is exceedingly problematic when one considers that many attackers conduct "living off the land" attacks. This clause could be read such that any application -- including those that are part of the core OS install -- would be at risk of removal.

Copy link

@ExplodingCabbage ExplodingCabbage Apr 30, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the objections of anybody above me in this thread.

I can see the argument that it should be okay to use GitHub to host even malware that's actively being used, and that as such this clause was and still is problematic. But what I'm not seeing is why you object to this change, per se.

Before, the terms banned hosting "active malware". Now they ban hosting "malware ... [that is] in support of ongoing and active attacks that are causing harm". Certainly there are plenty of vague terms in there, but no matter how we parse them, isn't the new wording strictly more liberal than the previous wording? What's an example of malware that the objectors would characterise as "in support of ongoing and active attacks" and yet would not characterise as "active malware"?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that "active malware" meant things like a browser exploit in the html hosted on github pages. This change makes the policy apply to code that can be used anywhere, not just from GH's infrastructure.

Copy link

@BlueTeamSteve BlueTeamSteve Apr 30, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"in support of ongoing and active attacks that are causing harm" is so vague that it is impossible to enforce fairly. I agree with @robertdavidgraham, replacing a specific rule (no C2) with a vague one does not clarify the policies at all.

The majority of Windows attacks abuse PowerShell in some way. Is https://github.com/PowerShell/PowerShell now in breach of this policy because it supports active attacks?

A vast amount of security tools are dual-use and can be abused by attackers while also being valuable to defenders. Without clear-cut guidelines there is a significant risk that defenders will be heavily penalised by arbitrary decisions with limited impact to attackers.


- infringes any proprietary right of any party, including patent, trademark, trade secret, copyright, right of publicity, or other right.

Expand All @@ -50,10 +50,21 @@ While using the Service, under no circumstances will you:

- violate the privacy of any third party, such as by posting another person's personal information without consent.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is also a gray area. What is considered personal information - is a single mailbox or name considered personal information?


### 4. Services Usage Limits
### 4. Spam and Inauthentic Activity on GitHub
Automated excessive bulk activity and coordinated inauthentic activity, such as spamming, are prohibited on GitHub. Prohibited activities include:
* bulk distribution of promotions and advertising prohibited by GitHub terms and policies
* inauthentic interactions, such as fake accounts and automated inauthentic activity
Copy link

@tunip3 tunip3 Apr 29, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/gelstudios/gitfiti
Will this block commit history modification and git commit art?

Copy link

@Technetium1 Technetium1 Apr 29, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gelstudios/gitfiti
Will this block commit history modification and git commit art?

It certainly would! That's automated and inauthentic activity.
Edit: It seems that GitHub only selectively enforces this. You probably won't get in trouble unless you routinely abuse it.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually not a new statement. If you notice, GitHub moved it up from bullet point 9 to bullet point 4, but the same provision exists.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, this should remain. Github has the right to defend their systems from abuse conditions.

Copy link

@fos111 fos111 May 1, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was never a abuse."Security researchers do not "support ongoing and active attacks that are causing harm", they instead raise awareness of those risks and help the concerned parties defend against them"

* rank abuse, such as automated starring or following
* creation of or participation in secondary markets for the purpose of the proliferation of inauthentic activity
* using GitHub as a platform for propagating abuse on other platforms
* phishing or attempted phishing

GitHub reserves the right to remove any Content in violation of this policy.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the event github removes content (for the reasons above or any reason for that matter) what is the expectation to the end user? is it just... gone forever? is it potential to recover the data and move it somewhere else? do we get a warning or anything? deprecation?


### 5. Services Usage Limits
You will not reproduce, duplicate, copy, sell, resell or exploit any portion of the Service, use of the Service, or access to the Service without our express written permission.

### 5. Information Usage Restrictions
### 6. Information Usage Restrictions
You may use information from our Service for the following reasons, regardless of whether the information was scraped, collected through our API, or obtained otherwise:

- Researchers may use public, non-personal information from the Service for research purposes, only if any publications resulting from that research are [open access](https://en.wikipedia.org/wiki/Open_access).
Expand All @@ -65,15 +76,15 @@ You may not use information from the Service (whether scraped, collected through

Your use of information from the Service must comply with the [GitHub Privacy Statement](/github/site-policy/github-privacy-statement).

### 6. Privacy
### 7. Privacy
Misuse of User Personal Information is prohibited.

Any person, entity, or service collecting data from the Service must comply with the [GitHub Privacy Statement](/articles/github-privacy-statement), particularly in regards to the collection of User Personal Information. If you collect any User Personal Information from the Service, you agree that you will only use that User Personal Information for the purpose for which that User has authorized it. You agree that you will reasonably secure any User Personal Information you have gathered from the Service, and you will respond promptly to complaints, removal requests, and "do not contact" requests from us or other users.

### 7. Excessive Bandwidth Use
### 8. Excessive Bandwidth Use
The Service's bandwidth limitations vary based on the features you use. If we determine your bandwidth usage to be significantly excessive in relation to other users of similar features, we reserve the right to suspend your Account, throttle your file hosting, or otherwise limit your activity until you can reduce your bandwidth consumption. We also reserve the right—after providing advance notice—to delete repositories that we determine to be placing undue strain on our infrastructure. For guidance on acceptable use of object storage in repositories, refer to "[What is my disk quota?](/github/managing-large-files/what-is-my-disk-quota)". For more details on specific features' bandwidth limitations, see the [GitHub Additional Product Terms](/github/site-policy/github-additional-product-terms).

### 8. Advertising on GitHub
### 9. Advertising on GitHub
**Short version:** *We do not generally prohibit use of GitHub for advertising. However, we expect our users to follow certain limitations, so GitHub does not become a spam haven. No one wants that.*

While we understand that you may want to promote your Content by posting supporters' names or logos in your Account, the primary focus of the Content posted in or through your Account to the Service should not be advertising or promotional marketing. This includes Content posted in or through Pages, Packages, repositories, and all other parts of the Service. You may include static images, links, and promotional text in the README documents or project description sections associated with your Account, but they must be related to the project you are hosting on GitHub. You may not advertise in other Users' Accounts, such as by posting monetized or excessive bulk content in issues.
Expand All @@ -82,16 +93,5 @@ You may not promote or distribute content or activity that is illegal or otherwi

If you decide to post any promotional materials in your Account, you are solely responsible for complying with all applicable laws and regulations, including without limitation the U.S. Federal Trade Commission's Guidelines on Endorsements and Testimonials. We reserve the right to remove any promotional materials or advertisements that, in our sole discretion, violate any GitHub terms or policies.

### 9. Spam and Inauthentic Activity on GitHub
Automated excessive bulk activity and coordinated inauthentic activity, such as spamming, are prohibited on GitHub. Prohibited activities include:
* bulk distribution of promotions and advertising prohibited by GitHub terms and policies
* inauthentic interactions, such as fake accounts and automated inauthentic activity
* rank abuse, such as automated starring or following
* creation of or participation in secondary markets for the purpose of the proliferation of inauthentic activity
* using GitHub as a platform for propagating abuse on other platforms
* phishing or attempted phishing

GitHub reserves the right to remove any Content in violation of this policy.

### 10. User Protection
You must not engage in activity that significantly harms other users. We will resolve disputes in favor of protecting users as a whole.
15 changes: 14 additions & 1 deletion Policies/github-community-guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -79,7 +79,16 @@ We are committed to maintaining a community where users are free to express them
You may not post content that presents a distorted view of reality, whether it is inaccurate or false (misinformation) or is intentionally deceptive (disinformation) where such content is likely to result in harm to the public or to interfere with fair and equal opportunities for all to participate in public life. For example, we do not allow content that may put the well-being of groups of people at risk or limit their ability to take part in a free and open society. We encourage active participation in the expression of ideas, perspectives, and experiences and may not be in a position to dispute personal accounts or observations. We generally allow parody and satire that is in line with our Acceptable Use Polices, and we consider context to be important in how information is received and understood; therefore, it may be appropriate to clarify your intentions via disclaimers or other means, as well as the source(s) of your information.

- #### Active malware or exploits
Being part of a community includes not taking advantage of other members of the community. We do not allow anyone to use our platform for exploit delivery, such as using GitHub as a means to deliver malicious executables, or as attack infrastructure, for example by organizing denial of service attacks or managing command and control servers. Note, however, that we do not prohibit the posting of source code which could be used to develop malware or exploits, as the publication and distribution of such source code has educational value and provides a net benefit to the security community.
Being part of a community includes not taking advantage of other members of the community. We do not allow anyone to use our platform in support of active attacks that cause harm, such as using GitHub as a means to deliver malicious executables, or as attack infrastructure, for example by organizing denial of service attacks or managing command and control servers.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

such as using GitHub as a means to deliver malicious executables, or as attack infrastructure

Would this include the use of PowerShell download cradles? If so, this clause would expose many PowerShell tools to removal... including those which are not 'malicious'.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my understanding @besimorhino such PowerShell download cradles would only be in scope under the proposed language if they were specifically hosted in support of unlawful attack or malware campaigns, if they have a dual-use (e.g. network penetration testing tooling, or security/malware research) established prior to any abuse reports associated to such an unlawful attack they would not be affected.


Note, however, that GitHub supports the posting of content which is used for research into vulnerabilities, malware or exploits, as the publication and distribution of such content has educational value and provides a net benefit to the security community. We ask that repository owners take the following steps when posting potentially harmful content for the purposes of security research:
Copy link

@LeeHolmes LeeHolmes Apr 30, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A large percentage of open source security tooling hosted on GitHub is designed to help with security audits, pen testing, red teaming, etc. It is used for research into network and operational vulnerabilities, rather than software vulnerabilities. It would be good to ensure this category is included in this list of "beneficial to the security community".

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Lee. Many repositories host/archive malicious phishing kits/sites, binaries, and code (e.g. metasploit) that are used for educational and unfortunately are used for malicious intent.


* Clearly identify and describe any potentially harmful content in a disclaimer in the project’s README.md file.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the following line imply that a repository must use Markdown. Not all users wish to use Markdown for their repositories, and any suitable file format should be acceptable.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

potentially harmful content

This clause would likely be better received by the security community if the same standards were applied to all code. There's plenty of sys admin scripts that can completely ruin your systems... is there a similar restriction placed on them? The placement of the clause confuses me. Is it for everyone, or just code that could be problematic?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's plenty of sys admin scripts that can completely ruin your systems...

Agreed - what the suggested change does is pushes responsibility onto the commiter whilst providing no clear definition of "potentially harmful".

rm is potentially harmful, but presumably wouldn't need to declare it.

There are Nessus plugins that are potentially harmful if run against a production box, but they're not intended to do harm. Would they need to put a disclaimer in?

* Provide a designated security contact through a SECURITY.md file in the repository.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As publishing exploits can be a legal grey area, in certain situations someone may wish to publish anonymously (e.g. whistle blowing, forcing a fix with public disclosure). Requiring a contact opens an avenue for legal action against researchers.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will simply result in an army of strawmen appearing as "security contacts" and nothing more. GitHub has all the means to get in touch with the user who published the content, why introduce this measure? Who exactly does this serve the most and which problem does this solve? Please explain how this possibly personal information will be used and why the currently existing means are not sufficient.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change essentially mandates that people publish PII somewhere it can trivially be scraped.

That seems like a really, really poor policy change. As @dev-zzo says, GH already has all that's needed to make contact (as well as the ability to take stuff down).

This feels like an example of really, really bad practice - this isn't an organisation exposing services (i.e. the use-case for .well-known/security.txt)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A SECURITY.md security policy seems positioned to identify how a project wishes to receive responsible disclosures. What would an example SECURITY.md look like for a project documenting a proof of concept?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More so what would a security.md look like for projects like metasploit that are actually used for malicious intent.


Please also note, GitHub will generally not remove exploits in support of vulnerability reporting or security research into known vulnerabilities. However, GitHub may restrict content if we determine that it still poses a risk where we receive active abuse reports and maintainers are working toward resolution.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once a 0day is published, have take downs been shown effective in mitigating spread? My assumption would be that malicious actors have access to it via personal networks at that point. The take down likely just draws more attention to it. Recommend to leave things up.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not only that, the take down also hinders detection and response teams. Look, the malware is going to exist and is going to be deployed. If we decide to remove it from public eye, we're also choosing to remove our capability to quickly respond.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depends on how operationalized/weaponizable the exploit is, and how easily it can fit into the attacker's toolkits and operational tempo.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a large part of what informed the current language in this policy. Take downs tend to just push explot/0day code into less-public and less-accessible spaces, where defenders and researchers are less likely to see them (and, thus, less likely to be able to create patches or fixes).

Ease of access by researchers becomes more, not less, important when an exploit is being actively exploited.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ease of access by researchers becomes more, not less, important when an exploit is being actively exploited.

I think this sentence might go against that spirit - However, GitHub may restrict content if we determine that it still poses a risk where we receive active abuse reports and maintainers are working toward resolution. Companies will want 0day or something being actively exploited (read: hurting their reputation) taken down and will push hard for this.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my experience, by the time an exploit hits public repos, it has either been depleted of most of its hack value and/or spread over "the forums" and whoever wanted has got a copy already or getting it is within direct reach. Removing content does not really help curb any ongoing attacks as they are, well, already ongoing, but it does hinder or prevent future analysis and other research work. If GitHub has any statistical data that would back the contrary, please share.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The “…and maintainers are working toward resolution” guideline is vague. Which maintainers’ involvement satisfies this prong of the guidelines? The maintainers of a GitHub-hosted project providing the proof of concept? The maintainers of a closed-source project that is the target of the PoC?


*GitHub considers the npm registry to be a platform used primarily for installation and run-time use of code, and not for research.*


### What happens if someone breaks the rules?
Expand All @@ -95,6 +104,10 @@ Actions we may take in response to an abuse report include but are not limited t
* Account Suspension
* Account Termination

### Appeal and Reinstatement

In some cases there may be a basis to reverse an action, for example, based on additional information a user provided, or where a user has addressed the violation and agreed to abide by our Acceptable Use Policies moving forward. If you wish to appeal an enforcement action, please contact [support](https://support.github.com/contact).

### Legal Notices

We dedicate these Community Guidelines to the public domain for anyone to use, reuse, adapt, or whatever, under the terms of [CC0-1.0](https://creativecommons.org/publicdomain/zero/1.0/).
Expand Down