Blackflake.
EN PL

Security

Responsible disclosure

If you believe you've found a security vulnerability affecting Blackflake or its operator Bennovate sp. z o.o., we want to hear about it. This page covers how to report, what's in scope, and the protections we extend to good-faith researchers.

Effective 22 April 2026 Version 1.0 Machine-readable: security.txt

01How to report

Email security@blackflake.com. Preferred languages: English, Polish.

A good report includes:

  • A clear description of the vulnerability and its potential impact.
  • Step-by-step reproduction instructions, proof-of-concept code if applicable, and the affected URL, endpoint, or asset.
  • Your name or handle (so we can credit you, if you wish) and a reliable contact address.

Machine-readable details: /.well-known/security.txt per RFC 9116.

02Scope

In-scope assets for this policy:

  • The blackflake.com domain and any direct subdomains operated by Bennovate sp. z o.o.
  • Publicly reachable Blackflake services and endpoints that process customer or enterprise data.

03Out of scope

  • Findings in third-party services we use as processors (e.g. hosting providers, email providers) unless they specifically affect our configuration or exposure. Report those directly to the relevant vendor.
  • Social-engineering, phishing, or physical-security attacks against staff or offices.
  • Denial-of-service testing, volumetric attacks, or automated fuzzing that materially degrades service availability.
  • Reports from automated vulnerability scanners without demonstrated exploitability.
  • Missing best-practice hardening (CSP directives, HSTS preload, DNS CAA, etc.) absent a demonstrated impact. We welcome these as suggestions but they do not qualify for prioritised response.

04Rules of engagement

  • Only test on assets you are authorised to test — this policy is the authorisation for in-scope assets above.
  • Make a good-faith effort to avoid privacy violations, data destruction, and service interruption.
  • Do not access, copy, or exfiltrate data beyond what is strictly necessary to demonstrate the vulnerability.
  • Do not use automated scanners that generate more than a low-volume probing rate.
  • Do not publicly disclose the vulnerability before we've had a reasonable opportunity to address it — see disclosure timeline below.

05Safe harbour

If you act in good faith and within the rules above, we will not pursue or support legal action against you for your research activity on in-scope assets. This includes activity that might otherwise be prohibited under computer-misuse or copyright laws when performed in the course of ordinary security research. If a third party brings action, we will take reasonable steps to make clear that your activity was authorised by this policy.

This safe harbour does not extend to intentional destruction of data, extortion, sharing of exfiltrated data with third parties, or activity outside the stated scope.

06Our response

StageTarget
Initial acknowledgementWithin 3 business days
Triage & severity assessmentWithin 10 business days
Remediation commitmentWithin 30 days of triage, or earlier for critical findings
Credit & public acknowledgementOn request, after remediation

We will keep you informed as remediation progresses. We do not currently run a paid bounty programme.

07Disclosure

We prefer coordinated disclosure. Unless otherwise agreed, we ask researchers to allow 90 days from initial report before public disclosure. Where a vulnerability is actively exploited or the public-interest case is strong, we will work with you on an accelerated timeline.

Thank you for taking the time to make our systems safer.