一个好的平衡尺度应该是综合考虑各方的技术力量、企业文化（“就是各部门领导的综合态度“）等因素……好吧，我放弃了。
![专栏特辑 | 开发安全铁三角纵横谈（二）]( "专栏特辑 | 开发安全铁三角纵横谈（二）")
一个简单的平衡尺度是在开发安全早期，双“六四“分。从开发团队等非安全团队和安全团队的直观感觉来说，双方的工作量对比为非安团队4，安全团队6；双方的责任划分为非安团队6，安全团队4。
为啥不干多少活负多少责呀？问这个问题的人，根本就不懂管理，请参考以下两句常听见的话：
开发安全的理论挺多的，目前最流行的提法是微软的SDL，大部分企业实施开发安全都说实施SDL，但用的微软的这个名，实际很少按SDL来实施的。不管如何，我们还是从SDL来梳理开发安全的主要工作吧。
主要是7个工作环节，跟国内软件工程提法做些微调则变为：
咱们从易到难来确认，一般发起开发安全工作分工的是安全团队，让安全团队接受责任和工作显然容易些。
最容易确认的是安全测试。这一部分责任在安全团队，工作内容也在安全团队，发现问题后，开发团队负责调整和修改。
然后是安全培训。虽然从培训效果来说，如果开发团队负责效果会好很多，然后从实践来说，还是安全团队负责可行，具体培训工作也由安全团队负责，或者安全团队从外部找老师来培训。
安全部署是开发团队负责，运维团队和安全团队协助，这部分争议不大。
安全编码是开发团队负责，这部分好像无争议，但其实有一个关键环节，就是源代码审计（SAST static application security testing）工作的展开对整个开发安全的落地很关键。
现在很多实践，将源代码审计作为安全测试的一部分，交由安全团队负责。从流程上，是交付测试后统一审。按现在源代码审计工具的报漏洞规则，最后肯定是上万漏洞，可直接利用的几乎没有，大家都尴尬，“改”，大幅延期；“不改”，虽然短期不死人，但也确实存在一些缺陷，总之就尴尬了。安全团队和开发团队都非常累，性价比还不高，实践效果不理想。大家总结原因是源代码审计工具不够好，可你也找不到理想的呀？其实可能一开始就分工错了。
在源代码审计出现前，开发阶段的质量控制在代码层面就是交叉检查。交叉检查一般是用于比较重要的系统开发，在开发过程中，会两人成对或者两组成对，交叉检查对方提交的代码。这种检查是在开发过程中进行的，最少一周一次，如果超过一周，由于代码修改太多，交叉检查就难以实现了。当时检查的内容主要是是否符合编码规范，编码规范则包含内存处理这种容易导致系统奔溃的地方，还有程序怎么注释充分，代码易懂等。敲黑板，重点来了——当时开发团队总结的经验是交叉检查必须及时进行，如果间隔时间长，修改代码量太大，检查的时间也长，修改时间也长，好多不规范的地方重复出现，就很难整改了。
所以像源代码审计这种安全检查，本质也是编码规范的另外一些内容的检查，按开发团队的经验，就应该及时检查，让开发团队自己负责。
在这个过程中，安全团队可以做什么呢？可以技术支持，帮着他们日常检查，解释一些漏洞，介绍一些常用的整改方式等。
在安全测试中，源代码审计就不管了吗？当然可以管，只需要审计最后一份源代码审计报告，确定遗留的漏洞的风险性可接受就通过，不可接受就让他们自己再去整改，直到获得合规的源代码审计报告再来评审。
总结一下，安全编码原则上肯定开发团队负责，安全团队支持，源代码审计（SAST）应该单独确定权责。
下一次我们将继续聊聊安全设计、安全需求、安全响应等方面的工作责任与分工问题。
原文始发于微信公众号（国舜股份）：专栏特辑 | 开发安全铁三角纵横谈（二）
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
http://cn-sec.com/archives/1166652.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论