攻击面永无止境时代的预防之道

本文曾发表于 SD Times。现经更新后在此同步发布。

‍

谈及进步，数字技术的发展通常处于讨论的核心。我们希望一切都变得更好、更快、更便捷、更强大，同时还希望降低成本、缩短时间并减少风险。在大多数情况下，这些看似“不可能”的目标最终都能实现；这可能需要数年时间和多个版本迭代（以及一群如果被要求再改一次功能设计就可能要“造反”的开发人员 再改一次简直要命），但代码确实在每一天改变着世界。

然而，软件规模的巨大扩张也带来了巨大的责任，现实情况是，我们从安全角度来看尚未做好准备。软件开发早已不再是孤立的领域。当我们审视软件驱动的各类风险时——从云端、家电和车辆中的嵌入式系统，到关键基础设施，更不用说连接这一切的 API——攻击面已变得无边无际且难以掌控。

我们无法期待每一行代码都能由资深安全专家逐一仔细检查的“魔法时刻”—— 这种技能缺口短期内无法弥补——但作为行业，我们可以采取一种更全面的代码级安全方法。

让我们探讨如何利用现有工具来管控这一无限的攻击面：

客观评估业务风险水平（以及你愿意承担的限度）

完美的安全性是不可持续的，但掩耳盗铃、假装一切风平浪静同样不可取。我们都知道企业在明知代码存在漏洞的情况下仍会发布，这显然是基于产品上市时间和功能迭代所做的权衡。

在高速开发中保障安全是一项挑战，尤其是在尚未将 DevSecOps 作为标准开发流程的组织中。然而，只需看看最近的 Log4Shell 漏洞，就能发现代码中相对较小的安全问题是如何为成功攻击创造机会的，也能看出因发布低质量代码而承担的风险，其后果可能远超预期。

习惯于成为（访问）控制狂

令人震惊的是，大量代价高昂的数据泄露事件都是由配置不当的云存储环境引起的，而因访问控制错误导致敏感数据暴露的风险，始终是大多数组织安全团队的心头大患。

2019 年，财富 500 强企业 First American Financial Corp. 惨痛地领教了这一点。一个本可轻松修复的身份验证错误，导致超过 8 亿条记录泄露，其中包括银行对账单、抵押贷款合同和身份证件照片。他们的文档链接无需任何用户身份识别或登录，任何拥有浏览器的人都能访问。更糟糕的是，这些链接采用顺序编号，这意味着只需简单修改链接中的数字，就能获取新的数据记录。

该安全问题在 被媒体曝光前已在内部被发现，然而，由于未能将其正确归类为高风险安全问题，且未上报给高层进行紧急修复，导致了至今仍在处理的严重后果。

失效的访问控制如今位居 OWASP Top 10 之首是有原因的：它极其普遍。开发人员需要经过验证的安全意识和实践技能，以掌握身份验证和权限管理的最佳实践，确保采取有效的检查和措施来防止敏感数据泄露。

API 的特性使其显得尤为重要且棘手；它们的设计初衷就是与其它应用程序频繁交互，因此开发团队应具备对所有潜在访问点的可见性。毕竟，在追求提供更安全软件的过程中，他们无法预见所有未知的变量和用例。

分析你的安全计划：在预防方面投入了多少精力？

安全计划的大部分内容致力于事件响应和处理是合理的，但许多组织未能充分利用现有资源来从源头上预防安全事件，从而错失了降低风险的宝贵机会。

诚然，市面上不乏能够协助发现漏洞的综合安全工具栈，但近 50% 的企业承认，他们曾在明知代码存在漏洞的情况下仍将其发布。时间紧迫、工具集复杂以及缺乏专业人员来处理报告，这些因素共同导致了这种本质上的“权衡风险”。然而，随着代码安全需求扩展至云端、应用程序、API 功能、嵌入式系统、代码库以及日益广阔的技术领域，现有的应对方式注定让我们始终处于被动局面。

安全漏洞归根结底是人为问题，我们不能指望机器人代劳一切修复工作。如果您的开发团队没有得到有效的技能提升——不是指一年一次的研讨会，而是扎实的教育体系——那么您将始终面临接受低质量代码及其伴随的安全风险的隐患。

您是否高估了开发人员的准备程度？

开发人员很少接受安全编码能力的评估，这通常也不是他们的工作重点（在许多情况下，甚至不属于关键绩效指标）。如果没能为他们指明更好的路径，也没将此作为衡量成功的标准，那么当出现糟糕的安全实践时，就不应让他们来背锅。

然而，企业内部往往存在一种假设，认为所提供的指导足以让工程团队有效规避常见的安全风险。但根据培训效果及其应用安全最佳实践的意识水平，他们可能并未做好准备成为理想的第一道防线（从而避免渗透测试报告中充斥着无休止的注入漏洞）。

理想的状态是，开发人员能够完成由浅入深的进阶学习路径，并通过验证确保所学技能在实际工作中切实有效。但这需要一种企业文化，即从一开始就充分考虑开发人员的需求并为其提供正确的赋能。如果我们这个行业想要守护好亲手构建的庞大代码世界，就必须尽可能争取一切助力……而我们面前的资源，远比想象中丰富。