当有新软件包可用时，我们应该如何自动重建不可变的基础结构？

#1 楼

采用不可变基础架构模式的一部分是将您的系统分解为可管理的小片段，这些片段可以非常快速地通过CI / CD管道移动，这意味着可以快速且可控地完成OS补丁程序。我经常看到客户最终会在基础设施几乎是不可变的半途而废。

但是，有几种方法已用于大规模的云架构部署中，通常我会实现更多作为深度防御策略的一部分，不只是一个而已：


安全信息和事件管理（SIEM）：这些产品（例如LogRhythm安全智能平台和更多通用产品，例如ElasticStack）采用来自操作系统的提要，其中包括频繁检查更新的输出。这里的技巧是快速自动获取有关修补程序的信息，以告知有关何时将其修补到管道中的决策。
漏洞管理系统比SIEM更适合于定制，因为它们仅关注整个系统中的漏洞因此可能会发现与作为部署到系统的软件的一部分而安装但未由操作系统管理的库有关的问题。这可能会突出显示尚无补丁的漏洞（但...希望如此）。
依赖关系检查工具构成了管道的一部分，可以配置为如果签入添加漏洞会使构建失败，如果自上次签入以来，该工具已添加了新漏洞。

#2 楼

您可以使用AWS Inspector进行漏洞扫描，并查找CVE漏洞。 Inspector具有CloudWatch指标，可以在发现结果时采取措施。确定需要更新WHICH软件包将很棘手，但是您可以只更新所有内容。您不必使用Inspector，您可以使用的任何漏洞扫描工具都可以使用。漏洞扫描通常是最佳做法。

另一个想法是设置一个cron作业，该作业可以进行apt-get更新和＆apt-get升级–dry-run> stuff-that-should-be-updated.txt文件，并解析待更新的软件包列表，并将其反馈到您的构建过程中。

#3 楼

这种方法看起来可以通过Chef审核解决您的目的，但是它有它自己的问题。 br />自定义解决方案-
如果要使用合规性策略（例如CIS，HIPPA），请创建一个作业，该作业将在运行的程序包映像上运行审核解析器，并在出现不投诉状态时通知更新任务。
以上策略可免费使用OVAL解析器和OVAL定义。对于自定义aduit策略，您可以编写自己的解析器并审核图像。