I would like to view this page in
DevSecOps 将安全做法融入开发的每一个阶段,确保在不减慢 CI/CD 管道速度的情况下尽早解决漏洞。
DevSecOps 强调了将安全测试和做法纳入软件开发流程的重要性。 将安全性工作左移有助于确保快速交付不会带来安全漏洞。
DevSecOps 是一种基于 DevOps 方法的软件开发方式。 正如“DevOps”融合了“开发”和“运营”,“DevSecOps”将开发、安全和运营结合在一起。 增加“安全”强调了将安全考量因素纳入软件开发生命周期每个阶段的重要性。
DevSecOps 的目标是让团队能够更快、更高效地交付软件,同时保持代码库不存在安全漏洞。 这种策略可以保护组织和用户免受网络攻击。
DevOps 方法旨在加快软件交付速度,同时提高质量并减少 bug。 DevOps 起源于敏捷运动,其开发目的是为了解决传统瀑布式软件开发和交付方式中存在的问题。
DevOps 鼓励团队在这些周期中快速、频繁地推进工作,而不是采用持续数年的设计、开发、集成、测试和发布的线性流程。 为此,DevOps 倡导稳健的自动化 CI/CD 流程,缩短交付时间,提供快速反馈,从而形成持续改进的良性循环。
DevSecOps 与 DevOps 有什么不同? 事实上,DevOps 从来没有打算将安全排除在外。 不过,虽然 DevOps 运动帮助打破了开发团队与运营团队之间的界限,但信息安全团队通常仍处于孤立状态。 DevSecOps 这个术语,以及 SecDevOps、DevOpsSec 和 Rugged DevOps 等其他几个版本,都是由此而生。
使用“DevSecOps”一词提醒团队将安全纳入软件开发和部署流程。 包括:
与“左移”测试使查找和修正 bug 变得更容易、更迅速的道理一样,在开发流程中尽早采用安全做法,也会使安全做法更容易纳入,而且更有效。
软件中安全漏洞的潜在影响怎么强调都不过分。
软件安全漏洞不仅会造成经济和声誉损失,还会导致大量敏感数据泄露,包括内部文档和客户个人信息。 根据适用的司法管辖区,泄露用户数据可能招致严厉的经济处罚并需要承担法律责任。
尽管如此,传统软件安全方式仍然会让人觉得它是一种负担,而不是一项资产。 安全审核与报告会减慢进度,阻止您将最新功能送到用户手中。 不过,如果忽视软件开发生命周期 (SDLC) 中安全的重要性,可能会使下一次网络攻击登上新闻头条。
虽然这些漏洞攻击登上了头条新闻,但它们的来历相比之下其实微不足道。 存在漏洞是因为代码由人类编写,而人类会犯错。 有时,这些错误别人以前也犯过,比较容易识别(只要您知道在哪里寻找)。 不过,有时这些错误是新的,可能是各种因素以前所未有的方式结合所致。
更加复杂的是,几乎所有软件都包含依赖项(无论是开源还是专有),而且也不能保证第三方代码没有漏洞。 因此,保护软件供应链与评估自身源代码的安全性同样重要。
那么,应该如何将安全性引入 SDLC? DevSecOps 方式采用与实现更快、更稳定发布相同的原则:将安全向左移动,使其尽早、频繁地得到解决。
表面上,将安全向左移动听起来就像只需要在 CI/CD 流程中添加一个阶段,让软件可供安全团队测试和检查。
尽管手动安全测试有其价值(我们将在下面讨论),但将对安全要求的参与限制在 CI/CD 流程末尾的一个步骤意味着您将错过快速、定期反馈的好处,原因如下:
那么,左移安全方式在实践中意味着什么呢? 虽然没有放之四海皆准的解决方案,但以下工具和技术有助于在整个 SDLC 中整合安全性。
虽然共担责任文化很重要,但仅仅告诉开发团队要其对软件安全负责是不够的。 紧跟攻击途径和恶意软件的最新发展是一项全职工作,您不能期望每个人都保持相同的专业水平。
将安全卫士引入多学科团队并让其指导他人并分享最佳做法,有助于增进理解并促进与安全专员的协作文化。
理想情况下,在编写任何代码之前都需要考虑安全性。 它应该与用户情景编织在一起,在积压工作审查会议上提出,并在计划每个冲刺时讨论。 在研究如何处理新功能时,需要讨论它可能带来的风险以及如何减轻这些风险。
采用 STRIDE 等威胁建模策略,或使用 OWASP 速查表等工具,可以帮助您在学习这些新技能的同时保持正确的方向。 虽然在设计阶段考虑安全性并不能解决所有问题,但这是一个好的开始,有助于促进 DevSecOps 文化。
自动化是 DevOps 的核心原则。 它可以加快任务速度并确保任务执行的一致性,让人腾出时间进行更多的创造性工作。 如果要定期和频繁地向用户交付软件,那么在管道中添加自动化安全测试是必不可少的一步。
在编写自动化单元测试、集成测试和端到端测试时,安全功能应该和其他功能同样重要。 如果您的团队一直将安全要求纳入用户情景并在设计流程中讨论威胁模型,那么添加涵盖安全功能的测试是这项工作的自然扩展。
除了您自己编写的测试之外,还有各种安全测试工具可帮助您建立对代码质量的信心。 传统的安全扫描工具并不适合自动化 CI/CD 管道,但现在已经有了专为自动化设计的 CI/CD 安全测试工具。 这些工具集成到 CI/CD 管道中,可以通过仪表板报告结果或直接将其输入到 bug 跟踪工具中。 与所有自动化测试一样,为您的测试构建结构以尽快提供反馈也很必要。
静态应用程序安全测试 (SAST) 工具执行静态代码分析,以检查源代码中是否存在已知的安全缺陷,例如缓冲区溢出和 SQL 注入机会。 由于静态分析运行于源代码之上,所以提交更改后即可在 CI/CD 管道中尽早运行静态分析。
SAST 工具特定于语言,某些工具集成到 IDE 中,可以在编写时提供持续反馈,也可以按需运行测试。 通过引导开发者找到包含漏洞的具体代码行,SAST 工具可以提供有针对性的指导,提升解决问题的速度。 但是误报可能是一个问题,因此,如果您想避免所有 SAST 结果都变成背景噪声,则必须能够将特定警报静音或关闭。
动态应用程序安全测试 (DAST) 是 SAST 的必然结果。 这会对正在运行的应用程序采取黑盒测试,检查有无已知漏洞(例如跨站点脚本、命令和 SQL 注入)和不安全的服务器配置。 由于 DAST 工具需要将应用程序构建并部署到测试环境,因此通常在 CI/CD 管道的后期使用。
网络攻击很有可能发生。 恶意行为者经常能够在广泛使用的软件中找到安全漏洞。 这些攻击以及其他类似的攻击,都在提醒我们保护软件供应链的重要性。
我们所说的“软件供应链”是什么意思? 简单地说,就是软件开发和交付所涉及的一切。 所有软件开发都需要其他软件,例如可重用的组件与库、IDE、框架和构建工具。 软件供应链安全涉及评估您所依赖的软件的安全性和保护您的开发流程。
您可以使用软件组合或组件分析 (SCA) 工具来评估前者。 SCA 工具不仅应该抓取您的依赖项,还应该在供应链上递归抓取它们的依赖项。这是一个最好交由计算机完成的完美示例,特别是考虑到新依赖项被添加到项目的频率。
除了作为 CI/CD 管道的一部分自动运行外,一些 SCA 工具还可以作为 IDE 插件,提供实时反馈。 与静态和动态安全测试一样,SCA 测试也受限于工具可以检测的漏洞,因此应确保您选择的工具定期更新,以应对新的漏洞攻击,并覆盖与产品和组织相关的领域。
红队的概念起源于战争游戏,在战争游戏中,己方成员被要求在模拟攻击中扮演敌人的角色,以发现己方防御和策略的弱点。 同样的方式在软件开发中也产生了巨大的影响,有时是以渗透测试或道德黑客的名义,用于发现新的和意外的漏洞攻击。
红队要想有效地工作,就不能参与被测系统的开发。 与探索性测试类似,红队需要测试人员打破常规,以非预期方式使用软件。
红队既可以在临时环境(最好尽可能与生产相似)中工作,也可以在实时生产系统中工作。 如果选择后一种方式,您需要相信软件的故障模式或相信用户(和首席级高管)相当宽容。
DevSecOps 方法要求每个人都对软件的安全性负责。 现在应该停止将安全问题与“常规”错误分开考虑了。 在系统中发现的任何故障或漏洞都与所有其他问题属于同一积压工作,应与这些问题并列优先处理。
整个团队,而不仅仅是安全卫士,都应当对修正漏洞负有责任。 这将帮助每个人积累安全和专业知识,并在当前代码库和未来项目中使用这些技能。
尽管您在 SDLC 的先前阶段付出了大量努力,但黑客仍然有可能在您的实时系统中找到弱点。 仍然值得投资防火墙和监视工具来保护您的组织和用户。 运行时应用程序自我保护 (RASP) 工具是这些防御措施的最新成员,可自动检测和阻止可疑行为。