Last Updated 15th May 2026
This is the full security policy for the collective repository containing all vulnerabilities found in projects owned/primarily maintained by Benshawmean. It outlines the guidelines and procedures for reporting vulnerabilities, the expected response times for handling reported vulnerabilities, and the overall approach to security for these repositories.
In the event of any conflict between this policy and any other policies or guidelines, the project's security policy shall take precedence. This means that if there are any discrepancies or contradictions between this policy and any other policies, the provisions outlined in this security policy will govern the handling of vulnerabilities and security incidents for the repositories covered by this policy.
This policy applies to all repositories owned/primarily maintained by Benshawmean, including but not limited to those hosted on GitHub and GitLab. It covers the handling of vulnerabilities, security incidents, and the overall security posture of these repositories.
The following are items that are considered to be in scope:
Remote Code Execution (RCE) vulnerabilities allow attackers to execute arbitrary code on a target system. This can lead to unauthorized access, data breaches, and other security incidents. Any code that can lead to an RCE vulnerability is considered to be in scope for this policy.
Denial of Service (DoS) vulnerabilities allow attackers to disrupt the normal functioning of a system, making it unavailable to users. This can lead to service outages and other disruptions. Any code that can lead to a DoS vulnerability is considered to be in scope for this policy.
Information Disclosure vulnerabilities allow attackers to access sensitive information that should not be publicly available. This can lead to data breaches and other security incidents. Any code that can lead to an Information Disclosure vulnerability is considered to be in scope for this policy.
Privilege Escalation vulnerabilities allow attackers to gain elevated privileges on a target system. This can lead to unauthorized access and other security incidents. Any code that can lead to a Privilege Escalation vulnerability is considered to be in scope for this policy.
Web-based vulnerabilities, such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and SQL Injection, allow attackers to exploit weaknesses in web applications. This can lead to unauthorized access, data breaches, and other security incidents. Any code that can lead to a web-based vulnerability is considered to be in scope for this policy.
The following are items that are considered to be out of scope:
Any of the previous items in scope that are found in third-party dependencies are considered to be out of scope for this policy. This means that if a vulnerability is found in a third-party dependency, it will not be handled under this policy and will instead be the responsibility of the maintainers of that dependency.
Social engineering attacks, such as phishing and pretexting, are considered to be out of scope for this policy. This means that if a vulnerability is found that is related to social engineering, it will not be handled under this policy and will instead be the responsibility of the individual or organization targeted by the attack.
Physical security vulnerabilities, such as unauthorized access to physical devices or facilities, are considered to be out of scope for this policy. This means that if a vulnerability is found that is related to physical security, it will not be handled under this policy and will instead be the responsibility of the individual or organization responsible for the physical security of the device or facility.
Non-security bugs, such as performance issues, usability problems, and other non-security related issues, are considered to be out of scope for this policy. This means that if a vulnerability is found that is related to a non-security bug, it will not be handled under this policy and will instead be the responsibility of the maintainers of the affected repositories to address it through their normal bug-fixing processes.
If you have found a vulnerability in any of the repositories covered by this policy, please report it to me as soon as possible. You can report vulnerabilities by contacting me through the following channels:
Personal Website Website Security.txt GitHub Security.txt
The following are the expected response times for handling reported vulnerabilities:
I will try my best to acknowledge receipt of your vulnerability report within 48 hours. It is recommended to email me as well as submit a report through the GitHub repository's security vulnerability reporting system to ensure that your report is received and acknowledged in a timely manner.
I will try my best to perform an initial assessment of the reported vulnerability within 7 days of acknowledging receipt of the report. During this initial assessment, I will determine the severity of the vulnerability and whether it is valid or not.
If the reported vulnerability is valid, I will try my best to remediate it as soon as possible. The time it takes to remediate a vulnerability will depend on its severity and complexity, but I will make every effort to address it in a timely manner.
Different levels of severity may require different response times. The following are the expected response times for different levels of severity:
Critical vulnerabilities, such as Remote Code Execution (RCE) and Denial of Service (DoS) vulnerabilities, will be prioritized for remediation and will be addressed as soon as possible, ideally within 30 days of the initial assessment.
High vulnerabilities, such as Information Disclosure and Privilege Escalation vulnerabilities, will also be prioritized for remediation and will be addressed as soon as possible, ideally within 60 days of the initial assessment.
Medium vulnerabilities, such as web-based vulnerabilities that do not lead to critical or high severity issues, will be addressed in a timely manner, ideally within 90 days of the initial assessment.
Low vulnerabilities, such as minor security issues that do not pose a significant risk, will be addressed as part of regular maintenance and may not have a specific timeline for remediation.
I will try my best to follow responsible disclosure practices when handling reported vulnerabilities. This means that I will work with the reporter to ensure that the vulnerability is properly addressed before it is publicly disclosed. I will also make every effort to provide credit to the reporter for their contribution to improving the security of the affected repositories.
I do not currently have a bug bounty program in place for the repositories covered by this policy. However, I may consider implementing a bug bounty program in the future as a way to incentivize and reward security researchers for reporting vulnerabilities. If I do decide to implement a bug bounty program, I will provide clear guidelines and rules for participation, as well as a transparent process for evaluating and rewarding valid vulnerability reports.
When reporting a vulnerability, it is helpful to include the following information to assist in the assessment and remediation process:
A clear and concise description of the vulnerability, including the affected repository, the type of vulnerability, and any relevant details about how it can be exploited.
Detailed steps to reproduce the vulnerability, including any necessary code snippets, commands, or configurations that can help in understanding and verifying the issue.
An assessment of the potential impact of the vulnerability, including any potential risks or consequences if it were to be exploited.
Any suggestions for how to remediate the vulnerability, such as code changes, configuration updates, or other measures that can help mitigate the issue.
Your contact information, such as an email address or social media handle, so that I can follow up with you if I need additional information or to provide updates on the status of the vulnerability report.
If you are able to provide a Common Vulnerability Scoring System (CVSS) score for the vulnerability, it can help in assessing its severity and prioritizing remediation efforts. It is requested that you use either version 3.1 or version 4 of the CVSS scoring system when providing this information.
If the vulnerability you are reporting has been assigned a Common Vulnerabilities and Exposures (CVE) identifier or a Common Weakness Enumeration (CWE) identifier, please include this information in your report. This can help in tracking and referencing the vulnerability across different platforms and databases, and can also assist in the assessment and remediation process.
For more information on CVE and CWE identifiers, you can refer to the following resources:
https://cve.org/ https://nvd.nist.gov/vuln/search#/nvd/home
If you would like to receive acknowledgment or credit for your vulnerability report, please include this information in your report. I will make every effort to provide credit to the reporter for their contribution to improving the security of the affected repositories, and I will work with you to ensure that your contribution is properly recognized in any public disclosures or acknowledgments related to the vulnerability.
Thank you for taking the time to read this security policy. I take the security of my repositories seriously and appreciate any efforts to help identify and address vulnerabilities. If you have any questions or concerns about this policy, please feel free to contact me through the channels mentioned above.