Create SECURITY.md

CONTRIBUTING.md

@@ -6,6 +6,7 @@ First off, thanks for taking the time to contribute! ❤️
 All types of contributions are encouraged and valued. See the [Table of Contents](#table-of-contents) for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions. 🎉
 
 > And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:
+>
 > - Star the project
 > - Tweet about it
 > - Refer this project in your project's readme
@@ -44,6 +45,7 @@ We will then take care of the issue as soon as possible.
 ## I Want To Contribute
 
 > ### Legal Notice <!-- omit in toc -->
+>
 > When contributing to this project, you must agree that you have authored 100% of the content, that you have the necessary rights to the content and that the content you contribute may be provided under the project license. That is, you transfer the all the rights to the content to the project, which will then be licensed under the project license and can be used by the project in any way deemed appropriate. We follow the [Apache Contributor License Agreement](https://www.apache.org/licenses/contributor-agreements.html), which you must agree to before your contribution can be accepted. You only need to do this once, we will inform you if your contribution requires another agreement.
 
 ### Reporting Bugs
@@ -68,7 +70,7 @@ A good bug report shouldn't leave others needing to chase you up for more inform
 <!-- omit in toc -->
 #### How Do I Submit a Good Bug Report?
 
-> You must never report security related issues, vulnerabilities or bugs including sensitive information to the issue tracker, or elsewhere in public. Instead sensitive bugs must be sent by email to <[email protected]>.
+> You must never report security related issues, vulnerabilities or bugs including sensitive information to the issue tracker, or elsewhere in public. Instead sensitive bugs must be sent by email to <[email protected]> or follow the guidelines in [SECURITY](./SECURITY.md).
 
 Use the following command to import the PGP key for encrypting the security bug report:
 
@@ -116,4 +118,5 @@ Enhancement suggestions are tracked as [GitHub issues](https://github.com/gatewa
 
 <!-- omit in toc -->
 ## Attribution
+
 This guide is based on the **contributing-gen**. [Make your own](https://github.com/bttger/contributing-gen)!

SECURITY.md

@@ -0,0 +1,65 @@
+# Security Policy
+GatewayD appreciates community feedback and responsible reporting of any vulnerability that may have been found.
+
+## Supported Versions
+GatewayD Labs /  https://gatewayd.io
+GatewayD Labs is behind the free and open-source project GatewayD, a cloud-native database gateway and framework for building data-driven applications
+[email protected]
+
+| Version | Supported          |
+| ------- | ------------------ |
+| All   | :white_check_mark: |
+
+## Reporting a Vulnerability
+
+The GatewayD research team is dedicated to working closely with the open source community and with projects that are affected by a vulnerability, in order to protect users and ensure a coordinated disclosure. When we identify a vulnerability in a project, we will report it by contacting the publicly-listed security contact for the project if one exists; otherwise we will attempt to contact the project maintainers directly.
+
+If the project team responds and agrees the issue poses a security risk, we will work with the project security team or maintainers to communicate the vulnerability in detail, and agree on the process for public disclosure. Responsibility for developing and releasing a patch lies firmly with the project team, though we aim to facilitate this by providing detailed information about the vulnerability.
+
+Our disclosure deadline for publicly disclosing a vulnerability is: 90 days after the first report to the project team.
+
+We appreciate the hard work maintainers put into fixing vulnerabilities and understand that sometimes more time is required to properly address an issue. We want project maintainers to succeed and because of that we are always open to discuss our disclosure policy to fit your specific requirements, when warranted.
+
+## Vulnerability Report (Suggested Format)
+I identified potential security vulnerabilities in GatewayD.
+
+I am committed to working with you to help resolve these issues. In this report you will find everything you need to effectively coordinate a resolution of these issues.
+
+If at any point you have concerns or questions about this process, please do not hesitate to reach out to me at [email].
+
+If you are NOT the correct point of contact for this report, please let me know!
+
+Summary<br>
+Short summary of the problem. Make the impact and severity as clear as possible. For example: An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the server.
+
+Product<br>
+GatewayD (or specific plugin)
+
+Tested Version<br>
+[version]
+
+Details<br>
+Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.
+
+PoC<br>
+Complete instructions, including specific configuration details, to reproduce the vulnerability
+
+Impact<br>
+[impact]
+
+Remediation<br>
+Propose a remediation suggestion if you have one. Make it clear that this is just a suggestion, as the maintainer might have a better idea to fix the issue.
+
+GitHub Security Advisories (please include https://github.com/mostafa)<br>
+If possible, please could you create a private GitHub Security Advisory for these findings? 
+This allows you to invite me to collaborate and further discuss these findings in private before they are published.
+I will be happy to collaborate with you, and review your fix to make sure that all corner cases are covered.
+When you use a GitHub Security Advisory, you can request a CVE identification number from GitHub.
+GitHub usually reviews the request within 72 hours, and the CVE details will be published after you make your security advisory public.
+Publishing a GitHub Security Advisory and a CVE will help notify the downstream consumers of your project, so they can update to the fixed version.
+
+Credit<br>
+List all researchers who contributed to this disclosure. If you found the vulnerability with a specific tool, you can also credit this tool.
+
+Contact<br>
+[contact]