supply-chain: no provenance, SBOM, signing or Scorecard — PyPI wheel + plugin + image published unattested, 4 unpinned actions

[cdeust]

Context

Parity pass against DeusData/codebase-memory-mcp (HEAD 97ce23f, v0.9.0, re-cloned 2026-07-24). Cross-repo tracking in cdeust/enterprise-backlog#27; this issue is the Cortex-side work and is completed here, not there.

CBM ships 21 CI workflows including scorecard.yml, codeql.yml, dco.yml and _security.yml, with cosign/SBOM/SLSA attestation wired into _build.yml and release.yml. Every release artifact is signed, checksummed and AV-scanned.

Measured state, 2026-07-24

$ grep -rlE "cosign|sigstore|sbom|slsa|scorecard|attest-build-provenance" .github/workflows
(no matches)

4 workflows (ci.yml, release.yml, publish-ccplugins.yml, sync-ccplugins-fork.yml), no attestation of any kind.

What this repo publishes:

• PyPI wheel + sdist via pypa/gh-action-pypi-publish@release/v1 (release.yml:150-162, pypi environment)
• GitHub release assets via softprops/action-gh-release@v2 (release.yml:108)
• the plugin bundle, via publish-ccplugins.yml
• a container image (docker/build-push-action@v6)

Unpinned third-party actions — every one is a floating ref, so the code that builds and signs our releases can change under us without a commit here:

Action	Pinned to
pypa/gh-action-pypi-publish	release/v1 (branch)
softprops/action-gh-release	v2 (tag)
docker/build-push-action	v6 (tag)
docker/setup-buildx-action	v3 (tag)

Why this repo, specifically

Cortex is the highest-consequence artifact in the ecosystem. It reads and persists every session transcript, installs session hooks, and runs with the user's full filesystem access. A compromised Cortex wheel is a keylogger on the user's engineering work — and we currently ask users to install it from PyPI with no provenance they can verify.

The privacy posture in PRIVACY.md claims local-only processing. That claim is only as strong as the artifact's integrity; without attestation there is nothing distinguishing our wheel from one that exfiltrates. CBM addresses this head-on in its README ("This tool reads your codebase and writes to your agent configuration files. That is what it is designed to do... every release binary is signed, checksummed, and scanned"). We make a larger ask and offer less assurance.

This is also a hard blocker for the enterprise track (cdeust/enterprise-backlog#11, #15, #18) — signed, attested artifacts with an SBOM are a procurement precondition, not a nice-to-have.

Acceptance criteria

1. Provenance — actions/attest-build-provenance on the wheel, the sdist, the plugin bundle and the container image. Verified with gh attestation verify; the command and its output quoted in the PR.
2. PyPI Trusted Publishing with attestations enabled, replacing any long-lived token.
3. SBOM (CycloneDX or SPDX) generated per release and attached. The ML stack (torch/sentence-transformers/scipy/sklearn) is the bulk of the attack surface and must appear in it.
4. Checksums published for every release asset, and scripts/ verifies them on the install path. Cortex's installer downloads models and dependencies at setup time — an install path that downloads without verifying is the concrete hole here, not a theoretical one. See the _pip_install history (Windows: _pip_install's commit destroys existing deps packages while the MCP server is running (rmtree + os.replace vs locked .pyd) — armed on every session start when the ML stack is missing #97) for how much this path already does.
5. CodeQL on a schedule, not only on PR.
6. OpenSSF Scorecard workflow; the first score is recorded as a baseline, as-is. A low score is a valid measurement, not a failure (§8).
7. All third-party actions pinned to commit SHAs — the four in the table above, with a comment naming the version each SHA corresponds to.
8. SECURITY.md states plainly what Cortex accesses (transcripts, hooks, filesystem) and what assurance is now offered.

Definition of Done

Completion Ledger (§13.2), one row per criterion with its evidence: workflow run URL, gh attestation verify output, the SBOM artifact, the Scorecard baseline, and the install-path verification test. Criterion 4 needs a test that a tampered artifact is rejected — asserting the happy path only would miss the entire point (§13 A3, G4).