假设我们nginx坐在 DMZ 中提供静态内容的设置，通过防火墙转发 (REST/WS) 请求到tomcat在其他应用程序也在运行的服务器上运行：
YOU <> [FW:443] <> (NGINX) <> [FW:8443] <> (TOMCAT)
( APP1 )
( APP2 )
( DB )
在修补 CVE/易受攻击的依赖项方面，我可以只关注 nginx 和 tomcat 应用程序，还是必须确保所有其他应用程序尽可能“无 CVE”。
我相信这与这个关于公共防火墙后面的应用程序是否需要修补的问题不同。
根据漏洞是否可远程利用[至少在理论上]，优先修复漏洞。优先考虑“前端”组件不是正确的方法，因为防火墙后面的组件可能存在严重漏洞，可以远程利用这些漏洞。例如，您在防火墙后面使用的 XML 解析器可能存在已知的 XXE 问题。防火墙可能无法阻止它，除非它是 WAF 并且有特定的规则来阻止它。根据您当前的优先级，您将忽略此漏洞，这将导致应用程序可远程利用。
在修补 CVE/易受攻击的依赖项方面，我可以只关注 nginx 和 tomcat 应用程序，还是必须确保所有其他应用程序尽可能“无 CVE”。
您必须确保所有应用程序不仅“无 CVE”，而且具有与其相关的合理的基于安全/相关的配置。
请考虑托管在 tomcat-nginx 设置上的 Web 应用程序易受攻击的风险。如果应用程序易受攻击，那么攻击者可能会以与运行应用程序相同权限的用户身份获得机器。如果其他应用程序是可利用的或配置是周的，并且该托管应用程序的用户可以访问它，它可以用于控制隐身因素以制造 APT（高级持久性威胁）或提升权限。修复优先级是@haxx 值得注意的一点。我要求您考虑再次进行全面风险评估。
应该修补堆栈的所有方面。
即使 App1、App2 和 DB 没有直接访问 Internet 的权限，也有可能间接攻击它们。例如，如果 App1 用于身份验证并且它有一个用于定时攻击的 CVE……在它前面有 Tomcat、2x FW 和 Nginx 并不会真正减轻定时攻击。
或者，我可能能够毫无问题地传递 Tomcat 处理的用户数据，但是您的其他应用程序之一是用 nodejs 或 python 编写的，并且我发送的字符串包含可能会做一些讨厌的事情的转义序列。
您还应该考虑您的风险状况。例如，如果您容易受到定时攻击，外部实体可能能够暴力破解有效用户名列表。如果这是一个狂热的维基，这可能是微不足道的……另一方面，如果这是一个 AshleyMadison 的克隆，那么你的用户列表被泄露可能是一个非常非常大的问题。
TLDR：是的，您应该注意所有相关的 CVE，并尽可能修补所有可能的问题，并尝试根据您的风险状况减轻无法修补的 CVE。