您的云提供商托管了大量的映像，如果它们还算成功的话。没有法律责任保持图像修补/固定/rev 'd。我们的行业没有提供内在机制来提供一个良好直到日期的形象。发霉的云图像可能会中毒，把我吓坏了。没有两家操作系统厂商以完全相同的方式进行补丁/修复/修订控制。
我听过各种统计数据，声称排名前五的云提供商在一天中的任何特定时间都可能托管超过3亿张图像。这些图像都发霉了。有没有见过大型云托管公司在他们的产品上标注更新日期?我也不。
其中一些映像(和内部二进制文件)是容器或虚拟机。它们的生命周期可能以小时为单位，但也可能以天、周甚至年为单位。它们都不能保证是最新的补丁/修复/更新。在图像内部，正在运行的不同程度的二进制文件也处于类似的未知补丁级别。黑霉是有可能的。想想:你冰箱里感恩节剩饭剩菜的状况。
添加到运行实例及其操作系统和应用程序补丁级别的未知补丁级别:先天二进制文件，也是未知补丁级别。当然，开启自动更新是一个好的开始，但在确保实例、应用程序和二进制文件的级别之前，还不能确定。在你的图像中，大约有43000个发霉的二进制文件，哪一个正等着变成数字肉毒杆菌?
因为图像上没有工业保鲜日期，我们只能靠自己的设备。输入使用带内查询方法的通信基础设施，称为不同的数据总线/dbus、通信总线/cbus等。通信管道连接到映像、容器、VM等等。管道通常通过端口443连接，并使用许多类似ssh的工具之一与执行操作的守护进程/系统进程通信。在我当前的讨论中，它所做的一件重要的事情是执行查询，在有适当逻辑的地方，执行基于这些查询的操作。
这些通信总线工具使图像和二进制文件变得有趣。返回的傻笑是质量，比如二进制文件或conf文件的修订号，或者配置文件内容的grep，等等。将许多图像连接到一个内聚的系统中，这是网络服务器、数据库应用程序等的标准，在查询后，你会获得一个公平的(但不一定全面的)库存基础，表面上是图像及其组件的补丁/修复/rev级别。
少量的财富是通过内部查询工具创造的，比如puppet、chef等。这些总线可以查询车队(是的，这是另一个产品的名称，但我们将它作为一个聚合)，并呈现补丁/版本/修复级别，寻找偏差，或未知或WTFware的存在。
在网络管理软件、syslog工具和定期的直接库存查询之间，各种云应用程序和工作的状态应该是已知的，对吧?
问题是，使用这些平台在某种程度上是特定于操作系统的，需要IT管理员具备技能、工具和时间来评估返回数据的结果，以确保这些项在云使用的整个生命周期中都是安全的。这似乎是一项基本技能和工作，但有一个巨大的问题:不方便。
由于“非发明”问题，每个操作系统供应商(通常也控制补丁/修复/版本控制)执行这项工作的方式不同。在传统的数据处理中，有一些罕见的共同点来帮助呈现常见的信息，比如文件创建日期、二进制文件的MD5哈希码，以及与可执行文件、库、配置文件质量相关的其他元数据信息，甚至用类似证书的质量识别二进制/可执行头文件。
但没人会用同样的方式做两次。当我看到微软试图让设备驱动程序的编写者进入他们的免费程序，从而帮助防止糟糕的驱动程序混合破坏服务器和基于民用的系统时，我感到悲伤和好笑。Windows会带来巨大的警告——哦哦，我们真的不知道这是不是好东西——并会给IT黑带和老奶奶们带来无尽的困惑。
公司的商店分配方法的感觉现在在我们身上，表面上理想的地方得到一切为操作系统厂商。苹果想要带你去苹果商店，微软，VMware，这个列表每周都在增加——无论什么时候，只要有供应商能给你提供他们的销售设备或补丁/修复源，他们就会给你。
我唯一的愿望是有一种经过一致同意的元数据格式，它包含一种适用于Windows、MacOS、Linux、Free/NetBSD等操作系统的最新日期方法，这可能是一个行业的第一个——不是发明——在这里。