Codebase-Memory-MCP Security Verification: VirusTotal, SLSA Provenance, and Checksums Explained

Codebase-Memory-MCP enforces a defense-in-depth security posture by scanning every release binary through 72 VirusTotal engines, publishing SLSA Level 3 provenance attestations, and distributing SHA-256 checksums alongside Sigstore cosign signatures.

Codebase-Memory-MCP (CBM) is a static, zero-dependency binary that constructs a full-text, graph-based knowledge store of source code. Understanding the codebase-memory-mcp security verification process is critical for teams integrating this tool into sensitive CI/CD pipelines. The project implements multiple supply-chain security controls, ranging from pre-release malware scanning to cryptographic build provenance verification.

VirusTotal Integration: 72-Engine Malware Scanning

Every release binary undergoes mandatory VirusTotal verification before publication. According to the source documentation in README.md (lines 89-95), each build is uploaded to VirusTotal and scanned by 72 distinct antivirus engines.

The release pipeline enforces a strict zero-detection policy. If any engine flags the binary, the tag is blocked from publication. This pre-distribution vetting ensures that the static binary—compiled with 158 vendored tree-sitter grammars and compression libraries—reaches users without embedded malware or trojans.

SLSA Level 3 Provenance and Supply Chain Integrity

CBM generates SLSA Level 3 build provenance attestations through a reproducible CI pipeline. These cryptographic attestations, referenced in README.md (lines 93-99), provide tamper-evident documentation of exactly how, when, and from what source code each binary was built.

Users can verify this provenance using the GitHub CLI:

gh attestation verify --owner DeusData <path-to-binary>

This command validates that the binary matches the SLSA attestation stored in GitHub's transparency log, confirming the artifact was built from the expected source repository and was not modified post-build.

Checksum Verification and Cosign Signatures

The project distributes multiple integrity verification mechanisms alongside each release. A checksums.txt file containing SHA-256 hashes is published for every release asset, allowing users to verify file integrity after download.

Additionally, all release assets are signed with Sigstore cosign using keyless signing. The signature bundle lives alongside the binary and is automatically validated during installation.

The repository also maintains scripts/vendored-checksums.txt, which lists internal checksums for all vendored source dependencies (tree-sitter grammars, compression libraries) compiled into the binary. This ensures the internal dependencies match known-good states.

Static Linking and Dependency Security

CBM's architecture eliminates dynamic supply-chain risks through zero runtime dependencies. All third-party code—including tree-sitter grammars from internal/cbm/, zstd, and LZ4 compression libraries—is statically compiled into a single binary.

As documented in README.md (lines 33-35), this static linking approach removes the attack surface associated with dynamic library loading or external package manager dependencies. The binary contains everything needed to build the graph database (stored in ~/.cache/codebase-memory-mcp/graph.db.zst) without reaching out to system libraries.

Runtime Security and Code Quality Gates

Before any release reaches the VirusTotal scanning stage, the code must pass CodeQL static analysis. As implemented in the CI pipeline (README.md lines 98-99), every pull request triggers automated security scanning. Open CodeQL alerts block the release pipeline, ensuring that known vulnerability patterns (buffer overflows, injection flaws) never ship in production binaries.

The multi-pass indexing architecture—spanning src/discover/ (file discovery), src/hybrid_lsp/ (type-aware resolution), and src/store/ (SQLite persistence)—is regularly audited through this static analysis framework.

How to Verify Your Installation

When installing CBM using the official installer, multiple verification steps run automatically. The scripts/install.sh script verifies both the SHA-256 checksum and the Cosign signature before extracting the binary to your system.

To manually verify security artifacts after installation:

# Verify SLSA provenance

gh attestation verify --owner DeusData codebase-memory-mcp

# Check VirusTotal report (replace VERSION with actual release)

open "https://www.virustotal.com/gui/file/$(sha256sum codebase-memory-mcp | cut -d' ' -f1)"

# Verify checksum manually

sha256sum -c checksums.txt

Once verified, you can safely index repositories and query the graph:

# Index the current repository

codebase-memory-mcp cli index_repository '{"repo_path":"$(pwd)"}'

# Search for handler functions

codebase-memory-mcp cli search_graph '{"label":"Function","name_pattern":"(?i).*handler.*"}'

# Trace call paths

codebase-memory-mcp cli trace_path '{"function_name":"processOrder","direction":"both"}'

Summary

• VirusTotal scanning: Every release is scanned by 72 engines with zero tolerance for detections before publication.
• SLSA Level 3 provenance: Cryptographic build attestations enable users to verify the binary's origin and integrity using gh attestation verify.
• Checksum verification: SHA-256 hashes in checksums.txt and scripts/vendored-checksums.txt ensure both release assets and internal dependencies match expected values.
• Cosign signatures: Keyless Sigstore signatures provide additional tamper-proofing alongside checksums.
• Static compilation: Zero runtime dependencies eliminate dynamic library supply-chain risks, with all 158 tree-sitter grammars and compression libraries built into the binary.
• CodeQL gating: Automated static analysis blocks releases containing potential security vulnerabilities.

Frequently Asked Questions

How does Codebase-Memory-MCP ensure binaries are malware-free?

Every release binary is uploaded to VirusTotal and scanned by 72 antivirus engines before the GitHub tag is published. The release pipeline enforces a strict requirement of zero detections across all engines. This verification happens automatically in CI, as documented in README.md (lines 89-95), ensuring no human-modified binary reaches users without independent malware scanning.

What is SLSA Level 3 provenance and why does it matter for CBM?

SLSA (Supply-chain Levels for Software Artifacts) Level 3 is a security framework standard that requires both hermetic, reproducible builds and tamper-proof provenance attestations. For CBM, this means the CI environment is isolated, build steps are scripted and version-controlled, and cryptographic signatures prove the binary was built from the official source. Users can verify this using gh attestation verify --owner DeusData <binary> to confirm the artifact matches the signed provenance stored in GitHub's transparency log.

How can I verify the SHA-256 checksum of my CBM installation?

Each release publishes a checksums.txt file containing SHA-256 hashes for all assets. The scripts/install.sh installer automatically verifies these hashes before extraction, but manual verification works with: sha256sum -c checksums.txt. Additionally, scripts/vendored-checksums.txt tracks internal dependencies' checksums, ensuring the statically compiled tree-sitter grammars and libraries match their expected cryptographic fingerprints.

Does Codebase-Memory-MCP have any runtime dependencies that could introduce vulnerabilities?

No. CBM is designed as a static, zero-dependency binary. All third-party code—including the 158 tree-sitter grammars in internal/cbm/, zstd compression, and LZ4 libraries—is compiled into the binary at build time. As noted in README.md (lines 33-35), this eliminates risks from dynamic linking, shared library hijacking, or package manager compromise, reducing the attack surface to the vetted, statically linked code alone.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}