DevSecOps：软件安全捍卫者

在软件复杂度高速增加的大趋势下，避免安全漏洞成为了棘手的难题。即便在舍弃传统瀑布式线性开发、避免冗长测试报告过于拖进度而采用DevOps的情况下，开发团队与运维团队的界限已被打破，但安全问题往往仍处于被忽视的状态。

测试“左移”是广为人知的凭借更早执行测试任务提高产品质量、缩短SDLC的概念，DevSecOps可同样理解为安全“左移”。DevSecOps强调从软件构建起就注重安全性，并将安全检查部署至CI/CD流水线（点击查看详情）的每个自动化测试步骤中，比起传统在研发完成后才确认安全性更易实践，也更符合软件安全性要求。

对外行而言，实现安全“左移”只需在CI/CD流水线中设置一处安全需求限制即可，但此解决方式或因实施时间太久而被忽略，或将导致流水线整体陷入停滞、产品发布无限期推迟，DevOps最关键的团队凝聚力也将因此受损。

安全“左移”暂时没有放之四海而皆准的可供实践的解决方案，但以下观点和技术将能确保一定程度上的SDLC集成安全。

1. 指定安全专员

通过知会让开发团队对软件安全负责是远远不够的，而且掌握最新的安全漏洞、攻击媒介及恶意插件并非易事，让全员具备同样水平是既不必要也不现实的。指定一位安全专员全职负责此类事项，通过分享最佳实践来指导团队将有助于建立企业安全合作文化。

2. 让安全成为约束

将安全设定为审查会议的核查项，在增加新功能前先讨论其可能带来的安全风险及其解决方案，使安全成为每位开发人员的责任。可采用如STRIDE、OWASP等寻找潜在威胁并建立对抗的威胁建模策略来推动DevSecOps文化落地。

3. 添加自动化安全测试

自动化是DevOps的核心所在，可在编写自动化单元测试、集成测试、端到端测试时将安全视作必要条件。添加自动化安全测试可使安全自然而然地贯穿SDLC始终。

4. 使用专业工具

除了执行自行编写的测试用例，测试人员还可利用各种专为自动化设计的安全测试工具。静态应用程序安全测试（Static Application Security Testing，SAST）工具可通过静态代码分析检查源代码安全漏洞，如缓冲区溢出、SQL（Structured Query Language，结构化查询语言数据库）注入。由于SAST工具存在语言限制，测试人员可在集成开发环境（Integrated Development Environment，IDE）中按需运行测试，更快修复问题，同时也可设置特定警报驳回以避免误报。

动态应用程序安全测试（Dynamic Application Security Testing，DAST）工具独立于应用程序的代码细节，是外部的漏洞扫描程序，可通过黑盒测试检查跨站点脚本、命令及SQL注入。DAST工具需要部署至测试环境进行使用，因此往往被使用于CI/CD流水线后期。

5. 检查依赖项

几乎每个代码库都包含开源库和其他组件，处处都存在安全漏洞的可能。软件成分分析（Software Composition Analysis，SCA）工具可在CI/CD流水线早期运行自动化安全测试，保障开源组件和代码库的可见性，帮助企业管理组件安全、规避许可证相关风险。

SCA工具可以生成开源组件的全面列表，包括从应用程序构建阶段解析到项目的任何依赖项，输出开源组件的版本、来源、文件路径等基本信息，还可作为IDE插件即时提供反馈。

可参考战争游戏中的“红队”概念，将部分开发人员划分为“红队”，不参与被测系统的开发，跳出既有测试框架，在与生产环境尽可能类似的暂存环境中以非预期的方式使用软件，以便找出软件可能存在的弱点。

DevSecOps需要每位成员都对安全性负责，将安全漏洞与Bug同等对待，有助于提升团队的专业知识，在更多项目中受益。

8. 保持关注

为降低随时可能发生的黑客攻击而毁掉先前所有努力的风险，可应用新型应用安全保护技术——运行时应用程序自我保护（Runtime Application Self Protection，RASP），使程序具备自我监控能力并识别有害输入及行为，以便运维人员立即响应和进行及时处理。

DevOps的应用意味着SDLC将频繁迭代，而将安全纳入CI/CD流水线则意味着应用程序安全的反馈将与软件状况反馈一样易于获取，可像改进其他功能一样改进安全设置，通过检查和防范安全漏洞让软件保持足够的安全性。

最后，DevSecOps与DevOps一样，需要团队文化的渲染与配合，其关键在于营造责任共担的安全合作文化，每位团队成员都应对安全的重要性有着明确认知及责任意识。

参考链接

https://www.jetbrains.com/teamcity/ci-cd-guide/what-is-devsecops/