第二部分——从门禁到责任

图片来源：未知

作者： Joe Basirico 发布日期： 2021年9月7日 阅读时间： 8分钟

这是一个多部分博客系列的一部分，如果您尚未阅读，请先查看第一篇文章： 第一部分——我在一家E轮初创公司ProdSec团队的前100天

在我的第一篇博文中，我讨论了我是如何找到Highspot这家公司以及吸引我的原因。我谈到了在快速扩充自身知识、努力适应新角色文化和要求时所面临的直接挑战。如果您还没读过，建议您先阅读那篇文章再回来。

在这篇文章中，我将探讨安全思维的转变：从将安全团队视为软件交付瓶颈的“安全门禁”模式，转变为通过培训、文化和安全团队的支持，使安全成为每个人的责任。这种转变将安全团队与工程团队其他成员的关系从“执行者”变为“赋能者”，这对所有人都有利！

微软SDL，每个阶段都附有安全“门禁” 当我开始从事安全工作的时候，很幸运地赶上了微软启动“可信计算计划”，那大约是20年前。当时，最先进的安全指导方针是通过一系列旨在确保漏洞不会溜走的控制结构和检查点（即“门禁”，与比尔·盖茨无关）来控制风险流。

• 想提出新功能或更改现有功能？需要从安全团队获得威胁模型。
• 想提交代码？需要安全团队进行代码审查。
• 想发布软件？需要安全团队进行安全评估和签字。

我当时是一名安全负责人，我的工作就是在将产品交付给客户之前签字批准。知道大多数开发人员和测试人员不具备深厚的安全知识，而我的工作是发现并修复该产品中的所有安全漏洞，这压力巨大！在发布日期前的几周里，我睡得很不好。

即使这些安全门禁有效，它们也是低效的。它们使安全团队成为任何安全相关事务的瓶颈。它将所有责任从构建软件的工程师转移到了安全团队身上，导致了一种“猜测并检查”式的安全方案，这种方案注定会失败。此外，这还是基于微软古老的18个月瀑布式流程设计的。在今天的敏捷开发环境中，它根本行不通。

尽管如此，我们仍然试图将这些观念生搬硬套进现代开发流程，结果并不成功。即使是像“左移”这样的高层次概念，我们也常常没有为工程师提供他们所需的工具、指导和培训，让他们有能力为自己的功能做出优秀的安全决策。

为了赋予工程师在安全方面的自主权，他们必须通过培训和反馈获得决策权，并且必须对这些决策负责。安全团队的存在是为了支持和指导这些决策，而不是替他们做决策。这是我已知的唯一能够随着组织规模扩展的模式。除非你计划为雇佣的每位开发人员配备一名安全工程师——这既不现实，也不可能成功。

培训 应用安全意识始于一套基础的安全培训。在这里，开发人员学习他们在构建安全代码、攻击场景以及首选修复和防御措施中的角色和责任。没有人比你的开发人员更了解你的代码库，请用知识和热情武装他们，以构建安全的软件。

Highspot拥有我所见过的最好的新员工入职流程之一。第一周用于了解行业和产品，然后在整个月剩下的时间里深入了解具体工作细节。如果你是工程师，那就意味着要理解我们使用的工具、流程和最佳实践。我们借此机会确保每位工程师都完成了我们的《安全101》培训，在培训中，我们让每位工程师掌握理解风险、常见漏洞以及寻求支持的渠道所需的知识。

完成《安全101》后，工程师有机会通过参加每两周一次的安全“办公时间”来增加知识。在我们的办公时间中，我们回答工程师提出的紧迫问题，当问题回答完后，我们会进行实时培训。这种办公时间培训可以是最终会推广到工程团队其他成员的正式培训，也可以是基于Highspot的新举措，甚至是另一家公司的新闻文章或数据泄露事件而更具针对性或范围更窄的培训。从自己的错误中学习总是很重要，但从别人的错误中学习则更好！

支持 安全团队必须为工程团队的其他成员提供支持，以取得成功。这意味着对请求做出快速响应，并在需要时做必要的工作以提供清晰的指导。支持可以有多种形式，从上面提到的培训，到审查，再到库或框架选择，或推荐的修复方案。

我在疫情期间加入Highspot，这意味着我没有机会与许多同事面对面交流。没有这种交流，我发现很难建立基于信任的关系，而没有这种关系，我的互动更像是交易性的。交易性关系在某些情况下是可以的，例如，如果我需要向IT团队申请某个系统的新账户，我不需要利用那里的关系。但要建立一个安全文化的环境，工程师必须乐于提出问题并指出缺陷。

安全有时会让人望而生畏，我经常会在系统中发现漏洞，这会给其他人带来额外工作。如果这种请求不是基于相互信任、尊重和共同的目标，人们很快就会不再向我的团队寻求帮助。能够支持工程团队的一个关键部分，是让他们能够轻松地向安全团队提出疑问或请求。通过频繁的互动及早建立这些信任关系，将来会受益匪浅。

我通过大量的一对一Zoom会议、打开摄像头、积极发言以及在会议中提问来做到这一点。

长效工具 为了安全地横渡海洋，我们需要工具和自动化来使安全变得容易。这意味着实现和集成安全的默认设置、库、框架、工具和自动化。其中每一项在安全系统的实现和检测遗漏问题时都扮演着不同的角色。

默认设置 为新系统创建安全的默认设置，可以大大减少错误的发生。拥有一套安全的默认设置也为你提供了一个在错误发生时进行更新的地方。是否看到很多未加密的S3存储桶？那就把加密设置为创建新S3存储桶时的默认设置。是否在你的环境中发现很多与操作系统相关的漏洞？那就创建一个设置了安全合理默认值的“黄金镜像”。每当出现问题，问问自己是否可以通过在某处设置更好的默认值来缓解。立即做出改变以缓解眼前的问题，并更新默认设置，这样你就再也不会看到那个问题了。

库和框架 你上一次看到CSRF或会话固定漏洞是什么时候？如果你的答案超过一两年，你应该感谢库和框架最近所做的重大改进。选择最新的库和框架并正确使用它们，可以极大地帮助提高整体安全性，同时减少安全性对整个开发流程速度的影响。

不过，恰当地使用库和框架非常重要。许多库都带有安全的默认设置，这很好，但它们可能无法直接替换不安全的现有库。这意味着，有时工程师可能只是简单地禁用安全控制来让某些东西运行，而不是花时间去理解新系统。这正是安全团队可以介入的地方，帮助建立最佳实践并提供支持和培训。此外，我们部署了监控来检测许多错误，并进行定期评估，以最小化这些问题处于活动状态的时间。

工具 根据工具在软件开发流程中的部署和集成位置，它们在缓解风险、提供反馈，或者可能引起开发人员挫败感方面的效果会有所不同。Highspot针对不同目的使用了许多工具。安全团队频繁运行SAST和DAST工具来寻找新引入的漏洞。你可以选择让安全团队定期运行这些工具，或者将它们构建到构建或集成管道中。Highspot选择让安全团队运行这些工具，以便我们能够对每个问题进行分级，并提供有针对性的具体修复指导。这有助于减少开发人员的干扰，并保持CI/CD管道的快速平稳运行。我们确实将带有安全规则的linter集成到了我们的CI/CD管道中，以确保工程师遵循最佳实践。

工具不仅有助于发现漏洞，也是将安全置于每位工程师首要考虑之处的绝佳方式。来自linter或SAST/DAST工具的提醒可以提醒工程师安全的重要性，以及代码质量需要达到一定的水平才能被接受。

自动化 我喜欢“第二次就自动化”这句话。如果有些任务经常做，就应该将其自动化。这将有助于安全和工程团队扩展规模，并应对新的独特挑战。我们已经将大部分工具的集成和自动化工作整合在一起，我们的依赖检查器和其他工具被定向到我们的缺陷跟踪器进行分类。工具与Slack和电子邮件集成，以提高可见性。当漏洞被修复后，它会被转化为单元测试，以确保后续不会出现回归问题。我们也会尽可能自动化漏洞的发现过程。手动检查TLS配置、Cookie标志和标头等内容是浪费时间。将其自动化，并集成到你使用的工具中！

总结 在我从事安全工作的20年里，很多事情都发生了变化。我们不再需要像过去那样费力地说服每个团队安全的重要性，我们与各个团队合作的方式也已经演变。现在，安全与工程团队其他部分之间有了更多的协作，其中很多都源于对支持、赋能和工具的关注，这些使得安全团队成为交付优秀软件的合作伙伴，而不是障碍。

在最后一篇文章中，我们将更多地探讨我在前100天里犯的错误和做出的假设，以及我如何转变思维以适应新团队和新公司的需求。

继续阅读第三部分