安全模型 · codebase-memory-mcp 繁中教學站

這個工具做什麼（先講清楚）

CBM 讀取你的 codebase，並寫入你的 agent 設定檔——這是它的設計本質。安裝前先知道這件事；想先稽核再看原始碼。

防護層	說明
VirusTotal	每個 release 二進位被 70+ 防毒引擎掃描（零偵測才發布）
SLSA Level 3	受信任的 GitHub Actions 建置流程產生的加密建置來源證明；用 `gh attestation verify` 驗證
Sigstore cosign	所有 artifact 的 keyless 簽章
SHA-256 checksums	每個 release 附 `checksums.txt`，安裝指令碼在解壓前驗證
CodeQL SAST	有未關閉的 alert 就擋 release pipeline
零 runtime 依賴	無供應鏈傳遞風險——所有函式庫在編譯時 vendored

100% 本機處理：所有解析、索引、語意搜尋都在本機跑，你的程式碼不會離開機器。
無 telemetry、無 phoning home：CBM 不會自行發任何網路請求，不會背景檢查新版本。
內建 embedding 模型：nomic-embed-code（768d int8）編譯進二進位——語意搜尋不需要 API key、Ollama、Docker。

不搞 in-process updater：更新交給外部 install.sh（避免二進位裡內建「下載 + 解壓 + 執行」的 dropper 特徵）。
不亂開設定：installer 絕不翻開實驗性 feature flag、不啟用 plugin、不做 global permission bypass、不信任第三方指令。
Conditional 安裝：只有當平台的 marker / 已存在的 config 路徑證明它 active 才寫入設定。
exact-build admission barrier：所有 CBM process 必須同版本、同建置、同 cache root，防止混版狀態。

因為無 telemetry，出了無法重現的問題時要自己抓資料。設 CBM_DIAGNOSTICS=1 後重開 daemon session：

檔案	內容
`trajectory.ndjson`	每 5 秒一行記憶體軌跡（rss/committed/peak/page_faults/fd/queries）——記憶體/洩漏回報要的就是它
`snapshot.json`	最新快照（乾淨退出時移除）

路徑在 ${CBM_CACHE_DIR}/logs/cbm-daemon.log 的 diagnostics.start 事件裡；使用隨機目錄避免其他帳號預置惡意連結。

變數	用途
`CBM_ALLOWED_ROOT`	把 `index_repository` 限制在此目錄內（未被信任的呼叫者/多租戶部署時用）
`CBM_CACHE_DIR`	覆寫 DB 存放目錄（一帳號只能用一個 canonical cache root）
`CBM_LOG_LEVEL`	log 級別：debug/info/warn/error/none

看完這頁你應該能說出：CBM 的 supply chain 六層防護、為何沒有 telemetry 又該怎麼自己抓診斷資料、installer 的三個「絕不」、以及 CBM_ALLOWED_ROOT 何時該設。