Security

Security Disclosure

Last updated: April 14, 2026

We build offensive security tools, so we hold ourselves to the standard we expect from the organizations we test. SprintSeven Limited (“SprintSeven”), the company behind SprintRED, welcomes responsible reports of security vulnerabilities affecting the SprintRED platform, the sprintred.com website, and our supporting infrastructure. This page describes how to report a vulnerability, what is in scope, what we commit to, and what we ask of you.

How to Report

Send vulnerability reports to [email protected] with the subject line beginning “SECURITY:”. We will acknowledge receipt within two business days.

A useful report contains, at minimum:

(1) a clear description of the vulnerability and its security impact; (2) the affected URL, endpoint, parameter, or component; (3) reliable, minimal step-by-step reproduction instructions; (4) any proof-of-concept code, request payload, or screenshot needed to reproduce; (5) the account, browser, IP, and timestamp you used during testing, so we can correlate logs; and (6) how you would like to be credited (or whether you prefer to remain anonymous).

In Scope

The following assets are in scope for this policy:

(a) the sprintred.com production website and any of its subdomains; (b) the SprintRED web application and authenticated user portal; (c) the SprintRED public API; (d) build artefacts and software supply chain components owned by SprintSeven and made available for download; and (e) infrastructure operated by SprintSeven for the purpose of running the Service.

Out of Scope

The following are not in scope and reports describing them will be closed without action:

(i) findings against assets that are not owned or operated by SprintSeven, including third-party services we link to or rely on; (ii) findings that require physical access to a target organization, social engineering of SprintSeven employees, or compromising user devices; (iii) denial-of-service, volumetric, or resource-exhaustion attacks; (iv) automated scanner output without a working proof-of-concept and a clear security impact; (v) reports of missing best-practice security headers (HSTS, CSP, X-Frame-Options, etc.) without a demonstrated exploit; (vi) reports about software versions disclosed in HTTP responses, banner grabs, or error messages, without an associated vulnerability; (vii) self-XSS, clickjacking on pages with no sensitive actions, or open redirects without further impact; (viii) findings already known to us or already reported by another researcher; and (ix) any test conducted against a target other than the assets explicitly listed in the “In Scope” section.

Safe Harbor

We will not initiate or pursue legal action against a researcher who, in good faith, complies with this policy and:

(1) limits testing strictly to the assets listed in the “In Scope” section; (2) avoids privacy violations, destruction of data, interruption or degradation of our services, and access to data beyond what is necessary to demonstrate the vulnerability; (3) does not exploit the vulnerability beyond the minimum required to confirm it; (4) reports the vulnerability to us promptly and gives us a reasonable time to remediate before any public disclosure; and (5) does not extort, threaten, or attempt to monetize a finding outside of any program we have publicly offered.

If you believe you may have inadvertently exceeded these boundaries, contact us before going further. Our intent is to work with researchers who act in good faith, not to punish honest mistakes.

Rules of Engagement

(a) Use only test accounts you create; do not access another customer's account or data. (b) Do not run automated scanners that generate excessive traffic against the platform; throttle your testing. (c) Do not attempt to extract, modify, or destroy data that is not your own; if you accidentally access another party's data, stop, do not retain or share it, and notify us immediately. (d) Do not target the personal devices, accounts, or social-media presence of SprintSeven employees, contractors, or customers. (e) Do not perform any test that could result in a denial of service for legitimate users.

Our Response Commitments

For reports that reach our team via the contact channel above, we commit to the following timeline as a target, not a guarantee:

Acknowledgement — within 2 business days of receipt. Triage and severity assessment — within 5 business days. Remediation plan or status update— within 10 business days for High and Critical severity findings, within 30 business days for Medium and below. Fix deployment— as fast as practical, with the target driven by severity. We will keep you informed of progress and let you know when the fix has been deployed.

Coordinated Disclosure

We follow a coordinated disclosure model. We ask that you do not publicly disclose a vulnerability before we have had a reasonable opportunity to investigate and remediate, and we commit to working with you on a coordinated public disclosure timeline. Where appropriate, we will request a CVE identifier from a CNA. With your permission, we will credit you in the disclosure.

Recognition

SprintSeven does not currently operate a paid bug bounty program. We do publicly thank researchers whose reports lead to a fix, where the researcher consents to be named.

Contact

Vulnerability reports and any other security-related correspondence: [email protected].

This policy may be updated from time to time. The current version is always available at this URL and is identified by the “Last updated” date above.