Reporting a Security Problem in Tessera

Version 1.0 — effective 2026-09-19

Tessera stands between people and the infrastructure they administer. A flaw in it is a flaw in somebody’s production access, so we would rather hear about one from you than from an incident.

Report to: security@tessera.company. In English, Romanian or Russian. You do not need to be a customer, and you do not need to have exhausted anything first.

What we promise

• An acknowledgement within 2 working days, from a person, saying that it reached us.
• An assessment within 7 days: whether we can reproduce it, how serious we think it is, and what we intend to do.
• Progress while it is open, at least every 14 days, without you having to ask.
• Credit where you want it. Tell us the name to use, or that you would rather not be named.
• No legal action against anyone who reports in good faith under the rules below — and no demand that you keep it quiet forever. We ask for time to fix, not for silence.

What we ask

• Give us 90 days before publishing, or less if we release a fix sooner. If you plan to publish earlier, say so and why; we will not argue, but we would like to know.
• Use your own installation. Run a Controller yourself — a single command gets you one, see the installation guide — rather than probing somebody else’s. Our own hosts, the demo and the customer portal are not test targets.
• Stop at proof. Do not read, change or keep data that is not yours, do not degrade a service, and do not run automated scanning against our production systems.
• One report per issue, with enough to reproduce it: version or commit, configuration, and the steps. A proof-of-concept helps more than a scanner’s output.

What is in scope

The Tessera Controller, the desktop client, the CLI, the Helm chart and the packages we publish — the current release and the one before it.

Particularly interesting to us, because they are where the product’s promises live:

• Anything that lets a user reach a target they were not granted, or in a mode they were not granted — including bypassing a read-only session.
• Anything that exposes a target credential to a client, or one tenant’s data to another.
• Anything that lets a session escape the audit log, or lets a recording be altered.
• Authentication and session handling: token forgery, replay, privilege escalation, fixation.
• Anything that turns the Controller into a route into a network it should not reach.

What is not

• Reports from automated tools with no demonstrated impact, and “best practice” findings (missing headers, weak TLS ciphers on a test host, version disclosure) without an exploit.
• Denial of service, volumetric or resource-exhaustion testing. Do not perform it.
• Social engineering, phishing or physical attacks against us, our staff or our customers.
• Anything that requires an attacker who already has administrative access to the Controller host or its database — that is the trust boundary, and it is documented as such.
• The read-only command filter for interactive SSH shells. It is a best-effort control and we say so in the documentation: a shell can be escaped by an editor, a subshell or an encoding. Reports that it can be bypassed in a way we have already documented are not findings; reports that it can be bypassed on databases or Kubernetes, where enforcement is not best-effort, are.

What happens after you report

We keep a coordinated disclosure process, and we are also subject to reporting duties of our own under Regulation (EU) 2024/2847 — the Cyber Resilience Act. If a vulnerability in Tessera is being actively exploited, we must notify the EU authorities within 24 hours of establishing that. That is about us, not about you: you are never expected to report to anyone but us, and your report is not passed on with your details attached unless you ask us to.

When a fix ships we publish what it fixed. Customers on a supported version are told by email; everyone else can watch the release notes.

Supported versions and security updates

The support period we declare under the Cyber Resilience Act is five years from the date a version is published. Fixes are delivered in the current minor release and in the one before it, so receiving one may mean upgrading to a supported line — the period is a commitment to keep fixing, not a commitment to backport indefinitely.

An SBOM in SPDX format is published with every release, and every container image we publish is signed with cosign.

If you need to encrypt it

Say so in a first message with no details and we will send you a key. We would rather agree a channel than publish a key nobody checks the freshness of.