Code of Conduct / General Tester Expectations

This Code of Conduct is in addition to our existing terms and conditions for all persons or machines accessing DarkHorse.

When signing up (as well as submitting a report), you must agree to the above terms, as well as the following Code of Conduct. Where applicable, some items here may be superseded by details on the engagement summary page, but only when explicitly stated as such.

This Code of Conduct is intended primarily for testers, but applies to all persons using the platform in any context, and outlines what we consider to be unacceptable behavior, as well as the repercussions for violating these terms. Furthermore, we reserve the right to enforce actions not explicitly outlined here, as well as upgrading or downgrading an offense, at our discretion.

1. Don’t be a bad person (conversely: just be a good person).
1. This is inclusive of, but exclusive to not being rude, mean, racist, derogatory, unprofessional, unbecoming, threatening, a jerk, an ass, a donkey, disrespectful, discriminatory, distasteful, disgraceful, dishonorable, malicious, nefarious, and so forth.
2. This applies to all interactions with all people, as well as systems (not that it’s about the system’s feelings, so much as people downstream may interact with whatever was fed into the system).
3. Pretty much everything that follows falls under this. If you’re a good person, you’ve got like 99% of this covered.
2. Don’t spam.
1. Don’t spam anything, unless it’s specifically been requested or condoned. Don’t spam messages, don’t spam reports, don’t spam comments, and so on. Just don’t.
2. As a specific callout, please also don’t spam the same report across multiple accounts in an effort to “farm” reports or to game the system. That’s not cool, and will most likely hurt instead of help you.
3. In the same vein, don’t submit reports as placeholders that you will update later in an effort to be the first report. Submitting a report that has insufficient initial data may be cause to discard it and require you to make a new report – which may result in your later report being later than another report that was more fully written at the start.
4. Relatedly, though it goes without saying, please only submit reports that have a reasonable and demonstrable security impact. If there’s no impact, your report will likely be discarded – if in doubt, always make sure to be as clear as possible when talking about the impact of your report.
3. Don’t use abusive language.
1. Again, covered under “don’t be a bad person”, but we’ll say it specifically… Harassment, threats, hate speech, discriminatory language, aggressive tones, and profanity are not ok. *(with the caveat that ‘tasteful’ profanity is tolerated… see below for an example of us using profanity, but not in a threatening or harassing way)
2. This extends beyond just your behavior on the platform. For instance, if you go on Twitter (or X, or whatever it’s called this week) and say some dumbass, racist shit… and at DarkHorse we aren’t super into supporting dumbass racists, then your account may be subject to negative repercussions. To be clear, we’re not policing everything you do online, and honestly we hate going on Twitter at all. But if it comes to our attention that you’re saying or doing some pretty odious stuff, then we may need to take action, at our discretion.
3. Once more, we’re not trying to be your parents here… and we don’t want to be. Just be a good person and we’ll have no issues (but if you're running around saying racist shit, regardless of how good of a hacker you are, we can't have our platform associated with your dumbass views).
4. Don’t perform unsafe testing.
1. As a general rule, unless expressly stated otherwise, only test as far as is needed to demonstrate the presence of a vulnerability. If you have RCE, you don’t need to exfiltrate data from the machine to prove you have RCE, just show that you can run remote commands. Same goes for any vulnerability – just do what is minimally necessary to demonstrate the presence of the vulnerability. If you happen to gain access to a system and want to take things further – please ask for permission before doing so.
2. Additionally, don’t perform any testing that may impact the stability of systems… for instance, unless the engagement summary page expressly says to do load testing, do not perform DoS attacks. If you suspect the presence of a DoS vulnerability, there are usually ways to test safely, and if there are no such ways, consult with the engagement owner before doing anything potentially damaging. Again, this is not limited to DoS-type attacks… if you have any reason to believe your testing will potentially affect site reliability or stability, reach out before doing that testing.
3. An important corollary to this is to not test against assets that are not in scope. If it’s not in scope, it’s not in scope… which means it shouldn’t be tested for one reason or another. And testing that which is not meant to be tested is, in this context, considered to be unsafe testing. We do understand that sometimes mistakes happen, so we’re not trying to get super militant about it – but absolutely do not knowingly test that which is not in scope.
4. In the event that you get exposed to PII or PHI, please limit the amount of it that you see, retain none of it, and alert the organizations as soon as possible.
5. Similarly, don’t intentionally impede the access or progress of other testers. You will often operate in a shared environment, and it’s essential that your testing not block or negatively impact the testing of others.
5. Don’t talk about (or share in any way) that which is private.
1. This includes talking about engagements, reports, scopes, messages, and anything else relating to that which is not otherwise public knowledge. If it’s not available via a google search, don’t talk about with anyone other than (1) the client; (2) DH staff; or (3) the tester or any collaborators listed on the report. This includes talking verbally, posting publicly, or any other means of communicating to people outside of the groups listed above. This includes reports that are marked as ‘not applicable’ or any other ‘non-accepted’ state – up until the non-disclosure timeline has expired.
2. Furthermore, all communication regarding the above must be kept within the DarkHorse platform. Unless expressly stated otherwise, no other means of communication should be used to communicate with anyone about private details (e.g. alternative discords, slacks, emails, forums, etc). Additionally, do not reach out to clients outside of the official channels on the platform – there’s a messaging feature for that. Do not find a company’s CISO on LinkedIn and tell them you’ve got a bangin’ clickjacking vulnerability. If you’ve got a question, we’ve got an appropriate route for that to go through.
3. The only exception to the above is after the vulnerability disclosure timeline is up – at which point, you may talk about your finding, etc. Please refer to the disclosure guidelines for more details.
4. You may find a need to upload a video for PoC purposes. On average, we’d prefer that you upload that to the platform, but in the event that you need to use a video service, please make sure that it is password protected, and not just a private youtube video or something that to that extent.
6. Don’t social engineer DarkHorse, other testers, or client organizations.
1. Again, covered under the “don’t be a bad person” clause, but as a reminder, if it’s not in scope, it’s not in scope. Don’t try to trick us into doing something for you (except within the bounds of our own VDP / Bug Bounty), and also don’t try to trick the client into doing something for you either. Same goes for other testers. Again, just don’t be a bad person.
7. Don’t steal.
1. This goes past the “don’t be a bad person” rule and straight into “don’t break the law”. Don’t steal. Not from clients, not from other testers, and not from DarkHorse. Don’t steal vulnerabilities, don’t steal techniques, don’t steal software, don’t steal creds, don’t steal toilet paper from the bathroom, don’t steal data, don’t, don’t, don’t. Real simple. Just don’t (unless of course, you have written permission to do so for testing reasons… at which point it’s not really stealing anymore).
2. It goes without saying, but stealing software is also stealing. If it is brought to our attention that you used stolen or counterfeit software to identify or report your finding, we may have to take action – so, please make everyone’s lives easier, and just don’t steal.
8. Don’t do other illegal things.
1. We’re sure there’s a large list of other illegal activities we should tell you not to do, but can we just say “please don’t do things that are illegal”? Of course, someone is going to argue that they live in a jurisdiction that has no laws… and, well, good for you. But for the sake of simplicity, let’s just use the laws of the USA as a baseline. Are they perfect? No way. Some are downright crazy and nonsensical, but it’s the jurisdiction that we operate in, so it’s in our best interest to not run afoul of those rules, specifically. If you have questions if something is afoul of the law, feel free to reach out, and then we’ll ask our lawyers.
2. Some illegal things we’d like to specifically ask you not to do include extortion and/or blackmail. Please don’t do those things, as they may open you up to legal liabilities.
9. Don’t try to circumvent the rules.
1. Don’t be pedantic. We’re sure we’ve missed some things in the above, which is why we have that clause about “we can do whatever at our own discretion”… but just because we didn’t specifically enumerate every possible use case, we ask that you understand the spirit of what’s been shared here, and operate within the bounds of reason and decency. Yes, we’re aware that “hackers gon hack”, but we’d prefer it if you kept your hacking to the targets, and instead just focused on being a good person. Again, we’re pretty sure that if you just do that one thing, 99% of this whole document becomes moot. You got this, we believe in you!
2. Don’t ban dodge or try to get around that which we put in place as judgements. Yes, it’s very hacker-y to not take no for an answer, and we love an underdog story as much as anyone… but please respect our decisions when we make them. We’re happy to have a conversation and work through appeals, but we also have low-to-no tolerance for bullshit. When in doubt, just be a good person, and things should work out pretty well from there.
10. Other general expectations and items to be aware of.
1. Reports that go more than seven days without a reply may be closed at the discretion of the receiving organization or DarkHorse.
2. You are responsible for the security of your account – this means making sure you have a secure password, and ideally also have MFA setup.
3. You may not transfer your account to anyone else, nor may you share the credentials, as doing so would effectively be sharing private vulnerability and program information.
4. Unless expressly stated in the engagement summary, do not submit:
1. Any form of DoS other than that which is directly triggered at the application layer. And if you are testing for app-level DoS, please exercise extreme caution, and only go so far as to demonstrate your thesis, and no further. Showing that you can make the page take 10x longer to load by changing a parameter is usually enough to create a report for the issue, etc.
2. Social engineering.
3. UI/UX Bugs.
4. Non-security issues (e.g. 404 pages, etc).
5. Issues with no clear path to impact (e.g. logout CSRF, etc).
5. VDPs, by definition, do not offer rewards in any manner. Do not expect any rewards from a VDP.
6. In order to be eligible for a reward on a bug bounty, you must be the first to submit a unique (non-duplicate), valid, in-scope issue that has meaningful security impact, and will lead to a code change of some nature.
7. In order to get paid, you will likely need to fill out some tax forms, as well as agreeing to the terms for the chosen payment vendor (e.g. paypal, etc). You also need to not be on a sanctioned list – directly (e.g. if you’re specifically named) or indirectly (e.g. you live in Iran).
8. You are responsible for paying your own taxes on any earnings, and any earnings not claimed via the platform after six months may be considered to be forfeited.
9. You agree to report any security vulnerabilities you identify via the DarkHorse platform, and will not intentionally withhold from reporting issues to programs and scope that you’ve been given access to.
10. As a new user, you are limited in how many messages you can have active with an organization at any one point in time. As you gain trust on the platform, that limit will be increased. To start, only one active message thread is allowed per user - so as to prevent spam to receiving organizations. If you need this increased, please reach out to info@darkhorse.sh.
11. This is, and will be a living document. As time goes on we'll likely need to expand or clarify items here. If you have suggestions, feel free to reach out to info@darkhorse.com.

Based on the severity of the infraction, it will receive a point score of 0.0-5.0 As time goes on, we’ll publish a rubric of what typically constitutes a 1 vs. a 5 (though as a starting point, if someone knowingly engages in blackmail or extortion, that'd be in the instant-ban category; whereas misunderstandings will be rated significantly lower). The points are accumulated in the aggregate over the course of a rolling 12 months – meaning that if there was one infraction for 3 points at month 1, and another infraction for 1 point at month 5, then at month 6 they’ll have a total of four points, at month 13 they’ll have a total of 1 point, and at month 18 they’ll have 0 point – provided there are no additional infractions. Here is what will happen at each point level.

0.0 - .5 - coaching messaging will be sent.
1.0 – 2.0 – a coaching + warning message will be sent
2.0 - 3.5 – a final warning + coaching message will be sent; a short-term suspension may be given
4.0 – 4.5 – a temporary suspension will be given
5.0+ - a permanent ban (that can be appealed at the one year mark) will be given

These are in addition to the general code of conduct and expectations. These expectations apply to anyone performing testing on a “Standard”, “Essentials”, or “Hunt” engagement.

1. All penetration testers will be background checked.
1. There may also be additional requirements to perform additional verification of person or skills as well.
2. There is no disclosure timeline for reports made to a pentest or security assessment. Unless granted express permission by the client, these reports and their contents are to stay private in perpetuity (the same is true for any and all program information).
3. Additional NDAs may be required for these types of engagements.
4. In the event that there is also a bug bounty (on this platform or elsewhere) that includes the scope that you’ve been assigned to test, you will only submit your reports to the pentest engagement, and not to any other program, bounty or otherwise.
5. When assigned a pentest engagement, you’ll be given an amount of time that we expect the test to take – in the event that you feel the test will take either 10% more or less time than allocated, please raise this concern to a member of the DarkHorse staff ASAP. Failing to use the full amount of time or to fully complete the assigned methodology may result in your disqualification from future pentest engagements.
6. QA will be performed on many pentest engagements – in the event that misses are found, they will be shared with the tester, along with an opportunity for explanation. If misses are persistent or particularly egregious, the tester may be disqualified from any future pentest engagements.
7. Exercise good judgement. By being part of the pentest team at DarkHorse, we’re putting a significant amount of trust in your person and quality of work. The more we build shared trust, the better outcomes we’ll have for everyone – you, us, and the client. Thanks!