如何让开发者爱上安全

开发人员和安全团队之间关系紧张的故事是软件行业的一个长期特征，源于通常认为安全会造成的摩擦。开发人员希望继续开发有价值的新功能，并且许多人非常关心他们代码的安全性。

但从历史上看，安全任务很难解决。任务要么缺乏上下文、明确的所有权，要么缺乏明确的缓解路径，这最终会拖累开发速度并导致安全漏洞持续存在。

在这种背景下，您可以做些什么来改善开发人员和安全团队之间的关系并保护您的产品？首先要了解开发人员的顾虑。

为什么一些开发人员觉得安全是个负担

开发人员冷落安全不仅仅是一个神话：行业调查一再表明，工程师试图避免安全工作，而安全团队对工程师的不作为感到沮丧。

GitLab 的 2022 DevSecOps 报告发现，57% 的组织认为安全是评估开发人员绩效的相关指标，但 56% 的组织还指出，开发人员很少优先解决安全问题。

不出所料，安全团队而非开发人员发现了 75% 的漏洞。然而，安全往往不足以单独修补漏洞。如果开发人员无法确定新发现风险的优先级，则漏洞可能会在被发现后很长时间内保留在产品中。

要打破这些孤岛，重要的是要倾听开发人员的担忧并实施安全工具，以鼓励和授权工程师参与安全工作。下面，让我们从阻碍成功的开发人员-安全协作的几个主要问题开始。

缺乏业务背景

安全风险很少在组织内部具体化。当没有安全业务案例时，我们为什么要期望开发人员通过主动接受安全团队推荐的修复来关心加强它？新功能通常比放慢速度检查安全问题更有价值，尤其是当产品没有已知漏洞的历史记录时。

产品负责人擅长将开发工作与开发团队产生的实际影响联系起来。您应该在安全团队内部和开发团队中提供清晰的上下文，说明安全任务为何重要。如果安全性不提供此上下文，那么开发人员将被要求放弃新功能开发以支持安全问题，而没有清楚地了解为什么需要额外关注，例如当支付系统成为特定监管范围内时框架。

不明确的优先次序

开发人员常常害怕新的安全任务，因为它们可能会突然出现并且都被视为关键任务，而无需考虑开发人员的其他预定工作。安全修复很重要，但它们是否比满足现有产品的最后期限更重要？在产品和功能工作通常被视为创收的地方，安全性通常被视为成本。他们可能更有可能以安全问题为代价来优先考虑功能。

我们不能成为“狼来了”的安全团队的牺牲品。清晰一致的优先顺序是关键。开发人员需要知道漏洞何时真正严重或严重并且应该优先于产品工作，以及原因。他们还将欢迎这样的保证，即花在修补关键问题上的时间将在他们的整体生产力中得到认可。

所有权和责任纠纷

大多数争议源于对谁应对漏洞负责的怀疑。开发人员通常觉得他们的角色是设计新功能，而安全和 DevOps 应该负责软件供应链、开发人员访问管理、硬编码秘密检测和环境强化等方面。

然而，安全性可以可靠地声称，在这些领域中的许多领域都需要开发人员的投入：例如，开发人员向软件供应链添加新包，以及开发人员提交硬编码的秘密。对于硬编码的秘密，开发人员也有必要的上下文来快速找到并修复存在的秘密。

不过，这并不意味着开发人员总是有错。安全团队应该有一个明确的职权范围，哪些风险也不应该与开发人员排队。如果开发人员不断承担所有安全任务，这可能表明安全应该将更多的工作带到内部。这可以提高整体生产力，避免工程师感觉他们被安全团队控制了。

长反馈循环

开发人员讨厌被拖慢或被打断。不幸的是，遗留的安全测试系统通常有很长的反馈循环，这会对开发人员的速度产生负面影响。无论是复杂的自动扫描，还是要求安全团队完成人工审查，这些活动都是摩擦的根源。它们增加了进行更改和验证其效果之间的延迟。

具有许多不同工具的安全套件可能会导致上下文切换和多步缓解。此外，工具也不总是能够发现旧代码中的问题。仅扫描管道中的新更改可以最大限度地提高性能，但是随着更多漏洞的出现，这可能会导致疏忽。

同样，每当漏洞影响时，开发人员都必须重新熟悉旧工作。这是一种认知负担，会进一步增加修复的总体时间和精力。很多时候，这些问题加在一起会形成一个低效的安全模型，该模型会阻止及时的补丁并消耗开发人员的生产时间。

变革能力不足

安全部门可能认为开发人员不愿意确定修复的优先级，而开发人员可能觉得自己没有能力解决问题。这可能有很多不同的原因：

开发人员可能不具备准确的特定于安全的知识。定义期望和建立基线标准是安全团队的职责。如果非安全工程师不熟悉常见的攻击向量，在代码的未知部分工作，或者没有被引入组织的安全标准，那么他们可能无法实施良好的安全实践。

开发人员可能很难保持更新。开发人员全职负责开发功能，如果没有足够的时间和教育来定期磨练他们的安全技能，他们可能会落后于他们的安全知识。定期更改安全预期会导致开发人员退缩，突然责成他们解决昨天、上周或上个月可接受的代码中的一系列新故障。开发人员会觉得他们一直在与一场他们无法影响或完全解决的危机作斗争。

外部压力会阻碍良好的意愿。即使开发人员想要优先考虑安全性，其他尚未认识到其价值的利益相关者也会阻止他们这样做。产品经理和业务主管可能会迫使开发人员专注于新功能，即使这意味着放弃计划中的安全补丁。

如何改变开发人员的想法

在听取开发人员讨论他们不愿从事安全工作之后，您可以改变您的流程来改变他们的想法。旨在为开发人员提供支持，以便他们可以为解决安全问题做出贡献，而不会降低他们的工程生产力。

提高清晰的安全工具链

首先，确保开发人员拥有方便的工具来识别和修复风险。尽可能多地自动化安全流程，以节省时间并获得更准确的结果。您的工具应该完全集成到您的流程中，同时保持足够的专注以在紧密的反馈循环中快速运行。

您可以在此处包含多个元素：

• 静态应用程序安全测试 (SAST)以发现已知的有问题的编码实践
• 软件组成分析 (SCA)以识别代码中的漏洞
• 动态应用程序安全测试 (DAST)以探测应用程序的端点并发现实时漏洞
• 扫描提交以查找暴露的秘密以避免暴露敏感凭证
• 监控系统以检测异常的开发人员活动，例如恶意代码和欺骗身份

您的工具应该为开发人员提供简单的解决方案来修复已发现的风险，以及代表他们自动修复的任何通知。没有补救措施的问题列表只会减慢您（和您的开发人员）的速度并导致警报疲劳。可行的见解和建议的解决方案将使您不断前进。

帮助开发人员保持速度

开发计划的中断通常是工程师在安全方面最担心的事情。通过实施允许安全工作更有效地进行而不影响开发速度的机制来解决这个问题。

这只能通过传统的安全工具链部分实现。真正无摩擦的安全需要一种新方法，在每次发生变化时为您提供快速有针对性的反馈和全面覆盖。

“无管道”安全方法让您从第一天起就可以轻松建立和维护 100% 的安全扫描，并为更早、更频繁地运行安全工作流打开了大门。与传统的安全工具相比，无管道安全应该会推动开发速度的提高，因为您已经消除了管道中代码更改的需要以及不加选择的安全待办事项，有利于将安全发现直接发送给适当的人（或渠道）最有能力快速解决安全问题。

不仅如此，您还可以根据策略或开发人员在他们选择的聊天工具中单击“为我修复”来自动执行缓解措施。

将安全性视为检查，而不是 CI 管道阶段，将其转换为更易于扩展和维护的轻量级流程。安全团队无需修改 CI 配置即可注册新检查，从而减少开发人员的工作量。

考虑使用无管道模型来可靠地执行组织的安全策略并最大限度地提高开发人员的工作效率。

不要羞愧和责备

正如我们所讨论的，传统的安全工具通常会将安全漏洞推入安全积压工作中，这在整个开发组织中具有广泛的可见性。这是有问题的，原因有二。首先，安全发现本身可能包含敏感信息，这些信息更适合与单个开发人员而不是整个团队直接沟通。例如，消除暴露的秘密。

但对于开发人员与安全协作的主题而言，更重要的是，将引入的安全风险归咎于开发人员的范式对于吸引开发人员参与这一事业是适得其反的。为了使安全性真正以开发人员为中心，应该为他们提供可操作的反馈，最好是直接反馈，以及在他们的常规工作流程中轻松提高代码安全性的机会。

在我们刚刚提到的硬编码机密示例中，在推送时检测到的机密应该停止推送并直接警告开发人员他们将要推送硬编码机密。不仅如此：开发人员应该收到清晰的布局路径，以快速手动修复问题或自动修复。

在这种情况下，风险在被引入生产之前就已经得到缓解，开发人员能够轻松解决问题，而且至关重要的是，避免了因可能引入的风险而受到责备和羞辱。

明确分类风险的所有权和优先级

最后，设法消除开发人员对安全所有权、责任和优先级的担忧。通过将其在组织、团队和项目级别的重要性置于上下文中，帮助开发人员了解安全的范围。

这一领域的成功取决于对安全和开发人员各自负责的内容的清晰沟通，以及安全可以代表开发人员自动化的内容。确保你告诉你的开发人员你已经通过检测和缓解推送时的秘密来自动化的“没有新的硬编码秘密”政策。

记录预期的标准和失败的直接后果可确保每次出现新漏洞时都有清晰一致的问责制。这使开发和安全团队能够迅速采取行动解决问题，而不会被责备和优先级问题分散注意力。

开发人员通常（可以理解）将安全视为新功能工作的延迟。这种看法会在软件交付过程中产生不必要的摩擦。然而，安全性是所有现代应用程序开发的重要组成部分。每个人都有责任维护良好的安全性包括工程师。

您可以通过“左移”以完全整合这两个学科来帮助开发人员和安全团队更好地合作。但是，不是将工作转移到左侧，而是转移检测和自动缓解。

向左移清除优先级。通过设置自动化工具链并为新的安全威胁建立清晰的分类系统来实现这一目标。

这将使每个人都了解每个风险的所有权和优先级。

原文始发于微信公众号（网络研究院）：如何让开发者爱上安全