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