Security questions customers ask¶

The answers that come up in every security questionnaire and vendor assessment, in one place, so that answering the fortieth one is a matter of quoting rather than of remembering.

Everything here is documented elsewhere in the handbook too; this page exists because a questionnaire asks in the customer's words, not in ours.

Which third parties process customer data¶

None. Etminan is software you run on your own hosts, and it is not a service:

We operate nothing on your behalf. No cloud component, no tenancy, no account with us. The verifier and the agents run inside your network, on your machines, and they are the only places attestation data exists.
The product makes no outbound connection to us. Not for licensing, not for telemetry, not for updates. The agent talks to your verifier over mutual TLS and to nothing else; the verifier talks to its agents and to whatever you configure it to notify.
There is no telemetry, and no analytics. Not off by default — absent.
Updates are files you fetch and verify, from a package you have checked the signature of (below). Nothing pulls them in on its own.

So there is no sub-processor list, because there is no processing by anybody but you. The only data that ever reaches us is what you put in an email to us — a support question, or a vulnerability report.

What we do host, for completeness: etminan.dev, which serves this documentation and the signed release artefacts. Downloading a release tells that web server your IP address, as any download does. It carries no attestation data and no customer data.

How releases are signed, and how to verify them¶

Every release artefact is signed by the Etminan Team key, and every one of them carries a detached signature and a SHA-256 sum beside it.

The signing key:

Etminan Team <team@etminan.dev>
Fingerprint: 7387 4214 090F 9137 862D 0AF1 E1E5 41B7 B424 36DF

Published on hkps://keys.openpgp.org and shipped in the repository as docs/downloads/gpg-etminan-team.asc. Verify the fingerprint out of band — a key fetched from the same place as the package proves only that both came from the same place.

Verify before installing, which is two commands and is not optional:

# Debian / Ubuntu
gpg --verify etminan_<version>_amd64.deb.asc etminan_<version>_amd64.deb
sha256sum -c etminan_<version>_amd64.deb.sha256

# Enterprise Linux
gpg --verify etminan-<version>.x86_64.rpm.asc etminan-<version>.x86_64.rpm
sha256sum -c etminan-<version>.x86_64.rpm.sha256

The signature answers who built this; the checksum answers did it arrive intact. They are different questions and both are worth asking, which is why both files are published.

Where the signing happens: in the release pipeline, with a key that is not on a developer's laptop. A break that let somebody ship a forged, validly signed release is explicitly in scope for our security policy — see below.

Reproducibility: builds are not bit-for-bit reproducible today. The chain you are relying on is the signature, not an independent rebuild.

How to report a vulnerability¶

Email team@etminan.dev, with [SECURITY] at the start of the subject.

For anything sensitive, encrypt to the key above — the same key that signs the releases.

Please do not open a public issue, and give us a reasonable opportunity to ship a fix before disclosing publicly.

What we commit to:


Acknowledgement	Within 5 business days
Remediation SLA	None promised — we are a small team and say so rather than publishing a number we would miss
Priority	Anything touching "a compromised host cannot lie" comes before everything else
Credit	With your permission, in the release notes and on the News page
Bug bounty	None at this time

What to include: the affected component (etminan-agent, etminan-verifier, the shared common crate, packaging and release signing, or the website), the version or commit, steps to reproduce, the impact, and a proof of concept if you have one.

What is in scope¶

The agent, the verifier and the shared crate; the attestation and trust logic — quote verification, IMA-log replay, the baseline and approval model, the operator identity registry the daemon authorizes against, the hash-chained audit log; cryptographic verification, the wire protocol and mutual-TLS handling; and packaging and release signing.

What is out of scope¶

Deliberately, and following the documented threat model: physical attacks (cold-boot, TPM desoldering, evil maid); anything below the TPM boundary such as firmware or SPI-bus implants, or a compromised hypervisor beneath a vTPM; social engineering, and anything that requires the operator's own signing key or console access; and the website, unless it affects the integrity or authenticity of a release.

One case is worth naming because it is reported as a bug and is not one: a monitored host that refuses to answer is a detected condition, by design. A report that a compromised host can be read as genuine, or can suppress an alarm without detection, is exactly what we most want to hear about.

How long a release is supported¶

Each release receives security updates for up to 12 months from its release date, and at most one release is supported at a time: when a newer release supersedes it, fixes move forward and you upgrade to stay supported.

The agent and verifier release in lockstep and are upgraded together. The wire protocol has been versioned since 0.8.0, so a mismatched pair fails safely rather than silently doing the wrong thing.