Cortex runs with your user's full permissions and, by design, reaches the most sensitive parts of your engineering environment. Stated plainly so the assurance below can be judged against the actual exposure:
- Every Claude Code session transcript under
~/.claude/— it reads and persists conversation history (projects/*/**.jsonl), memory notes and session logs to build your memory store (seePRIVACY.md). - Session hooks — it installs
SessionStart/SessionEnd/PostToolUsehooks (hooks/,scripts/install_hooks.py) that execute automatically on Claude Code lifecycle events. - Your filesystem, at your user's permission level — it reads source trees you point it at and writes its store and agent-config files.
A substituted or tampered Cortex distribution is therefore a keylogger on
your engineering work. That is precisely why the artifact integrity story
below exists: the local-only privacy guarantee in PRIVACY.md is only as
strong as the guarantee that the code you ran is the code we published.
As of issue #178, every Cortex release ships with verifiable provenance
(.github/workflows/release.yml):
-
Build provenance — the wheel, the sdist and the SBOM each carry a Sigstore-backed build-provenance attestation. Verify a downloaded asset binds to this repository and workflow:
gh attestation verify hypermnesia_mcp-<version>-py3-none-any.whl \ --repo cdeust/Cortex
-
PyPI provenance — the deprecated PyPI channel publishes via PEP 740 Trusted Publishing with attestations, so the package page shows a verified build. (
pipverifies distributions against PyPI's recorded hashes; this adds who built it and from which commit on top.) -
SBOM — a CycloneDX SBOM (
hypermnesia-mcp.cdx.json) generated fromuv.lockaccompanies every release, enumerating the full transitive dependency graph including the ML stack (torch / transformers / scipy / scikit-learn) that is the bulk of the attack surface. -
Checksums — every GitHub Release asset has a
<asset>.sha256companion. Verify a download before trusting it:python scripts/verify_release_artifact.py <asset> --checksum-file <asset>.sha256
A mismatch exits non-zero and prints both digests; this is the consumer side of the checksums, and it is what closes the risk — an attestation nobody checks changes nothing.
-
Continuous analysis — CodeQL runs on a schedule via GitHub's default code-scanning setup (Python, JavaScript/TypeScript and Actions), and OpenSSF Scorecard via
scorecard.yml. The Scorecard number is a recorded baseline, not a badge. -
Change control —
mainis protected: direct pushes are refused, every change lands through a pull request, and eleven status checks are required to pass before merge (Lint,Type Check,Build Package,CodeQL,Docker Smoke,Teston Python 3.10–3.13,Test (SQLite backend), andTest (Windows, SQLite backend)). Force-pushes and branch deletion are blocked, and conversation resolution is required.
Scorecard's Code-Review check scores a changeset as reviewed only when it
carries an approving review from someone other than its author. Cortex has
one maintainer, and GitHub structurally forbids approving your own pull request.
The check is therefore unattainable by construction, not unimplemented — no
configuration of this repository can satisfy it while it has a single
maintainer.
What is implemented instead is every part of the control that does not require a
second human: the pull-request requirement above (so no change reaches main
unreviewed by machine gates), the required-checks list, and the automated
analysis (CodeQL, Scorecard, Dependabot). The required approving-review count is
deliberately set to 0 rather than 1: at 1, a solo maintainer cannot merge at
all, so the setting would be traded for a repository that cannot ship — security
theatre that reduces real safety by pushing work outside the PR flow.
The residual risk is real and is not claimed away: a logic error that all
eleven automated gates accept will reach main without a second pair of human
eyes. Mitigation is the gate breadth above plus post-merge scanning; the honest
statement is that human code review is absent, not satisfied. This is why
the corresponding Scorecard alert is dismissed as "won't fix" rather than left
open — an alert that can never be actioned is noise that hides actionable ones.
It becomes actionable the moment a second maintainer joins, at which point the
approving-review count should be raised to 1 and this paragraph deleted.
What this does NOT claim. Provenance proves who built the artifact and
from which commit, not that the source is free of defects; and it is worth
nothing to a user who does not run the verification commands above. The
supported marketplace install path consumes the git tree directly
(ADR-0050), so its integrity is the tagged commit plus its attestation, not
a downloaded checksum. The container image built in CI is a bare-container
smoke test (ci.yml, docker-smoke) — it is never pushed to a registry,
so there is no published image to attest.
If you discover a security issue in this project, do not open a public issue. Instead, send a private report to the maintainer.
Disclosure channel: open a private security advisory on GitHub.
Include:
- Affected version (or commit SHA)
- Reproduction steps or proof of concept
- Impact assessment (what does an exploit accomplish?)
- Suggested fix, if you have one
| Severity | First response | Patch / mitigation |
|---|---|---|
| Critical (RCE, data exfiltration, auth bypass) | 24 hours | 7 days |
| High | 3 days | 14 days |
| Medium / Low | 7 days | Best effort |
Only the latest minor release on main receives security patches.
- Reporter sends private advisory.
- Maintainer acknowledges receipt within the first-response SLA.
- Maintainer + reporter agree on a coordinated disclosure date (default 30 days from the patched release).
- Patched release ships; reporter is credited unless they prefer anonymity.
- Public advisory published on the agreed date.
- Vulnerabilities in third-party dependencies that have not been patched upstream — please report those upstream first.
- Issues that require an attacker to already have control of the host process (in-process supply-chain attacks).
- Self-inflicted misconfigurations of your own MCP server registration.
Reporters who follow this disclosure process are credited in the release notes for the patched version, unless they explicitly request anonymity.