Kaldera阅读源代码
整个应用都是 Apache-2.0 开源的。安全关键路径记录在威胁模型中，实现它们的代码就在 GitHub 上。
这一说法的现状
哪些内容被自动化验证，由谁验证
如今存在的是自动化、可复现的验证：覆盖 248 个文件的 2204 个单元测试、针对导入解析、备份封装和附件元数据的基于属性的模糊测试门禁、使用 Stryker 进行的变异测试、在 CI 中运行的 CodeQL 分析和 OpenSSF Scorecard、gitleaks 机密扫描，以及一项遇到任何高危或严重 npm 安全公告就会失败的依赖策略。
尚不存在的是外部独立专家对密码学设计和实现的审查。内部评审报告记录了数百项发现和修复，但它们是由项目自身撰写的。这是另一类别的保证，本站也不会把它当作独立的保证来呈现。
计划中的是外部审计：范围文件草案已经存在，列出了纳入范围的组件——密码学、密码库持久化、扩展桥接、Tauri IPC 层——因此一旦聘请审计方，工作即可启动。在合同存在之前，不会承诺任何日期。
不依靠我们也能完成的验证
亲自运行各道门禁
测试套件、模糊测试门禁和发布加固扫描都可以在本地运行，使用仓库中已写明的 npm 和 cargo 命令。流水线没有任何隐瞒。
验证你安装的产物
每次发布都公布 SHA-256 校验和，更新器捆绑包带有 minisign 签名。验证页面给出了确切的命令。
多层安全防御体系
2204 test
fast-check
CodeQL + Scorecard
为什么我们把它写在公开页面上
诚实是设计的一部分
把一次未完成的审计包装成成果，正是信任型产品失去信任的方式。缺少外部审计是真实的局限：它意味着还没有独立专家去寻找自动化所遗漏的缺陷。直截了当地说出来，让你能自行权衡风险，也给了这个项目一份可供公众问责的承诺。
单元测试套件
248 个测试文件，强制覆盖率阈值为行覆盖率 90%、分支覆盖率 80%；实测基线高于该阈值。
模糊测试门禁
基于属性的测试在每次发布运行时，向导入器和密码学路径投喂格式错误的 JSON、CSV、KDF 参数和备份封装。
CI 分析
GitHub 上的 CodeQL 每周分析代码，OpenSSF Scorecard 为供应链评分，gitleaks 阻止被提交的机密。