在最近的幾次供應鏈攻擊之后，例如來自 SolarWinds 的攻擊，甚至是最近導致Celsius Networks 網絡釣魚攻擊的攻擊，許多人都在提倡更嚴格的第三方控制。Celsius 甚至表示，該公司“將提高我們在 ISO 和 SOC 認證方面對第三方的要求?！?/p>

但更嚴格的第三方控制究竟意味著什么？公司如何獲得第三方的控制權？在Web 供應鏈攻擊的背景下，腳本是否正在審查最終答案？讓我們找出來。

什么是第三方腳本審核？

要掌握第三方審查的概念，我們需要看一下普通網站。如今，隨著對更快的產品開發的需求不斷增長，開發人員越來越依賴外部源代碼片段，尤其是 JavaScript 框架和庫。這導致平均 Web 應用程序具有超過 1000 個模塊，也稱為代碼依賴項。由于這些模塊中的每一個都可以有自己的依賴項，因此每個應用程序最終都會有數千個第三方代碼。

然后，還有大多數網站在運行時使用的所有附加腳本的問題。如今，大多數網站都在使用外部服務，如聊天機器人、分析或廣告。

隨著第三方的大量使用，攻擊面增加，特別是在涉及供應鏈攻擊時。由于這些攻擊依賴于公司對其代碼對供應鏈的依賴性缺乏可見性，因此它們通常會在數周內不被注意。我們已經在2018 年Magecart 網絡瀏覽組攻擊英國航空公司的案例中看到了這種情況，該事件在兩個多月的時間里都沒有引起注意。

現在，第三方腳本審查背后的概念是，公司將審查每個第三方腳本和提供它的公司，以確保它們是合法和安全的。允許使用經過審查的腳本，而那些未通過審查程序的腳本將被放棄（至少在它們仍然不安全的情況下）。

審查腳本提供者的過程通常是通過尋找證明公司對安全的承諾的認證 (ISO/SOC) 來完成的。另一方面，腳本審查通常涉及掃描代碼以查找任何可能使攻擊者更容易破壞腳本的漏洞或安全漏洞。

乍一看，這似乎是問題的最終答案。然而，正如我們接下來將看到的，雖然這種第三方審查方法在幫助公司應對網絡供應鏈攻擊方面發揮著重要作用，但它必須與額外的安全措施相結合。

為什么腳本審查不足以防止 Web 供應鏈攻擊？

如果我們在幾天內仔細觀察任何給定網站的不同部分，我們會看到數百個代碼依賴項在不斷變化。這些框架和庫中的每一個都會收到更新，它們各自的第四方也會收到更新。

當我們將這種動態場景與腳本審查的概念進行對比時，我們很快就會明白為什么僅靠腳本審查不足以保證第三方腳本的安全。腳本審查的最大問題是它只提供了一個時刻的畫面。這意味著今天成功通過審查并被視為安全的腳本（因為它來自合法公司并且不包含任何已知漏洞）可能會突然成為安全責任。如果我們只相信審查，我們就會盲目相信這個腳本，完全無視它對我們網站的實際作用。說明這一點的完美例子是Copay 事件一個看似合法的庫被攻擊者秘密接管，攻擊者進行了包含惡意代碼的更新，最終進入加密錢包的生產版本并竊取了一些用戶的加密貨幣。

這種方法的另一個關鍵問題是平均網站包含 35 個不同的第三方組件。鑒于 Web 供應鏈如何與其最薄弱的環節一樣安全，強大的審查策略將需要檢查這些腳本中的每一個——這是一項極其復雜的任務。

最后，腳本審查過程本身并非沒有缺陷。雖然掃描漏洞是一種很好的安全做法，但它不會分析每一行代碼來尋找潛在的惡意行為。一個沒有已知漏洞的腳本仍然可能是危險的，例如，如果它試圖訪問敏感的用戶數據。

獲得完全的可見性和控制

因此，如果僅僅腳本審查不是網絡供應鏈安全的最終答案，那什么才是呢？這個問題的簡短答案是深度安全。

正如我們所見，腳本審查并沒有解決合法腳本如何突然改變其行為的問題。因此，深入方法的下一步是實時了解每個腳本在網站上的行為方式。這種可見性使公司能夠立即檢測到任何可疑行為，例如已知腳本突然開始篡改付款表格（Magecart 網頁瀏覽攻擊）或試圖將數據發送到未知域（數據泄漏）。

考慮到 Magecart web skimming 攻擊在被檢測到之前平均保持活躍 22 天，這種實時可見性可以極大地改善事件響應并遏制數據泄漏。

盡管如此，可見性只是深度安全方法所需響應的一半。另一半來自對每個腳本行為的完全控制。有效控制意味著能夠實時限制特定的允許或不允許的行為，以便立即阻止任何惡意活動的企圖（例如泄露用戶數據、在網站頂部顯示彈出窗口），從而阻止攻擊。

為了達到這種控制水平，公司需要尋找允許建立強大而靈活的規則來阻止客戶端所有惡意活動的解決方案。此外，這些解決方案必須確保每個腳本的正常功能都不會受到影響，從而使用戶體驗不受影響。

毫無疑問，公司要完全控制其網絡供應鏈還有很長的路要走。因此，這是邁出第一步的方法：請求一份免費的網站庫存報告，并全面了解您網站的腳本及其特定行為。