安全开发团队的建设并不是每个企业的必选项，但针对安全需求的定制开发确是越来越多企业的需求。从行业整体情况看，安全需求趋于复杂化、差异化。标准的，大而全的产品未来很难满足企业安全需求。所以越来越多的企业对针对自己在某个垂类的特殊需求，定制或改造安全产品。本文从三个方面分别论述安全开发工作的一些要点，先看脑图：
从开发方式上看，一般来说有三个选择：
1、自己招人，自建团队。自己组建开发团队是很多安全团队的梦想，有了自己的团队，不仅可以全面掌控需求的实现，也可以让团队的逼格全面提升。但是涉及到申请HC的问题，需要将自主开发的优劣跟高层说清楚。在后文我们详细探讨。退一步说，如果HC申请下来了，招人的时候你会发现会有三类人供你选择①懂开发的不懂安全；②懂安全的不懂开发；③都懂的高手。土豪公司当然可以直接选择都懂的高手加盟，但是对于大部分预算有限的企业来说一定要有个抉择。我们建议选择①，原因很简单安全团队一般都不缺懂安全的人。
2、人员外包。通过人员外包的方式可以快速组建团队，但除了前期团队组建时期对人员把关之外，还涉及到三个问题。①团队管理难，毕竟生杀大权不在安全团队leader手里；②团队稳定性差，根据经验，外包开发团队的人员稳定性相对较差，可能的一种原因是开发人员没有归属感；③难以保障知识产权，代码都是别人写的，想保护知识产权的成本还是很高的。
3、定制开发项目。通过项目的方式进行定制开发，避免了招人和团队管理的复杂性。但安全开发团队至少应该在合同签署前完全明确开发需求，否则项目验收会存在很大风险。另外，后续迭代大概率还需要用之前的合作方，在流程上存在一定风险。所以定制开发项目适合需求明确，后期迭代需求不大的项目。
开发方式确定后，进入到具体开发工作，也不是一件容易的事。
首先，我们要确定自主开发范围。任何一个团队都不是全能的，就算技术是全能的，精力也是有限的，所以我们要明确什么类型的工作是可以通过自主研发完成的。我们建议通过自主研发实现的工作至少应该满足下面有三个特点之一。①市场上没有（或很少有）能解决此类问题的产品，比如针对细分领域的风控产品；②企业对某方面的需求是市场常规产品无法满足的，比如对十万台主机以上系统实现极速漏洞扫描；③安全团队可以明确的设计产品运行逻辑，一些具体的技术难点可以单独攻关，但总体逻辑都说不清楚，很可能会使项目流产。
其次，要选择一个合理的迭代方式。一般说来我们借鉴互联网公司“小步快走”的模式。近日跟某大厂专家沟通的时候得知，他们的产品迭代需求，如果两周不能完成就要拆分需求。也就是说没两周就会有一个小版本出来。这样的好处是一方面可以频繁试错，避免犯大错。另一方面可以给用户一个持续的刺激，当然toB的应用是否适用这个方法有待验证。
第三，产品设计。从笔者经验来看，系统的复杂程度和系统推广的难度成正比的关系，所以强烈建议在系统设计的时候要充分考虑易用性。尤其是非安全部门内部使用的系统（比如工单系统）的开发，一定要考虑好用的问题。另外一个加分项就是好看，一个看着舒服的系统绝对是彰显安全团队能力的捷径，尤其是给管理层看的系统，至少不能难看。
最后，代码安全。一个每天发现别人系统漏洞的团队开发的系统，如果出现漏洞是一件非常丢人的事。就像一个资深安全工程师设弱密码一样丢人。所以安全团队输出代码的安全性最好不要出现安全问题，这是颜面问题。
最后我们探讨一下 自主开发的优势和劣势。
先说优势：
自主可控：对于一些重要的产品，代码和策略上的自主可控还是很重要的。可以有效避免安全策略被轻易突破。
贴近需求：文章开头就提到过，越来越多的企业对针对自己在某个垂类的特殊需求，通用的产业产品很难完全符合这类需求。这就需要开发能力的介入。
方便迭代：在攻防技术不断迭代的今天，很难有一个能力能一劳永逸的解决某一类的问题。企业安全团队作为防御者，如果有开发能力，就能掌握产品能力迭代的主动性，在对抗中取得一定的优势。
再说说劣势：
成本不可控：除非开发需求完全明确，而且期间没有任何技术攻关工作。否则投入的开发成本就没法做到完全可控。但一个有经验的团队会对一些“坑”有充分的预估，所以也不可能完全失控。
产品价值生效较慢（对比商业产品采购）：自主开发产品对比采购商业产品来说最直接的劣势就是速度了。所以开发团队在产品研发的前期要充分考虑需求的迫切性。要平衡商业产品和自研产品之间的关系。
管理成本高：增加团队的规模，会在一定程度上增加管理成本，这很好理解。另一方面，如何平衡安全开发团队和安全需求团队之间的关系也很重要。
团队稳定性影响产品迭代速度：一般来说，企业安全开发团队不会很大（经验上看5-8人居多，当然大公司除外）。这种情况下，每个人员的流失对团队的影响就比较大，如何保证小型团队的稳定性，并对流动性进行充分预估是管理者需要思考的问题。
写在最后
总体来说，安全团队中有一个负责开发的小组对整个安全体系建设是有很多好处的。甚至有些比较精锐的团队里都是安全和开发的双料高手，但这种情况下往往出现研发成果的功能性远远超过易用性。这种“专家系统”只有专家才能使用，产品化程度很低。造成这种现象的原因也不复杂，这些“双料高手”很难有时间和精力，甚至不屑去做那些工程化和产品化的工作。所以，笔者认为如果安全团队对未来的输出成果的预期不仅仅是工具，那么一定要考虑工程化和产品化的能力。
声明：本文来自小黄的安全工作实录，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
