更少更安全：Obsidian 如何降低供應鏈攻擊的風險 供應鏈攻擊是惡意更新，悄悄進入許多應用程序使用的開源代碼。以下是我們如何設計 Obsidian，以確保該應用程序是您思想的安全和私密環境。 更少更安全 這聽起來可能很明顯，但我們降低供應鏈攻擊風險的主要方法是避免依賴第三方代碼。與我們類別中的其他應用程序相比，Obsidian 的依賴項數量很少。請查看我們信用頁面上的開源庫列表。 像 Bases 和 Canvas 這樣的功能是從頭開始實現的，而不是導入現成的庫。這使我們能夠完全控制 Obsidian 中運行的內容。 - 對於小型實用函數，我們幾乎總是在我們的代碼中重新實現它們。 - 對於中型模塊，我們會分叉它們，並在許可證允許的情況下將其保留在我們的代碼庫中。 - 對於像 pdf.js、Mermaid 和 MathJax 這樣的較大庫，我們包含已知良好、版本鎖定的文件，並且僅在偶爾或安全修復發佈時進行升級。我們閱讀發佈說明，查看上游更改，並在切換之前進行徹底測試。 這種方法使我們的依賴圖保持淺層，子依賴項很少。較小的表面區域降低了惡意更新潛入的機會。 實際在應用中發佈的內容 只有少數幾個包是您運行的應用程序的一部分，例如 Electron、CodeMirror、moment.js。其他包幫助我們構建應用程序，並且從不交付給用戶，例如 esbuild 或 eslint。 版本固定和鎖定文件 所有依賴項都嚴格版本固定，並與鎖定文件一起提交。鎖定文件是構建的真實來源，因此我們獲得確定性的安裝。這為我們在審查更改時提供了簡單的審計軌跡。 我們不運行 postinstall 腳本。這可以防止包在安裝期間執行任意代碼。 緩慢、謹慎的升級 當我們進行依賴項更新時，我們： 1. 逐行閱讀依賴項的變更日誌。 2. 檢查新版本引入的子依賴項。 3. 當變更集較大或風險較高時，進行上游差異比較。 4. 在各個平臺和關鍵用戶路徑上運行自動化和手動測試。 5. 僅在這些審查通過後提交新的鎖定文件。 實際上，我們很少更新依賴項，因為它們通常工作良好且不需要頻繁更改。當我們這樣做時，我們將每個更改視為我們正在引入的新依賴項。 時間是緩衝 我們不急於升級。在升級任何依賴項和推送發佈之間存在延遲。這個間隔充當早期警告窗口：社區和安全研究人員通常會迅速檢測到惡意版本。在我們準備發佈時，生態系統通常會標記任何有問題的版本。 — 沒有單一措施可以消除供應鏈風險。但選擇更少的依賴項、淺層圖、精確的版本固定、不使用 postinstall 以及緩慢、重審的升級節奏共同使 Obsidian 更不可能受到影響，併為我們提供了一個較長的窗口，以在代碼到達用戶之前檢測問題。 如果您對我們更廣泛的安全方法感興趣，請查看我們的安全頁面和過去的審計。