全世界数以百万计的企业与组织信任NGINX并通过NGINX软件承载他们的网站并将 NGINX 应用交付基础架构，这让我们倍感自豪。鉴于用户对 NGINX 的依赖程度，我们十分惊讶的发现很多用户并没有意识到运行最新版本软件（包含安全漏洞，例如 CVE 漏洞的修复）的重要性，而这种情况在如今的互联网上十分普遍。
当然，仅仅考虑防范安全威胁还不够，您还需要实施完善的流程来跟踪漏洞并在漏洞出现后立即实施防护措施。如果您必须自行完成这些工作（就像使用开源软件），您会很容易低估所需要的时间和精力。NGINX Plus 等商业支持软件具有快速、轻松防范安全威胁的优势，但却经常被大家忽视。
在此文中，我们探讨了开源软件的防护挑战，并阐述了 NGINX Plus 如何帮助更快速、轻松地缓解 CVE 及其他安全威胁。
处理开源软件中的漏洞
尽管所有开发人员都认为自己编写的代码完美无暇，但任何软件都会存在漏洞。开发人员希望大多数漏洞都能通过严格的质量合规流程在开发过程中检测出来，只留少数漏洞在应用生命周期内的正常使用中慢慢发现。然而，最糟糕的情况是，漏洞常常是被恶意用户首先发现。
当您通过多个开源工具、编程语言和平台构建应用栈时，漏洞的危害会大大加剧。您需要分别查看每个组件，以确保它们不包含漏洞。当在开源软件中发现漏洞时，明确的漏洞验证、测试和修复（如果可能）策略很重要。
您的开源软件策略至少需要包括三个流程：
- 定期审查和测试
- 跟踪漏洞并在内部报告
- 及时修复漏洞
报告漏洞
当发现安全漏洞时，需要有一个标准的事件流程对其进行披露。第一步是向软件作者或厂商提交一份详细的报告。报告者和作者共同决定如何以及何时披露漏洞，通常以记录在通用漏洞披露（CVE）数据库的形式进行披露。按照惯例，作者在漏洞披露之前有 90 天的缓冲期，并且还可以协商更长时间。
NGINX 和 CVE
作为开源软件提供商和商业软件厂商，NGINX 积极参与 CVE 及和其他漏洞的报告和修复工作，以免影响 NGINX 开源版 和 NGINX Plus及其他商业产品（在撰写本文时包括 NGINX 控制器、NGINX App Protect和NGINX Ingress 控制器），以及免费的开源产品，其中包括 NGINX Service Mesh, NGINX Unit和NGINX Amplify。
NGINX开源版用户也受益于我们积极的漏洞修复策略，因为 NGINX Plus 是基于开源版本构建，同时我们致力于为 NGINX Plus 客户提供企业级支持和流程标准。这些标准包括与客户签订服务水平协议（SLA），规定在对核心软件、依赖项和受支持模块进行漏洞修复时必须遵守的漏洞修复和测试程序。SLA 可帮助客户遵守法规，并最大程度地减少漏洞被利用的风险。
NGINX 开源版的另一个麻烦是，许多第三方技术都利用它并将其嵌入自己的产品中。这些技术的提供商拥有自己的软件漏洞披露和修复流程。正如我们将在下节所讨论的，NGINX 开源版补丁与第三方技术的相应补丁在发布时间上有时会间隔很久。
NGINX Plus 如何帮助用户防范漏洞
我们在前言中提到了 NGINX Plus 经常被忽视的一个好处是，它能够帮助我们的客户更快速、轻松地防范安全漏洞。处理开源软件中的漏洞可能比许多人想象的更耗时，因此也更耗成本。
接下来，我们将介绍如何通过五种不同方法帮助 NGINX Plus 用户更快速、轻松地修复漏洞。
NGINX 主动通知 NGINX Plus 用户补丁信息
我们在发布 NGINX 开源版和 NGINX Plus 的安全补丁后，会通过电子邮件主动通知 NGINX Plus 客户。我们会发布一个博客，宣布补丁已发布，但无法直接联系 NGINX 开源版用户。这就需要用户定期查看CVE等漏洞库或者查看我们的博客。
F5 SIRT 为受到攻击的 NGINX Plus 用户提供实时帮助
F5 客户（包括 NGINX Plus 用户）受到攻击时，F5 安全事件响应团队（SIRT）将立即为他们提供实时帮助。SIRT 将快速、有效地缓解攻击，并帮助您尽快恢复正常运行。即使攻击停止，他们也会继续在您左右，他们“会基于报告的事件未雨绸缪，以降低对贵公司的总体影响，同时了解、预测和阻止未来威胁”。
NGINX App Protect 助力增强应用防护
NGINX App Protect 是一款凝聚 F5 20 年安全经验的企业级应用防火墙（WAF），作为动态模块部署在 NGINX Plus 中。它通过应用特定防护来增强 NGINX Plus 第 7 层安全性，能够抵御后端应用服务器中的更多 CVE 漏洞。NGINX 和 F5 会负责提供与特定攻击活动相关的签名。借助 NGINX App Protect，NGINX Plus 用户无需再亲自建立签名和处理多个误报。
NGINX Plus 支持基于 JWT 和 OpenID Connect 的认证
即使没有需要修复的特定漏洞，复杂的身份验证协议也有助于防止攻击者访问您的应用和基础架构。除了 NGINX 开源版提供的方法之外，NGINX Plus 还可为 web 以及 API 客户端提供基于 JSON Web 令牌（JWT）和OpenID Connect的身份验证。
NGINX Plus 用户可立即获得补丁
如“报告漏洞”部分所述，当漏洞影响 NGINX 软件时，我们通常会在其作为 CVE 被公开之前得到通知。这种预先警告让我们能够在漏洞公开披露之前准备修复程序，我们通常会在披露当天（有时会在几天内）发布补丁。修复程序以修复二进制文件的形式提供给 NGINX Plus 客户；以更正源码和受支持操作系统修复二进制文件的形式提供给 NGINX 开源版用户，但如上所述，我们无法在修复程序发布后直接通知他们。
利用或嵌入 NGINX 开源版的第三方技术在漏洞披露前可能不会知道该漏洞。即使他们知道，根据我们的经验，他们的补丁发布时间也可能会比 NGINX 晚几个月。这种情况可以理解，特别是对于通常由志愿者维护的开源软件，但这会导致您的基础架构存在安全风险，并且在漏洞公开披露后可能遭到黑客攻击。
例如，2018 年秋季发现了两个关于 HTTP/2 漏洞的 CVE（CVE-2018-16843 和 CVE-2018-16844）。作为响应，我们对NGINX Plus R16和 NGINX 开源版 1.15.6 进行了修复，而热门软件 OpenResty（基于 NGINX 开源版提供 NGINX Plus 中的某些功能）到 2019 年 3 月 3 日才发布了一个包含这些补丁的候选版本，与 NGINX 的补丁发布时间相差了整整 4 个月。基于 OpenResty 构建的解决方案通常还需要更长时间来修复其代码库。
有时，我们并不清楚漏洞的状态，或者软件提供商认为无需修复，即使漏洞构成了潜在的攻击向量。2020 年，应用最广泛的开源 WAF 软件 ModSecurity 就曾发生过这种情况。OWASP ModSecurity Core Rule Set（CRS）维护团队发现，ModSecurity v3 对正则表达式进行全局匹配的方式可能导致出现 OWASP CRS 团队认为的拒绝服务漏洞 (CVE-2020-15598)。ModSecurity 的维护企业 Trustwave 认为该行为属于安全问题，并拒绝发布补丁程序。
NGINX ModSecurity WAF 是基于 ModSecurity v3 构建的 NGINX Plus 动态模块。NGINX 团队认为，CVE-2020-15598中描述的行为极有可能导致 DoS 漏洞，因此我们在 2020 年 9 月发布了补丁。正如我们在宣布补丁可用的博客中所描述的，开源 ModSecurity 用户（包括 NGINX 开源版用户）必须自行决定是否应用 OWASP CRS 团队发布的补丁，还是继续使用 Trustwave 的未修复软件，并考虑实施 Trustwave 提出的缓解变更。
结语
在当今竞争日益激烈的商业环境中，软件团队面临着巨大压力，他们必须尽快交付新的更新的代码，以提供最具创新性的服务。与此同时，针对基础架构和应用的复杂攻击的兴起使得漏洞跟踪和快速缓解变得至关重要—这是一件枯燥且耗时的工作。
NGINX Plus 订阅减轻了应用团队的负担，使其能够专注于主要任务，即更快地交付代码，同时让组织远离安全漏洞之扰。
如欲试用 NGINX Plus 的全部高级特性，请立即下载30 天免费试用版或与我们联系以讨论您的用例。
