# Threat model

## Protected properties

- A release is identified by an operator-approved SHA-256 digest.
- Only regular, bounded, allowlisted archive entries are extracted.
- Release roots, state, pointers, and Caddy files reject symlink substitution
  at their checked boundaries.
- Configuration is strict JSON and is never interpolated into a shell command.
- Candidate health is established before traffic or the singleton current
  pointer changes. New deployments also satisfy configured content smoke
  checks; rollback uses health and readiness because future-release content
  markers are not valid requirements for an older retained release.
- Caddy configuration validates before reload.
- An activation failure restores the previously observed state.
- Active and previous releases survive pruning.

## Trusted inputs

Reviewed source, the Go toolchain, root-owned `tend.json`, systemd unit files,
the Caddy handler template, the operator, and the target host's root account are
trusted. Packaging a hostile repository can execute hostile Go compiler hooks
or consume resources; Tend is not a source-code sandbox.

## Adversarial inputs

Artifact paths and bytes, archive metadata, stale or malformed state, HTTP
responses, subprocess failures, and filesystem objects at managed paths are
validated and fail closed. Process output is bounded.

## Non-goals and preview limits

Tend does not defend against a concurrently malicious root user, a compromised
kernel/toolchain/systemd/Caddy installation, denial of service by the trusted
application, or secrets already exposed through service configuration. v0.1
does not manage data migrations, databases, containers, Kubernetes, or
application-specific activation. Transfer remains an application-local,
reviewed step until a transport can be added without weakening host-key and
credential boundaries.