Security
Security and vulnerability disclosure
How to report a vulnerability in our products or this site, what we promise reporters, our safe-harbour statement and where security.txt lives.
- Version of 6 September 2026
Jump to a section
We are a manufacturer too
We sell vulnerability handling, so we practise it. This page is the short version of the coordinated vulnerability disclosure policy we publish for our own products; the full policy is on the proof page, generated from the same template we use for customers.
What this policy covers
- this website and the customer portal;
- the SentinelSphere CRA platform and its public endpoints;
- the SentinelSphere analytics platform and our command-line tools;
- our published container images and packages.
Out of scope: customers' products (report those to the customer's own contact), third-party services we use (report to them; we will help you find the right address if you are unsure), and findings that require physical access to our equipment.
How to report
Email [SECURITY EMAIL ADDRESS]. If you want to encrypt, our PGP key is
at [PGP KEY URL]. The same details are in
/.well-known/security.txt, which also states the policy location,
preferred languages (English, French, Greek) and the expiry date of the
file.
Include what you can: the affected component and version, steps to reproduce, the impact as you understand it, and how you would like to be credited, if at all. You do not need to include an exploit.
What we promise
- We acknowledge your report within two business days.
- We give you a first assessment (confirmed, needs more information, or not a vulnerability) within [TRIAGE TARGET TO CONFIRM] business days, with a named engineer as your contact.
- We keep you informed as we work on a fix, and we tell you when it ships.
- We aim to fix confirmed vulnerabilities within [FIX TARGET TO CONFIRM] days of confirmation, and we agree a disclosure date with you, normally no later than 90 days after your report unless we both agree otherwise.
- We credit you in the release notes if you want us to.
- If a vulnerability you report in one of our products turns out to be actively exploited, we handle our own reporting duties under the Cyber Resilience Act; you do not have to do anything more.
We do not pay bounties at this time.
Safe harbour
If you research and report in good faith and within the rules below, we will not pursue legal action against you, we will not report you to law enforcement for your research, and we will work with you to understand and resolve the issue. If a third party takes action against you over research conducted under this policy, we will make it known that you acted in accordance with it.
The rules:
- Do not access, modify or delete data that is not yours beyond what is needed to demonstrate the issue; stop as soon as you have a proof.
- Do not degrade the service: no denial-of-service testing, no automated scanning at a rate that affects other users.
- Do not use social engineering, phishing or physical attacks against our people or premises.
- Do not test systems that belong to our customers or to third parties.
- Give us reasonable time to fix the issue before disclosing it.
- Do not demand payment as a condition of disclosure.
What we do on our side
Our own products go through the same pipeline we sell: an SBOM generated and signed in CI on every release, vulnerability scanning that gates builds, matching against vulnerability feeds and known-exploited catalogues every business day, a vulnerability-handling procedure and a reporting runbook that we rehearse. The current artefacts, with hashes, are on the proof page.
Contact
Security reports: [SECURITY EMAIL ADDRESS]. Everything else: the contact page.
Anything here you would like explained?
Ask us. An engineer answers, in plain words, and says so when a question is one for your own lawyer.