红帽社区是一个垂直网络安全社区，融合“红帽先锋”正能量精神，每日分享最新安全资讯，提供安全问答、靶场、众测、漏洞库等功能，是网络安全爱好者学习、交流的优质社区。

SDLC

现在SDLC越来越火，尤其是在甲方安全建设的漫漫长路上，经过在甲方工作一段时间后，分享自己遇到的一些难点

首先就来到了 SDLC 安全开发流程的知识普及时间，最终落地后每个公司的流程顺序安排和叫法可能略有区别，我就以我所接触到的举个例子哈，大致流程如下：

培训–>需求–>设计–>实施–>验证–>发布–>响应

培训：安全意识培训、专项安全培训
需求：安全需求分析、质量要求/BUG数量、安全和隐私评估
设计：设计需求分析、减小攻击面、威胁建模（风控）
实施：使用指定工具、启用不安全函数、静态分析
验证：动态分析、模糊测试、威胁模型和攻击面评析
发布、响应：事件响应计划、最终安全评析、发布存档

这些大致就是企业最初都会采用的一套流程，这里顺便多拓展一下，在此基础上 OWASP 又发布了----轻量级应用安全开发生命周期项目（S-SDLC)，流程大致都差不多，大家可以++点击++了解详情。

从上面的流程以及实现方法可以看出这个确实能够解决目前企业缺乏安全管控的现状，但是如果你同我一样也是在甲方安全建设的安全人员，那你一定也会觉得这个理想很美好，但是落地很残酷，下面就来给大家分析一下必经的四个阶段

1.痛点

很多安全部门大多都是最近几年才陆续建立的，而开发部门子公司推出产品以来就有了的，本来有序的生活突然被打乱了，还要被牵着鼻子走任谁都免不了一肚子气。所以安全部门成立初期首要目标就是想尽各种方法先和开发斗法，相信每个公司都免不了经历这个流程。如果是初创小公司的话还好，产品少业务线简单很容易改造。但是如果是中等规模的公司就会变成开发和安全互相瞧不起的一个模式，因为开发人员远远大于安全人员，而且产品多时间紧，各种开发流程都是能精简就精简，如果搞不定他们领导那工作就很难推动了。而大公司的恐怖之处就来自于那繁杂的业务线以及历史积累下来的NNNNN长的代码，牵一发而动全身啊，这种公司的安全推动一般是领导下发的一个又一个的整改，耗时 1-3 年不等。

2.高点

一旦安全这边的项目成功运转起来，那速度还是很不一般的，那感觉就像是乘坐了特斯拉一样–推背感十足啊，进度会以肉眼可见的速度增长完成 0-70% 的蜕变。这时候你可能会觉得你即将走向人间巅峰，照这样下去最终企业不会有任何安全问题，手里的活也会日渐轻松。

3.长点

如果你做着这样的梦，到了这个阶段就会发现虽然你不断地给一批有一批开发培训、不断地发现一个又一个漏洞、不断地推动一个又一个整改，安全问题依然没有减少（这里指的上线前安全组内发现的问题），还是有重复的问题一遍又一遍出现，于是究其根源才发现问题依然出在了开发人员的身上。因为企业是活的，而制定的闭环是死的，但是这个闭环中的一个点----开发人员也是活的，他们也会跳槽，在跳槽时还有可能将掌握的安全知识载入简历提高身价，但是新来的开发仍然是一张白纸，因为开发的招聘中根本没有要求开发人员需要掌握安全的基本常识。他们还是会犯着以前重复出现的问题，可能在人流量较小的公司这个问题没那么明显，但是放到大公司尤其是还经常招聘外包人员那种，在这种人流量的冲刷下SDLC的培训和实施直接就没了作用，所有的问题还是压到了上线前渗透测试人员的身上，你又要忙起来了，而这是一个漫长的战役~

4.稳点

之后的日子就在优化 SDLC 的模型，减少培训的次数、转换培训的方式，在实施的环节中将常出现问题的高风险功能点都统一化整改（禁止文件路径拼接、建立权限控制表、数据库建表存储文件路径只调用id、sql语句预编译等等）中度过，稳步推进那仅剩的 10% 的进度，因为改造的功能年代之久接口之多代码之庞大无不令程序猿称叹：“我太难了~，在安全探索的过程中发现还有一个重要的坑便是开发人员喜欢使用一些开源的解析库以及框架，并理所应当的认为其是绝对安全的，之后会单独拿出来讲一讲。果然安全永远不可能做到 100%

尾声

写此文旨在记录甲方安全建设的历程，因为甲方安全建设都在探索的道路上，希望有好方法的人可以分享出自己的经验来多多交流哈~

SDLC

现在SDLC越来越火，尤其是在甲方安全建设的漫漫长路上，经过在甲方工作一段时间后，分享自己遇到的一些难点

首先就来到了 SDLC 安全开发流程的知识普及时间，最终落地后每个公司的流程顺序安排和叫法可能略有区别，我就以我所接触到的举个例子哈，大致流程如下：

培训–>需求–>设计–>实施–>验证–>发布–>响应

培训：安全意识培训、专项安全培训
需求：安全需求分析、质量要求/BUG数量、安全和隐私评估
设计：设计需求分析、减小攻击面、威胁建模（风控）
实施：使用指定工具、启用不安全函数、静态分析
验证：动态分析、模糊测试、威胁模型和攻击面评析
发布、响应：事件响应计划、最终安全评析、发布存档

这些大致就是企业最初都会采用的一套流程，这里顺便多拓展一下，在此基础上 OWASP 又发布了----轻量级应用安全开发生命周期项目（S-SDLC)，流程大致都差不多，大家可以++点击++了解详情。

从上面的流程以及实现方法可以看出这个确实能够解决目前企业缺乏安全管控的现状，但是如果你同我一样也是在甲方安全建设的安全人员，那你一定也会觉得这个理想很美好，但是落地很残酷，下面就来给大家分析一下必经的四个阶段

1.痛点

很多安全部门大多都是最近几年才陆续建立的，而开发部门子公司推出产品以来就有了的，本来有序的生活突然被打乱了，还要被牵着鼻子走任谁都免不了一肚子气。所以安全部门成立初期首要目标就是想尽各种方法先和开发斗法，相信每个公司都免不了经历这个流程。如果是初创小公司的话还好，产品少业务线简单很容易改造。但是如果是中等规模的公司就会变成开发和安全互相瞧不起的一个模式，因为开发人员远远大于安全人员，而且产品多时间紧，各种开发流程都是能精简就精简，如果搞不定他们领导那工作就很难推动了。而大公司的恐怖之处就来自于那繁杂的业务线以及历史积累下来的NNNNN长的代码，牵一发而动全身啊，这种公司的安全推动一般是领导下发的一个又一个的整改，耗时 1-3 年不等。

2.高点

一旦安全这边的项目成功运转起来，那速度还是很不一般的，那感觉就像是乘坐了特斯拉一样–推背感十足啊，进度会以肉眼可见的速度增长完成 0-70% 的蜕变。这时候你可能会觉得你即将走向人间巅峰，照这样下去最终企业不会有任何安全问题，手里的活也会日渐轻松。

3.长点

如果你做着这样的梦，到了这个阶段就会发现虽然你不断地给一批有一批开发培训、不断地发现一个又一个漏洞、不断地推动一个又一个整改，安全问题依然没有减少（这里指的上线前安全组内发现的问题），还是有重复的问题一遍又一遍出现，于是究其根源才发现问题依然出在了开发人员的身上。因为企业是活的，而制定的闭环是死的，但是这个闭环中的一个点----开发人员也是活的，他们也会跳槽，在跳槽时还有可能将掌握的安全知识载入简历提高身价，但是新来的开发仍然是一张白纸，因为开发的招聘中根本没有要求开发人员需要掌握安全的基本常识。他们还是会犯着以前重复出现的问题，可能在人流量较小的公司这个问题没那么明显，但是放到大公司尤其是还经常招聘外包人员那种，在这种人流量的冲刷下SDLC的培训和实施直接就没了作用，所有的问题还是压到了上线前渗透测试人员的身上，你又要忙起来了，而这是一个漫长的战役~

4.稳点

之后的日子就在优化 SDLC 的模型，减少培训的次数、转换培训的方式，在实施的环节中将常出现问题的高风险功能点都统一化整改（禁止文件路径拼接、建立权限控制表、数据库建表存储文件路径只调用id、sql语句预编译等等）中度过，稳步推进那仅剩的 10% 的进度，因为改造的功能年代之久接口之多代码之庞大无不令程序猿称叹：“我太难了~，在安全探索的过程中发现还有一个重要的坑便是开发人员喜欢使用一些开源的解析库以及框架，并理所应当的认为其是绝对安全的，之后会单独拿出来讲一讲。果然安全永远不可能做到 100%

尾声

写此文旨在记录甲方安全建设的历程，因为甲方安全建设都在探索的道路上，希望有好方法的人可以分享出自己的经验来多多交流哈~