Clients reach Sneakers only through the gateway (two GraphQL endpoints, one for browser sessions and one for tokens), the MCP bridge and the web apps. Backend services aren't exposed outside the cluster.

SOC 2 CC6.1, CC6.6 · ISO 27001 A.8.20, A.8.22 · ASVS V1.4.1

Each service-to-service gRPC call carries the caller's projected Kubernetes ServiceAccount token. The callee checks issuer, audience, expiry and a per-method caller allow-list, and refuses to start without an issuer configured. Only the gateway may pass an end user's identity.

SOC 2 CC6.1, CC6.3 · ISO 27001 A.5.15, A.8.5 · ASVS V1.4.4, V4.1.3

Open work: sneakers-gateway#27 Workload identity for machine-API callers

The Helm charts install a NetworkPolicy for each service that admits only its declared callers, plus policies for the bundled identity provider and database. The install test checks that blocked pods are blocked. Outbound traffic isn't restricted by default.

SOC 2 CC6.6 · ISO 27001 A.8.20, A.8.22

Every service runs as non-root with a read-only root filesystem, no privilege escalation, all capabilities dropped and a seccomp profile. Each chart's values schema rejects an install that turns these off.

SOC 2 CC6.8 · ISO 27001 A.8.9 · ASVS V14.1.1

Each secret has its own 256-bit data key from the OS CSPRNG. Every field value is sealed with AES-256-GCM under a fresh 96-bit random nonce, with the field name bound as associated data, so a value can't be moved to another field undetected.

SOC 2 CC6.1, C1.1 · ISO 27001 A.8.24 · ASVS V6.2.2, V6.3.1

A root key wraps versioned working keys, which wrap each secret's data key. Working keys rotate by re-wrapping data keys only, without decrypting any value; rotation is resumable, retired keys stay decrypt-only, and a scheduler rotates every 90 days by default. Only a site admin can rotate on demand.

SOC 2 CC6.1 · ISO 27001 A.8.24 · ASVS V6.4.1, V6.4.2

Open work: sneakers-vault#104 Key ring design note

Outside development the vault won't start without a root key, and the root key must unwrap every working key before any database migration runs. An unknown key reference fails closed.

SOC 2 CC6.1 · ISO 27001 A.8.24 · ASVS V6.2.1

The vault reads its root key from the environment at start and holds it in memory. On the appliance the key lives on the encrypted state volume, whose key is sealed in the TPM, and is copied into the owner's escrow. The root key itself can't be rotated, and there is no HSM or cloud KMS provider yet.

SOC 2 CC6.1 · ISO 27001 A.8.24 · ASVS V6.4.1

Open work: sneakers-vault#41 HSM and cloud KMS key providers

TOTP seeds are sealed with AES-256-GCM under a dedicated key. Email codes and API tokens are stored only as SHA-256 hashes. The TOTP key can't be rotated yet without re-enrolling every factor.

SOC 2 CC6.1 · ISO 27001 A.5.17, A.8.24 · ASVS V2.9.1, V6.1.1

Only field values are application-encrypted. Secret names, folders, rules, targets and settings are stored as plain JSON in each service's database. On the appliance that database sits on the LUKS2-encrypted state volume; on your own Kubernetes, disk encryption is yours to provide.

SOC 2 C1.1 · ISO 27001 A.8.24

Internal gRPC calls are authenticated (ARC-2) but not encrypted: every client dials without TLS, and the gateway serves plain HTTP behind the cluster ingress. Confidentiality on the wire depends on the platform today (a private network or a service mesh with mTLS).

SOC 2 CC6.7 · ISO 27001 A.8.24, A.8.20 · ASVS V9.2.2

Open work: sneakers-appliance#235 TLS on the product endpoint and cert-manager, sneakers-notify#20 TLS in REDIS_URL is ignored

Sneakers uses only standard, published algorithms from the Go standard library and well-known libraries (AES-GCM, AES-XTS through LUKS2, SHA-256, HKDF, ECDSA, age). There is no FIPS 140-3 validated mode yet.

ISO 27001 A.8.24, A.5.31 · ASVS V6.2.2

Open work: sneakers-appliance#216 FIPS 140-3 mode

Passwords are stored and checked by the bundled Ory Kratos, never by Sneakers services. Its hashing parameters are Kratos configuration and aren't asserted by this review. Self-service reset uses an emailed code and answers the same way whether or not the account exists.

SOC 2 CC6.1 · ISO 27001 A.5.17, A.8.5 · 800-63B 5.1.1.2 · ASVS V2.4.1, V2.5.2

A session without a verified second factor gets mfa_required on the API. Factors are TOTP (RFC 6238), emailed six-digit codes (single use, five minutes, five guesses) and WebAuthn passkeys as a second factor with a strictly increasing sign counter.

SOC 2 CC6.1 · ISO 27001 A.8.5 · 800-63B 4.2.1, 5.1.4, 5.1.8 · ASVS V2.7, V2.8, V4.3.1

A pending second-factor sign-in ends after five wrong codes. TOTP verification itself doesn't yet refuse a code reused inside its period, and email codes don't prove possession of a device, so they don't meet SP 800-63B's out-of-band rules.

800-63B 5.1.4.2, 5.2.2, 5.1.3.1 · ASVS V2.2.1, V2.8.4

The browser holds only an opaque session id in a cookie that is HttpOnly, SameSite=Strict and Secure by default; a malformed setting stops the gateway at start. Sessions slide on use within an admin-set lifetime of 15 to 60 minutes, and an admin cutoff ends every older session.

SOC 2 CC6.1 · ISO 27001 A.8.5 · 800-63B 7.1, 4.2.3 · ASVS V3.2.1, V3.3.1, V3.4.1, V3.4.2, V3.4.3

Open work: sneakers-gateway#31 Session tokens are stored unencrypted in Redis

Changing factors, approving requests, consenting to an agent's sign-in, revealing where policy requires it, and sensitive check-outs need a second factor verified within MFA_MAX_AGE (30 minutes by default, 4 hours at most).

SOC 2 CC6.1 · ISO 27001 A.8.5 · 800-63B 7.2 · ASVS V3.7.1

Every state-changing browser request carries a 32-byte CSRF token checked by double submit in constant time. CORS is an exact-origin allow-list; a wildcard or malformed entry stops the gateway at start.

ISO 27001 A.8.26 · ASVS V4.2.2, V13.2.3, V14.5.3

The web apps send a nonce-based Content-Security-Policy with frame-ancestors 'none', plus nosniff, X-Frame-Options DENY and a same-origin referrer policy. Styles still allow 'unsafe-inline'.

ISO 27001 A.8.26 · ASVS V14.4.3, V14.4.4, V14.4.7

SAML sign-on runs through the bundled Ory Polis at the gateway. Passkeys work as a second factor, but passwordless passkey sign-in isn't built, and SSO sessions have an open subject-mismatch bug.

SOC 2 CC6.1 · ISO 27001 A.8.5 · 800-63B 5.1.8, 5.2.5

Open work: sneakers-identity#22 Passkey sign-in, sneakers-identity#20 SSO sessions fail with a subject mismatch

Access comes from rules on a folder tree, evaluated most specific first, first match wins, deny by default. Rules grant read, informed, approve and manage separately; approve and manage imply read, informed never does. Access decisions are made in the vault, not the gateway.

SOC 2 CC6.1, CC6.3 · ISO 27001 A.5.15, A.5.18, A.8.3 · ASVS V4.1.3, V4.1.5

A secret can require approval or always require it. A requester never approves their own request. Where nobody else can decide (a single-user install, or the only approver), the requester confirms once with a fresh second factor; that is a recorded self-confirmation, not two-person control.

SOC 2 CC6.3 · ISO 27001 A.5.3, A.8.2 · ASVS V4.1.3

Open work: sneakers-gateway#47 Approval queue, renewal, force check-in and quorum

An agent run's requests share one approval page with one second factor. Each item is still decided in the vault and audited on its own, the requester can't decide (the machine API has no decide call), and the stated purpose is shown as untrusted text.

SOC 2 CC6.3 · ISO 27001 A.8.2

Break-glass is open to site admins only, from their own web session with a TOTP code, and lasts 15 minutes. Agents and tokens are refused, refusals are audited, and a break-glass reveal is refused if its audit record can't be written.

SOC 2 CC6.1, CC6.3 · ISO 27001 A.8.2, A.8.18 · ASVS V4.3.1

Open work: sneakers-vault#70 Dual control for break-glass, sneakers-vault#72 Break-glass rate limits and frequency alerts, sneakers-vault#151 Enforce people-only reveals in the service, not only by routing

Listing a secret's history needs read access; revealing or restoring an earlier version needs the separate recovery role plus a fresh second factor. Site admin doesn't imply recovery.

SOC 2 CC6.3 · ISO 27001 A.8.2, A.8.3

A reveal is refused for a retired secret, then checks the field is sensitive, read access, approval and step-up, and only then decrypts the one requested field and records secret.reveal. Step-up on reveal is a global setting with per-folder overrides that only site admins set.

SOC 2 CC6.1, C1.1 · ISO 27001 A.8.3, A.8.12 · ASVS V4.1.1, V8.3.4

A prepared use expires in 10 minutes; once approved it must be redeemed within one minute, by the same token, once. Access is checked again at redemption, and the audit record never carries the value. Standing pre-approvals are capped at 24 hours.

SOC 2 CC6.1 · ISO 27001 A.8.3 · ASVS V4.1.3

Check-out needs read access, a type that allows it, a fresh second factor for sensitive types (on by default) and no lease already held. Only the holder can check in, and check-in rotates the credential. Concurrent check-outs issue one lease.

SOC 2 CC6.1, CC6.3 · ISO 27001 A.5.18, A.8.2

The connector pulls due heartbeat and rotation jobs and changes passwords over LDAP/LDAPS and Kerberos using the account's own current password, so it needs no admin rights. The directory's built-in Administrator is matched by SID and never rotated. SSH, WinRM and SAMR rotation aren't built.

SOC 2 CC6.1 · ISO 27001 A.5.17

Open work: sneakers-connector#16 SSH, WinRM and SAMR rotation, sneakers-connector#33 Respect directory password rules when rotating, sneakers-connector#75 Pin LDAPS certificates for an enterprise CA

Generated passwords come from the OS CSPRNG: 20 characters from an 86-character pool by default (about 128 bits), with per-policy length, required classes and excluded characters.

ISO 27001 A.5.17 · ASVS V6.3.1

In-browser SSH uses a single-use ticket that lives 30 seconds and holds no key material. The broker fetches the key as the user when the browser connects, wipes it after use, connects only to pinned host keys and cuts sessions at 8 hours. Sessions aren't recorded yet.

SOC 2 CC6.1 · ISO 27001 A.8.2, A.8.15

Open work: sneakers-sshbroker#21 Session recording, sneakers-sshbroker#26 Reject agent principals

The web UI masks values until revealed and tells the user each reveal is logged. Hiding is manual: there is no auto-hide timer and nothing clears the clipboard after a copy.

ISO 27001 A.8.12 · ASVS V8.2.1

Each record's SHA-256 covers its sequence, action, actor, subject, attributes, time and the previous record's hash. VerifyChain reports a gap, a wrong link or a wrong hash, walking the chain in pages so it scales.

SOC 2 CC7.2, CC4.1 · ISO 27001 A.8.15, A.5.33 · ASVS V7.3.3

Only listed services may record, only the gateway may read, the migration job may only record and verify, and the appliance may only write its own admin events. The service won't start without an issuer.

SOC 2 CC6.1 · ISO 27001 A.8.15 · ASVS V7.3.4

The chain is keyless and unsigned, and the database doesn't stop UPDATE or DELETE. It detects edits by anyone without database write access; someone with it could rewrite the chain and recompute every hash. Routine audit writes are best-effort (only break-glass fails closed), and there is no retention setting yet.

SOC 2 CC7.2 · ISO 27001 A.8.15 · ASVS V7.3.3

Open work: sneakers-audit#60 Signed audit archive, sneakers-audit#17 Run more than one instance safely, sneakers-audit#18 Record vendor sign-ins and denials

Audit records hold metadata only; reveals record which field, never its value. Notifications have no field that could carry a value. Services and the MCP never log tokens or values. The audit service relies on its callers for this and doesn't check it server-side.

SOC 2 C1.1 · ISO 27001 A.8.11, A.8.15 · ASVS V7.1.1, V7.1.2

The MCP bridge accepts OAuth JWTs (signature, issuer, audience and expiry checked locally), service-account tokens and personal tokens. Opaque tokens are confirmed by the gateway and cached for at most 60 seconds by hash; any failure is a 401 and is never cached. If the gateway is down, it fails closed.

SOC 2 CC6.1 · ISO 27001 A.8.5 · ASVS V3.5.3, V13.1.3

The bridge holds no credentials and makes no access decisions; it forwards the caller's own token to the machine API, where the vault applies the same folder rules, approvals and audit. Consent to an agent's sign-in needs a recent second factor, using PKCE with S256.

SOC 2 CC6.1, CC6.3 · ISO 27001 A.5.15 · ASVS V4.1.1

Open work: sneakers-gateway#145 Keep CLI tokens off the MCP switch

By design an agent with access receives plaintext values: reads of plain fields, approved reveals (once, within 60 seconds) and new values from rotation. Approval-gated secrets return an approval link, not a value. Super-sensitive fields are withheld from every token unless an admin turns on API access to sensitive secrets (off by default). MCP is an add-on, off by default.

SOC 2 C1.1 · ISO 27001 A.8.3, A.8.12

Open work: sneakers-mcp#17 Personal tokens of a disabled user

The appliance isn't a Linux distribution: it is built from a declared file list (a pinned kernel, busybox, OpenSSH and the project's own programs) with its own init as PID 1 and no setuid files. The root is a read-only SquashFS checked block by block with dm-verity, and the build is reproducible byte for byte.

SOC 2 CC6.8, CC7.1 · ISO 27001 A.8.9, A.8.19

Open work: sneakers-appliance#45 Build the kernel and static tools from pinned sources

Firmware boots a project-signed systemd-boot and one signed kernel image (UKI) with no shim and no vendor keys. The kernel runs in lockdown, and the dm-verity root hash is inside the signed image. If the box is set to Secure Boot and the firmware stops enforcing it, the product won't start. An admin can choose reduced protection, which is labelled.

SOC 2 CC6.8 · ISO 27001 A.8.9, A.8.19 · ASVS V10.3.2

Open work: sneakers-appliance#413 Production Secure Boot enrolment without a manual key reset, sneakers-appliance#62 Turn Secure Boot on or off later and reseal

The state and backup partitions are LUKS2 (AES-XTS) under one random 256-bit key, sealed in the TPM to the boot measurements (PCR 7 and 11 with Secure Boot). Without a TPM, including on arm64, the key falls back to a key-file partition, shown as reduced protection. There is no remote attestation.

SOC 2 CC6.1, C1.1 · ISO 27001 A.8.24, A.7.10

An update is checked against the release key built into the running OS, then its channel, size and SHA-256, before it is decrypted. Anything not newer than the running release is refused. Updates install to the inactive slot; three failed boots fall back to the previous release.

SOC 2 CC8.1, CC7.1 · ISO 27001 A.8.19, A.8.32 · ASVS V10.3.2

Open work: sneakers-appliance#72 Rotate the update key

SSH accepts only box-issued keys with their certificates, then a TOTP code; no passwords and no root login. A root shell needs a one-time challenge from the admin page. The firewall opens SSH and the admin page only on the management interface, step by step during first boot, and can limit them to an allow-list.

SOC 2 CC6.1, CC6.6 · ISO 27001 A.8.2, A.8.5, A.8.20

Appliance administration is written to a daily JSONL log on the encrypted volume, each line carrying the previous line's SHA-256. It isn't forwarded off the box yet.

SOC 2 CC7.2 · ISO 27001 A.8.15

Open work: sneakers-appliance#103 Forward the OS audit log

Every release asset (OS image, update headers, release manifest, checksums and a signature per pinned image digest) is signed with cosign using a project-held ECDSA P-256 key. Signatures aren't in a public transparency log, and image signatures are files on the release rather than attached in the registry.

SOC 2 CC8.1 · ISO 27001 A.8.32 · ASVS V10.3.2, V14.2.4

Production signing keys live only in a protected CI environment that needs the maintainer's approval and accepts only version tags. CI refuses lab keys in a release, keys sit on tmpfs only for the step that uses them, and every other CI run uses fresh lab keys.

SOC 2 CC6.1, CC8.1 · ISO 27001 A.8.24, A.8.31

Service images are built natively for linux/amd64 and linux/arm64 and published as one image index, so the same release runs on a Raspberry Pi. Appliance update and install images are amd64 only.

ISO 27001 A.8.32

No SBOM (SPDX or CycloneDX) or SLSA provenance is published yet. This is the main supply-chain gap.

SOC 2 CC7.1, CC9.2 · ISO 27001 A.5.21, A.8.30 · ASVS V14.2.5

Open work: sneakers-release#69 NIST SSDF (SP 800-218) self-assessment

The owner downloads an escrow file holding the disk key and the product's keys (the vault root key and the TOTP key), encrypted with age to one to three SSH recovery keys. A replacement box imports it at first boot so restored data opens.

SOC 2 A1.2 · ISO 27001 A.8.13, A.8.24

sneakers-migrate exports every service's data as an age-encrypted archive, verifies the audit chain end to end on import, and is rehearsed in CI, including a 727,000-record audit chain.

SOC 2 A1.2, A1.3 · ISO 27001 A.8.13

There are no scheduled or offsite backups yet: the appliance's backup service is a stub and its backup partition is unused. Until then, recovery relies on the escrow and a migration export.

SOC 2 A1.2, A1.3 · ISO 27001 A.8.13, A.5.30

Open work: sneakers-appliance#462 Scheduled offsite backups, sneakers-appliance#106 Backup lifecycle

Each service's gRPC health and /readyz fail while a required dependency (its database, gRPC peers, the workload-identity key set) is down; liveness checks the process only.

SOC 2 A1.1, CC7.2 · ISO 27001 A.8.16

Services log JSON at a level set per environment (production defaults to error) and can send traces and metrics to an OpenTelemetry collector. The appliance doesn't forward its logs and there is no built-in alerting yet.

SOC 2 CC7.2, CC7.3 · ISO 27001 A.8.15, A.8.16

Open work: sneakers-appliance#113 Forward logs to syslog or OTLP, sneakers-appliance#332 Export logs over OpenTelemetry

main accepts only squash-merged pull requests that pass the required checks (build and test, gosec, govulncheck, licence headers, dependency licences and the scrub). Force-push and deletion are blocked. No second reviewer is required: Sneakers has one maintainer today.

SOC 2 CC8.1 · ISO 27001 A.8.25, A.8.32

Open work: sneakers-release#23 A required release-review group

govulncheck and gosec run on every pull request and weekly; gitleaks and pattern checks run in the scrub. There is no CodeQL, container image scan or automated dependency update yet, and actions are pinned by commit only in the appliance repo.

SOC 2 CC7.1 · ISO 27001 A.8.8, A.8.28 · ASVS V14.2.1

Open work: sneakers-release#51 Excluded govulncheck finding awaiting an upstream fix

Behaviour is specified by tests through public APIs, with real Postgres, real sshd and network namespaces where it matters, and the appliance is exercised end to end in QEMU after each merge and nightly.

SOC 2 CC8.1 · ISO 27001 A.8.29

Vulnerabilities are reported privately through GitHub on the affected repository, acknowledged within a few business days, fixed and disclosed on a timeline agreed with the reporter, and credited in the advisory. A signed advisory feed for appliances is planned.

SOC 2 CC2.3, CC7.3, CC7.4 · ISO 27001 A.5.24, A.5.26, A.8.8

Open work: sneakers-appliance#330 Signed vulnerability-advisory feed