安全是个“无底洞”，没有一个企业的安全负责人会说自己的系统是百分百安全的，安全也不是特别好衡量和量化，尤其是定量地评估出谁比谁做得好、好多少。有时候也会反思，或者说迷茫，“上了那么多防护手段、到底能不能经得起对抗？”，“安全自研产品做了半年、用了半年、然后有一天它被废弃掉了”，“SDL喊了好几年了，怎么就运营不下去呢？”，“业务主动过来寻求支撑，可是我们手里没有核武器。”......
本文将介绍宜信安全建设不同阶段的思路和成果，每个阶段遇到的挑战、踩过的坑，以及收获的心得和体会，分享宜信内部安全产品的发展，探索企业安全建设路径。
一、背景
2013年，公司正式开始进行安全建设，投入资源成立专门的安全团队、搭建基础安全设施。宜信公司的安全建设自开始至今大致可分为三个阶段：
2013年-2016年处于V1阶段。V1阶段主要实现了：基础的安全环境（如防火墙、区域隔离、主机IDS、网络IDS、网络准入、防病毒等等）；在上市前后通过合规检查工作逐步建立和完善了公司的信息安全制度，通过了等保三级、ISO27001认证；在2016年建立了自己的安全应急响应中心。
2016-2018年处于V2阶段。V2阶段的主要成果是完善了安全技术，提高了安全工作覆盖的范围；参与了部分业务安全相关的工作（账号安全、反爬虫、短信接口攻击、人机识别等）；确定了SDL的相关流程（没有特意去实施，只是使用了其中一两个方法）；开发了漏洞扫描、GitHub监控等一些安全工具。
当前处于V3阶段，未来应该还会持续1-2年左右的时间。在这个阶段，我们开始追求构建更加贴合企业长期发展、在某个点更专注更深入的安全能力，比如安全运营的能力、数据安全的能力。
二、几年前的状态
上图是之前总结的行业里信息安全所处的状态和发展情况，以及截止2016年我们在安全上完成的一些项目。那个阶段在网络边界、IT等方面的工作，打下了比较扎实的基础，包括网络准入、终端DLP、防病毒等已经实施完成。在基础安全尤其是终端安全效果尤为显著，保证了内网、办公网处于一个相对安全的环境，不用天天紧急应对木马、勒索病毒、甚至APT这类安全事件，可以释放更多的精力去做更有意义的事情。
三、SDL实践 3.1 SDL流程
本阶段我们重点参考、借鉴了唯品会安全团队分享的SDL流程，挑选了适用我们现状的几个重点环节，包括培训、安全编码规范等，在公司进行推广。重要的项目安全也会参与安全需求评审，与业务、产品、技术等团队建立了很好的合作关系。
值得一提的是，在企业，与安全的合作可以分为两种：一种属于“免责甩锅型”、一种属于“合作共赢型”。两种类型，遇到涉及安全的事情，表面上都会找到安全，但内在的动机却是大相径庭。第一种更多的是为了免责，事情我通报你了、问题我抛给你了，甚至为什么要找安全、找安全解决什么需求问题都不知道也不关心，剩下的都与我无关了，出了问题，安全来背锅；第二种更多的是为了寻求安全的协作，我知道可能会有哪些安全风险、我有特别关注的业务上的安全需求，我需要和安全一起配合解决产品的安全问题，确保上线后系统、业务的安全性，两个团队相互促进和提升。
两种类型在合作方式、日常互动、最终的安全效果上截然不同。造成这种局面可能有多种原因，包括：非安全人员的综合能力和素质、安全培训的有效性、安全团队的专业性和影响力（安全是否真的帮别人解决过痛点、双方是否一起扛过枪）。
3.2 SDL案例
上面两张图展示的是我们做得比较好的地方，称之为SDL或DevSecOps都可以，是自动化嵌入到发布过程的，重点解决了第三方组件的安全问题，既可以快速在发布过的软件制品里检索出包含的第三方组件，也可以定义规则直接在构建过程中对包含存在严重漏洞的组件直接阻断。这部分工作可以完全实现自动化，支持Maven、Gradle、Docker等，并且不会影响持续交付的能力。统一的资产管理、代码库、软件仓库、CICD平台实施起来会更加便捷，维护成本也最低，当然这离不开DevOps团队的能力支持。
3.3 SDL威胁建模