|
| 1 | +# Coder Security |
| 2 | + |
| 3 | +Coder welcomes feedback from security researchers and the general public |
| 4 | +to help improve our security. If you believe you have discovered a vulnerability, |
| 5 | +privacy issue, exposed data, or other security issues in any of our assets, we |
| 6 | +want to hear from you. This policy outlines steps for reporting vulnerabilities |
| 7 | +to us, what we expect, what you can expect from us. |
| 8 | + |
| 9 | +You can see the pretty version [here](https://coder.com/security/policy) |
| 10 | + |
| 11 | +# Why Coder's security matters |
| 12 | + |
| 13 | +If an attacker could fully compromise a Coder installation, they could spin |
| 14 | +up expensive workstations, steal valuable credentials, or steal proprietary |
| 15 | +source code. We take this risk very seriously and employ routine pen testing, |
| 16 | +vulnerability scanning, and code reviews. We also welcome the contributions |
| 17 | +from the community that helped make this product possible. |
| 18 | + |
| 19 | +# Where should I report security issues? |
| 20 | + |
| 21 | +Please report security issues to security@coder.com, providing |
| 22 | +all relevant information. The more details you provide, the easier it will be |
| 23 | +for us to triage and fix the issue. |
| 24 | + |
| 25 | +# Out of Scope |
| 26 | + |
| 27 | +Our primary concern is around an abuse of the Coder application that allows |
| 28 | +an attacker to gain access to another users workspace, or spin up unwanted |
| 29 | +workspaces. |
| 30 | + |
| 31 | +- DOS/DDOS attacks affecting availability --> While we do support rate limiting |
| 32 | + of requests, we primarily leave this to the owner of the Coder installation. Our |
| 33 | + rationale is that a DOS attack only affecting availability is not a valuable |
| 34 | + target for attackers. |
| 35 | +- Abuse of a compromised user credential --> If a user credential is compromised |
| 36 | + outside of the Coder ecosystem, then we consider it beyond the scope of our application. |
| 37 | + However, if an unprivileged user could escalate their permissions or gain access |
| 38 | + to another workspace, that is a cause for concern. |
| 39 | +- Vulnerabilities in third party systems --> Vulnerabilities discovered in |
| 40 | + out-of-scope systems should be reported to the appropriate vendor or applicable authority. |
| 41 | + |
| 42 | +# Our Commitments |
| 43 | + |
| 44 | +When working with us, according to this policy, you can expect us to: |
| 45 | + |
| 46 | +- Respond to your report promptly, and work with you to understand and validate your report; |
| 47 | +- Strive to keep you informed about the progress of a vulnerability as it is processed; |
| 48 | +- Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints; and |
| 49 | +- Extend Safe Harbor for your vulnerability research that is related to this policy. |
| 50 | + |
| 51 | +# Our Expectations |
| 52 | + |
| 53 | +In participating in our vulnerability disclosure program in good faith, we ask that you: |
| 54 | + |
| 55 | +- Play by the rules, including following this policy and any other relevant agreements. |
| 56 | + If there is any inconsistency between this policy and any other applicable terms, the |
| 57 | + terms of this policy will prevail; |
| 58 | +- Report any vulnerability you’ve discovered promptly; |
| 59 | +- Avoid violating the privacy of others, disrupting our systems, destroying data, and/or |
| 60 | + harming user experience; |
| 61 | +- Use only the Official Channels to discuss vulnerability information with us; |
| 62 | +- Provide us a reasonable amount of time (at least 90 days from the initial report) to |
| 63 | + resolve the issue before you disclose it publicly; |
| 64 | +- Perform testing only on in-scope systems, and respect systems and activities which |
| 65 | + are out-of-scope; |
| 66 | +- If a vulnerability provides unintended access to data: Limit the amount of data you |
| 67 | + access to the minimum required for effectively demonstrating a Proof of Concept; and |
| 68 | + cease testing and submit a report immediately if you encounter any user data during testing, |
| 69 | + such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), |
| 70 | + credit card data, or proprietary information; |
| 71 | +- You should only interact with test accounts you own or with explicit permission from |
| 72 | +- the account holder; and |
| 73 | +- Do not engage in extortion. |
0 commit comments