Our security policies and procedures for this project are outlined below. Broadly, we wish to avoid leaving the ecosystem worse than we found it.
Any issues with minor versions will be investigated whilst this project is in early development, however we may recommend updated to the latest pre-v1.0 version.
| Version | Supported |
|---|---|
| < 1.0 | ✅ |
We take all security bugs in our projects seriously. Thank you for improving the security of them. We appreciate your efforts and responsible disclosure, and will make every effort to acknowledge your contributions. At this time we do not run a formal bug bounty programme.
Report security bugs by emailing the lead maintainer at [email protected].
They will acknowledge your email within 72 hours, and will send a more detailed response within a further 72 hours indicating the next steps in handling your report. After the initial reply to your report, we will endeavor to keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance.
Report security bugs in third-party modules should be to the person or team maintaining said module.
We are advocates of responsible vulnerability disclosure. If you’ve found a vulnerability, we would like to know so we can fix it.
Disclosures should be sent to [email protected], including:
- Your name and affiliation
- Sufficient details of the vulnerability to allow it to be understood and reproduced; this would include the website, page or repository where the vulnerability can be observed
- Optionally, the type of vulnerability and any related OWASP category
- Relevant HTTP requests and responses, HTML snippets, screenshots or any other supporting evidence. Redact any personal data before reporting
- Proof of concept code (if available), or non-destructive exploitation details
- The impact of the vulnerability
- Any references or further reading that may be appropriate
Our investigation process is straight-forward. We will work to:
- Confirm the problem and determine the affected versions.
- Audit code to find any potential similar problems.
- Prepare fixes for all releases still under maintenance
We have baked some baseline security checks into our toolchain, to be reflected in this section together with things to watch out for.
- You MUST encode, escape and validate any inputs
- You MUST NOT commit secrets, passwords or keys
- You SHOULD pin any new dependencies
Prospective contributors are encouraged to familiarise themselves, if not already, with existing techniques and good practise.
If you have suggestions on how this process could be improved please submit a pull request.
All notable changes to this policy should be noted below. We use SemVer for versioning, with the following intents:
- We will increment the MAJOR version when we change contact information, encryption keys, or a field in security.txt in a backwards-incompatible manner
- We will increment the MINOR version when we otherwise change this file or the security.txt in a backwards-compatible manner
- We will increment the PATCH version for minor typos or similar
- 1.1.0 (2024-10-16) - Inclusion of Aikido Security in Security Toolchain
- 1.0.0 (2024-04-03) - Initial policy and procedures
Thanks to @trewaters for their thoughts on structuring a SECURITY readme together with the team behind security.txt
Based in part on the excellent material in the standardjs security readme
Licensed under CC BY-SA 4.0 Creative Commons Attribution-ShareAlike 4.0 International