聚焦源代码安全，网罗国内外最新资讯！
编译：代码卫士
有时，安全和开发团队无法从二者关系中获益。这并非谁的错，只是因为工作性质不同而已。安全团队最关注的问题是保护组织机构免受应用安全风险。开发团队试图追赶进度并尽快交付客户所需特性。遗憾的是，由于安全团队和开发团队经常独自为战，因此它们的优先级会打架，从而引起摩擦。
这种摩擦可为开发团队造成一种恐惧文化，他们习惯于安全团队的苛责，但这样并不会促进开发团队的工作也无法帮助它们在build时避开风险。我们需要从恐惧文化转变为责任共担文化，快速应对安全问题并修复。就像思科CISO顾问总监 Wendy Nather 提到的那样，“应当将安全设计为被采纳接受，而非通过密谋被强制执行。”
不应衡量开发人员在应用架构中存在多少差距、犯下多少错误，而是衡量这些问题的发现和解决速度有多快。所有人都想让应用程序是安全的；我们只需要将安全和开发流程集成到无缝工作流中即可。
第一步始于安全团队如何和开发团队协作。在成功破除孤军作战和消除摩擦的团队中，它们的安全指南具备四个属性可精简工作流并使安全团队和开发团队一致。
对于开发人员而言，没有什么要比从安全团队收到一份列明应用中所有安全考虑因素的、长达25页的Word 文档更令人沮丧了。这些文档常常难以理解且拖慢工作进程，因为文档使用的语言是安全团队而非开发人员能看懂的。
比如，如果安全团队建议开发人员“保护验证器免遭越权披露或修改”，多数开发人员不知道说的到底是什么意思，即使这是一个重要的安全考虑因素。如果安全团队可以给出更容易让开发人员触达的指南，用他们所理解的语言编写，那么开发人员更可能解决这些问题。
清晰易懂的安全指南只是第一步。如果安全团队不仅仅是解释需要修复哪些地方，而是告知开发人员如何修复，那么安全团队会让开发人员的生活好过许多，而且他们的安全建议也会更快地得到执行。精通安全的开发人员很少，而且即使安全建议是可触达的，但开发人员将可能不得不做更多的工作搞清如何修复问题。
为此，要直奔主题。开发人员不需要明白某个问题的详情，强迫他们研究如何修复得不到任何好感。所有开发人员想知道的就是你想让他们干什么。提供实操性指南，让他们尽快去往绿色复选框即可。
虽然以可理解的语言解释需要修复的问题并提供实操性指南告知开发人员如何修复，但安全团队是否还可以更进一步，自动化修复这些问题？
安全团队和开发团队之间的摩擦源自开发人员坐拥自动化和速度，而安全团队却缺乏这一点。不通过 Word 文档，安全团队如何通过自动化以开发的速度前进呢？流程中的这部分要求投入时间和精力。自动化应该被纳入安全流程中，扫描部署前和部署后的潜在安全问题。
当安全团队采用了与开发团队同等的自动化，他们就能更无缝切入工作流中。
应在流程中提前引入安全性并将其纳入现有的开发生命周期和工作流中。开发人员不必等到下一次冲刺或下一个月才获得安全指南。
如果在正确的时间参与，那么开发人员就能在涉及应用时修复安全问题并涉及差异，而非在实现应用后。这种“左移”同时为开发团队和安全团队降低了风险并梳理工作流。
这些改变的实施需要改变文化。我们需要从各自为政的恐惧文化转向一体化的、现代的、自动化的工作流，安全团队和开发团队责任共担。
实现这一点需要我们衡量成功（如问题修复的速度有多快），而不是衡量失败。这种文化转型将安全团队作为开发团队的可靠顾问，并创建了这样一种认识和协作：确保每款应用设计时就是安全的。
马上免费试用代码卫士：https://codesafe.qianxin.com
为增强软件供应链安全，NIST 发布《开发者软件验证最低标准指南》
https://www.darkreading.com/application-security/4-keys-to-bridging-the-gap-between-security-and-developers
题图：Pixabay License
本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的产品线。
觉得不错，就点个 “在看” 或 "赞” 吧~
原文始发于微信公众号（代码卫士）：弥合安全和开发间隙的四个关键点
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论