原创 Mirko Zorz 信息安全D1net
GitLab的CISO Josh Lemos探讨了从DevOps到DevSecOps的转变，指出构建系统复杂性和安全工具集成是企业面临的主要挑战，他建议简化构建系统，将安全检查直接融入流水线，并采取措施避免次优设计决策，同时，强调了以软件最小化为目标、在非阻塞模式下逐个项目启用安全工具的重要性，此外，Lemos还讨论了培养安全协作文化、利用框架制定安全策略以及通过关键指标衡量DevSecOps成功的方法，包括资产和软件清单、项目安全覆盖率、RTO/RPO以及冷启动恢复时间等。
在采访中，GitLab的CISO Josh Lemos谈到了从DevOps到DevSecOps的转变，重点讨论了构建系统的复杂性和安全工具的集成，他分享了保持开发速度、促进协作以及使用指标跟踪DevSecOps成功的技巧。
企业在从DevOps转向DevSecOps时面临的最大挑战是什么?
对于那些寻求将安全性融入DevOps实践的企业来说，其构建流程和开发者生态系统的复杂性是一个重大挑战。拥有多个构建系统，每个系统都使用定制工具且未与安全工具全面集成的情况并不罕见。此外，安全团队通常使用与开发工具相邻的工具，并因此遭受长反馈周期的困扰。
在DevOps中，开发者可能每天部署代码数十次或数百次，而扫描器(例如静态应用安全工具(SAST))通常按计划运行，这会导致反馈循环出现延迟，这种模式在采用单一仓库(mono repo)的企业中最为普遍。
企业在从DevOps转向DevSecOps时必须是有意为之。将构建系统简化为一个通用的技术栈，使团队能够使用通用的工具链为其所有软件项目配备工具，这样做带来的效率提升是巨大的，通过将安全检查直接构建到流水线中，可以实现短周期时间。
企业应采取措施简化安全在其系统中的实施，以避免因次优设计决策(如难以维护的代码和冗余依赖)带来的复杂性，这些决策可能会创建更大的攻击面，并生成更多的安全扫描结果，供团队筛选、优先处理和解决。
企业还应以软件最小化为目标进行开发，即他们应有意识地选择采用的工具和决定构建到其代码库中的内容，这有助于移除依赖项、提高软件供应链的安全性、减少扫描器噪声，并减轻开发者修复非关键问题的负担。
在不显著减慢CI/CD流水线速度的情况下，集成安全工具的实际方法有哪些?
CI系统是静态工件(如基础设施即代码(IaC)、软件成分分析和SAST)的最佳内省点，这些工具可以在非阻塞模式下逐个项目启用，直到它们与环境良好适配。
AI驱动的工具可以帮助企业加速常规任务(如代码分析)，并在不离开开发工作流程的情况下提供可操作的修复措施。通过为大型语言模型(LLM)和开发者提供上下文，并在联系安全团队之前或代替联系安全团队的情况下，识别安全反模式的解决方案。
企业如何培养一种文化，让安全被视为所有团队的共同责任?
我们已经看到安全成为工程团队实践中的转变，并且可以预期两者之间的界限将继续模糊。
在许多企业中，安全测试在软件开发生命周期中发生得太晚，这会导致团队在准备发布软件时感到沮丧，但因为漏洞发现得太晚而被迫延迟。
团队可以通过采用基于可重复用例的经过测试和保证的设计模式(即“铺路”方法)来避免这种情况。
采用铺路方法会减少一些灵活性，但最终会减轻工程团队的操作负担和返工，它还提高了安全性，使安全团队和开发团队之间能够进行更多的协作。
然而，随着AI的采用和软件开发的相应加速，企业必须建立系统和框架，以优化最大的安全效益。培养协作文化至关重要，但安全和工程团队还必须共同努力，重新思考软件开发的基础方面，如优化现有代码库，并构建可扩展的、以工程为中心的解决方案，以便企业内的技术团队能够无缝采用。
像OWASP Top 10或NIST 800-53这样的框架在为DevSecOps制定安全策略方面扮演什么角色?
NIST 800-53等框架被用作控制框架，帮助企业了解在CI/CD环境中可能使用的工具，然而，框架并不是观点，企业必须基于威胁模型和业务需求来确定其技术栈，OWASP Top 10是旨在告知企业常见威胁类别的列表，不应将其编入政策中。
哪些指标对于跟踪DevSecOps计划的成功最有用，企业如何实施主动监控以在漏洞成为威胁之前加以解决?
为了衡量DevSecOps的成功，我们必须超越传统的安全指标，并关注那些反映开发、安全和运维一体化性质的指标。
从安全领导力的角度来看，我优先考虑以下四个关键领域：
资产和软件清单(包括软件物料清单(SBOMs))：全面的清单提供了对攻击面的基本可见性，通过数据库关联实现有效的漏洞管理。纳入SBOMs为软件组件和依赖项添加了详细的细节，从而增强供应链安全性和精确的漏洞跟踪，支持主动监控、自动化扫描和优先修复。
项目的安全覆盖率：量化软件开发生命周期内的安全集成至关重要。通过SAST、DAST、SCA和渗透测试衡量代码覆盖率，可以实现早期漏洞检测和修复。分析漏洞数量/严重性有助于风险优先排序，而跟踪覆盖率则揭示了测试的有效性并有助于合规性。
恢复时间目标(RTO)和恢复点目标(RPO)：这些关键指标衡量韧性，并在中断后最大限度地减少停机时间和数据丢失。RTO(可接受的停机时间)和RPO(可接受的数据丢失)反映了潜在的业务影响。定期根据RTO/RPO测试恢复能力，可以验证恢复策略和备份程序，通常推动自动化和IaC在恢复中的采用，并增强韧性。
冷启动恢复时间：该指标衡量从最坏情况场景中恢复的能力。模拟完整的系统故障可以验证IaC和自动化部署流水线的有效性，暴露隐藏的依赖项，并提供比传统故障转移测试更全面的韧性评估。满足监管恢复目标通常取决于成功的冷启动测试，识别性能瓶颈，推动恢复改进，并展示对韧性和成熟DevSecOps的承诺。
版权声明：本文为企业网D1Net编译，转载需在文章开头注明出处为：企业网D1net，如果不注明出处，企业网D1net将保留追究其法律责任的权利。
（来源：企业网D1net）