Comparison refreshed · August 19, 2026

Enterprise Security

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

Security built into every release

GoodMem combines signed image verification, a hardened runtime, built-in TLS, and automated supply-chain analysis.

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.

GoodMem install verificationSLSA generator v1.0.12Private server-v1.0.307 CLI bootstrap reviewedPrivate server-v1.0.307 Cosign bootstrap reviewed

Reviewed

TLS lifecycle built in

REST and gRPC use TLS by default, with custom, self-signed, or ACME-issued certificates, automatic renewal, and hot reload.

GoodMem TLS configurationGoodMem ACME setupPrivate server-v1.0.307 TLS implementation reviewed

Reviewed

Release gates and supply-chain visibility

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.

Private server-v1.0.316 release and scan workflows reviewedSLSA release workflow v1.0.15September 2026 enterprise whitepaper

Reviewed

Release-pinned comparison

Security 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.

Directly evidencedScoped or conditionalNot locatedNot applicable

Swipe horizontally to inspect every pinned release.

Security findings for GoodMem, Mem0, Supermemory, Cognee, OpenViking, and Graphiti; GoodMem and authorization findings refreshed August 19, 2026
Security featureGoodMem

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.

GoodMem TLS configurationGoodMem ACME setupPrivate server-v1.0.307 TLS implementation reviewed

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.

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.

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.

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

How to read this review

Exact release pins

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.

Evidence, not inference

“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.

Like-for-like scope

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.

A dated snapshot

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.

Need the evidence behind a security review?

Review our security documentation and Trust Center, or contact us with the controls your team needs to validate.