Responsible Disclosure Procedure

We take the security of our systems very seriously at Red Sift but sometimes vulnerabilities can slip through our rigorous checks. If you discover a vulnerability we want to know about it so we can address it. We would like to count on the security community out there to help us better protect our users and systems.

We ask you not to take advantage of the vulnerability, not to tell others about it or use malicious methods to look for or exploit them. Please email your findings with sufficient information about its impact and how to reproduce it to [email protected].

Reporting guidelines

Reports must include details of the vulnerability, steps to reproduce it, and a description of the vulnerability and its potential impact.

Every report must include:

• Clear, step-by-step instructions to reproduce the issue.
• The affected product, environment (e.g. production, staging), and URL(s) (if applicable).
• Relevant evidence such as screenshots, logs, request/response details, or proof-of-concept code.
• The potential security or business impact of the issue.

Please make reports as detailed and specific as possible. Reports must demonstrate original analysis and a clear understanding of the issue. Low-effort, generic, template-based, or automatically generated reports without meaningful validation or context may be rejected.

Our commitment to you

• You will receive an automatic acknowledgement when your report is submitted. If you do not receive this acknowledgement, please contact us.
• We will then evaluate the issue and provide updates on our progress toward resolving the issue.
• If you wish, we will publish your details in our Hall of Thanks, should your report meet these guidelines.

To ensure the safety of our users and systems, we ask that you:

• Act in good faith and avoid privacy violations, destruction of data, or service disruption
• Only test systems that are in scope
• Avoid accessing, modifying, or deleting data belonging to other users
• Avoid performing actions that could degrade system performance
• Stop testing immediately and report the issue if you encounter sensitive data.
• Avoid using scanners or automated tools to find vulnerabilities
• Do not attempt non-technical attacks such as social engineering, phishing, or physical attacks against our employees, users, or infrastructure.
• Do not publicly disclose the vulnerability until it has been resolved or we have agreed on a disclosure timeline

If you act in good faith, follow this policy, and report vulnerabilities responsibly:

• We will not pursue legal action against you for your research
• We consider your actions to be authorized testing within the scope of this policy
• We will work with you to understand and resolve the issue

This safe harbour applies only to activities conducted in accordance with this policy.

Rewards

• Rewards are discretionary and depend on the severity, impact, and quality of the report. Not all valid reports will qualify for a monetary reward. Some may receive recognition in our Hall of Thanks instead.
• If multiple reports are received for the same vulnerability, a bounty will only be awarded once and will typically be granted to the first report that provides sufficient detail for us to reproduce and validate the issue.

Eligible Bounties

Any vulnerability that could compromise the confidentiality, integrity, or availability of Red Sift systems or customer data.

• Cross-site scripting
• Cross-site request forgery
• Remote code execution
• Clickjacking
• Code injection
• Leaks of sensitive data

Ineligible bounties

We cannot reward bounties for things that are outside of our direct control, or are not relevant vulnerabilities, such as:

• Social engineering
• Physical access to hardware
• Vulnerabilities in third party software (Ruby, nginx, wordpress, etc)
• Denial of Service
• Usability issues
• Missing security headers that do not lead to an exploitable vulnerability
• Clickjacking on pages with no sensitive actions
• Rate limiting or brute force findings without a demonstrated exploit or security impact
• Reports that only show theoretical impact
• Self-XSS
• Tabnabbing
• Open redirects without demonstrated security impact
• Best-practice or informational findings without exploitation