POLICY.txt

ORGNAME Security and Vulnerability Reporting Policy

1. Services Covered by this Policy

This policy covers all services directly operated by us (ORGNAME).
Services can be identified by the following means:
- The website has a .well-known/security.txt that links to this policy.
- The reverse DNS of an IP address resolves to one of the following
  domains: example.com

2. Acceptable Use

We generally invite security researchers to search for vulnerabilities
in our services. We kindly ask to not put any actual user data or
production systems at risk.

3. Classification of Vulnerabilities
We will consider a vulnerability report most likely as relevant if it
reports one of the following problems:
    1. The vulnerability can be used to directly access non-public
       information that either reveals further security relevant problems or
       contains user data, credentials, or sensitive data in general.
    2. The vulnerability can be used to disrupt the orderly operation of a
       service (Denial of Service).
    3. The vulnerability can be used to manipulate data within the service.
    4. XSS, CSRF, RCE, authentication/authorization bypass, SQL inections,
       etc are considered relevant.
We will consider a vulnerability report most likely as NOT relevant if
it reports one of the following problems:
    5. Missing security features, for example HTTP headers, if they are not
       actually preventing a vulnerability.
    6. Publicly accessible version strings of used software.
    7. Security vulnerablities that can only be used within the scope of the
       used account.
    8. Publicly available information even when retrieved over usually non-
       public channels (i.e. APIs).

4. Reporting Vulnerabilities

Report vulnerabilities via e-mail to security@example.com. For
encryption the PGP key https://example.com/pubkey.asc can be used.

Please make sure that you include the following information:
- Which service is affected
- How can the bug be used/exploited
- Explanation of the risk

Reports will be answered within 48 hours. If you have not received an
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 the 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.

7. About this Policy

This policy is MIT licensed. Feel free to suggest modifications and
additions at https://github.com/digitalfabrik/security-policy.