SECURITY.md

Rama main · réplica de lectura del repositorio original.

# Security policy

This repository holds the Sesame server: the vault-blind Go API, the account
portal, and the administration portal. It is early software and has not had an
independent security audit.

The rule this service exists to keep: the shipping API stores account and
release records, not vault data. Sync stores opaque ciphertext and signed
headers and has no decryption key. It is off until an operator turns it on, and
it has not had an independent security review.

## Reporting a vulnerability

**Do not open a public issue, discussion, or pull request for a security
problem.** Use GitHub private vulnerability reporting: open the repository's
**Security** tab and choose **Report a vulnerability**.

If you cannot use GitHub, ask for a security contact through the account
portal's support form. Do not put vulnerability details in that first message:
support intake is read by a wider group than an advisory.

### What to include

- What an attacker gains, in one sentence.
- Whether it needs an account, an admin session, or neither.
- The steps to reproduce it, in order, against your own deployment.
- Whether you ran the self-hosted Compose deployment or something else.

### What not to include

Never send a real password, vault, export, recovery kit, TOTP seed, session
cookie, or account token. Use fictional data in every reproduction.

### What happens next

- We acknowledge within 5 working days.
- We give an assessment and a rough timeline within 10 working days.
- We tell you when a fix ships and credit you unless you prefer otherwise.

## Scope

In scope:

- Any endpoint that accepts, stores, or returns something a vault-blind
  service must never hold: a vault, a master password, a PIN, a recovery kit,
  a wrapping key, or a TOTP seed. This is the highest-severity class here.
- Authentication, session handling, CSRF, and the origin rules: reaching an
  account route from an origin that is not the account portal, or an admin
  route from anything but the admin portal.
- Cross-account access: reading, changing, or deleting another account's data.
- Privilege escalation between admin roles, audit-log tampering, or crossing
  from an admin session to account data.
- Desktop link and device tokens, download tickets, passkey ceremonies, and
  the signed capability envelope.
- The self-hosted deployment: a key that is predictable, shared between
  installations, or logged; an admin bootstrap that can be replayed.
- Support intake accepting secret-shaped content it should refuse.
- Sync: a server that can read, add, hide or reorder a device or a version
  without a client noticing, a request signature that can be replayed or moved
  to another token, and any route that changes state without a device
  signature.

Out of scope:

- Missing hardening with no demonstrated impact: header audits, version
  disclosure, rate limits without a working amplification, scanner output.
- Denial of service through traffic volume, and social engineering.

## Safe harbour

We will not pursue or support legal action against research that stays within
the scope above, uses only your own deployment and your own accounts, avoids
accessing or retaining anyone else's data, avoids degrading the service for
others, and gives us reasonable time to ship a fix before public disclosure.

## Audit log integrity

Each administrator audit row stores `hash = SHA256(prev_hash || canonical(row))`
over its stored values, computed in the same transaction as the insert. The API
recomputes the chain during the hourly maintenance run and writes a signed
checkpoint, covering the newest row, with the capability signing key from
`SESAME_CAPABILITY_SIGNING_KEY`. It logs the covered sequence, the chain hash,
the signing key id and the signature in hex. The checkpoint proves the covered
history was not rewritten after the checkpoint was taken, when that log line is
retained outside the database. It does not prove that the entries were accurate,
and a writer who rewrites the whole chain and every retained copy before the
next verification is not detected by the database alone.

## Known limits

- Sesame has not had an independent security audit.
- The self-hosted deployment runs over loopback HTTP by default. A deployment
  behind TLS must set the two session-secure settings itself.