Preface

We are a small group of developers that strive to write bug-free code. We also want to take responsibility for the software we make, and thus we put our best efforts to verify and audit our products before we post them to the public. In despite of that, we know that it is virtually impossible to write flawless code, especially in larger projects.

If you are a vulnerability researcher or a member of the security community we would appreciate if you could help us review our software for the presence of security bugs & vulnerabilities that can pose risk to the end-users and to their systems when interacting with our software.

Even though we do not have an official bug bounty program, I will personally thank you with a monetary reward if you responsibly disclose to us an "in-scope" vulnerability, following the rules outlined below.

Points of Interest

Please note that not all "fields of research", activities and types of software/resources are covered by this program. And even though it is difficult to cover all aspects of vulnerabilities (and we welcome all of your submissions) we want to point out that we are not interested in processing reports that fall under the "out-of-scope" categories listed below. Please respect our and your time and review this document before submitting your reports.

Indemnity & Anonymity

We also want to assure you that we will hold you harmless of any legal actions as long as you follow the "in-scope" rules outlined on this page. We also promise to keep all submissions private and to respect your anonymity (unless you request otherwise). To facilitate that, we provide means of encrypting communication, as well as various ways of getting hold of us, including online forms, and Twitter & Facebook private messaging.

Bug Fixes, Time Line & Rewards

We want to assure you that all reports and submissions will be taken seriously. In return, we would like to ask you the following:

• Respect the privacy of the users whose information could be leaked, or involved in the vulnerability itself.
• Do not disclose reported vulnerability in a public setting for the duration of time that it will take us to fix it. (Such will depend on the vulnerability itself and will be discussed with you after your submission. From our side, we will put our best efforts to patch the vulnerability in reasonable time.)
• Never publicly expose personal or private information of the end-users that was involved in the vulnerability/leak. Besides being ethically wrong, doing so may be illegal in your country that can get you into trouble!
• All rewards and remuneration, if any, will be assessed only after we fix the vulnerability. We will take into account the "helpfulness" of your report and of your communication with us while fixing the issue.
• Don't "hoard" similar bugs. It takes time, money and resources to fix a working production system. And thus we would prefer to receive from you similar bug reports in a single submission so that we could fix them all at once.
• All rewards will be subject to our discretion. We promise to be fair, but be one yourself as well. If a reward is awarded, we would prefer to do it via PayPal. If PayPal is not available for you, we may use Bitcoin.

Fields of Research

The following are examples and types of software that we are interested in receiving your vulnerability reports for, along with the "in-scope", "out-of-scope" and "prohibited" conditions:

Binary Executables

We're especially interested in finding and fixing vulnerabilities in any of our binary executables (files) that are a part of our software:

In-Scope:

1. Any PE executable file (with extensions: .exe, .dll, .scr, .msi, etc.) that is digitally signed by our code signing certificate (read here how to check) that is hosted on our website dennisbabkin.com.
2. The vulnerability must either expose end-user data, or jeopardize their system after interaction with our software in a way that was not intended by the end-user and was not described in the software manual. (Example: a buffer overflow that could allow an attacker to launch a malicious code without the end-user's knowledge. Or, a bug in the parser in our software that could allow an attacker to execute their script from a seemingly benign interaction with our software. Or, a way by which an attacker can "trick" our software to download or execute a malicious script without the end-user's knowledge, etc.)
3. If actions of our software could lead to an exposure of the operating system, or other software, to an attack. (Example: if our software creates a condition at which a system service is subjected to an imminent risk of a take-over by an attacker. Or, if our software inadvertently "pokes a hole" through the Windows Firewall, etc.)

Out-of-Scope:

1. Binary executables that are not signed by us, even though they may bear our name (read here how to check.)
2. Binary executables that are not hosted on our website that we cannot update with a fix.
3. Schedulers that execute arbitrary commands. (Example: A command to download and execute a virus that was typed into one of our schedulers is obviously a command supplied by the end-user, or by some other, possibly malicious, software following the prescribed guidelines of interaction with our software.)
4. Older versions of our software that have explicit warnings of an increased risk to the end-user, if used with a specific outdated, but still supported, option/setting falls out of scope. We provide such software with adequate warnings for the users of the older operating systems, that are assumed to be acting on their own risk.

Prohibited:

1. Even though we agree with you conducting a private reverse-engineering research of our software, we do not allow you to publish extensive details of such research in any public setting.
2. Disclosure of any trade secrets and know-hows obtained from your reverse-engineering research of our software is not allowed.

Website

Anything concerning the functionality and security of this website (hosted under the dennisbabkin.com domain) falls under this category. Also please note that the "in-scope" reach of this category is much narrower:

In-Scope:

1. Exposure of any end-user private data via interaction with our website.
2. Exposure of any internal resources that are otherwise inaccessible via our website.
3. Hosting of malicious content.
4. "Tricking" of the end-users to download malware or to redirect to a malicious website via the interaction with our website.
5. A vulnerability that thwarts or hinders the performance of our website (excluding denial-of-service or similar persistent scripting attacks.)

Out-of-Scope:

1. Any bugs in the rendering of client-side HTML and JavaScript that do not expose end-user data, or "trick" them into redirecting to a malicious website. (Such bugs, including cross-site-scripting, or XSS, are indeed bugs that will be promptly fixed, but they will not be considered a vulnerability unless they fall under any of the "in-scope" categories above.)
2. Bugs and anomalies that are not repeatable or reproducible. Example: A temporary glitch in a web server could make our website behave unexpectedly. Unless such occurrence falls under any of the "in-scope" categories above, it will not be considered a vulnerability.
3. Any occurrence of an unusual website behavior that takes place during a temporary update, maintenance or service outage. Unless such occurrence falls under any of the "in-scope" categories above, it will not be considered a vulnerability.
4. If our website's client-side code is modified (en-route) by an ISP, by an anti-virus software, or by a firewall.
5. There's too much to name here. So again, if whatever you see happening with our website doesn't fall under any of the "in-scope" categories above, it will probably not be considered a vulnerability. Although we would encourage you to send your reports anyway.

Prohibited:

1. Use of any automated scripts to probe or load repeatedly any pages of our website is not allowed.
2. Employ social engineering, phishing, spam, malware, or any similar means to elicit access to our resources is not allowed.

Finally, if you're not sure about what category your type of research falls under, please don't hesitate to ask first.

Thank You!

Lastly, we want to thank you for your efforts to help us make a more secure software.