Merge pull request #205 from gocardless/asilde-patch-1

Update SECURITY.md

SECURITY.md

@@ -1,58 +1,50 @@
-GoCardless looks forward to working with the security community to find security vulnerabilities in order to keep our businesses and customers safe.
+Vulnerabilities are flaws in software and services that, if exploited, may allow malicious actors to perform reconnaissance, steal sensitive information, perform protected actions, or make a system or service unavailable. A confirmed vulnerability is usually registered by MITRE as a CVE ([Common Vulnerability or Exposure](https://cve.mitre.org/)) and assigned a CVSS ([Common Vulnerability Scoring System](https://www.sans.org/blog/what-is-cvss/)) score to reflect the potential risk it could introduce to an organisation.
 
-We really appreciate your help in uncovering any security issues and look forward to your findings. If anything is unclear or you have any questions, please reach out to [email protected].  
+Exploitation is the next step after finding a vulnerability. Exploits are the means through which a vulnerability can be leveraged for malicious activity by perpetrators. Exploits can manifest as pieces of software, sequences of commands, or even open-source exploit kits.
 
-# Response Targets
-GoCardless will make a best effort to meet the following response targets for hackers participating in our program:
+Alongside following secure design, development, and configuration principles, GoCardless performs regular vulnerability assessments and security tests to identify flaws in our production services and systems that may be exploited for malicious purposes.
 
-* Time to first response (from report submit) - 2 business days
-* Time to triage (from report submit) - 2 business days
-* Time to bounty (from triage) - 10 business days
+GoCardless also looks forward to working with the security community to find security vulnerabilities enabling us to keep our business and customers safe.
 
-We’ll try to keep you informed about our progress throughout the process.
-
-# Program Rules
-* Social engineering (e.g. phishing, vishing, smishing) is prohibited.
-* Follow HackerOne's disclosure guidelines.
-* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
-* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
-* Any activity that could lead to the disruption of our service (DoS) is prohibited.
-* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
-* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
-* Amounts below are the minimum and maximum bounties we will pay per bug based on severity. We aim to be fair; all reward amounts are at our discretion.
+# Report a Vulnerability
+If you think you have identified a vulnerability and can present a proof of concept (PoC) or other evidence that a vulnerability exists in our systems or services, please use our public [Bug Bounty program](https://hackerone.com/gocardless_bbp) to submit a report.
+
+Alternatively, email [[email protected]](mailto:[email protected]) to receive further instructions on reporting a vulnerability to the GoCardless security team.
+
+Please do not discuss any vulnerabilities (even resolved ones) outside of the program without express consent from GoCardless.
+
+Please review our [vulnerability disclosure policy](https://hackerone.com/gocardless_bbp?view_policy=true) before submitting a report.
+
+# Testing Restrictions
+Please conduct dynamic testing on our Sandbox environment only. You can sign up for a [Sandbox account](https://manage-sandbox.gocardless.com/signup) to get started. Our [developer documentation](https://developer.gocardless.com/getting-started/introduction) provides details on how to configure an account.
+
+There is currently no Sandbox environment for the Bank Account Data portal. As such, no automated scanning is to be conducted, and only manual testing is permitted on the following in-scope domains (both represent the same application):
+* https://bankaccountdata.gocardless.com
+* https://ob.gocardless.com
+Consult the [documentation](https://developer.gocardless.com/bank-account-data/sandbox) to find out how to use sandbox bank details for Bank Account Data testing purposes.
+
+You must use a [HackerOne email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html) account for accounts configured in our environments (e.g., `[email protected]`).
+
+You must not conduct denial of service or other forms of destructive testing, and social engineering against GoCardless employees or customers is strictly prohibited.
+
+# Response Targets
+GoCardless will make the best effort to meet the following response targets for processing submissions from the community:
+
+* Time to first response (from report submission) - 5 business days
+* Time to triage (from report submission) - 10 business days
+* Time to bounty (from report submission) - 30 business days
 
 # Scope
-All scope is listed below in the structured scope section
+You can review the full scope of our bug bounty and vulnerability disclosure programme on the [program scope page](https://hackerone.com/gocardless_bbp/policy_scopes).
+
+Our [public GitHub repositories](https://github.com/gocardless?q=&type=public&language=&sort=) are also included.
 
 # Out of Scope
-Third party services are out of scope for this program, even if they are accessible under an in scope URL. This would typically include services such as Zendesk or externally hosted forms.
-
-If you are unsure, please email [email protected]
-
-# Out of scope vulnerabilities
-When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:
-* Clickjacking
-* Unauthenticated/logout/login CSRF.
-* Attacks requiring MITM or physical access to a user's device.
-* Previously known vulnerable libraries without a working Proof of Concept.
-* Comma Separated Values (CSV) injection without demonstrating a vulnerability.
-* Missing best practices in SSL/TLS configuration.
-* Missing best practices in Content Security Policy.
-* Missing cookie flags
-* Email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
-* Vulnerabilities only affecting users of outdated or unpatched browsers and platforms
-* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack-traces, application or server errors).
-* Rate limiting issues that lead to spam.
-* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
-* CSRF on none sensitive pages
-* CORS headers misconfiguration without demonstrating impact
-* Email enumeration
+Third-party services are out of scope for this program, even if they are accessible under an in-scope URL. This would typically include services, such as Zendesk or externally hosted forms.
+
+GitHub repositories under the GoCardless organisation that are forks, mirrors, or archived are out of scope.
+
+Please refer to our [vulnerability disclosure program page](https://hackerone.com/gocardless_bbp?view_policy=true) for a full list of vulnerabilities that are considered to be out of scope.
 
 # Safe Harbor
 Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
-
-# Test Plan
-
-Where appropriate, hackers can create their own accounts using their HackerOne email alias, by signing up with [email protected] (e.g. [email protected]) to use in testing applications/services.
-
-See more here: https://docs.hackerone.com/hackers/hacker-email-alias.html