Vulnerability Disclosure & Bug Bounty Program

Last updated: 29 September 2026. This policy applies to reports received on or after that date. Reports we received before a revision are assessed under the version of this policy that was in force when they reached us.

Scope

We welcome responsible disclosure of security vulnerabilities in Kosli’s platform and services. Our production environment is app.kosli.com and the supporting APIs. Our marketing site is www.kosli.com. Findings against domains or infrastructure outside these, including retired brands, parked domains and non-production environments, are assessed on their merits but are generally not treated as production issues.

The Kosli CLI is not in scope for the bug bounty program. The CLI is an open source client that runs in your environment rather than ours, so findings against it are not exploitable in our production environment and do not qualify for a bounty payment. The same applies to our other client-side tooling that you download and run yourself.

We do still want to hear about CLI vulnerabilities, and we will acknowledge, assess and fix them under the responsible disclosure process set out below, and credit you if you would like us to. Please report them to security@kosli.com and see SECURITY.md in the CLI repository for what to include.

Testing guidelines

When testing, please:

• Only test against accounts you own or have explicit permission to use
• Stop as soon as you have confirmed a vulnerability, and do not access, modify or retain data belonging to other users
• Keep automated testing to a reasonable volume, and avoid anything that could degrade service for our customers
• Give us reasonable time to investigate and fix an issue before disclosing it publicly

If you follow these guidelines, we will treat your research as authorised, work with you to understand and resolve the issue quickly, and will not pursue legal action against you.

We don’t provide researcher or test accounts, and we don’t pre-authorise accounts for testing. The programme is mainly for our customers testing their own orgs. We do accept reports against our public orgs, cyber-dojo and kosli-public, within these guidelines.

Out of scope

The following are excluded from this program:

• Social engineering attacks (phishing, pretexting and similar), unless the vulnerability enables our platform to be used as a vector for social engineering
• Denial of service (DoS/DDoS) attacks or testing
• Username, email or account enumeration, including differences in login or SSO responses between registered and unregistered addresses, unless chained to a demonstrated further impact
• Absent, weak or bypassable rate limiting, unless chained to a demonstrated further impact

More generally, findings that amount to missing hardening controls or best-practice configuration, where no exploitable condition is demonstrated, are treated as Informational and do not qualify for payment. The same applies to disclosures that give no access to customer data, accounts, credentials or secrets, such as internal route names, aggregate metrics, or software and configuration details. We will still acknowledge them, and we often act on them.

Eligibility

To qualify for a bounty payment:

• The vulnerability must be Medium severity or above, as assessed under Severity assessment below
• The vulnerability must be actually exploitable in our production environment
• The report must include a working proof of concept that we can reproduce
• We must not have existing defence in depth that mitigates the issue
• The finding must be new. We do not pay for duplicates or issues already identified internally, and we can provide dated ticket evidence on request

Where several reported issues share a single underlying cause, we treat them as one finding and make one award.

Severity assessment

We score findings using CVSS v3.1, and we use the Bugcrowd Vulnerability Rating Taxonomy as our reference for how a class of issue is normally classified. The CVSS base score measures how easily an issue can be reached, not what it exposes. Where the VRT rates a class of issue lower than its CVSS score, for example an easily reached disclosure that grants no access, we use the VRT rating (P1 Critical, P2 High, P3 Medium, P4 Low, P5 Informational). Where our assessment differs from the reporter’s, we will share our vector and our reasoning.

Bounty rates

Low and Informational findings, whether rated by CVSS score or by the VRT, are appreciated but do not qualify for payment.

Reporting

Please send all reports to security@kosli.com and include:

• Clear description of the vulnerability
• Steps to reproduce
• Potential impact assessment
• Any supporting evidence (screenshots, logs, proof of concept)

Please submit one issue per email, and make sure any attachments relate to the issue described.

We accept at most two reports from each researcher in any 7-day period, counted by when we receive them, so that we can give each report proper attention. We will skim any further report for severity, so that we can act straight away on anything High or Critical, but we will not assess it or consider it for a bounty. Please resubmit it once 7 days have passed since your earlier reports. If we act on it in the meantime, the date you first sent it is the one we use when we check whether the finding is new.

Our commitment

Integrity is a core value at Kosli. We have a strong track record of working fairly and openly with security researchers, and we’re committed to transparent communication throughout the disclosure process. We will acknowledge receipt, assess the finding, and respond with our determination. If we classify the vulnerability differently than reported, we’ll explain our reasoning and show our working.