osquery的当前痛点是什么？- Trail of Bits博客

您正在阅读我们关于osquery的四部分系列文章的第二篇。阅读第一篇以了解该工具的当前使用情况、其在企业安全团队中日益受欢迎的原因，以及它与商业替代品的比较。

osquery显示出彻底改变端点监控市场的巨大潜力。（例如，它通过Windows可执行代码签名验证大大简化了签名恶意软件的检测。）然而，我们为本系列采访的五家主要科技公司的团队和osquery开发人员表示，这款开源工具仍有改进空间。

其中一些担忧涉及真正的限制。然而，我们也听到一些潜在用户和行业竞争对手最近的抱怨，这些抱怨与osquery的实际缺点不符。

与许多快速改进的开源项目一样，文档更新滞后于快速开发进度可能是这些误解的原因。因此，在深入探讨osquery社区接下来应该解决哪些真正的痛点之前，让我们先澄清一些当前关于osquery限制的误解。

osquery的神话式限制

“osquery不支持容器”

哦，但它支持！像Uptycs这样的团队在过去一年中为这一备受要求的功能投入了大量开发支持。目前，osquery可以在管理主机层执行容器内省（更高效），也可以在每个容器中操作（更细粒度），而不会占用大量CPU。

“osquery无法实时操作”

osquery处理macOS和Linux的文件完整性和进程审计。它还可以在选定的操作系统中监控用户访问、硬件事件和套接字事件。它通过与审计内核API的交互来执行这些任务。与其他基于拉取的查询不同，这些监控服务实时创建基于事件的日志，并确保osquery不会错过查询之间的重要事件。这些功能对于osquery在事件检测中的能力至关重要。

“osquery开销高”

当正确部署和管理时，osquery是一种轻量级解决方案。正如我们将在后文提到的，性能问题的主要原因是配置错误：调度失控查询、在高流量文件路径上执行基于事件的查询，或在资源受限的环境中运行osquery而未实施CPU控制。事实上，实施了如Cgroups等保护措施的受访者对osquery的性能如此有信心，以至于他们在每个端点（包括生产服务器）上部署了该工具。

osquery的当前限制；事实

用户支持需求超过供应

对于一个开源项目，osquery提供了大量用户支持；一个网站、一个活跃的Slack频道、广泛的文档和许多博客（比如这个！）。也就是说，社区可以做得更好。

文档更新未能跟上项目功能更新列表的增长速度，使用户 unaware of new functionality or confused about how to use it.

困惑的用户涌入osquery Slack频道提出类似问题。专家们试图帮助这些个人，而不是创建FAQ、编写全面的查询包和制作教程。

用户测试功能完整性

Facebook在彻底审查新代码和就如何最佳构建新功能进行富有成效的辩论方面做得非常出色。然而，对新功能效能的监督不足。到目前为止，这一直是用户的工作，他们向Slack频道或GitHub仓库报告边缘案例和意外行为。

这个问题的一个最近例子：开发人员和用户在osquery的文件完整性监控中看到了假阴性。审计后端包含多个导致不准确日志的错误。自2015年首次启用FIM以来，这一问题一直未被检查。幸运的是，我们自己的Alessandro Gario正在实施修复。

扩展问题

osquery的这一关键组件一直给用户带来问题。问题源于开发过程中支持不足。osquery当前的SDK仅提供与osquery集成所需的最低要求。文档和API也有限。由于这些因素，许多扩展构建或维护不佳，因此引入了不可靠的结果。

幸运的是，社区已开始解决这些问题。Kolide的osquery-go为开发人员提供了一个丰富的SDK，用于用Go创建osquery扩展。上周，我们解释了如何为osquery编写扩展。我们还发布了一个我们自己维护良好的osquery扩展仓库，用户可以从那里拉取（目前只有一个，但很快会有更多！）。我们打算帮助社区导航扩展构建过程，并创建一个可靠的更新扩展来源。

超出Linux和macOS的有限平台支持

用户渴望osquery支持更多平台并在所有端点上提供更好的内省。osquery当前仅限于端点的子集，在用户的监控能力中留下漏洞。此外，他们指出一些受支持的平台缺乏重要功能。

例如，macOS和Linux平台可以收集关于各种事件类型的可用实时数据。osquery for Windows中的实时数据仅限于Windows事件日志，该日志仅暴露难以解析的系统数据流。我们采访的用户中没有人在其部署中成功实施或解析这些日志。

来自Teddy Reed和Mitchell Grenier在2017年LISA会议上的osquery演示

可读的实时监控支撑了osquery的事件检测能力。虽然计划查询可能错过查询之间的系统事件，但基于事件的实时监控不太容易出现假阴性。Windows端口中缺少此功能大大降低了osquery对于在其车队中运行Windows机器的用户的事件检测效用。

失控查询和指导

受访者对其缺乏对不良查询的保护措施保留了一些最严厉的批评，特别是那些意外拉取过多数据的查询。有时，这些失控查询对更大的车队造成重大问题，如端点系统性能下降和内存堵塞。此外，格式错误的查询可能淹没数据日志并覆盖收集的其他数据，导致其他事件未被检测到。

osquery的看门狗功能确实通过杀死任何消耗过多CPU或内存的进程来防止一些性能问题。然而，这是在未考虑当时运行内容的情况下完成的。格式良好的基于审计的查询经常超过默认配额，不必要地杀死进程。因此，用户关闭了该功能以避免丢失基本数据。更好的解决方案是理解用户查询的规模并要求确认。

用户还希望更智能的查询。一位受访者希望获得关于不同类型系统数据的正确查询间隔的指导。他还希望节省因不同查询包中数据重叠而浪费的存储空间。虽然问题相对较小，但如果osquery能够去重这些数据，将会很有帮助。

大规模调试/诊断不足

用户在与osquery的大规模部署作斗争，主要是因为难以在其车队中调试和诊断查询问题。一家公司报告称，大约15%的查询节点因未知原因持续处于挂起状态。另一家公司报告称，某些端点偶尔会“从互联网上掉线”而没有任何明显原因。虽然用户可以使用详细设置重新启动osquery以打印关于每个执行操作的信息，但此选项主要是开发人员的工具，并不用户友好。

部署和维护问题

每家实施osquery的公司都以不同的方式应对这一持续斗争。我们在之前的文章中详细介绍了他们用于管理此问题的各种工具和技术。尽管支持和文档有所改进，问题仍然存在。一位用户报告在员工为管理员的端点上实施osquery版本更新时持续遇到麻烦。

结论

在阅读了所有这些痛点之后，您可能想知道为什么osquery今年赢得了多个产品奖项，以及为什么超过1,100名用户参与了开发社区的Slack频道和GitHub仓库。您可能想知道为什么我们为本系列调查的五家顶级科技公司团队报告称，他们比商业车队管理工具更喜欢osquery。

这很简单。该工具吸引了一个充满活力的开发社区，投资于其成功。每一项新发展都使osquery更接近与竞争对手完全集成且价格更高的安全套件的等效组件功能对等。随着用户委托像Trail of Bits这样的公司进行这些改进，整个社区都受益。

这将是本系列第三篇文章的主题：osquery的开发请求。如果您今天使用osquery并有请求想添加到我们的研究中，请告诉我们！我们很乐意听取您的意见。

您与osquery的经验与本文中提到的痛点相比如何？您是否有其他投诉或问题希望在未来版本中解决？告诉我们！帮助我们引领改进osquery的开发和实施。

如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

页面内容 osquery的神话式限制 “osquery不支持容器” “osquery无法实时操作” “osquery开销高” osquery的当前限制；事实 用户支持需求超过供应 用户测试功能完整性 扩展问题 超出Linux和macOS的有限平台支持 失控查询和指导 大规模调试/诊断不足 部署和维护问题 结论 最近文章 构建安全消息传递很难：对Bitchat安全辩论的细致看法 用Deptective调查您的依赖项 系好安全带，Buttercup，AIxCC的评分回合正在进行中！ 使您的智能合约超越私钥风险 Go解析器中意外的安全隐患 © 2025 Trail of Bits。 使用Hugo和Mainroad主题生成。