AppMap 的运行时分析如何发现性能和安全漏洞

当在开发环境中完成运行时分析时，开发人员可以通过一种简单易用的方式来观察正在运行的进程，分析负责这些进程的代码模式，了解我们的编码模式如何影响以及哪些数据受到影响，并直接在该应用程序的源代码。我们花费了大量的时间和金钱来运行、测试和监控我们的代码，试图找到在应用程序上线之前或之后出现的问题的根本原因，希望下一个问题不会再出现。我们可以在调查结果中看到，我们不仅发现了两个 N+1 查询，还在我们的应

文章共3,547字 · 阅读需要大约12分钟

一键AI生成摘要，助你高效阅读

问答

jascl

1146人浏览 · 2023-06-17 11:55:34

jascl · 2023-06-17 11:55:34 发布

软件和应用程序开发很困难。生成无缺陷和无错误的代码更加困难，有时发现我们软件中的问题可能是创建安全、可靠和高性能应用程序的成功的一半。我们花费了大量的时间和金钱来运行、测试和监控我们的代码，试图找到在应用程序上线之前或之后出现的问题的根本原因，希望下一个问题不会再出现。负责生产。因此，为了为不可避免的事情做好准备，我们在所有地方都使用了工具，尽我们所能在它发生时抓住它。但是，如果我们可以减少这种开销，并在我们仍处于开发阶段时让自己“抢先一步”发现问题呢？在本文中，我将介绍运行时分析并描述它的用途。

什么是运行时分析？

运行时分析是在代码运行时对其进行分析的过程，捕获代码在使用实际数据时的行为方式。传统上，开发人员使用静态代码分析工具来检查模式并创建代码模型以及数据如何流经和应用程序而无需实际执行它。通常，如果我们想观察进程并查看实时运行的应用程序中发生了什么，我们会使用在生产环境中运行的应用程序性能监控工具。此选项成本高昂，而且很少显示源代码中出现问题的位置，这使得将解决方案重新集成到代码中变得具有挑战性。运行时分析为我们提供了“两全其美”的场景。当在开发环境中完成运行时分析时，开发人员可以通过一种简单易用的方式来观察正在运行的进程，分析负责这些进程的代码模式，了解我们的编码模式如何影响以及哪些数据受到影响，并直接在该应用程序的源代码。这反过来让我们有机会在提交代码进行代码审查之前解决问题。

缺陷与错误

运行时分析识别缺陷，这与错误不同。错误通常是逻辑错误的结果，例如忘记初始化变量或导致竞争条件。另一方面，缺陷是代码中的基本结构问题。它们涉及代码设计、处理数据时的代码行为或代码实现的更深层次结构方面的问题。

在开发环境中进行运行时分析的好处

虽然有可用于生产环境的监控工具，但开发环境中的运行时分析具有三个优势：

成本效益

生产监控工具可能很昂贵，尤其是在您的应用程序具有高流量或复杂架构的情况下。更不用说很难根据您的需要定制这些工具，而忽略您不需要的东西。

早期问题检测

通过在开发阶段在运行时分析您的代码，开发人员能够在投入生产或被客户看到之前及早发现缺陷和弱点。在 Meta 去年发表的一项研究中，他们发现在开发阶段发现问题使他们更有可能得到修复并使修复更有可能

与开发工作流程无缝集成

通过运行时分析，您可以将您的应用程序部署到不同的测试环境和阶段，在开发生命周期的不同点捕获和解决问题。这提高了代码质量并降低了潜在风险。

使用 AppMap 进行运行时分析

AppMap 在您的 IDE 中执行运行时分析。与创建代码行为模型的静态代码分析不同，AppMap 会观察您的代码运行，使其能够比静态分析更准确、更明确地对其进行推理。

为了识别缺陷，AppMap 从Common Weakness Enumeration (CWE) 论坛上发现的OWASP 前 10 条规则中获取其默认的 12 条规则列表。CWE 是社区开发的软件和硬件弱点类型列表，由高层组织和公司管理，重点关注安全性、可维护性和性能。其他规则也可供使用，可用规则及其定义的完整列表可在我们的文档中找到。

这种基于规则的运行时分析的好处是速度很快。使用静态代码分析器，我们需要等待工具解析代码、构建模型并对其进行评估。AppMap 采用了一种略有不同的方法。由于我们可以实际运行您的代码，因此我们能够动态检测您的代码。这样做可以更深入地了解您的应用程序中发生的事情、运行的位置和进程。我们会在某些事件发生时对其进行标记，并添加标签，其中包含有关事件发生时您的应用程序中实际发生的情况的附加信息。AppMap 的运行时分析扫描器然后利用这些标志和标签来识别潜在问题或发现可能有问题的模式。

如何设置 AppMap 运行时分析

在您安装 AppMap、记录您的应用程序并创建您的第一个 AppMap 后，我们将通过创建或修改文件来添加这些默认规则appmap-scanner.yml。这扩展了扫描器的功能，并允许您包含适合您特定需求的自定义规则。

我们的文档还提供了有关规则构建方式、我们在检测中使用哪些标签以及扫描器如何使用标志来匹配模式和发现缺陷的见解。

示例 1：appmap-scanner.yml

<span style="color:var(--syntax-text-color)"><span style="color:var(--syntax-text-color)"><code><span style="color:var(--syntax-name-color)">checks</span>:
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">authz-before-authn</span>
  <span style="color:var(--syntax-comment-color)"># - rule: circular-dependency</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">deprecated-crypto-algorithm</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">deserialization-of-untrusted-data</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">exec-of-untrusted-command</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">http-500</span>
  <span style="color:var(--syntax-comment-color)"># - rule: illegal-package-dependency</span>
  <span style="color:var(--syntax-comment-color)"># - rule: incompatible-http-client-request</span>
  <span style="color:var(--syntax-comment-color)"># - rule: insecure-compare</span>
  <span style="color:var(--syntax-comment-color)"># - rule: job-not-cancelled</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">logout-without-session-reset</span>
  <span style="color:var(--syntax-comment-color)"># - rule: missing-authentication</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">missing-content-type</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">n-plus-one-query</span>
  <span style="color:var(--syntax-comment-color)"># - rule: query-from-invalid-package</span>
  <span style="color:var(--syntax-comment-color)"># - rule: query-from-view</span>
  <span style="color:var(--syntax-comment-color)"># - rule: rpc-without-circuit-breaker</span>
  <span style="color:var(--syntax-comment-color)"># - rule: save-without-validation</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">secret-in-log</span>
  <span style="color:var(--syntax-comment-color)">#  - rule: slow-function-call</span>
  <span style="color:var(--syntax-comment-color)">#  - rule: slow-httpServer-request</span>
  <span style="color:var(--syntax-comment-color)">#  - rule: slow-query</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">too-many-joins</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">too-many-updates</span>
  <span style="color:var(--syntax-comment-color)"># - rule: unbatched-materialized-query</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">unauthenticated-encryption</span>
  - <span style="color:var(--syntax-name-color)">rule</span>: <span style="color:var(--syntax-string-color)">update-in-get-request</span>
</code></span></span>

结果

创建配置后，您将获得有关应用程序在运行时可能出现的问题的各种信息。

示例 2：分析概述

当针对示例应用程序运行时，我们将配置设置为查找导致性能问题的 N+1 查询，而使用传统的静态代码分析很难找到这些问题。我们可以在调查结果中看到，我们不仅发现了两个 N+1 查询，还在我们的应用程序中发现了 69 个其他缺陷，其中 28 个是潜在的安全风险。在完全透明的情况下，此示例应用程序被构建为故意不安全，因此这些安全发现并不那么令人惊讶，但令人惊讶的是我们可以获得有关所发现缺陷的大量信息。

了解运行时分析结果

当我们深入研究其中一个发现时，我们可以看到一个指向缺陷定义的链接，其中包含更多关于它的信息（例如 3.1）、它发生的次数（例如 3.2）、堆栈跟踪以了解如何它发生了（例如 3.3），以及用户可以采取哪些“路径”来遇到该缺陷（例如 3.4）。有了这些见解，我们就能够确定是否有必要进行修复，需要在何处进行修复，并且我们可以在我们的功能进入审查之前设计和实施修复。

示例 3：调查结果

这为我们提供了有关此缺陷对我们应用程序性能的负面影响的真实可操作信息。想象一下，如果它在生产中被发现，或者更糟的是，根本没有发现，这将导致的成本和用户中断。