Skip to content

Security: Summer-CMS/.github

SECURITY.md

IMPORTANT: THIS PAGE IS NOT FINISHED AND STILL NEEDS FINISHING

CONNECT EMAIL AND HACKERONE WEBPAGE


Security

Summer CMS takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include all our other websites, products and services.

If you believe you have found a security vulnerability in any Summer CMS owned repository that meets Summer CMS's definition of a security vulnerability, please report it to us as described below.

Reporting Security Issues

Please do not report security vulnerabilities through public GitHub issues.

Summer CMS is an advocate of responsible vulnerability disclosure. If you've found a vulnerability, we would like to know so we can fix it. This notice provides details for how you can let us know about vulnerabilities, or alternatively you can view our security.txt file which contains quick links to contact us.

You can report a vulnerability to Summer CMS through our vulnerability disclosure programme at HackerOne. Alternatively, if you prefer to submit without logging in to HackerOne, send an email to [email protected]. If possible, encrypt your message with our PGP key; please download it from the Summer CMS PGP Key page.

You should receive a response within 48 hours. If for some reason you do not, please follow up via email to ensure we received your original message.

Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue.

When reporting a vulnerability to us, please include:

  • The website, page or repository where the vulnerability can be observed.
  • A brief description of the vulnerability.
  • Details of the steps we need to take to reproduce the vulnerability.
  • Non-destructive exploitation details.

If you are able to, please also include:

  • The type of vulnerability, for example, the OWASP category.
  • Screenshots or logs showing the exploitation of the vulnerability.

If you are not sure if the vulnerability is genuine and exploitable, or you have found:

  • A non-exploitable vulnerability.
  • Something you think could be improved - for example, missing security headers.
  • TLS configuration weaknesses - for example weak cipher suite support or the presence of TLS1.0 support.

This information will help us triage your report more quickly.

Guidelines for reporting a vulnerability

When you are investigating and reporting the vulnerability on a Summer CMS domain or subdomain, you must not:

  • Break the law.
  • Access unnecessary or excessive amounts of data.
  • Modify data.
  • Use high-intensity invasive or destructive scanning tools to find vulnerabilities.
  • Try a denial of service - for example overwhelming a service on a Summer CMS website with a high volume of requests.
  • Disrupt Summer CMS's services or systems.
  • Tell other people about the vulnerability you have found until we have disclosed it.
  • Social engineer, phish or physically attack our staff or infrastructure.
  • Demand money to disclose a vulnerability.

Only submit reports about exploitable vulnerabilities through HackerOne.

Preferred Languages

We prefer all communications to be in English.

Disclosure Policy

Summer CMS follows the principle of Coordinated Vulnerability Disclosure (CVD).

Under the principle of Coordinated Vulnerability Disclosure, researchers disclose newly discovered vulnerabilities in hardware, software, and services directly to the vendors of the affected product; to a national CERT or other coordinator who will report to the vendor privately; or to a private service that will likewise report to the vendor privately. The researcher allows the vendor the opportunity to diagnose and offer fully tested updates, workarounds, or other corrective measures before any party discloses detailed vulnerability or exploit information to the public. The vendor continues to coordinate with the researcher throughout the vulnerability investigation and provides the researcher with updates on case progress. Upon release of an update, the vendor may recognize the finder for the research and privately reporting the issue. If attacks are underway in the wild, and the vendor is still working on the update, then both the researcher and vendor work together as closely as possible to provide early public vulnerability disclosure to protect customers. The aim is to provide timely and consistent guidance to customers to help them protect themselves.

For more information on CVD, please review the information provided in the following links:

Bug bounty

Unfortunately, Summer CMS doesn't offer a paid bug bounty programme. Summer CMS will make efforts to show appreciation to people who take the time and effort to disclose vulnerabilities responsibly. We do have an acknowledgements page for legitimate issues found by researchers found on our thanks.txt page.

Code of Conduct

Summer CMS have a contributors code of conduct, which you can find here: Code of Conduct

Traffic Light Protocol (TLP)

Summer CMS uses the Forum of Incident Response and Security Teams (FIRST), Traffic Light Protocol (TLP) version 2.0.

According to FIRST, the color-coded TLP labels should be applied based on the audience that should have access to the shared sensitive information:

image

Comments on this Policy

If you have suggestions on how this process could be improved please submit a pull request.

There aren’t any published security advisories