Company · Security & trust
What we defend, what you may test, and how to prove a release is ours.
A security product should be easy to hold to account. This page is the disclosure policy, the remediation clock, the supported versions and the verification steps, the same commitments as the platform's own security policy.
Vulnerability disclosure
Report privately. We answer within two business days.
Please do not open a public issue for a security vulnerability.
A PGP key for encrypting reports will be published at https://trony.network/.well-known/pgp-key.txt. Until it is live, request the current key from the address above.
Include a description and impact, the affected component and version, reproduction steps or a proof of concept, and any suggested remediation.
Safe harbour
Good-faith research conducted under this policy (without privacy violation, data destruction or service degradation) is authorised, and we will not pursue legal action for it. Do not access or modify data that is not yours; stop and report immediately if you encounter personal data. Reports must not exfiltrate, retain or disclose collected attacker data.
Our commitment
- Acknowledgement2 business days
- Triage and severity (CVSS)5 business days
- Critical remediation7 days
- High remediation30 days
- Medium / Low remediation90 days
Supported versions
Current tagged minor
Supported. Fixes ship in the next patch release on that line, within the targets above.
Previous tagged minor
Supported. Critical and High fixes are backported; Medium and Low are fixed on the current line only.
Pre-release (main)
Security fixes on a best-effort basis; the fix lands on main.
Older
Not supported. Upgrade to a supported line.
At most two minor lines are supported at once. A fix is a forward upgrade; rollback is redeploying the previous image, never a down-migration. A running instance reports its version at GET /api/system/version.
Scope
What is in scope, and what is not.
In scope
The application code: API, ingestion clients, sensor forwarder and device personas, frontend, Helm and Compose deployment artefacts.
Out of scope
Third-party dependencies (report upstream), and any deployment you do not own or lack authorisation to test.
Contracted tests
A pentest scope document governs contracted engagements: in-scope assets, provisioned test accounts, rules of engagement (no DoS; the sensor personas may be attacked freely; the emulation surface and customer endpoints are out of scope), an ASVS L2 / API Top 10 checklist.
Supply chain
Prove an artefact is ours before you run it.
Images, SBOM attestations and the Helm chart are signed with the project’s own cosign key. Signatures are deliberately not written to a public transparency log, so the key is the whole trust root: pin it once, from a channel you trust, and check its fingerprint.
cosign.pub · SHA-256 fingerprint
480fc295dabeaa07d20ae0f4c816c9ac73bf3c7951b839b35ab175a953378f41
The public key ships with every release and is listed in its SHA256SUMS. Compare that copy with this fingerprint, or with the one we give you directly: a key that arrived with the artefact it vouches for proves nothing on its own.
Each release carries CycloneDX SBOMs (per image and for the source tree), Trivy scan reports, the OpenAPI specification and SHA256SUMS over every file. Images are delivered with the release; deploy them by digest, not by tag.
# 1. pin the key
sha256sum cosign.pub
# 2. verify the image signature, by digest
cosign verify --key cosign.pub --insecure-ignore-tlog <image>@sha256:…
# 3. verify the SBOM attestation
cosign verify-attestation --type cyclonedx --key cosign.pub --insecure-ignore-tlog <image>@sha256:…
# 4. check every other file against the checksums
sha256sum --check --ignore-missing SHA256SUMS
--insecure-ignore-tlog tells cosign not to look for a transparency-log entry, because none is written. The signature itself is checked in full against the pinned key. If verification fails, do not deploy: report it to the security address above, with the digest and the command output.
Documents
Three documents say what the platform defends.
threat-model
Threat model
STRIDE per trust boundary, every mitigation named against the file that implements it, plus the residual risks we know about and the assumptions we make about the environment.
pentest-scope
Pentest scope
The engagement scope for a contracted test, the test accounts we provision, the rules of engagement and the reporting format.
supply-chain
Supply chain
How to verify a released image, chart and SBOM against the project’s public key, and what a release actually contains.
All three, and the CI security gates with their expiring-exception mechanism, ship in the documentation with every release; ask for the current set. Data-protection documents are under Legal.
Bring your questionnaire.
Vendor-risk questionnaires get answered from these documents. Send it; we will return it with references, not adjectives.