應用安全的工作有時候感覺就像在“和以往一樣的工作”與“該死的一天來了”之間反復橫跳。而當數字化轉型在每個部門都在加速進行，遠遠超過安全控制的節奏的時候，平衡就更加困難了。

打斷這個加速化進程的問題點基本都發生在網站開發和安全環境。二十年前，一個“典型”的網站都是為了發布信息的靜態頁面。而現在，則是由一個動態的網站應用處理極其敏感的數據，并執行關鍵操作。

[[410641]]

敏感信息持續通過幾乎每個網站，從而讓攻擊者有了竊取并販賣這些私人信息的完美機會。事實上，這樣的攻擊已經相當成功了，而被泄漏數量的增長速度也在持續攀升。最近的數據顯示，2020年第一季度泄露的記錄相比2019年第一季度高出了273%。

現在，那些在應用安全工作的人已經知道傳統安全系統(比如像WAF這種服務器端和網絡安全的產品)無法防范針對網站的數據流出攻擊。攻擊者會利用客戶端側的安全盲點，將惡意代碼注入公司的網站，而不需要先成功攻擊他們的第一方服務器，這就引出“定時炸彈”——網站供應鏈。

代碼相關性的收益和風險

現在典型的JavaScript開發流程總是依賴于開源組件，來加速發展。這意味著公司在他們的網站上會使用幾百個外部源代碼。這個情況下，公司對代碼幾乎完全沒有管控能力，最終絕大部分會選擇信任他們使用的代碼模組可靠且安全。但問題是，這些模組可能也會依賴于第三方代碼，導致代碼相關性變得更為復雜。

代碼的相關性越多，攻擊面也就越大，也就使得攻擊者更有機會控制相關性中的一部分，并對網站頁面進行惡意代碼注入。

如果這個網站供應鏈攻擊看上去簡直在復現SolarWinds事件，那是因為SolarWinds本身就是一個展示供應鏈攻擊如何能達成爆炸效果的完美例子。

最近，攻擊者在PHP Git的官方代碼庫里植入了遠程執行后門。不過，這個惡意代碼在本地代碼檢查中被發現，因此它沒有進入官方的更新包中。然而，它顯現出網站供應鏈當中的另一個安全缺陷：如果惡意代碼被隱藏得更好，它們能否進入公開發布的更新包中?這種事情以前就發生過，比如Copay事件中，惡意代碼影響了數個版本的產品(加密貨幣錢包)，并且竊取了用戶數據。

另一個事件能讓我們意識到，事件更加糟糕。安全研究人員Alex Birsan通過利用相關性混淆的設計漏洞，成功攻擊了35個科技公司，包括微軟、蘋果、PayPal等。盡管說Alex的行為只是出于道德安全研究的目的，但是攻擊者們很快復制了這個攻擊方式，并試圖攻擊其他還沒開始防御的公司。

這些例子不過是冰山的上層。網站供應鏈廣而且深，平均每個網站應用包含超過1,000個外部源代碼組件。而且，最近的研究顯示，安裝其中的一個代碼包意味著間接信任79個第三方代碼包和39個維護人員——我們可以猜測一下現代網站應用的攻擊面到底有多大。

減少潛在危險

那么，有那么多不確定的組件，同時越來越多的人認為網站供應鏈會是一個必然發生的災難，能做些什么?

這個問題的答案可能是使用深度防御，在服務器端和網絡安全管控之上，進一步部署更好的供應商管理能力，并加上一層客戶端防御。用新的協議審查和管理第三方供應商在越來越重要，盡管說審查數百個第三方部件相當困難。另外，審查只能給出某個時間點上的代碼狀況，卻無法識別突然被感染的原正常代碼。因此，需要在客戶端運行時額外加一層安全管控，檢測和控制可疑的代碼行為。在這個等級實現管控，能產生消耗的是數月，還是是實時，發現并解決因網站供應鏈產生的數據泄露。

這些都是組織能夠采取的減少網站供應鏈暴露的措施。至少，希望組織和機構別到最后一秒才開始進行這些操作。