Security
Our threat model is public. Our crypto choices are documented.
This page summarises how Linux Identity protects your fleet, your audit data, and our shared infrastructure. If something here is unclear or wrong, email security@linuxidentity.com.
Security model
Linux Identity operates across three trust zones: your Linux fleet (the most sensitive), our hosted control plane, and your identity provider. The control plane holds the SSH CA private key inside a managed KMS — it never leaves. Signing happens via a KMS API call; no process ever sees plaintext key material. Your IdP (Okta, Google Workspace, or Microsoft Entra) issues the identity assertions; we verify token signatures on every cert request.
The host agent captures sudo invocations and shell session metadata, then uploads them to an append-only audit log. The agent is deliberately not in the SSH critical path: if it crashes, your engineers still get in. The sshd on each host validates the short-lived SSH certificate against the CA public key, which it received once at enrollment. No online dependency on cert validation.
The audit log uses a sha256 hash chain across every row, backed by a Postgres role with no UPDATE or DELETE privilege. Session recordings land in WORM object storage with compliance-mode immutability. Tampering is provable: you can re-derive the expected root hash from the raw rows. We run a hash-chain verification job hourly and alert on breaks.
Threat model — 12 threats, 4 themes
Read the full threat modelWe modelled threats before writing code. Below is a summary grouped by theme. Click the link above for the full STRIDE analysis, mitigations, detection, and recovery procedures.
Key custody and cert lifecycle
- T1SSH CA private key disclosure
Key never leaves the managed KMS. Signing is a KMS API call. No code path reads key material into process memory.
- T5Cert revocation lag
KRL pushed to all hosts within 60 seconds of revocation. Default TTL is 4 hours to bound worst-case exposure; configurable 1 min – 24h via the admin portal.
- T10OIDC token impersonation
ID token signature verified against IdP JWKS on every cert issuance. Weak algorithms (none, HS*) rejected outright.
Tenant isolation and data access
- T2Cross-tenant data leak
All Postgres queries run through row-level security views keyed on tenant_id injected from the authenticated principal. No raw WHERE clauses in app code.
- T11Insider access (Linux Identity operator)
Production access requires 4-eyes approval. All admin queries are logged. Customer audit logs will be encrypted with customer-derived keys in a future release.
- T12Stolen vendor credentials
Hardware-backed MFA on all employee accounts. Cloud access via SSO-federated short-lived credentials only. No long-lived static keys to any production system.
Host agent and audit integrity
- T3Agent crash locks out engineers
The agent is not in the SSH critical path. sshd validates certs against the CA public key directly. Agent failure degrades logging only; SSH access continues.
- T4Compromised host extracts secrets
Agent stores no long-lived secrets. SSH cert requests are on-demand via SSO flow. Audit cache is uploaded then deleted.
- T7Audit log tampering
Append-only Postgres role (no UPDATE/DELETE). Hash chain over every row. Recordings in WORM object storage with compliance-mode immutability.
Supply chain and runtime integrity
- T6Sudo plugin compromise
Plugin compiled from the same source as the agent, cosign-signed. Signature verified by sshd on init. Integrity monitoring alerts on unexpected file changes.
- T8Malicious agent release
Releases signed with cosign. SBOM published per release. Build infrastructure uses GitHub OIDC to short-lived cloud credentials; no static credentials in CI.
- T9Self-update RCE via tampered manifest
Update manifests signed. Signature verified before exec. Version downgrades rejected. Update windows are opt-in per customer.
Cryptography
Read ADR-0003: Secrets and key custody| Asset | Algorithm / Mechanism | Notes |
|---|---|---|
| SSH CA private key | ECC_NIST_P256 in a managed KMS | Plaintext never accessible. FIPS 140-2 Level 2 validated key store. |
| SSH cert signing | ECDSA_SHA_256 | Default TTL 4h; configurable 1 min – 24h via the admin portal. KRL pushed in ≤60s on revocation. |
| OIDC client_secret (per tenant) | AES-256-GCM envelope encryption via managed KMS | Stored as encrypted ciphertext in Postgres. Decrypted only on use, in process memory, not logged. |
| Audit log hash chain | sha256 | Each row includes prev_hash. Chain verified hourly by background job. Alert on break. |
| Session recordings | AES-256 at rest, WORM object storage | Compliance-mode immutability. Neither us nor the customer can delete during the retention window. |
| Release binaries | cosign (sigstore) | SBOM published with every release. Cosign public key in repo at /policies/release-signing.pub. |
We chose ECDSA P-256 over ed25519 because major managed KMS services do not yet support ed25519 asymmetric keys as of May 2026. We’ll re-evaluate when broad managed-KMS support lands. Full rationale in ADR-0003.
Vulnerability disclosure
Email security@linuxidentity.com. We acknowledge within 24 hours and provide a substantive response within 72 hours. We don’t have a bug bounty yet — that ships post-GA. We do commit to credited disclosure and won’t pursue legal action against good-faith researchers.
GPG key for encrypted reports: fingerprint TBD — we’ll publish it at /security/ and in /.well-known/security.txt once generated. For now, email is fine.
security.txt is live at /.well-known/security.txt.
Subprocessors
The platform runs on a single cloud provider today; the architecture is portable across major clouds. No third-party SaaS processes customer audit data. Enterprise customers receive the full current-provider mapping under NDA. Last updated May 2026.
| Service | Purpose | Region |
|---|---|---|
| Managed KMS | SSH CA private key custody and signing | Primary region + cross-region key replica |
| Managed Postgres | Audit log, tenant config, host registry | Primary region |
| Object storage (WORM) | Session recording storage with compliance-mode immutability | Primary region |
| CDN / edge | Marketing site + install script delivery | Global edge |
| Managed DNS | Authoritative DNS for linuxidentity.com | Global |
SOC 2
SOC 2 Type II — underway
Audit period started Q1 2026 with [auditor TBD]. Expected Type II report: Q3 2026. We will publish the summary report when it is available. Until then, we share our controls mapping and relevant ADRs with design partners on request.
We don’t claim SOC 2 certification yet. The amber dot above is honest: underway, not complete. If you need a signed NDA before we share the controls mapping, email saheed@linuxidentity.com.