新思科技:以 DevOps 的速度打造安全的软件
现代软件开发具有更多的代码、语言、平台以及部署选项。 DevOps 要求自动化最大限度地提高速度。而这些都意味着更多的安全风险。因此,DevSecOps 开始受到关注,从软件开发初期就进行全生命周期的安全管理。新思科技(Synopsys)近期发布的《2020年DevSecOps实践和开源管理报告》显示 DevSecOps 在全球范围内迅速增长。总计 63%的受访者表示他们正在将一些 DevSecOps 活动融入其软件开发计划中。
那么,如何将安全置于 DevOps 之中呢?
引入 DevSecOps
向 DevSecOps 过渡极具挑战性。一方面,虽然目前主要是安全小组独立地负责安全,但逐渐开发团队也参与进来,共同负责安全和预算,使安全成为开发流程不可或缺的一部分;另一方面,开发团队正在通过自动化和持续改进流程来优化速度,实践 DevOps。
许多团队缺乏全盘计划,忽视了管理风险。团队没有采取审慎的、深思熟虑的方法来提高安全,而是陷入一种僵局。团队试图使一切运行得足够快,以跟上 DevOps 的步伐,但由于信息量太大,以至于他们不知道从哪里开始才能改善流程。
在不影响速度的情况下为 DevOps 增加安全
从切实降低风险的角度出发,从整体上解决安全问题的最佳方法是什么?答案是更高效的自动化。开发人员不必在每次更改代码时都运行全面扫描,而是根据上下文使用智能测试,并决定要运行的内容、运行时间以及运行方式。
逐步提升安全
让我们看一下软件开发中安全测试的典型演变。也许从部署静态应用安全测试(SAST)开始。仅分析集成就有许多可能性:
分析每次提交
分析每个推送请求
分析主要版本
选择分析检查器
配置分析检查器
接下来,您决定进一步提升安全性,添加软件组成分析(SCA)。您可以将其单独集成到管道中,但是仍然有很多其它选择:
扫描应用程序
扫描部署容器
选择扫描粒度和其他配置选项
识别通用漏洞披露(CVE)公布有违反政策的组件
识别 CVE 公布的组件在通用漏洞评分系统(CVSS)的评分
识别操作风险高的组件
识别有一定许可证风险的组件
将扫描结果的总结上传到风险追踪系统
每个不符合要求的组件信息都将发送到风险追踪系统
将策略当作代码
策略很重要。要求所有应用程序开发团队使用静态分析是一种简单但无效的软件安全策略。更有效的策略应该根据需要指定要使用的工具、所需的配置,最重要的是,可以指定在发布应用程序之前所需的结果类型。
阐明策略的好方法是采用机器可读文件的形式,有时将其称为代码(我实际上并没有将其称为代码;它实际上是一个配置文件,可能是 JSON 或 YAML)。
DevSecOps 中安全层的关键功能
这里的“策略”描述了应该进行哪些测试、规定需要什么样的结果(或将停止构建或部署)、将什么样的结果发送到常规问题追踪系统、需要进行哪些合规性活动等等。可以有多个策略,每个策略反映不同类型的应用程序和不同类型的风险状况。
根据策略的规定在开发管道中的特定事件上执行相应的测试,但是针对项目的当前状态进行了优化。安全层处理与工具的集成。
与安全层的轻量级集成发生在特定事件(例如合并请求)上。安全层旨在简化集成。
什么时候应该做安全防护呢?在发生代码仓提交或代码仓合并请求之类的事件时,管道会要求安全层执行安全测试。安全层可以发挥一些强大的魔力,我们称之为智能编排(Intelligent Orchestration)。首先,它参考策略来了解哪种安全测试是适合的。根据策略,安全层可以优化测试的执行方式。例如,如果开发人员刚刚对 CSS 文件进行了更改,那么 Intelligent Orchestration 会意识到完整的 SAST 扫描和 SCA 扫描是不必要的。对于更改特定模块中的几个 Java 源文件,可以执行增量 SAST 以优化速度。
那是否合规呢?开发管道可以要求安全层对项目是否合规做出判断。
我们如何处理安全问题?可以按严重性对结果进行分类,通过 CWE Top 25 或 OWASP Top 10 进行检查,也可以根据需要进行过滤和排序。您可以将结果整合到 Tableau 或 Power BI 之类的分析工具中。您可以制作图表,显示随着团队努力解决安全问题而使得错误(和风险)下降的趋势。
使用安全集成层还可以简化添加新的安全测试工具或替换现有工具的流程。每个新工具都集成到安全层中,但是开发管道和安全层之间的接口保持不变。
为未来做好准备
软件安全是一个蓬勃发展的领域。如果您试图建立 DevSecOps 策略,那么确定所需的工具和流程可能会面临挑战。有了安全层,您开发过程中的集成就不需要更改。您只需要从安全层集成到新工具,然后调整策略即可。
评论