ACM通信

实践

为静态分析工具设计ui

作者:丹尼尔·提加诺夫，丽莎·阮光都，卡里姆·阿里
ACM通信，2022年2月，第65卷第2期，52-58页
10.1145 / 3486600
评论

过去的研究表明，静态分析工具存在常见的可用性问题，例如高的误报率，缺乏响应能力，以及不清楚的警告描述和分类。尽管这些工具已经变得更加复杂，而且它们的行业使用已经普及，但这些问题仍然很突出。^{6，7，9，11，13，15，19，20.}

为了解决静态分析工具的可用性问题，Lisa Nguyen Quang Do等人。^20.提出了一种在分析开发过程中设计这些工具的以用户为中心的方法，而不是将分析的开发与其用户界面(UI)分开。为此，他们为设计分析工具的UI定义了10条指导原则。作者从现有的文献和他们在17个静态分析工具和87个软件开发人员之间进行的研究中提取了这些指导方针。指南考虑了分析引擎需求、用户行为、报告平台，以及公司政策对静态分析工具使用和采用的影响。¹⁸

本文探讨了应用这种以用户为中心的方法和SWAN的设计指南的效果，²⁶Swift编程语言的一种关注安全的静态分析工具。SWAN正在积极开发中，以更好地集成到Swift开发工作流中，提供更快、更精确的分析引擎，以及新的UI。我们的目标是评估提高SWAN下一个版本可用性的方法和指导方针的有效性。

创建SWAN是为了解决Swift缺乏公开可用的静态分析工具的问题。它为用户提供命令行界面(CLI)和图形用户界面(GUI)，以可视化其静态分析的结果。SWAN的目标之一是在开发过程中提供即时的分析结果，而不是像工业中经常做的那样在一夜之间运行分析。^9，15

SWAN的多个元素使它成为探索静态分析工具可用性的一个有趣的案例研究。首先，它有一个庞大的目标受众:所有Swift iOS开发人员(在本文的其余部分中，术语迅速开发人员而且iOS开发者可以互换使用)。虽然这个用户组跨越了不同的配置文件，从大型组织到单个开发人员，但他们的不同需求都被SWAN的即时、轻量级特性和与Swift开发工作流的紧密集成所驯服。因此，不同类型的开发人员解决警告的方式非常相似，他们的UI需求也是如此。

其次，由于SWAN的目标是提供即时的结果，因此它有可能轻松地集成到开发人员的工作流程中，从而在未来支持更多的用例和可用性测试。第三，SWAN独立于现有的分析平台。因此，它的UI可以在没有这些平台施加的外部约束的情况下进行修改，允许探索不同的UI设计。

回到顶部

Swift程序分析

斯威夫特²³是一种开源编程语言，也是苹果在其移动操作系统iOS上进行开发的推荐选择。^3.桌面操作系统macOS。⁴网络流量分析工具StatCounter估计，2019年iphone和ipad占全球移动设备的24.79%，²²macOS设备占桌面电脑的16.46%。²¹趋势还显示，2020年两种操作系统的受欢迎程度分别增长了4.41%和3.82%。因此，对Swift应用程序进行静态分析的能力对全球数百万用户具有重大影响。

尽管针对Android设备存在许多静态分析框架(例如，FlowDroid)，⁵SCanDroid,⁸和DroidInfer¹²)，目前还缺乏与Swift类似的工具。虽然LLVM¹⁶和叮当声¹⁷虽然支持一些低级分析，但不适合对Swift应用进行更深层次的分析，如数据泄漏的精确检测。这是因为在将Swift源代码编译为低级LLVM IR的过程中，特定于语言的结构和信息通常会丢失。此外，目前大多数Swift可用的工具(例如Swift- lint²⁴和裁缝²⁵)只能帮助实施Swift最佳编码实践。

SWAN弥补了Swift日益普及和可用分析工具缺乏之间的差距。²⁶Swift的这个开源静态分析框架主要针对应用程序开发者。它同时提供CLI和GUI。CLI使开发人员能够将SWAN集成到持续集成工作流中，在主要的开发里程碑上提供分析结果。或者，开发人员可以使用GUI直接在VSCode中获得按需分析结果。²⁸这种相对即时的反馈帮助开发人员专注于手头的任务，这进一步帮助他们在更短的时间内修复更多的bug。¹⁴

伴随数字展示了SWAN VSCode扩展的主要GUI元素。用户通过选择SWAN选项卡并按下键来启动SWAN运行污染分析在侧边栏。然后，如果现有的SWAN实例正在运行，则扩展会自动附加到该实例;如果没有运行，则启动一个新的SWAN实例。对于图中的代码示例，SWAN以类似文件树的形式在侧边栏中显示结果。每个脆弱路径都是树中用红色叉标记的元素。它的子结点是路径中的节点。第一个子节点是源，最后一个是接收器，中间的节点是中间节点。用户可以选择任何路径节点，扩展将在相应的源位置打开文件。在图中，用户选择了最后一个节点。因此，SWAN突出显示源文件中的第13行，向用户显示受污染的数据到达了函数水槽()作为参数。

数字SWAN VSCode扩展的主GUI。

回到顶部

设计指导方针

在过去的研究中，Nguyen Quang Do等。^20.研究了Software AG的静态分析工具的使用，关注代码开发人员使用工具的动机(例如，工作环境，工具类型)，他们在面对常见可用性问题时的行为，以及内部创建的解决这些问题的策略。他们的研究涵盖17个分析工具、87个开发人员和两个大型项目，包括开发人员调查和分析结果的研究，以及开发人员对其中一个项目结果的响应。

该研究发现，时间限制是影响开发人员如何与静态分析工具交互的主要因素，因此也影响他们用于优化工作的策略。例如，为了节省时间，44%的参与者根据问题的类型将警告标记为假阳性，而没有进一步调查警告。同样，一些参与者如果不理解警告的描述，就会忽略或压制警告。在这两种情况下，不同的UI可能帮助开发人员做出更好的决策(例如，通过提供已经解决的类似警告的示例)。

因此，Nguyen Quang Do等人定义了10条关于如何为更好地支持开发人员的静态分析工具创建ui的指南(在本文中称为G1-G10)。这些指导方针呼应了以前的研究中报告的可用性问题，稍后会详细说明。

以下描述了适用于SWAN的指南和注释。

g1 -在设计UI过程时考虑时间限制

Nguyen Quang Do等人发现，参与者大多在他们的业余时间(会议之间)使用静态分析工具，Carmine Vassallo等人也有同样的发现。²⁷由于时间限制是使用静态分析工具的主要动机，所以所有UI交互都必须在此上下文中设计。例如，该工具可以帮助开发人员确定修复给定警告所需的时间，并帮助他们计划工作。SWAN的即时分析方法和与Swift开发工作流的紧密集成可能会减少对此类基于时间的预警指标的需求。

g2 -分析响应性和工具界面应该被精心设计以最小化等待时间

提交修复后等待警告更新是参与者报告的停止使用分析工具工作的主要原因之一。由于复杂的分析可能需要很长时间才能运行，修复过程可能会中断，将修复拆分为多个调试会话。这个可用性问题也被报告为工作流中断的一个原因。^11，13，15SWAN的创建考虑到了响应能力。它的UI可以设计为显示和更新即时警告，但这带来了挑战。

将开发人员的知识反馈到分析中

Nguyen Quang Do等人的研究。^20.和Vassallo等人。²⁷观察到程序员开发了如何解释分析结果的启发式方法。例如，Software AG工程师建立了分析不能很好地处理哪些API调用的知识，并且他们忽略了包含此类调用的警告。^20.isstehad Chowdhury和Mohammad Zulkernine¹⁰已经表明，这种分析弱点可能有助于区分真假阳性。因此，Nguyen Quang Do等人主张将开发人员的知识反馈到分析中，这样就可以使所有其他用户受益。SWAN最初缺乏API安全建模，可能会产生许多误报和误报;在这种情况下，开发人员可以采取一些措施。

g4 -提供具体的警告解释

正如在过去的研究中所报告的，警告描述通常是通用的，并且需要安全漏洞或被分析项目的领域特定知识。^{6，11，13，15}这使得理解警告并找出如何修复它们成为开发人员的一项艰巨任务。Nguyen Quang Do等。^20.建议让警告尽可能针对所分析的特定代码段，并提供它在用户上下文中的含义的解释(例如，修复它的难度有多大以及需要什么样的知识)。由于SWAN的目标是容纳所有的开发人员，包括那些技术经验有限的开发人员，提供可理解的解释对其采用是至关重要的。SWAN最初会有传统的解释，其中包含的信息包括类别、严重性、警告如何影响代码、如何利用它，以及如何在高层次上修复警告。稍后，我们将提出一个评估SWAN解释有效性的建议。

根据开发人员的知识提供建议

正如在G4中提到的，修复警告需要特定的领域知识。由于分析工具可以访问修复历史，因此它们是向特定开发人员推荐特定警告的理想参与者，或者为特定警告推荐过去的修复。首先需要在大量用户基础上测试SWAN，以增加对包含过去警告、修复和开发人员信息的知识库系统应该如何开发和集成的理解。因此，该指导方针在未来的计划中。

---

需要使用启发式方法来估计修复给定警告所需的时间。

---

g6 -提供协作选项

关于G3和G5, Nguyen Quang Do等人。^20.建议提供一个平台来共享开发人员知识，并推荐可能拥有修复某些bug所需知识的开发人员。与G5一样，该指南也需要一个知识库，本文稍后将对此进行讨论。

g7 -鼓励优秀的开发者策略

在他们的研究中，Nguyen Quang Do等人观察了他们在面对警告时的行为策略。例如，他们创建启发式来区分真假阳性，或者默认某些带有他们不理解的警告的行为模式(例如，忽略、升级或压制这些警告)。作者建议使用分析知识和开发人员的集体知识来鼓励良好的策略，如升级，并阻止更危险的策略，如警告抑制。首先必须测试SWAN，以确定之前的准则是否不足以促进良好行为。这一指导方针将在关于未来计划的部分中讨论。

使用不同类型的分析工具覆盖不同的方面

由于这是分析用户的责任，因此该指南被认为超出了SWAN的范围。

g9 -对所有警告使用单一报告平台

和G8一样，集成不同的分析工具是分析用户的责任，因此，G9也不在SWAN的范围内。然而，为了促进集成工作，SWAN的下一个迭代可能包括SARIF(静态分析结果交换格式)中的导出选项。¹

g10 -通过政策执行和传播意识促进分析工具的使用

SWAN可以提供与git、building和ide的平滑集成，使其更易于采用、配置和使用。这将使开发人员更愿意采用SWAN，这也将使通过公司政策实施其使用更容易。SWAN还可以附带具体的政策建议和广告材料，以帮助开发人员理解SWAN为他们提供了什么。然而，工具不能直接影响公司的政策，因此G10超出了本文的范围。

回到顶部

短期设计目标

现在让我们检查一下立即从SWAN的角度制定可用性指南。

时间约束。G1-开发者的时间有限。重要的是，它们在任务之间的时间跨度很小。这是他们最愿意解决警告的时候。

Nguyen Quang Do等人认为:“(分析)工具可以在(开发者可以选择的)特定时间范围内提出适当的警告。”换句话说，开发人员为修复警告选择一个所需的时间跨度(例如，15或30分钟)，然后分析工具提供一个批处理在这段时间内解决警告问题。

为此，需要使用启发式方法来估计修复给定警告所需的时间。这种启发式应该考虑几个因素，如警告的复杂性(例如，它流经多少个文件和方法)、警告类型和开发人员经验。为了有效地选择警告，它们的优先级(或严重性)必须与修复它们所需的时间相平衡。开发这种时间估计启发式需要使用经验开发人员试验对其进行调整，这可能会包括在未来的试验中。如果通过即时修复来限制上游警告，从而减少对时间约束的强调，那么开发这种启发式可能不是优先考虑的问题。

---

警告消息应该建议可以帮助开发人员解决警告的人员。

---

SWAN将促进立即修复，并限制上游出现的警告数量。上游状态仍可用于查看未执行的警告。此外，SWAN关注的是安全性，因此出现的任何警告都不应被忽视，就像一般bug或代码样式问题一样。

Swift开发工作流的本质以及SWAN如何通过构建系统集成到工作流中，使得它能够在开发人员积极开发应用程序时快速发现警告。开发人员在开发过程中必须修复的警告数量应该足够少，因此可以立即修复。因此，在这方面解决时间限制的重要性可能大大降低。

然而，有两种主要的方法可以同时引入许多警告，这可能需要进行时间估计。首先，当开发人员第一次在代码库上运行分析时，SWAN可能会发出许多开发人员无法立即解决的警告。其次，每当SWAN的分析在新版本中发生变化时，由于新的警告支持，它可能会产生许多新的警告。未来的计划包括探索如何评估SWAN是否会产生积压的警告，以及在多大程度上，开发人员将不得不在有限的时间内解决这些警告。这将有助于决定是否追求时间启发式的发展。

此外，当开发人员正在工作时，他们可能不想立即解决警告，因为他们专注于编码。在这种情况下，时间估计也会很有帮助。在这里，一个粗略的估计可能就足够了。SWAN UI还可以提供一个方便的按钮，提示一个带有警告信息和时间估计的日历事件，这样开发人员就可以分配时间来稍后解决警告—因此，立即处理警告而不是忽略它。

该研究领域的下一步将是研究开发人员如何使用SWAN来确定将哪些指标合并到时间估计中。这些度量可以从开发人员对给定类型的警告的经验到代码库的大小，再到一天中的时间。这些指标对时间估算的影响可能因开发人员而异，但由于SWAN专注于非常具体的代码警告，这些不确定性可能会受到限制。

响应性。G2开发人员不喜欢等待分析工具，特别是当他们有时间限制的时候。分析响应性和工具接口应该被精心设计以最小化等待时间。

Swift应用程序遵循基于模块的设计，其中每个用户(非包)模块通常足够小，可以被SWAN快速分析。用户的代码可以分布在多个模块中，并且所有包都作为模块包含。

Swift库不是以二进制形式分布的，因此可以由SWAN和用户代码一起分析。SWAN的新基础设施旨在单独处理这些模块，并将它们自动链接在一起。因此，在重新构建时，SWAN不需要重新分析所有模块，只处理已更改的模块。然后SWAN将它们与前一个构建中的缓存模块链接起来，以获得完整的数据流信息。通过这种设计，SWAN为每个后续构建提供了快速的迭代分析。

关于UI, SWAN的目标是在开发人员工作时提供即时反馈。轻量级分析将在每次构建他们的应用程序时运行，并且他们应该在他们的ide中收到警告更改通知。然而，并非所有ide都提供插件支持。²因此，插件不应该被认为是创建SWAN的主UI的手段，而目标是实现IDE集成，至少通知用户新的警告。详细的警告信息将在SWAN的专用(主要)UI中显示，该UI可以是桌面或基于web的应用程序。

开发人员应该能够很容易地说出他们的更改对当前警告列表的影响—也就是说，他们的更改是否解决了或引入了警告。SWAN可以在专用的UI中提供多个列表，以帮助开发人员理解他们的更改:与最新提交不同的警告(类似于git)和与前一次构建不同的警告，包括前一次构建时的警告状态。前面提到的IDE通知也可以类似地配置为显示来自最新提交或构建的更改。SWAN未来的部分UI工作将致力于设计和测试不同的功能，以显示实时更新，而不会使用户感到困惑。在SWAN的未来计划一节中，我们将进一步讨论该系统与鼓励良好行为及其评价的关系。

可定制的启发式。G3-开发人员应该能够使用他们自己的规则或启发式来配置分析工具，以便在必要时使其适应他们的需要。

Swift开发人员使用各种包(如库或api)。Swift构建系统的一个主要优势是所有非apple /专有包都包含在源代码中。这意味着通过这些包的基本数据流不必建模，但它们的安全行为需要建模。因为SWAN目前没有支持所有通用API的资源，所以缺少一些安全信息，比如哪些API方法是源、接收器或杀毒器。然而，在发布之前，SWAN至少会对Swift标准库进行建模。

不可避免地，开发人员会发现一些警告是假阳性(例如，当杀菌剂丢失时)或假阴性(例如，当源或接收器丢失时)。SWAN将提供两种方法，开发人员可以同时调整他们的本地分析，以最小化那些不正确的警告，并通知SWAN的开发人员不正确的行为。

首先，在假阴性的情况下，开发人员可以创建关于缺失行为的简短报告，包括有问题的API方法、它的正确行为(源、接收器或消毒液)，以及可选的简短描述。这将自动在分析引擎中为API方法提供所需的行为，并向SWAN开发人员发送报告。

其次，他们可以针对特定的警告创建类似的报告，但在这种情况下，将自动提供更多的报告信息。发送给SWAN开发人员的报告中不包含任何用户代码。通过这些选项，开发人员可以在不抑制警告的情况下继续使用SWAN, SWAN团队可以对SWAN进行调整，以便在下一个版本中获得更好的支持。

有了这个报告数据，SWAN开发人员可以构建开发人员启发式的大量知识库。一旦对这些启发式进行了分类，SWAN最初的bug报告系统就可以通过更详细的UI进行改进，以便软件工程师输入不同类型的启发式，并将这些启发式自动反馈到分析引擎中。这需要进一步研究不同类型的启发式应该如何以及何时影响分析引擎。

回到顶部

讨论及未来计划

虽然有些设计准则可以立即适用于SWAN，但有些则不能。本节讨论后一组，以及评估SWAN可用性的未来计划。

警告积压。SWAN专注于最小化开发人员不能立即解决的警告数量，方法是将其紧密集成到工作流程中，并提供理解更改引起的警告的简单方法。然而，可能会突然出现许多警告，开发人员最终必须克服这些警告。SWAN团队需要评估这种情况是否存在以及在何种程度上存在。结果可能是，一旦开发人员修复了最初的一组警告，就很少需要使用时间估计(G1)、推荐(G5)或协作(G6)系统。这将降低这些准则与SWAN的相关性。警告解释(G4)还可以在帮助开发人员立即解决警告方面发挥重要作用。因此，在未来的试验中，SWAN开发人员计划分析有多少警告未得到解决，以及警告解释在这一结果中起什么作用。

鼓励良好行为。G2部分讨论了开发人员在提高响应能力时出现的IDE警告通知。这是开发人员决定是否处理警告的关键时刻。因此，开发人员不能忽视重要的警告(我们认为所有的安全警告都很重要)，必须有明确的信息来帮助他们解决这些警告。时间估计和良好的警告解释可以帮助实现这一目标，但这可能还不够，因此应该探索其他鼓励良好行为的方法(G7)。例如，SWAN专注于安全性，将产生许多警告，这些警告可以通过一个消毒API传递数据来快速解决。对于这些警告，可以使用“快速修复”选项，尽管缺乏IDE插件支持可能会使此操作变得困难。SWAN试验可以帮助评估开发人员是否以及为什么没有立即解决警告，并有助于确定可以改进或添加哪些策略来鼓励良好行为。

知识库中。以下准则要求SWAN有一个知识库，其中包含过去的警告、修复和开发人员信息等信息。在开发这样一个系统之前，必须对SWAN进行大量的用户基础测试，以找到可以记录和使用的数据。

G5-警告信息和推荐系统应考虑开发人员的知识和可用时间。

个性化的警告消息可以帮助开发人员更有效地解决警告。如前所述，在计算警告消息中包含的警告时间估计时，应该考虑开发人员的知识。此外，警告消息应该建议可以帮助开发人员解决警告的人员，如团队成员。该消息应该推荐具有解决类似警告的经验的开发人员、从事过警告流经的代码库部分的开发人员，或者自认为是特定警告类型或类别的专家的开发人员。

G6-用户应该有合作解决警告的方法，例如通过消息系统，他们可以就特定的警告进行沟通。

UI应该提供一种传达警告的方法，例如聊天系统。它应该提供一种启动关于警告的对话的方式，然后开发人员应该能够标记建议的开发人员以获得帮助。应该向所有开发人员提供这些对话的存档，这样他们就可以在寻求帮助之前阅读之前关于分配给他们的警告的对话。对话存档还可以在以后帮助了解开发人员最纠结(寻求帮助)的警告是什么，开发人员不理解的具体内容是什么，以及他们接受帮助的速度有多快，从而提高工具的可用性。在警告消息中应该包含一个到相关对话的快速链接。

未来用户研究。为了评估下一代SWAN UI，该团队计划进行几项用户研究。识别开发人员工作流程中的集成点将有助于理解如何自动化分析工具和最小化干扰。此外，通过行业静态分析工具UI的具体示例深入探索UI设计和布局，将有助于设计新的SWAN UI。结合Nguyen Quang Do等人的工作，未来的可用性研究将提供对SWAN的全面理解。

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2022 ACM, Inc.

---

没有找到条目