企业SDLC建设不成熟设想

1、说明

1.1 背景说明

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

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

之因此说“不成熟”，一是由于从本身感受上没有很完善，二是由于没有大量的实践证实其可靠性和可行性；而之因此要“强行描绘”，一是为了作个阶段总结，二是感受后边去T公司后短期内也没机会实践SDLC全流程。

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

 

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

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

入行：如今进入安全行业，主流途径通常是学校课上学计算机/信息安全的知识、课余本身找环境实操打打CTF，毕业后进入安全乙方安全公司、安全岗，积累必定程度后转入甲方安全岗。

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

 

2、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就是指将原来集中在软件开发生命周期后期进行的工做，散布到软件开发生命周期各个阶段去，在每一个阶段作安全该作能作的事。

 

3、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网站。