Vulnerability management policy
Last updated 2026-11-02
Last updated 2026-11-02.
What this policy covers
This policy says how we find a security weakness in Botseon, how serious we judge it to be, who fixes it and how the fix reaches you. It covers the hosted service, the self-hosted edition, the desktop apps and the packages we publish. It describes what we do today. Where a piece is not in place yet, we say so. Each section ends with the file in our code that backs the claim. The code repository is private; we show the named file to a customer's security reviewer on request.
How to report one
Report a suspected vulnerability by e-mail to security@botseon.com. The address is read by the maintainers only. Do not post it anywhere public. Include the version or commit you tested, the edition (hosted or self-hosted), the steps, and what you expected instead. Never send a real credential, a real customer's data or a production database row; name the variable or the table, not its value. We keep reports confidential and use them only to assess and fix the weakness.
We aim to acknowledge a report, by a person, within 2 working days and to give a first assessment within 10 working days. We tell you when the fix is released, agree the disclosure date with you, and credit you unless you ask us not to.
Research done in good faith is welcome, and we will not pursue or support legal action over it, as long as you test only against your own installation or accounts and data you own; do not access, change or delete data that is not yours, and stop and tell us the moment you reach someone else's; do not degrade the service for anyone else (no denial of service, no load testing of the hosted service, no spam or social engineering); and report promptly and keep the finding confidential until the agreed date.
Source: SECURITY.md.
How we find vulnerabilities
Reports from you, as above.
Our own checks. Every change runs our tests before it can land, including the tests that keep each organisation's data separate. A static analysis scanner (Semgrep) on every pull request is being introduced. Automatic alerts for known vulnerabilities in the packages we use (Dependabot) are not set up yet. Both are on our work list. Until then we learn of a vulnerable package from its publisher's notice or from a report.
Running the service. Alerts from the running service go to the person on call, who follows the incident runbook.
Our sub-processors. A weakness in an outside service we run on is handled under this policy once we learn of it from the provider. Those services are listed on our sub-processors page.
Source: .github/workflows/ci.yml; docs/operations/incident-runbook.md (the alert playbooks);
apps/web/app/api/v1/memories-caller-isolation.test.ts (one of the isolation tests).
Severity levels and target fix times
We give every confirmed vulnerability one of four levels. The times below are targets we work to, counted from the day we confirm the report. They are not a contractual promise.
| Level | What it means | Target for a fix or mitigation |
|---|---|---|
| Critical | Someone outside an organisation can read or change its data, or take over an account, without help from a member | 7 days |
| High | The same harm, but it needs a member's account, a member's action or an unusual setup | 30 days |
| Medium | Limited harm, or harm that needs several unlikely conditions at once | 90 days |
| Low | Hardening, or a weakness with no practical harm on its own | the next scheduled release where practical |
A vulnerability that is being used against the service is handled as an incident straight away, whatever its level. A way to make a bot act on instructions hidden in content it reads, without the approval step our Security page describes, is rated by the harm the action can do, like any other weakness.
Source: SECURITY.md (the response window; high and critical within 30 days);
docs/operations/incident-runbook.md.
Who fixes it
The maintainers read every report, decide its level and own the fix. The founder of Nordio ApS is accountable for that decision and for the fix; no step of it is left to an AI model alone. The same team owns the code that decides what an extension may do.
Source: SECURITY.md; .github/CODEOWNERS (the maintainers team).
How a fix ships
A security fix goes through the same pull request, required checks and merge queue as any other change. Nothing skips the checks. A fix that affects the running service is not held for other work; it lands and is deployed as soon as it is green. A production deploy is refused unless the pipeline proves that exact version green.
The hosted service runs the latest version, so a fix reaches every organisation when it is deployed. For the self-hosted edition, a fix goes into the latest release; we do not patch older releases, so keep your installation current. We tell the reporter and, where an organisation's data was reached, the affected organisations. We do not publish public advisories today; we will say so here when that changes.
Source: .github/workflows/ci.yml (the merge queue run); .github/workflows/deploy-prod.yml
(the green-on-main check); SECURITY.md (supported versions).
When it becomes an incident
If a weakness has been used, or personal data may have been reached, we follow our incident runbook: detect, triage, mitigate, tell the affected organisations, and write a postmortem. If personal data is involved we also follow the breach runbook, which tracks the 72-hour clock for telling the supervisory authority. A credential that may have leaked is rotated using the credentials runbook.
Source: docs/operations/incident-runbook.md; docs/operations/breach-runbook.md;
docs/operations/credentials-runbook.md.