Semgrep 的核心 SAST 引擎是用 OCaml 编写的。出于许多优秀的技术和历史原因，我会留到其他时间再说。使用像 OCaml 这样（相对）生态系统小的语言的一个重要后果是，缺乏像可观察性这样的库，而可观察性对于在数十万个代码库上运行工业软件（例如 Semgrep）以及保持软件的可靠性和性能至关重要。我们大量使用了现有库，例如 OCaml OpenTelemetry 库，并且贡献并编写了一些我们自己的库。去年我在 FunOCaml 举办了一场研讨会，讲解我们如何使用和受益于可观察性，以及您如何在自己的 OCaml 程序中实现它。然而，在研讨会结束后，我有多个与会者来问我“持续分析怎么办？”我的回答是：“它还不存在”。好吧，7 个月后，我很高兴地宣布我们发布了 Pyro Caml 1.0.0，这是一个用于 OCaml 的持续分析器。什么是持续分析？在深入技术细节之前，我们必须先了解正常分析器和持续分析器之间的区别。分析是一种动态分析形式，测量程序的方面，例如时间复杂度、指令使用或代码中时间的花费位置。OCaml 有几个分析器，例如内置的 ocamlprof、magic-trace 或 olly，仅举几例。持续分析器的一个特点是，它不是由开发者直接运行的，而是在生产环境中持续运行，持续分析程序，并将数据报告回中心位置。对我们来说，这一差异极其重要。我们曾经依赖于前面提到的其他分析器，以及 prof 等更通用的分析器，但这仅仅满足了我们的部分需求。Semgrep 对代码进行静态分析，通常我们尽量避免让工程师轻易访问分析的用户代码。因此，如果我们无法获取源代码的本地副本在自己的机器上进行分析，持续分析就成为唯一的选择。此外，度量和跟踪只有在知道该去哪里查找时才能有效识别性能问题，而随着代码库的成熟，这种情况变得越来越少。我们必须在客户扫描代码时进行分析，否则我们注定要生活在黑暗中。持续分析器的要求 所以我们知道持续分析器是一个非常有用的工具，但 Semgrep 有一些额外的限制。 在 gVisor 下运行 我们是一家安全公司，因此我们希望保持安全，这意味着当我们扫描某人的代码时，我们使用 gVisor 沙箱扫描，该工具在用户空间中实现 Linux API。它不实现的 Linux API 的一部分是 perf_event_open **，这是像 prof 这样的分析器工作的方式，也是一些持续分析器构建的基础（例如 ddprof）。我们的第一次尝试使用了这些工具之一。一切在我们的测试环境中运行正常，但当我们部署到生产环境时，出现了一些关于该系统调用无法正常工作的错误。最后，我们发现是 gVisor 的问题，尽管我们对此感到失望，但我 secretly excited，这意味着我可能会写自己的分析器。 支持 OCaml 一些非常优雅的持续分析器很好地与语言的运行时集成（因此不使用 perf_event_open），例如 Pyroscope 或 Datadog 的 Python Profiler。OCaml 没有任何可用的。在那时，我们知道如果要构建自己的持续分析器，我们希望基于开源标准，这样我们可以为社区提供有用的工具（这样我们就不需要从头写太多工具）。值得一提的是，Pyroscope 的 SDK 是开源的，而 Datadog 的不是。 成熟度 OpenTelemetry 还拥有（当时是预发布）分析规范，以及由 Elastic Search 慷慨捐赠的分析器。这个分析器非常非常酷，通过 eBPF 程序解码原始内存中的堆栈跟踪，包括 Python 和 Ruby 等解释语言。这些都是疯狂的东西，如果您觉得这篇文章有趣，值得在那个仓库中挖掘。使用 OCaml 程序在本地运行此内容会产生一些非常神秘的堆栈跟踪，我们很快意识到，为了从中获取有用的信息，我们必须编写自己的 eBPF 程序来遍历 OCaml 堆栈。虽然这听起来很有趣，但 OTel 信号也是预发布的，其他基础设施也是如此，因此即使我们驯服了 eBPF，仍然存在许多未知的风险。此外，我们甚至不确定这是否可以在 gVisor 中运行（经过进一步研究，我们发现它确实不行）。所以这不是一个严格的否定，但如果我们沿着这条路走，那将是一个非常冒险和困难的项目。 性能和安全性 最后，持续分析器需要具备良好的性能和安全性！如果一个分析器对您的程序运行时产生显著影响，您就无法轻松地在生产中运行它。现有的 OCaml 分析器是