現代的 JavaScript 開發人員都喜歡 npm。GitHub 和 npm registry 是開發人員在查找特定軟件包時常去的地方。開源模塊為開發人員提供了很多可在項目中重用的功能，幫助他們提高工作效率。可以說，如果不是這些開源軟件包，今天的大多數框架都不會以當前的形式存在。
一個成熟的企業級應用程序可能依賴數百個（如果不是數千個）軟件包。通常的依賴包括直接依賴、開發依賴、捆綁依賴、生產依賴和可選依賴。
然而，人們通常忽視了存在軟件包中的風險。雖然這些第三方模塊在某些方面特別有用，但也會往你的應用程序中引入一些安全風險。
開源庫是否有漏洞？
OSS 軟件包確實存在漏洞，容易遭受攻擊。我們來看幾個例子：
最近在一個名為 eslint-scope 的軟件包中發現了一個漏洞，它是一些流行的 JavaScript 軟件包（如 babel-eslint 和 webpack）的依賴項。這個軟件包維護者的帳號遭竊取，黑客在其中添加了一些惡意代碼。所幸的是，有人很快發現了這個漏洞，最後隻影響了少數幾個用戶。
Moment.js 是用於解析和顯示日期的常用 JavaScript 庫之一，最近出現了一個漏洞，嚴重性評分高達 7.5。這個漏洞容易遭受 ReDoS 攻擊。不過他們很快發佈了補丁， 問題也將很快得到解決。
5 月份，npm 中出現了一個偽裝成 cookie 解析器的後門程序， NPM 在接到投訴後迅速將其移除，好在沒有造成任何真正的破壞。
今年早些時候，GitHub 就開始提醒開發人員他們的代碼中包含不安全的庫。
GitHub 平臺負責人 Sam Lambert 在最近的媒體採訪中表示，他希望能夠通過機械化提交的方式來自動化代碼提交流程，從而檢測並替換可疑代碼。
NPM 安全負責人 Baldwin 在採訪中說，NPM 可能會採取類似的措施，而不只是提供簡單的通知。
漏洞太多，幾乎每週都會出現很多新的漏洞。其中一些很快被發現，但也有一些在造成嚴重破壞後才成為頭條新聞。
那麼我們該如何降低這些風險呢？在本文中，我將介紹一些可用於保護開源依賴項的行業最佳實踐。
1. 跟蹤應用程序的依賴項
從邏輯上講，隨著依賴項數量的增加， 受到攻擊的風險也會增加。對於直接和間接依賴項來說都是一樣的 。雖然說你不可能停止使用開源軟件包，但對它們進行跟蹤總不是件壞事。
要查看這些依賴項十分容易， 可以在應用程序的根目錄中運行 npm ls 。你可以使用 -prod 參數顯示所有的生產依賴項，或使用 -long 參數顯示每個包的描述摘要。
此外，你也可以使用服務來自動化依賴項管理過程， 為你的依賴項提供實時的監控和自動更新測試。一些常見的工具包括 GreenKeeper、Libraries.io 等。這些工具會整理依賴項列表並跟蹤它們的相關信息。
2. 移除不需要的包
隨著時間的推移和代碼的不斷變更，你可能會停止使用某些軟件包，然後 添加新的包，但可能不會去刪除舊包。
隨著時間的推移，你的項目可能會積累大量不使用的依賴項。雖然這不會導致 直接的安全風險，但這些依賴項肯定會增加項目的攻擊表面，並導致不必要的代碼混亂。攻擊者可能通過加載具有較高漏洞商數的舊包來查找漏洞，從而增加造成潛在破壞的可能性。
那麼該如何檢查這些不使用的依賴項？你可以使用 depcheck 來完成這項任務。depcheck 會掃描整個代碼庫，嘗試查找 require 和 import 命令。然後，它將這些命令與已安裝的軟件包或 package.json 中提到的軟件包相關聯，併為你提供分析報告。這個命令也提供了不同的參數選項，讓自動檢查不使用的依賴項變得更加簡單。
安裝 depcheck：
npm install -g depcheck
3. 查找並修復關鍵安全漏洞
上面討論的所有要點主要涉及可能會遇到的潛在風險，但那些你正在使用的依賴項呢？
最近的一項研究表明，當前有近 15％的軟件包包含已知漏洞，無論是組件還是依賴項。但是，好消息是，你可以使用很多工具來分析代碼並發現項目中存在的開源安全風險。
最方便的工具是 npm audit。audit 是隨 npm 6 一起發佈的一個腳本。npm audit 最初是由 Node Security Platform 開發的，後來放在了 npm registry 中。下面是 npm audit 官方博客的一段描述：
安全審計是對軟件包依賴項安全漏洞的評估，可幫助你查找和修復依賴項中的已知漏洞，從而達到保護軟件包的用戶的目的。npm audit 命令會將的依賴項的描述提交到默認 registry，並要求提供已知漏洞的報告。
生成的報告通常包含以下詳細信息：受影響的程序包名稱、漏洞嚴重性和描述、路徑和其他信息，以及用於修復問題的補丁命令（如果有）。你甚至可以通過運行 npm audit --json 來獲取 JSON 格式的審計報告。
除此之外，npm 還提供了根據報告採取行動的建議。你可以使用 npm audit fix 來修復已經找到的問題。這些修復通常使用引導式升級或開源補丁來完成。
4. 使用內部替代方案替換過期的庫
開源安全的概念在很大程度上依賴於有多少雙眼睛在盯著特定的庫 。越是使用廣泛的軟件包就越是受到密切的關注。因此，開發人員更有可能解決這些特定包中的已知安全問題。
我們來舉個例子。在 GitHub 上，有很多 JSON web 令牌實現可以與 Node.js 庫一起使用。但那些沒有活躍維護者的庫可能包含嚴重的漏洞。Auth0 就報告了一個這樣的漏洞，任何人都可以使用任意有效負載創建自己的“簽名”令牌。
如果一個很受歡迎的軟件包有這樣的漏洞，被開發人員發現和修補的幾率會更高。但是一個不活躍甚至被遺棄的項目呢？
5. 始終選擇有人在維護的庫
判斷一個特定包是否活躍最快最有效的方法可能是在 npm 上檢查其下載量。你可以在 npm 的包主面的 Stats 裡找到它。也可以使用 npm stats API 自動提取這些數字或瀏覽 npm-stat.com 上的歷史統計數據 。對於具有 GitHub 存儲庫的軟件包，應該查看提交歷史記錄、問題跟蹤器以及庫的相關拉取請求。
6. 經常更新依賴項
bug 和安全漏洞會不斷出現，在大多數情況下，它們會立即得到修復。
我們以 2016 年初在 HMAC 軟件包 hawk 中出現的正則表達式拒絕服務（ReDoS）漏洞為例。hawk 的這個 bug 很快得到修復，但僅限於最新的 4.x 版本，而像 3.x 這樣的舊版本在很長一段時間後才打上補丁 。
因此，一般來說，如果使用最新可用的依賴項版本，就不太可能存在安全問題。
判斷你是否正在使用最新版本依賴項的最簡單方法是使用 npm outdated 命令。這個命令支持是要 -prod 標誌來忽略開發依賴項，而是要—json 參數會讓自動化變得更簡單。
定期檢查你的依賴項， 驗證它們的修改日期，你可以通過 npm UI 或運行 npm viewtime.modified 命令來檢查依賴項的最後修改日期。
結論
保護應用程序的關鍵是形成從一開始就將安全放在第一位的文化。在這篇文章中，我們介紹了一些用於提高 JavaScript 組件安全性的標準實踐。
- 選擇有人在維護的開源依賴項。
- 更新和監控你的組件。
- 檢查你的代碼並編寫測試。
- 刪除不需要的依賴項或使用替代項。
- 使用 npm audit 等安全工具來分析你的依賴項。
閱讀更多 在我的瞳孔裡照見你 的文章
關鍵字: 編程語言 JavaScript 軟件
