Add general improvements

* Fix line breaks at 72 chars
* Improve wording for (not) relevant reports
* Add note about open source software
* Only responsible disclosures qualify for rewards

POLICY.txt

@@ -16,21 +16,21 @@ production systems at risk.
 
 3. Classification of Vulnerabilities
 
-We consider vulnerabilities as relevant when they meet one or more of
-the following conditions:
+We will consider a vulnerability report most likely as relevant if it
+reports one of the following problems:
 - The vulnerability can be used to directly access non-public
   information that either reveals further security relevant problems or
-  contains user data.
+  contains user data, credentials, or sensitive data in general.
 - The vulnerability can be used to disrupt the orderly operation of a
   service.
 - The vulnerability can be used to manipulate data within the service.
 - XSS, CSRF, RCE, authentication/authorization bypass, SQL inections,
   etc are considered relevant.
 
-We consider reports of vulnerabilities not as relevant when they contain
-the following information:
-- A service is missing HTTP security headers or comparable "add-on security"
-  features.
+We will consider a vulnerability report most likely as NOT relevant if
+it reports one of the following problems:
+- Missing security features, for example HTTP headers, if they are not
+  actually preventing a vulnerability.
 - Publicly accessible version strings of used software.
 - Security vulnerablities that can only be used within the scope of the
   used account.
@@ -46,20 +46,27 @@ Please make sure that you include the following information:
 - Explanation of the risk
 
 Reports will be answered within 48 hours. If you have not received an
-answer within that time frame, please make sure to contact us again.
+answer within that time frame, feel free to contact us again.
+
+For used open source software, we recommend to file bug reports and/or
+pull requests against the upstream repositories. This includes hardening
+instructions in the installation documentation.
 
 5. Bug Bounties / Vulnerability Rewards
 
 The amount of reward payed depends on the severity of the found
 vulnerability. We usually do not pay rewards if vulnerabilities can be
 found in mass scans with of-the-shelf software.
 
+Only responsible disclosures are eligible for rewards.
+
 6. Acknowledgement
 
 We list recognized reports of vulnerablities online if the reporting
-security researcher agrees. The name, contact e-mail address, and type of
-vulnerability can be included in the list. Our public acknowledgements
-can be found at https://example.com/security-acknowledgements.html.
+security researcher agrees. The name, contact e-mail address, and type
+of vulnerability can be included in the list. Our public
+acknowledgements can be found at
+https://example.com/security-acknowledgements.html.
 
 7. About this Policy