更少更安全：Obsidian 如何降低供应链攻击的风险 供应链攻击是恶意更新，悄悄进入许多应用程序使用的开源代码。以下是我们如何设计 Obsidian，以确保该应用程序是您思想的安全和私密环境。 更少更安全 这听起来可能很明显，但我们降低供应链攻击风险的主要方法是避免依赖第三方代码。与我们类别中的其他应用程序相比，Obsidian 的依赖项数量很少。请查看我们信用页面上的开源库列表。 像 Bases 和 Canvas 这样的功能是从头开始实现的，而不是导入现成的库。这使我们能够完全控制 Obsidian 中运行的内容。 - 对于小型实用函数，我们几乎总是在我们的代码中重新实现它们。 - 对于中型模块，我们会分叉它们，并在许可证允许的情况下将其保留在我们的代码库中。 - 对于像 pdf.js、Mermaid 和 MathJax 这样的较大库，我们包含已知良好、版本锁定的文件，并且仅在偶尔或安全修复发布时进行升级。我们阅读发布说明，查看上游更改，并在切换之前进行彻底测试。 这种方法使我们的依赖图保持浅层，子依赖项很少。较小的表面区域降低了恶意更新潜入的机会。 实际在应用中发布的内容 只有少数几个包是您运行的应用程序的一部分，例如 Electron、CodeMirror、moment.js。其他包帮助我们构建应用程序，并且从不交付给用户，例如 esbuild 或 eslint。 版本固定和锁定文件 所有依赖项都严格版本固定，并与锁定文件一起提交。锁定文件是构建的真实来源，因此我们获得确定性的安装。这为我们在审查更改时提供了简单的审计轨迹。 我们不运行 postinstall 脚本。这可以防止包在安装期间执行任意代码。 缓慢、谨慎的升级 当我们进行依赖项更新时，我们： 1. 逐行阅读依赖项的变更日志。 2. 检查新版本引入的子依赖项。 3. 当变更集较大或风险较高时，进行上游差异比较。 4. 在各个平台和关键用户路径上运行自动化和手动测试。 5. 仅在这些审查通过后提交新的锁定文件。 实际上，我们很少更新依赖项，因为它们通常工作良好且不需要频繁更改。当我们这样做时，我们将每个更改视为我们正在引入的新依赖项。 时间是缓冲 我们不急于升级。在升级任何依赖项和推送发布之间存在延迟。这个间隔充当早期警告窗口：社区和安全研究人员通常会迅速检测到恶意版本。在我们准备发布时，生态系统通常会标记任何有问题的版本。 — 没有单一措施可以消除供应链风险。但选择更少的依赖项、浅层图、精确的版本固定、不使用 postinstall 以及缓慢、重审的升级节奏共同使 Obsidian 更不可能受到影响，并为我们提供了一个较长的窗口，以在代码到达用户之前检测问题。 如果您对我们更广泛的安全方法感兴趣，请查看我们的安全页面和过去的审计。