在當今競爭日益激烈的業務環境中，軟體團隊承受著盡快交付全新或更新代碼，以及最具創新性服務的壓力。同時，基礎架構和應用程式的複雜攻擊興起使得追蹤漏洞並儘快緩解漏洞至關重要，卻是十分困難與耗時。商業支援例如 NGINX Plus 訂閱服務可減輕維運負擔，使應用團隊可以專注於其主要任務—更快地交付代碼—同時使組織免受安全漏洞的侵擾。
世界各地數以百萬計的組織使用基於開放原始碼開發的NGINX來為其網站和應用交付基礎架構提供支援。雖然企業對NGINX的依賴程度非常高，但令人感到驚訝的是，許多企業承認並未認真考慮運行具有安全漏洞修復程序的最新版本之重要性—例如常見漏洞和暴露（CVE）—但這在當今的Internet上變得已如此普遍。
當然，僅考慮安全威脅防範是不夠的—企業需要定義明確的流程來追蹤漏洞，並在可取得後立即實施保護措施。就像使用開源軟體一樣，很容易低估由自己包攬全部工作會耗費多少時間和精力。的確，快速而輕鬆地保護自己免受安全威脅是商業支援軟體經常被忽視的優點。在此文中探討了保護開源軟體的挑戰，並說明了商業支援版軟體如何更快更輕鬆地緩解CVE和其他安全威脅。
擬定開源漏洞處理政策
儘管所有開發人員都以為他們編寫了完美的代碼，但沒有任何軟體可以避免錯誤。開發人員希望在開發過程中能將大部分的漏洞檢測出來並加以修復，然而仍然避免不了最糟的情況，這些漏洞未被檢測出，並且被惡意用戶加以利用。尤其是當開發人員從多種開源工具、編程語言和平台構建應用時，錯誤的後果會更加複雜。
開發人員需要分別檢查每個組件，並且為其驗證為無錯誤的。在開源軟體中發現錯誤時，重要的是要有一個定義的策略來驗證，測試和修復它們。而開源軟體政策至少應包括三個過程：定期審查和測試、跟蹤漏洞並在內部報告、即時修復漏洞。
漏洞披露與補救
發現安全漏洞後，須按照標準的事件序列進行披露。第一步是向軟體的作者或供應商提交詳細報告。報告者和作者共同決定如何以及何時公開此漏洞，通常是常見漏洞和披露資料庫中記錄的形式。按照慣例，作者有90天的時間在公開之前解決問題，但有可能協商更多的時間。
作為開放源代碼軟體的提供者和商業軟體的供應商，NGINX積極參與報告和補救過程，以解決影響商業產品和免費開源產品的CVE和其他漏洞。NGINX Plus是基於開源版NGINX，並且致力於為商業版客戶提供企業級支援和流程標準。這些標準包括與客戶的服務水準協議（SLA），這些協議規定了針對核心軟體，相關軟體模組和受支援的模組的修補程序必須遵循的錯誤修復和測試過程。SLA幫助客戶實現法規遵循，從而最大程度地降低遭受漏洞利用的風險。
NGINX開源的另一個缺點是，許多第三方技術都將其改寫並嵌入到其產品中。這些技術的提供者擁有自己的發現和修補軟體漏洞的過程。正如後續討論的那樣，在為開源版NGINX發布的修補程序與為第三方技術發布相應的修補程序之間，有時會有相當大的時間差。
免受漏洞侵害的五個方法
前文提到，商業支援版軟體經常被忽視的好處是，它如何使客戶更快更輕鬆地保護自己免受漏洞侵害。處理開源軟體中的漏洞可能比許多人認為的要耗時得多，因此成本也更高。下面以NGINX Plus為例討論讓訂戶可以更快、更輕鬆地解決漏洞的五種特定方法。
主動通知用戶有關修補的信息
開源NGINX和NGINX Plus的安全修補發布時，會透過電子郵件主動通知NGINX Plus客戶。此外還建置了一個部落格，公告了大多數修補程序的發布情形。但由於NGINX開源用戶無法被直接聯繫上，必須自行密切注意CVE和其他漏洞資料庫以及定期檢視該部落格。
即時協助受攻擊用戶
當F5客戶（包括NGINX Plus訂戶）成為攻擊的受害者時，F5安全事件回應團隊（SIRT）將會提供即時幫助。SIRT可以快速有效地緩解攻擊並讓用戶恢復正常運行。即使在攻擊停止後，他們仍將與用戶合作檢測事件以減少對企業組織的整體危害，而且可以了解、預測和阻止未來的威脅。
強化應用程式保護
NGINX App Protect是一種企業級網頁應用程式防火牆（WAF），具有F5的20年安全經驗，並已作為NGINX Plus動態模組進行了部署。它藉由特定於應用程序的保護來增強第7層安全性，以防止後端應用伺服器中更多的CVE，可使訂戶強化應用安全。
支援基於JWT和OpenID Connect身份驗證
即使沒有需要修補程序的特定漏洞，複雜的身份驗證協議也有助於防止駭客攻擊企業用戶的應用和基礎架構。除了NGINX開源中可用的方法之外，NGINX Plus還支援基於JSON Web令牌（JWT）和OpenID Connect的身份驗證，適用於Web和API客戶端。
訂戶立即獲得修補
如報告漏洞中所述，當漏洞影響NGINX軟體時，通常會在將其作為CVE公開披露之前得到通知。預先警告使原廠能夠在公開披露之前準備修補，並且通常在披露當天（或在某些情況下，在幾天之內）發布修補。該修補程序以修補二進制檔案的形式提供給商業支援版客戶。開源用戶可使用更正的源代碼或被支援的作業系統的修補二進制檔案，但是如上所述，原廠無法直接通知他們。
利用或嵌入NGINX開源程序的第三方技術可能不會在漏洞披露之前就意識到該漏洞。即使他們這樣做，過往的經驗是他們的修補程式可能比NGINX修補程式滯後幾個月的時間。這是可以理解的，尤其是對於通常由志願者維護的開源軟體而言，但是在該漏洞公開暴露並受到駭客利用之後，它會使企業的基礎架構不受保護。
例如，在2018年秋季發現了兩個有關HTTP/2漏洞的CVE（CVE-2018-16843和CVE-2018-16844）。作為回應，原廠對NGINX Plus R16和NGINX開源1.15.6應用了安全修補。流行的OpenResty軟體建立在NGINX開源之上，它於2019年3月3日首次發布了包含這些修補的發行候選版本—距離NGINX修補整整四個月。然後，基於OpenResty構建的解決方案通常需要花費更長的時間來修補其代碼庫。
有時，漏洞的狀態不清楚，或者軟體提供商不認為有必要安裝修補，即使該修補構成了潛在的攻擊媒介也是如此。舉例來說，2020年，最廣泛使用的開源WAF軟體ModSecurity發生了這種情況。OWASP CRS團隊發現，ModSecurity v3對正則表達式進行全局匹配的方式可能導致團隊認為這是拒絕服務漏洞（CVE-2020-15598）。Trustwave自己維護ModSecurity，但該組織對這種行為被認定是安全問題表示懷疑，並拒絕發布修補。
該WAF是NGINX再加上動態模組建立的，NGINX團隊認為CVE-2020-15598中描述的行為具有導致DoS漏洞的潛在可能，並於2020年9月發布修補。正如在發布修補的部落格中的解釋，開源ModSecurity的用戶（包括NGINX開放源代碼用戶）必須自行決定是應用OWASP CRS團隊的修補，還是堅持使用Trustwave未修補的軟體並實施其建議的緩解措施。
作者：
F5台灣區資深技術顧問 陳廣融