Signed image verification
The CLI verifies the server image’s signed SLSA attestation and digest before launch by default. The bootstrap still relies on HTTPS delivery for the CLI and Cosign verifier.
Reviewed
Comparison refreshed · August 19, 2026
Every GoodMem release ships with signed image verification, automated supply-chain scanning, and a hardened nonroot server image. The evidence is on this page, pinned to exact releases.
See how GoodMem compares with popular alternatives on the security features that matter most to enterprise teams.
Built for secure deployment
GoodMem combines signed image verification, a hardened runtime, built-in TLS, and automated supply-chain analysis.
The CLI verifies the server image’s signed SLSA attestation and digest before launch by default. The bootstrap still relies on HTTPS delivery for the CLI and Cosign verifier.
Reviewed
The server runs as nonroot UID 65532 on a distroless Java 21 image with no shell or package manager, reducing its runtime attack surface.
Reviewed
REST and gRPC use TLS by default, with custom, self-signed, or ACME-issued certificates, automatic renewal, and hot reload.
Reviewed
At server-v1.0.316, release dependencies include blocking OSV vulnerability and FOSSA license-policy checks. Server and CLI security pipelines generate SBOMs; Grype is a separate reporting scan. Vulnerability exclusions apply.
Reviewed
Release-pinned comparison
Exact self-hosted release pins. GoodMem and every authorization finding were refreshed August 19, 2026; other cells retain the evidence dates shown. Hosted offerings may add controls beyond the releases compared here.
Swipe horizontally to inspect every pinned release.
| Security feature | GoodMem Server server-v1.0.307 · 54bb861 Released 2026-08-19 | Mem0 Memory server v2.0.11 · f2532f0 Released 2026-07-01 | Supermemory Memory server server-v0.0.3 · 39ef7e1 Released 2026-06-13 | Cognee Memory platform v1.2.2 · ce4a935 Released 2026-06-26 | OpenViking Context database v0.4.8 · 07113f8 Released 2026-07-08 | Graphiti Context graph engine v0.29.2 · ff7e29c Released 2026-06-08 |
|---|---|---|---|---|---|---|
| Secure installationDoes the supported install path verify released artifacts? | Scoped or conditional The CLI verifies the server image’s signed SLSA attestation and digest by default. The bootstrap script and auto-installed Cosign binary are not independently verified; --skip-verify disables image verification. GoodMem install verificationSLSA generator v1.0.12Private server-v1.0.307 CLI bootstrap reviewedPrivate server-v1.0.307 Cosign bootstrap reviewed Reviewed | Not located The supported Compose path builds locally, then force-reinstalls unpinned mem0ai from PyPI at startup. It performs no signature or provenance check and is not reproducibly tied to v2.0.11. | Scoped or conditional The installer checks SHA-256 against an unsigned co-hosted manifest. On macOS it replaces a failed vendor signature with a local ad-hoc signature, which does not authenticate the publisher. | Not located Source, package, and container installation are documented; no signature or provenance verification is performed by the supported install paths. | Not located Pip, uv, and container installation are documented; no built-in consumer verification step was located. | Not located The server guide pulls stale latest (currently 0.22.0), while Compose builds locally and installs unpinned graphiti-core unless a version argument is supplied. Neither path verifies artifact identity. |
| Verifiable provenanceCan a consumer verify who built the released artifact? | Directly evidenced The CLI verifies signed SLSA Build L3 provenance and the digest for the server image by default. | Scoped or conditional The 2.0.11 Python files have signed PyPI Trusted Publisher attestations. The supported server has no signed image, and its Compose path installs an unpinned package. | Not located The release provides checksums, but no publisher signature, attestation, or public server build workflow was located for the native binaries. | Scoped or conditional The 1.2.2 image carries unsigned BuildKit provenance but no publisher signature or consumer verification policy. Its provenance references post-tag commit 1913271 rather than tagged ce4a935; runtime files were unchanged. | Scoped or conditional PyPI files have signed Trusted Publisher attestations. The container is published by digest with unsigned BuildKit provenance, but no publisher signature or consumer verification policy. | Scoped or conditional graphiti-core 0.29.2 has a signed PyPI Trusted Publisher attestation. No matching 0.29.2 server image exists; Docker Hub latest remains 0.22.0. |
| Hardened server imageWhat attack-surface and privilege baseline does the released image use? | Directly evidenced Distroless Java 21 runtime with no shell or package manager; runs as nonroot UID 65532. Private server-v1.0.307 Dockerfile reviewedGoodMem public image configurationGoodMem public server image Reviewed | Scoped or conditional The source-built API development image uses a general Python base, runs as root, and enables Uvicorn reload; only the dashboard image switches to nonroot. | Not applicable The self-hosted server is distributed as a native binary rather than a container image and runs with the invoking user’s privileges. | Scoped or conditional The runtime uses a general Python slim image and does not set USER, leaving the server at the image’s root default. Reviewed | Scoped or conditional The runtime uses a general Python slim image with development utilities and does not switch away from the root default. Reviewed | Scoped or conditional The v0.29.2 source Dockerfile creates a nonroot app user on Python slim, but no matching 0.29.2 image is published; Docker Hub latest is the older 0.22.0 build. |
| Security automationWhat automated scanning or update control is visible? | Scoped or conditional SBOM, Grype, OSV-Scanner, and FOSSA jobs are present, with monthly patch-only Dependabot updates and checked auto-merge. Vulnerability findings are not a universal release gate. Private server-v1.0.307 scan workflow reviewedPrivate server-v1.0.307 Dependabot policy reviewedPAIR Systems Trust Center Reviewed | Not located The pinned workflows run tests and packaging; no dedicated code, dependency, or container vulnerability scanner was located. Reviewed | Not located The pinned CI runs formatting, lint, and type checks; no dedicated vulnerability scanner or public server build workflow was located. | Scoped or conditional An OpenSSF Scorecard workflow uploads repository security analysis; no dedicated dependency or container CVE scan was located. | Directly evidenced CodeQL scans Python and C++ with security-and-quality queries in CI and on schedule; Dependabot updates Python and GitHub Actions dependencies weekly. | Directly evidenced CodeQL scans Python and GitHub Actions on pushes, pull requests, and weekly; Dependabot updates root, server, and MCP Python dependencies weekly. |
| TLS boundaryDoes the project terminate TLS, or does the operator/host? | Directly evidenced REST and gRPC use TLS by default; custom, self-signed, and ACME-issued certificates are supported. No mTLS. Reviewed | Not located The supported server and dashboard are documented over HTTP; no native TLS configuration was located. | Scoped or conditional Vendor documentation exposes an HTTP listener and no TLS setting. The server implementation is absent from the public tag, so this cannot be independently verified in source. | Not located The supported Uvicorn and Compose paths expose HTTP; no native TLS termination configuration was located. | Scoped or conditional OpenViking listens over HTTP. Its supported Compose stack includes Caddy for HTTPS termination and automatic ACME issuance and renewal after the operator enables a domain and ports 80/443. | Not located The FastAPI server is documented over HTTP on port 8000; no native TLS termination configuration was located. |
| Authorization modelAfter authentication, what roles, scopes, and resource policy does the self-hosted server enforce? | Directly evidenced HUMAN and SERVICE principals are authorized for an operation on a typed target through fixed roles, ownership, direct grants, and all-authenticated grants; scoped-key ceilings independently cap live authority. Policy is additive, roles are code-defined, groups and deny rules are absent, and hard tenant isolation requires a separate instance. GoodMem access-control referenceGoodMem security modelGoodMem built-in rolesGoodMem API-key ceilingsPrivate server-v1.0.307 authorization implementation reviewed Reviewed | Scoped or conditional JWTs and user-owned revocable API keys add coarse admin-only gates. Ordinary authenticated callers can still create, search, read, update, and delete memories under arbitrary entity identifiers or memory IDs; there are no resource grants or key ceilings. | Scoped or conditional Self-hosted Supermemory is one local organization owner with one unrestricted key. Multi-member roles and scoped keys are Enterprise controls, so container tags do not isolate callers sharing that key. Local auto-login trusts the request hostname rather than the peer address. Supermemory local and enterprise scopeSupermemory authorization recheck at server-v0.0.8Official server-v0.0.8 Linux binary behavior reviewed Reviewed | Scoped or conditional Tenant-scoped custom roles and positive per-dataset ACLs grant read, write, delete, and share to users, roles, or tenants. There is no policy below the dataset, explicit deny, or scoped and expiring credential authority; enforcement is distributed across application paths. | Scoped or conditional ROOT/ADMIN/USER gates combine with account and per-user namespace isolation. There are no assignable per-resource permissions; account-shared resources are readable and writable by every account user. HTTP context is the boundary, while an omitted in-process context defaults to root. | Not located No built-in inbound authentication was located on the self-hosted FastAPI or MCP HTTP surfaces, and there are no principals, roles, tenant binding, or resource policy checks. group_id is a caller-controlled namespace/filter rather than an authorization boundary. Use network isolation or an authenticating proxy. |
| Persistence dependenciesWhich stateful services are required or optional? | Directly evidenced The supported local stack includes PostgreSQL; a remote PostgreSQL database can be configured. | Directly evidenced The supported self-hosted stack requires PostgreSQL with pgvector. | Scoped or conditional Vendor documentation says the graph engine is embedded and persists to local disk with no external database. The server implementation is absent from the public tag. | Directly evidenced Embedded SQLite, graph, and vector stores are the defaults; PostgreSQL, Neo4j, and Redis are optional profiles. | Directly evidenced Local embedded storage is the default; remote vector, object, and metadata stores are optional deployment choices. | Directly evidenced The server requires a graph database, with Neo4j and FalkorDB as the documented Compose options. |
| FIPS postureIs there a documented, scoped FIPS cryptographic boundary? | Scoped or conditional Server JCE/TLS runs through BCFIPS and BCJSSE in approved-only mode, but the deployed BC-FJA 2.1.2 patch is still under submission; database and CLI paths remain outside the boundary. GoodMem FIPS boundaryPrivate server-v1.0.307 FIPS bootstrap reviewedBouncy Castle Java FIPS releasesNIST CMVP certificate 4943 Reviewed | Not located No documented FIPS mode or scoped cryptographic boundary was located in the pinned public source tree. Reviewed | Not located No documented FIPS mode or scoped cryptographic boundary was located in the pinned release or self-hosting documentation. | Not located No documented FIPS mode or scoped cryptographic boundary was located in the pinned public source tree. Reviewed | Not located Encryption and KMS options are documented, but no FIPS mode or scoped validated cryptographic boundary was located. | Not located No documented FIPS mode or scoped cryptographic boundary was located in the pinned public source tree. Reviewed |
Methodology and limits
We inspect exact stable tags rather than moving default branches. The comparison table uses the releases and review dates shown, not a continuously updated latest-release claim. Authorization findings have their own refreshed review dates. Current GoodMem release-gate details are summarized above; the table retains its original pinned snapshots.
“Not located” means the audited public release did not expose an explicit artifact or workflow. When server source is absent, vendor-documented runtime claims are marked scoped or conditional instead of directly evidenced. Neither status rules out a private or commercial feature.
We selected active, self-hostable memory and context systems. Hosted-only controls are excluded; image hardening is marked not applicable when a project distributes a native server binary instead of a container.
Projects change. Treat this as a reproducible snapshot, re-check the linked source before procurement, and report a stale finding so we can correct it.
Review our security documentation and Trust Center, or contact us with the controls your team needs to validate.