企业SDLC建设不成熟设想

一、说明

1.1 背景说明

之前在N市，面试的是“IT系统安全工程师”的岗位但合同上签的是“集成工程师”的名头（前阵子找之前的邮件offer才注意到的），工作内容现在看来还是和当时离职时表述一样基本一半是系统集成的工作一半是安全的工作。其好处是一方面对数据库、中间件、大数据平台等技术有比较深入的了解，另一方面对4A、SoC、安全基线等安全概念也有一定程度的认识。

来到S市，司职是正经的安全岗位“渗透测试工程师”，渗透能力逐渐形成了比较完整的知识体系，最后又演变成了当前的SDLC认识。

之所以说“不成熟”，一是因为从自己感觉上没有很完善，二是因为没有大量的实践证明其可靠性和可行性；而之所以要“强行描绘”，一是为了做个阶段总结，二是感觉后边去T公司后短时间内也没机会实践SDLC全流程。

其实感觉企业安全体系核心包括两方面，一是以SDLC为核心的单个应用的从设计到上线全流程，二是以SoC为核心的所有安全设备、安全系统的统筹管理。但对于后者一是自己概念就更模糊了，二是感觉即便在业界也未形成统一的认识，如果以后有更深的理解再说了。

1.2 安全行业一些不成熟预测

出身：即便到现在网上还可以经常听到某某黑客大佬不是信息安全专业出身、不是计算机学院出身、没读过大学、小学没毕业之类的说法。但就趋势而言，以后科班出身的比例会越来越高，专业知识掌握得越深的人走得越远。

入行：现在进入安全行业，主流途径一般是学校课上学计算机/信息安全的知识、课余自己找环境实操打打CTF，毕业后进入安全乙方安全公司、安全岗，积累一定程度后转入甲方安全岗。

归宿：在职业前中期更多要求技术深度，在职业中后期更要求知识广度；公司越大技术深度的存活度就越久。其实就和程序员类似，更多的出路就是管理岗，更多的公司要的就是你能给公司架起安全体系。

二、SDLC概念理解

2.1 关于SDLC名词来历

最开始听到的应该不是SDLC而是SDL，而最早开始听到SDL应该是在软件工程课上讲的微软的SDL；因为软件工程讲的是软件开发生命周期，所以我一直以为讲课一笔带过的微软SDL是“Software Development Lifecycle”。

近几个月听到很多公司很多安全岗位都讲SDLC，感觉虽然意思可以理解但安全直接占用开发的名词不太好吧，但回头一看其实出自微软的SDL并不是“Software Development Lifecycle”而是“Security Development Lifecycle”，确实本身就是一个安全名词。

一方面，可能安全人员之间说SDL或SDLC不会有歧义但与开发等交流就会有问题；另一方面，当下安全所谓的SDL就是指安全人员要介入到软件开发生命周期的整个流程中，在开发框架大体不变基础上建设安全。所以现在书面形式上更多使用S-SDLC（Secure Software Development Lifecycle）的说法（比如OWASP）。

2.2 SDLC的含义

我们前面说，当下在安全行业中，SDL、SDLC、S-SDLC都是一个意思，都是指介入到“Software Development Lifecycle”中建设安全，那具体怎么个建设法呢。

我们知道软件开发生命周期可以分为可行性分析、需求分析、设计、编码、测试、上线、运维几个阶段。在最开始的时候，软件一般是都不做安全的基本都是在运维阶段发现安全漏洞后再去进行修复；在开始做安全后发现很多漏洞完全可以在上线时自我检测发现（很多公司现在都是做到这一步在上线时设置安全关卡）；在积累到一定程度后人们又发现，检测出的很多安全问题要么都是同类原因引起的（比如SQL注入都是因为使用拼接形式）要么就是因为软件架构原因修改工作量相当大（比如原来没有水平越权防护数据库的所有资源都没有权限标识），如果安全部门在编码等更早阶段介入那就可以更多避免”翻工“的情况。

总而言之，安全中的SDLC就是指将原来集中在软件开发生命周期后期进行的工作，散布到软件开发生命周期各个阶段去，在每个阶段做安全该做能做的事。

三、SDLC各阶段安全可做的事情

3.1 软件开发开始前

安全培训：主要是告诉开发安全是什么、安全要做什么、安全怎么做的。可选的一些主题，如”渗透测试方法“、”渗透测试工具使用“、”某种语言的安全编码规范“等。

3.2 可行性分析阶段

法律法规可行性分析----针对要开发的系统，衡量其是否违背法律法规，或者有哪些需要注意的点。

3.3 需求分析阶段

安全编码规范----参与需求分析会议，了解需求，针对需求拟定相应的安全编码规范。

3.4 设计阶段

各方案数据流图----要求开发提供数据流图、设计文档，对各方案进行安全评审。

3.5 编码阶段

静态代码审计（SAST）----使用Fortify、Sonarqube等工具对代码进行扫描，一方面理解代码是否按设计实现，另一方面看是否有存在问题的地方。注意静态代码扫描误报一般会比较大要注意先自己确认，而不要一把就给开发。

3.6 测试阶段

第三方组件列表----要求开发整理使用到的的第三方组件列表，作为运维阶段的输入。主要包括组件名称、组件官网、当前使用组件版本等列。

端口矩阵列表----要求开发整理端口矩阵列表。主要包括进程名、运行用户、监听IP、监听端口等列。

手工渗透----对系统进行手工渗透测试。可参考“渗透测试思路总结”。

3.7 上线阶段

基线扫描----自行编写基线规范检测程序，在上线时要保证主机和服务都符合基线规范。可参考“安全基线自动化扫描、生成报告、加固的实现（以Tomcat为例）”。

网络扫描----使用Nessus等网络扫描器对主机进行扫描，确保服务器上运行的服务软件没有什么重大漏洞。

web扫描----使用AWVS等扫描器对web进行扫描，确保别人使用这些通用工具也扫不出什么问题。

3.8 运维阶段

第三方组件最新版本跟踪----在提供的第三方组件列中中添加最新版本一列，编写自动追踪脚本每次运行就可以在“最新版本”列显示最新版本。可参考“Python3第三方组件最新版本追踪实现”。

第三方组件CVE跟踪----编写脚本，每天爬取更新的CVE并筛选出产品使用的所有第三方组件的CVE。可参考“最强半自动化抓鸡工具打造思路”。

应急响应中心----包括SRC邮箱、SRC网站。