# WirtPilot Security Policy

## Supported releases

Security support is attached to a named, signed WirtPilot Own Cloud release. A
customer release remains usable indefinitely; security fixes are supplied only
for the support window stated in its signed order.
`v1.0.0` is the first customer-release line; unsigned branches and previews are
not customer releases.

## Reporting a vulnerability

Do not open a public issue for a suspected vulnerability or include secrets,
guest data, employee data, access tokens, database dumps, or production URLs in
a report.

The canonical public policy is
<https://wirtpilot.com/own-cloud/sicherheit>. If you received WirtPilot as an
archive and do not have access to the publisher repository, use the publisher
contact published at <https://wirtpilot.com/impressum> with the subject
"Vertraulicher Sicherheitsbericht – WirtPilot Own Cloud". The first message
must contain no exploit, secret, personal data, or production URL; request a
confidential follow-up channel instead. This path intentionally reuses the
publisher's maintained legal contact and does not embed a possibly stale email
address in customer releases.

If your repository access includes private security advisories, use its private
GitHub Security Advisory flow. In either case, include only after a confidential
channel is established:

- affected release and commit;
- the smallest safe reproduction;
- likely impact and affected roles;
- whether production data may have been accessed;
- a proposed fix only when it does not expose additional data.

The maintainer will classify severity, coordinate a fix, and publish
customer-safe upgrade instructions. No acknowledgement time, availability, or
response-time SLA is created by this file; contractual support terms take
precedence.

## Security boundaries

- Customer accounts, MFA, billing, recovery codes, domains, and provider
  contracts remain under the restaurant's control.
- Secrets belong in provider secret stores and must not be committed, pasted
  into tickets, or included in launch evidence.
- Production migrations, deploys, destructive data changes, restores, and key
  rotation require an explicit human approval and a verified rollback point.
- A green runtime health check is not a substitute for launch-readiness,
  backup, restore, tenant-isolation, and integration acceptance evidence.