如何在 IDE(如 VisualStudio)中最好地向开发人员展示“安全漏洞反馈”

信息安全 Web应用程序 代码审查 owasp
2021-09-02 08:14:57

我今天发布了一个非常酷的 PoC,我能够在开发人员在 VisualStudio 中编写代码时向他提供实时的“安全漏洞反馈”。

您可以在 VisualStudio 内的 Real-time Vulnerability Creation Feedback 中看到视频(带有绿色和红色),每次用户对代码进行更改时,都会进行自动编译(使用 Roslyn 的 C# 编译器)和 SAST 扫描(使用 Cat 。网)

虽然这个 PoC 非常激进(我对每个按键都进行了编译和扫描,这有点 OTT),这里有另一个视频显示了更大的编译+保存扫描:实时 C# 解决方案编译和安全扫描(使用 Roslyn 和猫网)

这个 PoC 的关键在于它代表了我们需要解决(某些类型的)安全问题的实时循环(几乎是一个 REPL)。

接下来,我们需要考虑将这些信息呈现给开发人员的最佳方式。例如,我在想我们可能希望根据问题的类型、问题的严重程度、可利用性等显示多种颜色……

另一个很酷的想法是更改光标的颜色或形状(考虑更大或更小),具体取决于当前未解决的问题数量:)

4个回答

这是一个非常酷的想法,但我认为要成功,将其与现有环境无缝集成很重要。

为此,我建议不要想出一些新的、意想不到的方式来呈现信息,而是使用现有的格式和机制。

例如,用红色波浪线强调关键和高风险漏洞——就像 Visual Studio 默认对编译错误所做的那样,也正如几乎所有程序员所期望的那样。您可以用不那么可怕的颜色标记不太严重的缺陷 - 蓝色、绿色等。
我会更进一步 - 并允许它是可配置的,int VS 的Fonts and Colors选项对话框,以使程序员能够使其适合他们的特定设置,甚至让它脱颖而出。您可以为关键设置一个设置,为高设置另一种颜色等。

此外,就像编译错误和警告一样,应该有一个窗口列出所有当前发现的问题——这个窗口越丰富,当然越好(过滤、排序等)。

这将大大提高开发人员的安全性缺陷,就像功能性错误一样的错误 - 在某些情况下(例如严重/高),应该被视为编译错误。

请注意,VS 的内置代码分析与此类似(大部分情况下不是实时的)。

当窗口失去焦点或获得焦点时触发安全编译怎么样?还是在用户 10 秒无操作后?绝对在保存文件时这样做,这是一个很好的,总是在预构建时发生。

对于开发人员反馈,如何在窗格左侧显示调试断点旁边的区域显示彩色骷髅和交叉骨。给它们着色以表示严重性:黄色表示“必须修复”,红色表示“OMG!!!” 将鼠标指针悬停在它们上面可能会弹出一个描述错误的工具提示。

也许将背景设置为浅红色(或彩色)渐变,强度以漏洞为中心。或者在滚动条旁边使用彩色条,例如 WinDiff 的屏幕,用于向您显示差异所在。对没有漏洞的区域使用黑色、白色或不存在的线段,并使用与表示漏洞的头骨颜色匹配的线段。

至少要确保它输出的错误会破坏构建。

您需要告诉开发人员,没有自动化系统可以找到所有缺陷,开发人员需要保持警觉并自己寻找缺陷。一种虚假的安全感是绝对的|最糟糕的| 您可以提供给开发人员的东西。

什么都不相信,测试一切。

(附带说明一下,简单地突出显示每个危险功能并提供说明其危险原因的文档可能非常有用。此外,您应该认识到,您将永远无法解决实际应用程序中 1/2 的严重安全问题。 “解决方案”。缺少重要控件不能加下划线或突出显示,因为不存在。)

此处的开发人员 - 仅使用 IDE 中提供的工具和可视化功能。不要试图引入自己的风味,因为这只是他们需要学习的一件事。毕竟你只是强调一个问题区域

IDE中任何时候都不应指定代码的正确形式,因为您不了解开发人员当前工作的上下文。此类工作应在发布的构建管道中进行。

如果您因为感知到的安全问题而阻止项目编译,那么您的工具就是一个问题,应该立即从任何开发环境中删除。

有时人们想编写易受攻击的代码作为测试工具,或者在现有代码库上存在代码库之外的控件。更不用说 Roslyn 诊断分析器在项目范围内很糟糕,并且仅限于单个单元。