Security

Report a vulnerability.

Etminan is built for a demanding threat model — a fully root-compromised monitored host that must not be able to forge a "genuine" verdict or silently suppress an alarm. We take reports against that property, and against the code that enforces it, seriously. This page is our coordinated-disclosure policy: how to reach us, what's in scope, and what to expect.

01 — How to report

Report it privately — intake queue or encrypted email.

Please do not open a public issue for a suspected vulnerability, and give us a reasonable opportunity to release a fix before any public disclosure.

Security intake

Submit it through the private, write-only security queue at desk.etminan.dev — reports there are visible only to our team and are never listed publicly.

Or email team@etminan.dev, with the subject prefixed [SECURITY].

Encrypt sensitive reports

Encrypt to our PGP key (below). It's published on hkps://keys.openpgp.org and served here as gpg-etminan-team.asc.

Machine-readable contact

/.well-known/security.txt (RFC 9116) carries the same contact and key.

What to include

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

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

02 — Coordinated disclosure

We're a small team — here's what we commit to.

We do not promise a fixed remediation SLA, but we do commit to the following.

Acknowledgement

We aim to acknowledge a report within 5 business days.

Working with you

We'll agree a disclosure timeline with you and keep you updated on the fix.

What we prioritise

Trust-affecting issues — anything touching the "a compromised host cannot lie" property — are prioritised above everything else.

Credit

With your permission we credit reporters in the release notes and on the News page. There is no bug-bounty program at this time.

03 — Scope

What we most want to hear about — and what's out of scope by design.

The out-of-scope items below follow directly from the documented threat model, not from a wish to dodge reports.

In scope

The binaries

The etminan-agent and etminan-verifier binaries and the shared common crate.

Trust logic

Quote verification, IMA-log replay, the baseline/approval model, the RBAC daemon's default-deny identity registry, and the hash-chained audit log.

Crypto & transport

Cryptographic verification, the wire protocol, and mutual-TLS handling.

Release integrity

Packaging and release signing — a break that lets an attacker ship a forged, "validly signed" release.

Out of scope (by design)

Physical attacks

Cold-boot, TPM desoldering, evil-maid. This defends against remote/software compromise only.

Below the TPM boundary

Firmware/UEFI implants, SPI-bus attacks, or a compromised hypervisor underneath a vTPM.

Operator authorization / console access

Social engineering, and anything requiring an authorized operator identity on the verifier (RBAC by Unix UID) or console access.

A host that refuses to answer

That is a detected condition by design, not a vulnerability. 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.

04 — Supported versions & support period

Security updates for 12 months per release.

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

Current release

Security updates, up to 12 months from its release date.

Superseded / older

Upgrade to the current release.

Upgrade in lockstep

The agent and verifier release together and must be upgraded together — the wire protocol has been explicitly versioned, so a mismatched pair fails safely rather than silently.

05 — Our threat model, in one line

The monitored host may already be compromised — and still can't lie.

Etminan assumes the monitored host may already be fully compromised, and is built so that host cannot forge a genuine verdict or silently suppress an alarm — the evidence is anchored in a TPM the host's own root cannot rewrite and is verified off-box. See the architecture and the comparison with AIDE/Tripwire/Samhain for the full model. A report that breaks this property is the highest-severity class we handle.