在规模上，最好不断审查您的自动化，但最重要的部分：自动化

对于 RHEL、CentOS、Fedora 等，有 yum-cron。如果您只需要关键补丁，您甚至可以指定 security-severity:Critical。

对于 Debian、Ubuntu 等，有类似概念的无人值守升级。

如果您构建应用程序或安装自定义应用程序，请确保您也被覆盖。此外，还有确保修补的基础设施。尽可能自动化。人们会争辩说这会破坏事情。这就是为什么我建议你尽可能地自动化——但不要太多以至于你破坏了事情。如果你只是自动安装关键的安全补丁，那么你就不太可能破坏东西。弄清楚如何至少自动化它。即使您有一项政策，在未经人工批准的情况下不直接自动化——自动收集所有信息，下载补丁，并拥有推送或拉取机制，一触即发。

OWASP 通过 Dependency Check 具有很多强大的集成功能——甚至通过这个项目为它提供了一个 Web 界面——https: //www.owasp.org/index.php/OWASP_Dependency_Track_Project

可以很容易地集成类似的概念来构建服务器和持续集成/持续部署项目。这些环境为这种自动化配备了强大的设备。许多商业解决方案也存在——很容易在网上找到它们。

我知道没有这样的服务可以适应所传达的需求，尽管我不确定是否有智慧可以创造一种在没有持续的消费者关注的情况下提供价值的服务。

我可以想到 4 组需要关注的信息源，如下所列。除非您的业务的具体情况需要关注 us-cert、bugtraq 或 cvedetails，否则我不会将它们包含在有用的资源列表中。

4套分别是：

• 操作系统
• 基础设施提供商
• 个别软件供应商
• 开发平台/库

一般规则是 - 在没有聚合的可配置源的情况下，需要注意的最重要的单个源是正在使用的软件和基础设施的提供者，无论是在操作环境中还是在开发环境中。对于那些，请同时关注任何特定的安全和发布公告列表以及他们的一般技术博客。Ubuntu 的博客是发布关于他们对 POODLE 的回应的新闻的地方（例如http://blog.canonical.com/2014/10/16/ubuntu-security-update-on-poodle-cve-2014-3566-and-sslv3-降级攻击/）。

操作系统是这个三明治中的一层。在操作系统之下，如果服务器是在云环境中虚拟化的，那么这条规则包括云提供商——AWS、谷歌、Digital Ocean 等。AWS 一般而言，每个主要服务都有博客——它们将传达与安全上下文相关的信息.

如果虚拟化或云平台也包含容器，那么上游容器提供商——Docker、linuxcontainers 等的博客、安全、发布公告值得关注。

操作系统之上是单独的应用程序。这些可能由操作系统提供商提供，但仍然是独立的新闻和信息来源，因为操作系统提供商的策展过滤器将排除与这些应用程序的功能和配置相关的重要上下文。

关注这些的重要性取决于它们在您的基础架构中的作用，它们的作用可以在两个方面进行分级 -

• 它们对潜在恶意流量来源的可见度
• 它们在保障您的生计方面有多重要

您可能有一个重要的数据库，该数据库本身并未公开暴露于潜在的恶意流量，但仍需要关注其发布、安全列表和技术博客，因为重要的架构和防御配置信息将在那里传达，而不会通过其他来源。

同样，您可能会运行 nginx 或 apache Web 服务器以及某种应用程序服务器。Ubuntu 当然会从这些项目的发布、安全公告和技术博客中收集和处理信息，但他们的策展过滤器将再次排除这些项目将直接通知其用户的配置和部署的特定问题。

作为一家 Web 开发商店，您的团队可能在一个或多个平台上工作——Node、Rails、Spring、React，无论是使用主要提供商以及在该生态系统中运行的库开发人员的平台版本，然后为你的客户。关注平台和您使用其工作的库提供商的公告和博客，并及时了解依赖关系，这一点很重要。这里有一些新服务专注于通过对开发平台和库的静态分析发现和管理漏洞，然后将这些信息集成到持续集成/交付工作流中——这些服务值得您的团队考虑。

一般规则再次是 - 如果您使用服务或应用程序作为操作基础架构中的依赖项，或者如果您在开发基础架构中使用应用程序或库，那么遵循这些特定上游提供商的公告处于当前状态行业成熟度对安全至关重要。

从上游打包和分发软件的下游提供商通常不会解决对安全敏感且上游软件提供商花费大量时间考虑的配置和部署用例。

最后，这是很多潜在的材料，这本身就是关于攻击面的重要一点。由于所有软件都包含漏洞，因此消耗和利用的软件越多，其攻击面就会变得越广。使用某些软件的功能而不关注其上游流是一种表外的技术债务形式。

希望这会有所帮助。

过去我采取了一些不同的方法。

鉴于 Linux 发行商正在积极监控上游资源的新版本，我从命令行使用包管理系统（在我的情况下是 yast，因为我正在运行 SuSe）来列出任何需要的更新。

我没有盲目相信这一点。相反，我对更新历史进行了抽样检查，比较了 CVE 发布和更新发布之间的延迟。平均差距在 3 天左右。但是，我确实承认，不能保证快速发布补丁，并且除了等待供应商的修复之外，通常还有其他可用的缓解措施（几家大型软件公司似乎不承认这一点）。

我不是 apt 的出口商，但我希望应该可以使用aptitude来识别所需的更新。