摘要
对互联网行业而言，安全总是后知后觉！只有遭受损失时才想办法去弥补。互联网的历史就非常清楚的验证这个理论，早在1969年美国军方就发明了互联网命名为「Arpanet」，1973年 Arpanet 发明了 TCP/IP 协议，随后在1981年发明了一系列的应用协议如「SMTP，POP3，FTP，TELNET 」等等，在1991年，就发明了 HTTP 协议。
这一系列的应用协议都是采用明文传输的，没有进行任何加密措施，在当时如何将世界各地的人联系在一起和增加新的功能才是最高优先级。黑客非常容易就可以截取传输的内容，在经过非常惨痛的损失后才出现了加密传输协议「FTPS，SMTPS，SSH 以及 HTTPS」。假如互联网在在设计之初就对安全进行很好的的设计，就不会出现现在这么多安全问题了。
同样的情况发生在软件开发过程，安全开发的优先级永远低于功能的开发，都是在开发后期才考虑安全问题。本文主要讨论如何开发安全软件以及探讨为什么 SDLC (系统开发生命周期)是开发安全软件的最理想模型。
该模型引出 「安全设计」和「深度防御」的方案，安全开发应该是 SDLC 过程的一个非常重要的组成部分，应该在软件开发和测试的每个过程将安全完整的进去，越早期修复安全漏洞所花费的成本，时间和代价都是最低的。
应用层安全攻击
随着时间的流逝，网络攻击不断沿着 OSI 协议模型往上移动的趋势越来越明显，大多数攻击集中在应用层，在80、90年代的大多数攻击集中在 OSI 模型的1层，2层和3层，现在网络层的防护已经非常出色了，但是应用层安全仍然是一个很大的挑战。
根据 Gartner 的研究报告，指出今天75%的攻击发生在 OSI 模型的应用层。根据 Trustwave 公司的一项调查显示，82%的 Web 应用程序容易受到 XSS 攻击。根据另一项调查，金融领域80%的安全事故是由于跨网站脚本攻击导致的。因此，应用层的防御是不可或缺的。
应用层防护方案
现在市面主要有两种应用层安全防护方案，一种是应用安全防火墙（WAF），另外一种是运行时应用程序自我保护（RASP）。
WAF 可以做为一种额外应用程序保护层，但是所有 WAF 基本上是基于一个「黑名单」来判断输入是否为攻击，黑名单就是把所有已知的 Web 攻击行为归纳起来形成一个黑名单，但是相对于黑名单来说只允许有限的合法输入的白名单更有效，但是由于应用程序是非常动态的，形成白名单是非常不现实的。但是基于黑名单的保护防护方式效果不是太好，现在有太多的绕过防火墙的方式了。绕过防火墙对一般黑客都不是特别麻烦的事情。极端一点来说 WAF 可以说是形同虚设了。
运行应用程序自我保护（RASP）是防止应用层的攻击一种新方法，在运行时保护应用程序面试攻击。RASP 保护程序位于应用程序等应用程序与数据库、文件系统和网络的连接点上，识别和阻挡任何恶意活动，使应用程序能够保护自己。相对应WAF来说，RASP 熟悉应用程序的上下文，可以非常精确的识别攻击，能关键点保护程序，黑客基本不可以绕过，可以自适应云环境，这些都是 WAF 没法比的。虽然从长远来看 RASP 是应用安全防护领域的趋势，但是目前大部分 RASP 还是基于黑名单保护的基础上，技术上还没有完全成熟，同时和应用程序绑定在一起，保护代码的质量直接影响应用程序，同时在性能上也也有一定的影响。
虽然应用程序保护方案在一定程度上能防护网络攻击，但是作为底线，你不能写一个充满漏洞的程序然后依赖安全保护系统来保护。
安全的 SDLC 流程
上面讲到的安全防护措施的确能起到一定的保护作用，但是绝不是最好的办法，最好的办法就是让应用程序能真正的自己保护自己，尽可能少的漏洞。要做到这一点就需要从程序设计的初始阶段把安全考虑将来并且将安全嵌入到SDLC 即需求收集、设计、开发、测试以及实施的各个阶段。
下面笔者就详细讨论在 SDLC 各个阶段需要做哪些方面的安全工作。
需求分析
SDLC 的第一阶段是需求分析，在这个阶段确定整个项目的范围和目标，OWASP 组织推荐在需求分析时也应该把安全的需求和目标确定下来，客户的需求也应该依据相应的安全标准比如密码策略，安全网络协议等进行明确，使之符合安全标准。
设计阶段
在设计阶段：设计人员应该树立良好的安全意识，清楚现有的安全模型有哪些，应用程序可能面临哪些安全威胁，攻击途径可能有哪些，实施哪些安全策略和计划会缓解安全攻击的危害性，以及如何去实施这些安全测试。
这段视频非常清楚的介绍了安全模型方面的知识：
https://youtu.be/ZtSrcq7gscE， 能翻墙英文好的同学可以学些一下。
开发阶段
写出安全代码首先需要制定安全代码规范，各种语言都有现成的代码安全规范，企业可以根据自己的情况进行适当修改。同时要对项目中所有的开发人员培训安全编码规范，确保每个人能够完全明白如何编写安全的代码。最重要的一步就是要确保每行代码都符合安全规范，每个开发提交代码前都应该由安全专业人员对代码进行安全审查，确保代码的安全性，审查员非常关键可以是公司内部的资深安全人士，也可以聘请第三方专业人士（这种 Review 可能更客观一些）。
测试阶段
测试阶段应该进行大规模的渗透测试，使用静态 SAST 和动态（DAST）以及 IAST 进行漏洞扫描，验证所有已知的漏洞是否已经在设计和开发过程以及被修复。必须对所有模块进行彻底的扫描，条件允许的话可以使用多个扫描工具进行，因为每个扫描工具范围不完全一致。这样就可以最大限度的将漏洞消除在发布前。
还有特别需要注意的是应用程序本身逻辑的 Bug，程序是多种多样的，每个应用程序的功能逻辑是不一样的，这方面的 Bug 如果在设计和开发阶段做的足够好的话应该不会有太多 bug，同时通过功能和系统测试可以消除这方面的 Bug。
部署
在确保没有漏洞后，将系统部署到生产环境，在部署过程中应该遵守安全部署，不讲新的漏洞带入到生产环境。部署完成后再使用漏洞扫描工具进行扫描，确保没有漏洞发现。同时要确保环境配置和环境是安全的，比如 Tomcat 等容器有相应的安全配置，操作系统，容器以及使用的第三方软件保持最新的状态。
后语：
坦率地讲，这是一个比较理想的开发模式，真正能完全执行的项目很少，各种因素都会导致重功能而轻安全的情况比如：开发周期快，上线压力大，人员素质无法满足，安全资源缺乏等等。但是在这里我还是呼吁所有的软件提供商重视安全，早期安全投资一块钱，收获将是100块。
在的确没有能力去实施 SDLC 的企业，上面提到的 RASP 技术是退而求其次的选择，它在一定程度充当一个虚拟补丁的作用，可以暂时修复应用程序和第三方程序的漏洞，使用 RASP 可以让企业可以将不安全的程序上线后大幅度缓解安全攻击，具备一定自我保护的能力。
本文系 OneRASP 安全总监刘再耀原创文章。如今，多样化的攻击手段层出不穷，传统安全解决方案越来越难以应对网络安全攻击。OneRASP 实时应用自我保护技术，可以为软件产品提供精准的实时保护，使其免受漏洞所累。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客