安全向左，开发向右？论二者矛盾与解决之道

例如安全测试的人员吐槽：“这帮人研发啥脑回路能写出这种漏洞”、“上次都说测过这个漏洞了，这次还有”。开发人员也吐槽安全：“这样写有什么风险，你又不能证明”。听起来就像是安全向左，开发向右，各有各的难处，充满矛盾。

安全角度关注的重点在于过程——过程的安全性。所以在从事安全工作的过程中，需要通过分析去开展工作，比如业务是怎么运行的、调用了哪些组件、访问了哪些组件、身份认证是怎么实现的等。甚至很多时候需要结合自身的经验，去推测研发人员是怎么实现，去构造测试方式以及测试用例，自然有了“这研发啥脑回路能写出这种漏洞”的感慨。

开发工作更多地关注的是结果的正确性，在结果的正确性上考虑其他因素。例如连续性、健壮性、实现效率。开发人员更倾向于选择已验证的技术去达到正确的结果。只不过已验证并不是安全的已验证，而是结果已验证。例如搜索引擎里其他人是怎么解决的、技术文档里是如何解决。但是很多问题都没有标准答案，需要通过一个个小问题的答案的组合，所以开发人员往往是通过组装的方式，不会去关注中间过程是如何实现的。

安全人员的知识体系的储备是从安全的角度出发的，以XXX漏洞原理、XXX威胁、风险为主，围绕这些相关的案例和实践经验进行学习和成长。而开发人员的知识体系储备则是从语言规则、工具包、设计模式、算法这些内容为主，可以说是完全不相同的维度。

苛求开发人员能像安全人员一样，避开所有漏洞是不太可能的，甚至可以说安全不是开发人员的第一优先级，而安全人员往往对于研发的技术不太熟悉，很难给出能直接可供研发人员使用，达到安全目标的建议。

大多数情况下，安全人员不是开发多团队协作里的一环，开发团队确保的是应用系统的快速交付上线与迭代更新，而安全团队需要确保待上线的系统是满足监管与安全要求的。跨部门协作，各自团队与角色工作目标不一致，自然会有很多“矛盾”。

安全团队认为开发不配合，给业务带来巨大安全隐患，也造成后续不必要的安全投入；开发团队认为安全就是来添麻烦的，既要又要还要。

从更高维度的企业角度来说，开发和安全并不是对立的两个事情，不是要安全还是要开发的选择题，安全、稳定、可靠的应用系统支撑业务发展才是共同的目标。

安全开发必然多团队配合的工作，消除矛盾、确立共同目标才有协作的基础。这就对安全团队提出了更高的要求。

我们其实在聊安全的时候都离不开风险这个概念，都听过一句话“绝对的安全是不存在的，安全是相对的”， 绝对安全大家可能都知道，但是什么叫相对安全就是一个大大的问号。从开发人员角度，就会出现——“既然永远有问题，那么还需要做安全吗”的疑问，而安全人员也会陷入到需要一直一直找漏洞和风险的情况，甚至以数量作为KPI，这极大地强化了开发和安全之间的对抗，针对多个漏洞和风险进行挑战和复议，难以推进协作，反而造成了大量内耗。

弱化安全对抗的第一步是跳出提升漏洞数量的陷阱，其实安全和开发的出发点都是一样的，希望应用系统的风险越来越小。从安全质量的角度上来看，安全团队的理想情况是测出的漏洞和风险是0个，而开发团队的理想情况是编写的漏洞和风险是0个。

但是由于风险属性的存在，0个是很难存在的情况，所以第二步是尝试对相对安全的标准进行细化，围绕这个相对安全的标准工作就能更加容易得达到“0个”得目标，无论安全还是开发都可以围绕标准部署工作，从某种意义上消除摩擦，避免后续在具体工作上的矛盾。

赋能不仅仅只是一些培训，更多的需要建立起相互理解和认识，但是由于过于庞大的开发团队，往往需要安全团队优先行动起来，从开发人员一贯思路上提供助力。

安全团队构建起安全需求以及威胁的知识库，通过威胁建模工具的方式（例如安恒安全需求分析工具）帮助开发从系统、业务等角度识别各个安全需求，细化开发任务，落地安全质量标准。

安全团队与开发团队一起设计一些常用的安全工具方法，例如安恒信息的安全开发SDK，开发人员不需要再用考虑如何组件的设计是否安全，重新回到如何组装这些组件、工具去解决问题的角度上。

但是这些并不代表着开发团队不需要行动起来，所有这些措施里都包含了大量的安全知识和经验，如何掌握和使用这些信息，从来不是一件轻易的事情，哪怕它们已经做得非常清晰、完善、通俗易懂。

开发和安全需要互相认识、理解，才能真正的协作。

这里不仅仅是说某个开发流程的协作，而是思路上的转变，围绕思路的转变去设计、调整协作流程。

可能有的人会问，你说的转变是安全团队既管杀也管埋吗？做到漏洞的检测发现到修复一条龙。

确实，这是转变的一部分，但是除了这个意外很重要的一点是开发与安全团队现在是以系统的安全质量为共同的目标，那么就不能是以问题导向为唯一目标了，问题、bug、安全漏洞的修复不是闭环的终点，需要将发现的问题推回到整个体系中，优化流程，发现知识体系的残缺、工具规则的优化等等，通过PDCA中A去实现闭环。

安恒安全开发一体化平台概要