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

> Enhance codebase-memory-mcp security with VirusTotal scanning, SLSA provenance, and checksum verification. Discover how DeusData ensures robust binary integrity for your projects.

- Repository: [Martin Vogel/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp)
- Tags: security-verification
- Published: 2026-07-06

---

**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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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:

```bash
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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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:

```bash

# 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:

```bash

# 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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/checksums.txt) and [`scripts/vendored-checksums.txt`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/checksums.txt) file containing SHA-256 hashes for all assets. The [`scripts/install.sh`](https://github.com/DeusData/codebase-memory-mcp/blob/main/scripts/install.sh) installer automatically verifies these hashes before extraction, but manual verification works with: `sha256sum -c checksums.txt`. Additionally, [`scripts/vendored-checksums.txt`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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.