trust + security

reporting a vulnerability

report security issues through the security topic on our contact form. it routes straight to the maintainer — please don't open a public GitHub issue for anything exploitable, and don't post it on social media before we've had a chance to fix it.

a useful report includes:

• the affected surface (URL, endpoint, package, or repo path) and the version / build sha
• a clear description of the issue and its impact
• reproduction steps — a minimal proof-of-concept beats a long writeup
• any logs or screenshots, with secrets and real personal data redacted

a PGP key is available on requestif you need to send the report encrypted — ask for it via the contact form and we'll provide the fingerprint and public key before you send anything sensitive.

our response targets

once you've reported, here is what to expect:

• acknowledgement — within one business day (Flanders / EU business hours).
• triage + severity assessment — within five business days, with an initial view on validity and severity.
• fix + disclosure— timeline depends on severity. critical issues are prioritised immediately; we'll keep you updated and credit you in the changelog (or stay anonymous if you prefer) once a fix ships.

responsible disclosure + safe harbour

we will not pursue or support legal action against you for security research conducted in good faith that follows this policy. specifically, if you:

• make a good-faith effort to avoid privacy violations, data destruction, and service degradation;
• only interact with accounts you own or have explicit permission to test;
• do not exfiltrate, retain, or share more data than is necessary to demonstrate the issue;
• give us a reasonable window to remediate before any public disclosure;

then we consider your research authorised, we won't treat it as a violation of our terms of service, and we'll work with you to understand and resolve the issue quickly. if a third party brings action against you for activity that complied with this policy, we'll make it known that your actions were authorised.

scope

in scope:

• briven.tech — the dashboard + marketing site
• api.briven.tech — the control-plane and HTTP api
• the open-core repository at github.com/flndrn-dev/briven and the published @briven/* npm packages

out of scope (a non-exhaustive list — please use judgement):

• findings that require physical access to a user's device, or a compromised device / browser
• social engineering, phishing, or attacks against briven staff or infrastructure providers
• volumetric denial-of-service (DoS/DDoS) and brute-force / rate-limit testing against production
• missing security headers or best-practice nits with no demonstrated exploit
• reports from automated scanners with no validated, reproducible impact
• issues in third-party services we depend on (Polar, Cloudflare, Mittera, the hosting provider) — report those to the vendor; tell us if it affects briven users
• vulnerabilities in your own self-hosted deployment caused by your own configuration

supported versions

the hosted platform at briven.tech always runs the latest build — there is only ever one production version, and security fixes ship to it directly. you can confirm the live build sha in the dashboard footer or via GET https://api.briven.tech/info.

for self-hosters, security fixes land on the main branch of the open-core repo and in the latest published @briven/* packages. we support the latest release line only — keep your deployment current to receive fixes. older pinned versions do not receive backported patches.

related

see also the service level agreement for uptime commitments and the support page for non-security help.