如何評估NPM軟件包依賴項的安全性？近年來，編程領域已轉向越來越高的安全標準。在過去五年中，超過50%的數據泄露事件在增加，并且記錄了大量的網絡犯罪攻擊，因此，確保在線服務的安全性和可操作性正在逐漸消耗開發團隊的時間。數據泄露的成本可能會使一家老牌公司癱瘓，更不用說可能會使一家初創公司被判處死刑。這就是為什么在每個級別上努力減少和減輕所開發軟件的安全威脅非常重要的原因。

　　一、包裹檢查工具

讓我們從一些簡單的命令開始，您可以將它們添加到構建腳本中或作為CI/CD步驟。

　　1.npm重復數據刪除

重復數據刪除命令只是嘗試通過將依賴關系上移樹來簡化依賴關系。本質上，試圖擁有一個可以被更多軟件包使用的兼容的依賴項，而不是每個軟件包都有其自己稍有不同的版本。更少的版本可以通過所說的依賴關系提供更少的攻擊媒介（較新的版本往往具有針對已知和已發布漏洞的修復程序）。

　　2.npm審核?

一個非常強大的命令，它將掃描您的項目中的所有已知漏洞，并為您提供安全報告以及潛在的修復程序。在某些情況下，它甚至可以為您更新軟件包。在其他情況下，它僅告訴您如何進行修復。雖然功能非常強大，但也有其局限性。即它只能檢查報告給npm Registry的已知漏洞。對于所有尚未通過驗證的漏洞，您真是不走運。

　　3.OWASP依賴項檢查

OWASP依賴項檢查是根據已知漏洞的公共數據庫檢查依賴項的。它具有一個CLI工具，可在本地存儲要檢查的整個數據庫。這使得它適合您不想授予完全訪問權限的系統。

　　4.NPQ

使用此命令行實用程序，您可以檢查是否存在不良依賴關系，并提示您確認是否注意到您試圖安裝具有已知漏洞的軟件包。

在這里，您可以找到一系列精選的面向安全性的不同node.js安全性資源。對于簡單更新不那么容易的情況，它對于修復或緩解問題和漏洞可能很有用。

　　二、超越自動檢查

除了可以添加到常規代碼工作流中的內容之外，您可能還需要定期進行更深入的軟件包分析。嘗試為您的項目回答以下問題：

我要用這個模塊做什么？還是有必要嗎？

1.是否存在使用不同模塊（或我們的代碼）來解決同一問題的情況？

2.哪些軟件包帶有大多數子模塊？我可以用一些“更扁平的”包裝代替它們嗎？

3.他們都還在積極發展嗎？哪些長期未更新或沒有活躍的開發人員？

4.看一下他們的問題/錯誤跟蹤器，是否有關于漏洞或錯誤代碼的報告？

5.他們是否發布測試覆蓋率，通過和/或任何其他代碼質量指標？

上面的問題將幫助您評估是否必須更新任何軟件包或將其替換為替代軟件包，或者甚至由團隊進行編碼。但是您可能必須走的更遠。上面的問題集中于一些攻擊媒介。主要是在開發人員有意或無意中將漏洞引入其代碼庫的情況。但是，如果發布者的用戶帳戶受到威脅該怎么辦？

密碼錯誤和重復是一個現實，它會影響每個在線服務（包括npm注冊表）的安全性。如果您具有發布者的密碼，則可以使用git克隆其代碼，添加您的惡意代碼，并將其構建并發布到NPM注冊表中。一切看起來都不錯，可能要花費數月和數百萬次下載才能有人注意到有什么問題。

其中一個案例是一個包裹，該包裹在被發現之前從礦工的錢包中竊取了近三個月的比特幣。當前，沒有很好的方法來驗證發布的內容是該項目的Github上顯示的內容。

　　三、那么該怎么辦？

有幾種方法可以驗證上述內容：

1.比較GitHub和您從注冊表下載的版本之間的git commit散列。

2.下載源代碼并自己構建，然后將其與從NPM下載的軟件包進行比較。針對這兩個版本運行測試和基準，并尋找結果和性能的任何變化，可能會發現代碼差異，這可能表明存在潛在的惡意代碼。

　　四、尋找新的可能的攻擊媒介

這篇文章從您可以采取的一些簡單步驟開始，以提高安全性。超出范圍的所有內容都趨于變得更加復雜，并且在項目的日常工作中很難做到。除了知道現在可以使用哪些向量來破壞您的應用程序之外，您還必須注意將來可能發生的攻擊向量（這些攻擊向量仍是未知的或從未嘗試針對npm注冊表/軟件包）。而且，可悲的是，為此，除了閱讀博客，參加會議，尋找正式公告或讓專門的安全專家為您做之外，您幾乎無能為力。

這就是像我們這樣的網絡安全工具可以派上用場的地方。從理論上講，您可以通過研究所有攻擊媒介，漏洞報告站點，測試案例，代碼基準以及創建運行所需的腳本和CI/CD管道以使其自動化來重新實現整個檢查堆棧。但是，所有這些工作只會帶您進入當前的最新狀態。此外，僅要保持其運行就需要額外的維護工作。

但是，使用基于云的漏洞掃描器，您不僅可以訂閱最新的漏洞檢查技術。您還將委派您或您的團隊必須獲得并不斷更新的所有專業知識和研究，以擁有用于安全驗證的內部解決方案。

以上就是關于如何評估NPM軟件包依賴項的安全性的全部內容介紹，想了解更多關于信息安全的信息，請繼續關注中培偉業。