网络安全反模式：无效工作生成器
2025年4月19日 · 3025字 · 15分钟阅读
本文最初发表于Open Government Products的Substack。提醒：我正在与No Starch Press合作出版新书！《从零日到零日》专为希望进入漏洞研究领域的新手撰写。
优秀设计和平台工具的目标是让弹性和安全成为背景而非焦点。理想情况下，安全应该是隐形的——开发者甚至不会意识到后台正在运行的安全机制。他们的工作流程不会感到更繁琐。
——Kelly Shortridge，《安全混沌工程》
这是关于在Open Government Products构建网络安全解决方案第一原则系列博客的第一篇。来自攻击性安全背景的我发现，最具有弹性的网络安全解决方案直接解决根本原因，从而产生高度可扩展的解决方案，减少组织的整体工作量。
然而，许多安全计划陷入一个常见陷阱：本有前景的安全解决方案最终产生越来越多的工作，逐渐消耗大部分资源和注意力。这最终会分散团队解决更重要安全问题的精力，因为他们忙于发送提醒、填写（数字）文书和处理豁免请求。
让我们看一个非虚构的例子：
*John Doe是NotBeyondCorp的一位进取型网络安全专家。在一系列由简单注入漏洞引发的安全事件后，他建议购买代码扫描解决方案以识别公司代码库中的这些漏洞。在初步试验中，他评估发现并找到了50多个可利用漏洞！受到结果的鼓舞，公司批准了该解决方案，John负责在全组织内实施。
John兴奋地开始推广该解决方案。尽管遇到一些小问题（如破坏某些CI/CD工作流程），他完成了推广。但他很快意识到很少有开发者响应漏洞发现。他们太忙无法进行分类，或者不知道这个解决方案。
John尝试了一些改进措施，如调整检测规则和向开发者发送自动提醒。这些改进略微提高了参与度，但效果短暂。无论如何，不可能达到100%的真阳性率。发现数量不断堆积，修复时间指标亮起红灯。John感到沮丧：开发者难道不知道漏洞很重要吗？
无计可施，John求助管理层按下“大红按钮”：强制要求对这些发现进行分类和修复时间表。管理层被John清晰解释真阳性被利用可能带来的后果说服，表示同意。为了执行授权，John获得了一些人手来跟踪漏洞发现。
面对数千个未解决的漏洞警报，John意识到需要一个适当的工作流程来管理它们。他的团队创建了一个Jira工作流程，自动提醒开发者（如果未及时响应，还会提醒他们的经理）。
然而，并非所有问题都能妥善解决——有争议的发现、豁免请求和其他查询开始涌入，需要团队手动响应。有时，特别固执的团队会将问题升级到管理层，需要更多会议来协调。团队为常见问题（如豁免请求）创建了更多Jira工作流程，但最终仍需人工批准。
John为授权辩护，但逐渐感到失望。他倡议初期解决的容易问题大多已处理，因此误报比例也在增加。此时，投入该倡议的大部分工时涉及分类误报或处理官僚内斗。他希望投入更多时间改进解决方案或构建内部集成，但总有另一个会议…
这是许多安全计划中常见的场景。虽然初始意图良好，结果起初看似有希望，但实际投资回报随时间大大减少，特别是考虑到维护合规机构的机会成本。
这是第一个网络安全反模式：无效工作生成器。
什么创造了无效工作生成器？ 🔗
为避免这种反模式，理解其发生原因及促成偏见至关重要。
浅层因果关系 🔗
John的倡议核心是解决可利用漏洞。这很关键但容易忽视。鉴于此，任何花费在不可利用漏洞上的时间都是浪费时间和资源，偏离目标。James Berthoty在博客文章和附图中简洁地阐述了这一点：
在我保护云原生应用的职业生涯中，从未见过在SaaS应用上下文中容器镜像的可利用CVE证据。尽管进行了数千次漏洞扫描，发现数百万漏洞，以及无数开发者工时修复它们。不幸的是，惊人的误报数量对安全在组织中的合法性造成了实际损害。
来源：James Berthoty, Latio Pulse
许多“左移”无效工作生成器的问题在于，大量成本转移给开发者，这在评估计划有效性时未准确捕获。通常，运营总成本要高得多。
部分动机是归咎于人为错误的偏见——在这种情况下，“可利用漏洞发生是因为有人将其引入代码库。”因此，负责人应分类和修复已识别漏洞。表面上看，这确实正确。但表面级评估对组织不利。保持好奇并实践“五个为什么”很重要：
- 为什么注入漏洞发生？因为不受信任的输入直接用于构建数据库查询。
- 为什么不受信任的输入被允许进入查询逻辑？因为开发者编写原始SQL而未使用参数化查询等安全抽象。
- 为什么开发者能在代码库中使用原始SQL？因为开发环境未限制或控制数据库访问的实现方式。
- 为什么未限制对不安全API或模式的访问？因为没有架构控制，如默认安全库或消除不安全模式使用的框架。
- 为什么系统未设计为强制执行安全模式并禁止不安全模式？因为应用栈未包含使安全方式变得容易（或唯一）的防护栏，如安全强化的ORM或禁止原始查询构建的框架。
通过深入分析，您可以识别许多比“又一个警报生成器”更多的潜在解决方案，提供比扩展性差的最低共同分母解决方案更多的选择。
错误的解决方案优先级 🔗
明确地说，这并不意味着警报生成器是错误的解决方案——情况可能要求先从更容易的解决方案开始。有一个专门致力于检测和响应的安全操作领域（将在未来文章中讨论）。
初步了解漏洞数量是重要的第一步。然而，在应用安全中，应根据解决方案解决根本原因的能力来优先排序。为此，我喜欢参考Kelly Shortridge的安全解决方案冰淇淋锥层次结构：
来源：Kelly Shortridge, 对CISA信息请求的响应
虽然该框架源自许多行业使用的既定控制层次结构，但不幸在网络安全领域被忽视。简而言之，冰淇淋锥底部的较弱解决方案越来越依赖人类干预才能成功，而接近顶部的解决方案通过设计消除危险。
任何依赖人类干预的解决方案都内置了误差边际——毕竟我们只是人类——然后需要额外干预来解决。回想John为确保开发者修补错误而必须做的Jira工作流程、电子邮件提醒和会议。这就是无效工作的来源，也是为什么他的解决方案注定产生越来越多的无效工作。更糟的是，这意味着消除可利用漏洞的实际结果永远无法达到100%——总会有另一个未分类或错误驳回的警报。
缺乏机制 🔗
此时，您可能有一个常见且非常合理的反对意见——并非每个人都有Google的安全团队能力来构建和推广整个Web框架。
如果Google开源他们的高保证Web框架会很好，但它可能过度优化了Google的内部工具链和模式。一些组织可能有高度异构的内部环境，排除了单一框架。
这是选择像警报生成器这样的最低共同分母解决方案的一个重要因素。它处于大多数缺乏全组织范围机制来实施变革的安全团队的控制范围内。
如何避免无效工作生成器？ 🔗
既然您理解了导致无效工作生成器的原因，让我们探索如何避免这些原因并探索替代方案。关键是从这些第一原则开始：
清理干净与保持干净不同 🔗
DevSecOps领域有一种常见方法：“清理干净，并保持干净。”“清理干净”指解决所有未决发现，而“保持干净”指阻止新发现发生。这里的关键原则是这些是两种独立的策略。更关键的是，“清理干净”是临时的第一步，而“保持干净”是长期解决方案。
将其视为从沉船中舀水。理论上您可以添加更多人舀水，但某些时候需要修补变大的洞。一个常见错误是认为需要完全清理干净才能保持干净。这是不可能的任务；总会有新问题涌入。
相反，清理到足以解决真正可利用的高危和关键问题，然后转向保持干净。John的错误是过度专注于清理干净，未设定时间点开始投资保持干净。
有多种方法设定合理的“足够干净”点——可利用性或可达性、严重性、CVE的KEV/EPSS。只需设定该点并承诺。在OGP，我们利用Dependabot自动分类规则，编写了自己的CodeQL规则集，并投入几个周期处理（优先的）漏洞积压，然后为高严重性漏洞设置警报。这为我们提供了探索“保持干净”解决方案的空间，同时为重要漏洞维持合理基线。
真正可扩展的代码漏洞解决方案看起来更像Google的高保证Web框架蓝图，其中Google的安全工程团队内置了多个安全控制。他们的分享很像Shortridge在本文章开头的引用：
值得强调：此列表中的所有内容都由安全团队维护。使用我们的高保证Web框架，应用所有者无需意识到任何这些功能——它们都启用并开箱即用。
在OGP，我们构建了一个Starter Kit，其中安全工程团队内置了安全组件（Starter Kitty）以解决一些常见重复发现。虽然它们在首次尝试中未完美工作，但我们通过跨多个产品的连续渗透测试逐渐强化它们，确保一个产品团队学到的教训被编码并传递给所有其他产品，使我们能够明显消除一类Web漏洞。
良好意图无效，机制有效 🔗
任何依赖人类干预的解决方案都带有内置失败率。虽然开发者培训重要，但并非万无一失——或者攻击者可能发现新的攻击向量。理解这一原则帮助您远离警报生成器或NagOps，转向构建真实机制。
即使缺乏现有机制，从合规到安全工程的演变部分涉及强大的跨学科工作——特别是与拥有高杠杆机制的工具、平台、devops和其他工程团队合作。安全在孤岛中作为首席阻止者运作是最简单和最差的运营模式。
在OGP，安全工程团队未构建Starter Kit——工具团队构建的。通过与他们合作将Starter Kitty组件引入Starter Kit，我们还解决了开发者体验和可用性问题，工程师更敏感（观察此线程），改进了最终实现。
回想John最初在推广中如何破坏开发者的CI/CD管道。安全工程有时可能缺乏其他工程团队的背景，这就是为什么密切合作对于避免“大红按钮”很重要。授权也是一种机制，但肯定不是最有效的。
简而言之，缺乏正确机制不是使用错误解决方案的借口——构建或找到那些机制。我将在第二篇关于构建有效机制的博客文章中进一步讨论。
案例研究：tj-actions供应链攻击 🔗
让我们通过tj-actions供应链攻击案例研究来应用这些原则。借助一些ChatGPT辅助（指导避免警报生成器），您可以快速映射五个为什么：
- 为什么我们的仓库受到tj-actions漏洞影响？因为开发者使用了被破坏的第三方GitHub Action，并通过可变标签（@v35, @v1）自动拉取其最新版本。
- 为什么我们的工作流程自动更新到恶意版本？因为GitHub Actions默认使用可变标签，我们允许生产工作流程中使用未固定版本。没有强制执行防止它。
- 为什么我们未阻止运行未固定的第三方操作？因为我们未将GitHub Actions视为生产依赖。我们的安全态势将应用依赖（如npm、pip）视为不可变和扫描的——但CI/CD依赖完全信任且未审计。
- 为什么GitHub Actions与应用依赖区别对待？因为我们缺乏让我们像代码依赖一样管理GitHub Actions的框架或工具。没有锁文件，没有审查过程，没有仓库到操作信任模型——即插即用。
- 为什么我们没有那个框架？因为GitHub未提供开箱即用支持，没有对锁文件、中央批准工作流程或操作依赖代理的首方支持。我们接受了该风险作为正常而不是解决它。
从这里，您可以生成一些可能的解决方案：
- 检测和警报非哈希固定的GitHub Actions。
- 在运行时或静态扫描、检测和警报恶意GitHub Actions。
- 使用GitHub策略强制执行哈希固定的GitHub Actions。
- 仅允许批准的、白名单的GitHub Actions。
我相信您可以自己想到更多——供应商通常很乐意在此类事件后推荐一些自己的产品。但哪些解决方案解决根本原因，它们在安全解决方案冰淇淋锥层次结构中处于什么位置？
无效工作生成器解决方案
负面的无效工作生成器结果可能是“检测和警报”解决方案，甚至是白名单；这通过警告系统和管理控制将更多人纳入循环。
根本原因解决方案
然而，在这种情况下，GitHub确实为企业范围的GitHub Actions策略提供了明确机制。这必然是一个破坏性变更，因为开发者不能再使用不受信任的操作。正如Google关于高保证Web框架的博客文章分享：
其中一些功能确实约束了应用所有者编写的代码（例如，它们会阻止编写如
document.body.innerHTML = "foo"的代码），但这是我们“安全编码”安全方法的有意部分…
“使安全方式变得容易（或唯一）”是可能的，但安全团队需要完全拥有推广以减少意外中断并确保可维护性。
我们的做法
GitHub策略功能只有一个问题：GitHub只允许将操作限制为内部操作、已验证市场创建者拥有的操作、官方GitHub操作和白名单操作。然而，这可以解决强制哈希固定依赖的实际根本原因。
幸运的是，我们能够使用白名单中的模式为哈希固定操作创建变通方案。虽然不完美，但这在GitHub实际在策略中添加哈希固定操作作为选项之前足够了。我们还决定允许市场验证创建者和官方GitHub操作，以减少实施策略时的失败操作数量，降低开发者摩擦。
更重要的是，我们与工程师合作构建了一个自定义GitHub应用，识别并通知开发者所有不受信任的操作，这些操作在策略实施后会失败——您可以在此处查看FormSG的示例。这减少了我们在切换时的不愉快惊喜。
最后，我们为GitHub Actions中断指标和日志创建了监视器，以警报新策略是否导致失败激增，确保我们需要时可以及时回滚。
根据组织背景，您可能得出不同的解决方案，但您可以看到这种方法如何满足两个原则：
- 清理干净与保持干净不同：我们投入一些时间识别不受信任的操作并警报开发者，但这为自动执行的GitHub策略铺平了道路，防止更多不受信任的操作。我们未在检测和警报阶段停滞。
- 良好意图无效，机制有效：使用哈希固定或受信任的操作可能繁琐。当不知情开发者使用失败的不受信任操作时，会引入意外元素。假设唠叨开发者使用受信任/哈希固定操作无效是合理的。相反，我们使受信任操作成为唯一路径，但通过准备工作和更友好的策略选择使其尽可能容易。
结论 🔗
在这篇博客文章中，我解释了一些网络安全解决方案设计的第一原则，希望说明好解决方案与坏解决方案的区别。您的安全计划可能并不总是具备能力或机制，但培养良好品味很重要：
“没有人告诉初学者这一点，我希望有人告诉我。所有从事创造性工作的人，我们之所以进入，是因为我们有良好品味。但存在这个差距。头几年你制作的东西，就是不够好。……你的品味是你的工作让你失望的原因。……这需要时间。花时间很正常。你只需要努力突破。”
——Ira Glass
在我的下一篇文章中，我将讨论我们在OGP学到的关于构建有效机制以支持强大安全解决方案的一些教训。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
公众号二维码
