高危漏洞并不意味著要最先修復
安全團隊每天都會被越來越多的漏洞所淹沒，但通過改變漏洞的優先級，可以極大地減少修補工作量。
大多數企業都會關注通用漏洞評分系統(CVSS)框架中對缺陷的評分，評分范圍從0到10，并根據漏洞的特點，分為低、中、高和極危。一般而言，企業會從被視為“極危”的漏洞開始補救工作，然后再高中低逐級往下解決。
但現實情況是，對于許多企業來說，大多數漏洞都不會對它們構成威脅。安全公司Rezilion在5月發布的一項研究報告顯示，組織中約85%的漏洞并沒有加載到內存，也就意味著不能夠真正被利用。（Rezilion成立于2018年，專注方向為自動化的攻擊面管理）
在這項研究中，Rezilion的研究人員檢查了Docker Hub上20種流行的容器鏡像，這些鏡像總共被下載和部署了數十億次，包括MariaDB、WordPress、Memcached、MongoDB、Nginx和MySQL。此外，他們還研究了來自AWS、Azure和GCP的基本操作系統鏡像，以確定有多少漏洞不適用，又有哪些漏洞構成了實際風險。
在Rezilion研究人員分析的21種容器鏡像中，有4347多個已知漏洞，但經測試后發現，只有平均15%的CVE漏洞曾加載到內存中并構成威脅。研究人員還在分析的12個基本操作系統鏡像中發現了6167個已知漏洞，其中約有20%加載到內存中。
因此報告得出結論，容器和主機中發現的所有漏洞，有85%從未加載到內存，因此不可利用。如果使用傳統的漏洞管理方法，人們將花費85%以上的時間和精力來修補對環境沒有實際風險的漏洞。
不僅如此，在實際的漏洞修補工作中，許多補丁是手動打上的，更為糟糕的是，有些漏洞的性質很難快速進入修補流程，時間長的可能需要幾個月，往往還需要系統停機。
一方面，組織在處理漏洞和補丁管理方面的資源和能力十分有限。另一方面漏洞發現和披露的數量逐年增加。因為只要人們編寫代碼，漏洞就會出現，修補工作就跟不上。因此，一個看上去比較合理化的建議是，首先處理實際加載到內存中的漏洞，如果再有額外的時間或資源再處理其他的漏洞。因為只有這些能夠進入到內存中的漏洞，才是真正重要的，真正構成威脅的漏洞。
但問題是，那些從未加載到內存的漏洞真得沒有風險嗎？誰能保證這些漏洞以后不會加載到內存？理論上而言，存在漏洞的軟件，即使沒有運行，仍然存在風險。因此，一個非常有效且簡便易行的方法就是，刪除那些執行指定任務時系統不需要的軟件。
方法論有了，但最大的問題在于，現實中的大多數組織缺乏對其所有信息資產的了解，也不知道哪些軟件程序的哪些部分會加載到內存中。所以，一切又回到了對企業資產環境的充分了解上。
“不清楚保護對象，何談保護？”——數世咨詢
不管怎樣，組織面臨的風險永遠存在，修補能力也永遠趕不上漏洞的增長。回歸到最佳實踐上，那就是合理利用現有的資源、工具和預算，將工作重點放在與自身更相關的漏洞上。
