微软、谷歌、亚马逊、IBM 和甲骨文如今都在关注云上的 DevOps。这些大公司正在给企业提供 IT 自动化的服务。然而，DevOps 仍然在持续的演进中。DevSecOps、AIOps 和 NoOps 正在成为下一个流行词。随着开发和管理人员看到及时交付高质量软件的商业价值， 敏捷 Agile 方法论和 DevOps 也变得流行起来。拥有灵活的发布周期，并且交付具有 可扩展 scalable 和 可定制 customizable 的软件，是世界上每个企业的目标。通过将 CI/CD 工具和 管道 pipeline 部署到云端，DevOps 使发布过程变得更加流畅。融合了 DevOps 的 Polyglot 微服务架构正在帮助企业降低总拥有成本（TCO）。他们现在有能力用渐进式网络应用程序和最新的 UI 框架升级他们的技术栈。总的来说，团队正在以更好的效率执行任务，并且正在开发高质量的软件模块。自治 DevOps容器和 DevOps 与云原生应用走到了一起。Kubernetes 和 Docker 正在被用作容器，一个新的名词 NoOps 现在正在流行。对于不同的容器， 编排 Orchestration 都是一个重要的功能。为了扩展应用，开发环境中要创建容器集群。有一些新的容器正在进入云原生应用这个领域，比如 Mesos、Swarm、Openshift Rancher 和 Nomad。NoOps 有助于缩短编码周期，从而监控和管理应用程序。缺陷修复和热修复是不同的活动，它们都是 NoOps 的一部分。NoOps 有助于提高技术团队和业务运营人员之间的协同作用。它也有助于更好的监控、管理和流程自动化。NoOps 基础设施能够控制应用程序在云上的部署。企业从中获得的好处包括更好的交付、弹性的服务、更快的发布、良好的质量和 CI/CD 自动化。DevSecOpsDevSecOps 算是另一个流行趋势，它与在开发操作中的安全问题有关。最近与 漏洞 vulnerabilities （log4j）， 安全泄露 security breach （谷歌、脸书、微软），和安全攻击相关的问题增加了 DevSecOps 在企业中的重要性。 左移 shift left 方法强调了在软件生命周期的早期处理安全性和质量的重要性。在架构阶段就需要考虑隐私和 遵从性 compliances （如 GDPR）。这有助于降低成本，并且提升软件交付的速度。审计工具和安全检查列表是 DevOps 工具和系统的一部分，现在我们称为 DevSecOps。AIOpsAI DevOps 现在被称为 AIOps。据预测，将来 AI 应用会由 AIOps 来管理。与 AIOps 相关的工具和软件正在开发中，并且将很快发布首个版本。AI/ML 应用部署和模型更新可以由 AIOps 来处理。这将在 工业 4.0 Industry 4.0 以及数据科学中扮演重要角色。有一种观点认为，NoOps 将会是 AIOps 的最终形态。AIOps 包括数据集管理、模型训练、模型服务、元数据管理、模型更新和服务更新。分布式训练将由 AIOps 来完成，这会提供 超参数 hyper parameter 优化，工作流程管理和“ 假设 what if ”的分析能力。微服务配置管理当前，DevOps 和微服务正在成为标准部署和 架构蓝图 architectural blueprints 来实施。应用可以在模块级别上就进行扩展。微服务可以在简化缺陷修复和问题区域隔离上提供帮助。经过设计，微服务可以通过添加更多 计算能力 computing power 的 实例 instances 来进行扩展。但是当它们没有被正确实现的时候，数据安全和管理的问题就会突然出现。平台即产品云上的 软件即服务 Software as a Service 和 平台即产品 Platform as a Product 最近非常流行。通过加速向平台部署和功能交付，DevOps 使这些变成现实。从编码到上线阶段，CI/CD 管道有助于可视化应用的部署。持续交付、集成和部署都是 DevOps 的一部分。DevOps 生产线模拟工业生产线是未来要关注的。DevOps 正在慢慢地向 DevSecOps 和 AIOps 转变。对于企业，NoOps 才是未来。现在需要的是减少与安全相关的攻击、事故和破坏发生。对于企业来说，数据安全和隐私的优先级更高，并且这些新技术都将在这方面有所帮助。via: https://www.opensourceforu.com/2022/09/where-is-devops-headed/作者：Bhagvan Kommadi 选题：lkxed 译者：Yufei-Yan 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。什么是《代码英雄》 代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。本文是《代码英雄》系列播客第二季（5）：关于 DevSecOps 的故事的音频脚本。导语：不良的安全和可靠性实践会导致影响数百万人的中断。现在是时候让安全加入 DevOps 运动了。并且，在 DevSecOps 的世界中，我们可以创造性的提升安全性。每月发现一个漏洞曾经是常态。而现在，由于敏捷流程和 DevOps 团队，软件开发的进展迅速。Vincent Danen 告诉我们，这如何导致被认为是漏洞的东西急剧增加。前亚马逊灾难主管 Jesse Robbins 介绍了公司如何为灾难性故障和漏洞做好准备。而 Elastic 的产品安全主管 Josh Bressers 则展望了科技领域安全的未来。我们不应该把安全团队当成脾气暴躁的妖怪。听听 DevSecOps 团队如何将英雄们聚集在一起，以实现更好的安全。00:00:01 - 众议院小组委员会代表：1991 年 6 月 26 日，在华盛顿特区，马里兰州和西弗吉尼亚州的大部分地区，以及我的家乡的大部分地区都因公共电话网络的大规模故障而瘫痪了。然而，随着技术变得越来越复杂，网络系统越来越相互依存，反复发生故障的可能性也会增加。似乎并没有警告说会发生这种情况。00:00:23 - Saron Yitbarek：在 20 世纪 90 年代初，有 1200 万美国人遭受了大规模的电话网络故障。人们不能给医院打电话，企业不能给客户打电话，父母不能打电话给托儿所。对于一个基础设施严重依赖于万物互联的计算机系统的国家来说，这是一场混乱也是一记警钟。这些计算机网络变得越来越大，然后当它们出现故障时，故障时间就会很长。00:01:01：电脑故障会导致电话系统崩溃。在今天代码中的一行小错误的后果比以往时候都要严重。00:01:15：我是 Saron Yitbarek，这里是是红帽公司的原创播客节目《代码英雄》。00:01:24：因此，软件安全性和可靠性比以往任何时候都重要。传统的瀑布式开发方法，安全性只是一个附加流程而已，已经不再适用。我们生活在一个 DevOps 的世界里，一切都变得更快、更敏捷、扩展性更强，这在电话网络崩溃时是他们无法想象的。这意味着我们的安全和可靠性标准必须不断改进，以应对这些挑战。00:01:55：在本集中，我们将研究如何将安全性集成到 DevOps 中，我们还将探索在运营中构建可靠性和弹性的新方法。即使在介绍了所有这些之后，我们知道还有很多东西可以讨论，因为在 DevSecOps 的世界里，对于开发人员和运营人员来说，事情都在快速变化。这些变化意味着不同的事情，这取决于你的立场，但这是我们的看法。我们也很想听到你们的消息——所以如果你认为我们错过了什么，不要害羞——在网上联系我们。00:02:34：好了，让我们开始探索这个全新的领域吧。00:02:43：事情就是这样，让安全性和可靠性跟上时代的步伐，并为 DevOps 世界做好准备，这意味着我们必须对工作方式进行一些关键的调整。第一，我们必须拥抱自动化。我的意思是，想想双因子认证的逻辑。想想那些难以想象的艰巨任务吧。很显然，你不能仅仅通过增加员工来解决问题，所以第一点就是拥抱自动化。00:03:15：然后，第二点，这个可能不是那么明显，那就是它真的改变了文化，使安全不再是一个祸害。稍后我将解释我所说的改变文化的含义。但是让我们一个一个的解释这两点。首先，拥抱自动化。00:03:42：以前，应用程序的部署在每个单独的发布之前都涉及到一个人为的安全审查，我不知道你是否注意到了，但是人为的审查可能会有点慢。这就是为什么自动化是在 DevOps 构建安全性的关键部分。以 Verizon 最近的数据泄露报告为例。他们发现，81% 的与黑客相关入侵涉及密码被盗或者弱密码。从表面上看，这是一个非常简单的问题，但是规模却很大。就像我之前所提及到的，你不能用工作人员去解决 3000 万个密码问题，对吧？问题在于解决大规模问题，而每次的答案都是一样的。那就是自动化，自动化。00:04:36 - Vincent Danen：如果你等待人参与进来，那么规模就不会扩大。00:04:41 - Saron Yitbarek：Vincent Danen 是红帽公司产品安全部门的主管，在过去的 20 年里，他见证了 DevOps 的快速发展。安全团队不得不竞相追赶。00:04:56 - Vincent Danen：刚开始的时候，每个月都有漏洞，后来变成了每隔一周，然后是每周都有。现在，每天都能找到几百个漏洞。00:05:08 - Saron Yitbarek：有趣的是，Vincent 说，随着安全团队的发展，实际上会出现更多的漏洞，而不是更少。00:05:17 - Vincent Danen：我们永远不会说，哦，我们现在安全了，我们做完了，我们的工作结束了。安全审计会一直存在，就像呼吸一样，这是必须要有的。00:05:27 - Saron Yitbarek：事实证明，对于安全性和可靠性团队来说，细节的问题变得越来越重要。00:05:35 - Vincent Danen：当我们在寻找这些漏洞时，我们会发现更多的东西，而且这个趋势还将继续。因为你会发现新的漏洞类型和一些我们可能认为不太重要的东西，或者以前甚至不知道它们存在的东西。我们会发现这些东西发展的速度很快，而且数量更多，因此规模爆炸性增长。知识、软件的数量、消费者的数量都促进了该领域安全性以及漏洞的增加。00:06:06 - Saron Yitbarek：一旦你将安全视为一个不断发展的问题，而不是随着时间的推移而 “得到解决” 的问题，那么自动化的理由就会变得更加充分。00:06:18 - Vincent Danen：嗯，我认为有了自动化，你可以以一种非常快的方式将这些东西集成到你的开发流水线中，这是其一。其二，你不需要人类来做这些工作，对吧？计算机不需要睡觉，所以你可以在处理器允许的情况下以最快速度浏览代码，而不是等待人类通过一些可能相当乏味的命令行来查找漏洞。00:06:44：然后通过模式匹配和启发式方法，甚至在开始编写代码的时候，你就可以知道代码中那些地方是易受攻击的。如果在你编写代码的时候，在你的 IDE 或者工具中有一个插件，它能告诉你。嘿，这看起来有点可疑，或者你刚刚引入了一个漏洞。在你提交代码之前你都可以纠正这些可疑点或者漏洞。00:07:08 - Saron Yitbarek：安全在进步。这真是一笔巨大的奖励。00:07:12 - Vincent Danen：每一天，甚至每一小时，都会有很多东西涌现出来。通过持续集成和持续部署，你写了代码，10 分钟后它就被部署了。因此，在代码被推送之前自动进行验证是非常关键的。00:07:32 - Saron Yitbarek：我们可以使用各种各样的工具来完成这个任务，不管是静态代码分析，还是 IDE 的插件，或者是一大堆其他选项。我们将在 redhat.com/commandlineheroes 上分享一些我们最喜欢的片段。00:07:53：一旦我们有了这些工具，它们将帮助我们把安全放在首位。结果就是，DevOps 被重新定义为 DevSecOps。安全被纳入到流程中。00:08:08 - Vincent Danen：就像开发人员和运维人员结合的方式一样，你将这两个规则合成到了一个规则。现在，你有了 DevOps，并将安全这第三个组件与开发和运维集成到一起，我认为这非常重要。因为事后才考虑安全性，这会使安全性变得非常被动、昂贵以及可能会损害消费者。当你一开始就把安全代入其中，你就可以完成开发工作，从头到尾进行安全检查并开始运作。00:08:44 - Saron Yitbarek：当然，就像我们在这一集的开头提到的，自动化只是一个大蛋糕的一半，而 Vincent 也明白这一点。00:08:53 - Vincent Danen：并不仅仅是一部分。不能仅仅在你的 CI/CD 流水线中随便引入一个工具就期望一切都变好。为了达到我们希望看到的最终有益结果，需要使用各种技术和行为。00:09:15 - Saron Yitbarek：自动化确实让我们做到了一半，但我们必须记住另一部分 —— 稍微模糊一点的那一部分。让我们一起来说，那就是文化部分，让开发者和运维人员都一起参与进来，这样这些问题就不再是可怕的问题。00:09:33：我们必须改变一种文化，而有些人正在学习以一种最不痛苦的方式，通过游戏的方式来做到这一点。00:09:44：现在让我们来看看事情的另一面。如今建立庞大的基础设施很容易，但这并不意味着我们应该做粗制滥造的工作。我们仍然应该努力改进我们的系统，确保可靠性，未雨绸缪。这就是 Jesse Robbins 正在努力实现的。00:10:08：如今，Jesse 是 Orion Labs 的 CTO，但在此之前，他因在亚马逊被称为灾难大师而名声大噪。在那里，Jesse 特别是在让大家至少意识到这些问题这件事上几乎是个奇才。他通过一个叫做 “游戏日” 的活动来做到这一点。让其中可能涉及成千上万的员工进行故障演练，通过灾难演练来习惯系统被破坏并了解发生的原因和方式。00:10:39：下面是 Jesse 和我在讨论，尤其是在运营方面如何建立可靠性和弹性。00:10:47：大家都知道你做了很多非常酷的事情，其中之一就是你在亚马逊做的活动 —— “游戏日”。那是什么? 是什么游戏?00:10:58 - Jesse Robbins：“游戏日” 是我创建的一个项目，通过大规模破坏来测试最脆弱系统的运行情况。如果你是 Netflix 的 “混乱猴子” 的粉丝，“游戏日” 则是我的一个可以实现类似的所有事情的东西。实际上，它非常专注于建立一种卓越的运营文化，建立大规模测试系统的能力，当系统崩溃时能了解它们是如何崩溃的以改进它们。然后还要建立一种文化，能够对事件做出反应并能恢复。它是按照事故指挥系统建模的，这是世界各地的消防部门用来处理任何规模事故的系统。00:11:56：它的诞生源于...00:11:58 - Saron Yitbarek：旁白，Jesse 早在 2005 年就经过训练成为一名消防员。在那儿，他了解了这个事故指挥系统，最终激发了 “游戏日” 的灵感。因此，所有做这些故障演练的开发人员，都要感谢 Jesse 对消防和应急管理的激情。好了，回到我们的谈话。00:12:22 - Jesse Robbins：弹性是一个系统的能力，这包括人和这些人建立的适应变化、应对失败和干扰的能力。而建立这种文化最好的方法之一 —— 建立一种文化，能够对这种类型的环境做出反应，并真正理解这些环境是如何工作的 —— 就是提供人员培训演习。这些演习可以很简单，比如重启服务器，也可以很复杂，比如关闭整个数据中心造成大规模故障等等。所以，“游戏日” 首先是一个过程。在这个过程中，你通过让整个组织聚集在一起，讨论系统如何发生故障，并思考人类对故障发生的预期。而这个演习本身就是 “游戏日” 开始时最有价值的部分之一。00:13:24：但是，当你实际对系统做了一个或大或小的破坏后。当你这样做的时候，你就可以看到每个人是如何反应的。你看到系统崩溃了，可能是之前安全的东西崩溃了，一个很容易理解的组件或者是某个东西暴露了一个潜在的缺陷。这些问题隐藏在软件、技术或者大规模的系统中，只有当你遇到极端或者意外事件时，我们才能发现。“游戏日” 的目的是为了训练员工并且建立系统让你了解他们如何在压力下工作。00:14:12 - Saron Yitbarek：所以当我听到 “游戏日” 的时候，我就会想，“这是对某个特定事件的回应吗? 它是从哪儿来的?”00:14:20 - Jesse Robbins：因此，“游戏日” 刚开始的一段时间内，因为我知道自己的角色以及作为消防员和应急管理人员的背景，因此将文化方法从注重预防失败的观念转变为拥抱失败非常重要，接受失败发生。激发我这样做的部分原因是我自己的经历，你知道，了解系统，比如建筑是如何倒塌的，市政基础设施是如何倒塌的，以及灾难是如何发生的，以及灾难给人们的压力。所以说，如果环顾我所在工作场所所具有的复杂性和运营规模就会知道，想要真的构建成一个高可靠性、持续在线环境的唯一办法就是拥抱消防服务的方法。我们知道失败会发生，这不是如果的问题，而是什么时候的问题。就像我之前的消防队长说的，不是你选择时机，而是时机选择你。你只需要在它发生的时候准备好即可。00:15:28 - Saron Yitbarek：哦，这个不错。所以当你第一次开始做 “游戏日” 并思考如何为灾难场景做准备时，每个人都同意了吗？你得到任何反对意见了吗？00:15:40 - Jesse Robbins：每个人都认为我疯了。因此，肯定有人反对。有趣的是，有一种非常简单的方法可以克服这种抵制，那就是首先创造出我称之为 “冠军” 的东西。你要教一小群人，如何以非常安全的方式工作，然后你能够使用一些信服的指标。你能够说，看，让我们只需衡量发生了多少分钟的中断，我的团队经过了这种培训并以这种方式进行操作的停机时间有多少分钟。相反，你的团队没有这个，并且似乎认为进行这种类型的培训和练习没有价值或者不重要。00:16:25 - Jesse Robbins：你一旦完成了这种事情，基本上就会有我所说的引人注目的事件。因此，经常会有断电或其他事情让组织突然意识到：哦，我的天哪，我们不能再像以前那样继续做事了。这就是你用来说服怀疑论者的方法。你一方面使用数据和性能数据，再结合指标，然后讲故事，然后等待一个大的故障或者可怕的事情发生。然后，你就可以说，如果我们要在 web 规模或者互联网规模上运维，整个组织都需要这种应变能力。00:17:06 - Saron Yitbarek：嗯嗯。所以我喜欢它的原因是它不只是停留在亚马逊内部。相反，它在传播。很多其他公司也在这么做。很多人最终接受了要为故障做好准备这个知识和过程。那下一步是要做什么？我们如何将从 “游戏日” 中学到的知识继续运用到未来的项目和公司中？00:17:31 - Jesse Robbins：我喜欢把它称为趋同进化。每个在 web 上运行的大型组织现在都采用了我提倡的事件管理基础的一个版本，并创建了他们自己的 “游戏日” 测试。比如，Netflix 将其称为 “混乱猴子”。谷歌有他们的 Dirt 计划。00:17:57 - Saron Yitbarek：那么你对未来的 “游戏日” 有什么寄望呢？00:18:00 - Jesse Robbins：首先让我感到兴奋的是，我们可以看到人们从闭门造车思维的转变。系统从根本上是相互联系，相互依赖的，而且由世界各地试图有所成就的聪明人构建和运行的。00:18:22：几年前，当我刚参加工作时，对运维工作毫不关心，我觉得那非常无趣。然后突然的，我们发现自己能够传播这样一种理念：开发人员和运营人员一起工作是在互联世界中构建和运行有意义的技术的唯一途径。00:18:44：所以我对未来的希望是，第一，我们看到越来越多的人接受这些想法并学习它。明白了当你建造了人们依赖的东西时，你有义务确保它是可信赖的、可用的、可靠的，它是人们可以作为日常生活的一部分来使用的东西。00:19:05：而且我们也看到了一种新的学科的诞生。“游戏日” 的这种思维模式正在被研究，也有博士正基于这个撰写博士学位论文。它正在不断建立中。00:19:16 - Saron Yitbarek：这真的是太棒了。00:19:16 - Jesse Robbins：也有写这方面的书，但是包含这些新资源的没有。只有少数人在会议上谈论他们认为世界应该怎么运转。所以我的那种鼓舞人心的希望是，你要明白如果你正在构建软件和技术，那么你真的成为了社会基础设施的一部分。所以作为一名消防员，我所努力贡献的一系列技能和正在出现的技术，这些技术将使它走得更远，它们是建造人们日常生活所依赖的东西的基础的一部分。00:19:53 - Saron Yitbarek：很好。这是一个很好的结束方式。Jesse，谢谢你抽出时间来。00:19:56 - Jesse Robbins：是的，谢谢。00:11:59 - Saku Panditharatne：我认为所有这些因素都不利于采用最佳软件。00:20:02 - Saron Yitbarek：在 Jesse 看来，像 “游戏日” 或者 “混乱猴子” 这样的演习是我们不断发展的科技文化的重要组成部分，但它们对于整个社会也至关重要。我很喜欢他很重视这个，因为他是对的。我们的世界取决于我们所做的工作。早在 90 年代，当电话网络开始崩溃时，这一点就很明显了。00:20:26 - 众议院小组委员会代表：我们所知道的现代生活几乎陷于停顿。00:20:31 - Saron Yitbarek：这是一种伴随的责任。我们有责任关心安全和可靠性，关心我们所建造东西的弹性。当然，当谈到在 DevOps 中的构建安全性时，我们才刚刚开始。00:20:53 - Saron Yitbarek：这是 Josh Bressers。他是数据搜索软件公司 Elastic 的产品安全主管。对 Josh 来说，尽管计算机行业已经成熟了半个世纪左右，但我们在这里讨论的安全问题却让人觉得它是刚刚才出现的。00:21:11 - Josh Bressers：实际上，就像我想说也行作为一个专业，安全仍然是非常新的东西，有很多事情我们还不是很了解。00:21:19 - Saron Yitbarek：但我们确实明白，在 DevSecOps 的世界中，有一些非常好的机会可以创造性的思考安全能达到什么成就。00:21:29 - Josh Bressers：我最近和一些人讨论了一个概念，他们利用用户行为来决定用户是否应该能够访问系统。每个人都有特定的行为，比如他们来自哪里，他们访问系统的时间，他们打字的方式，他们移动鼠标的方式。所以我认为，如果我们做得好，他们的这些行为，可以产生一些非常强大结果，如果我们能做到这一点，我们可以注意到有人在做什么。然后假设我表现的很奇怪，因为我刚刚扭伤了手臂。但你知道，另一端并不知道。00:22:05 - Josh Bressers：因此，它可能会说，这种行为就有些奇怪，我们就会希望你使用双因子认证登录，并且还会向您发送条短信或其他内容，对吧？这就从用户名和密码变成了更有趣的东西。所以我认为用新的和独特的方式来看待这些问题将是关键。在很多情况下，我们只是还没到那一步。00:22:27 - Saron Yitbarek：实现这一目标需要我们所描述的两大步骤。第一步，就是自动化，这很重要，因为……00:22:35 - Josh Bressers：人类很不擅长重复地做同一件事。00:22:38 - Saron Yitbarek：很公平。然后，我们有了第二步，就是文化，无论我们的职称是什么，我们所有人都有不安全感和责任感。00:22:49 - Josh Bressers：当大多数人想到安全团队时，他们不会认为那是一群快乐的好好先生，对吧? 一般来说，这些人都很可怕，脾气暴躁，令人讨厌，如果他们出现了，就会毁了你的一天。没有人想要这样，对吧?00:23:10 - Saron Yitbarek：但我认为我们可以克服这种偏见，因为我们必须这样想——每天都有更多的安全威胁发生，而且 IT 基础设施每天都在变得更大、更强。把这两个事实放在一起，你最好可以生活在一个被安全环绕的世界里。一个非常 DevSecOps 的世界，在这个世界里，开发人员和运营人员都在提升他们的安全，提高他们的可靠性。我所谈论的是一个自动化被整合到每个阶段的未来，每个人对这些问题的态度变得更加全面。这就是我们保护未来系统安全的方法。这是我们保持电话响，灯开，所有现代生活健康强壮的方法。如果你查一下《福布斯》全球 2000 家公司的名单，也就是前 2000 家上市公司，你会发现其中整整四分之一的公司都采用了 DevOps。集成的敏捷工作场所正在成为规则。并且在几年之内，关于 DevSecOps 的思考可能会成为第二天性。我们希望尽可能快，但是当团队中的每个成员都齐心协力时，长距离比赛实际上会更快。00:24:40 - Saron Yitbarek：下一集，我们将面临数据的大爆炸。人类已经进入了 泽字节 Zettabyte 时代。到 2020 年，我们将在服务器上存储大约 40 泽字节的数据，而这些信息大部分甚至现在还不存在。但是我们该如何让这些数据有用呢？我们如何使用高性能计算和开源项目让我们的数据为我们所用呢？我们会在 Command Line Heroes 第 6 集中找到答案。00:25:13 - Saron Yitbarek：提醒一下，我们整季都在致力于《代码英雄游戏》的开发。这是我们自己的开源项目，我们很喜欢看着它的诞生，但是我们需要你来帮助我们完成。如果你点击 redhat.com/commandlineheroes，你可以发现如何贡献。你也可以深入了解我们在这节课中讨论过的任何内容。00:25:39 - Saron Yitbarek：《代码英雄》是红帽原创播客。你可以在 Apple Podcast、Google Podcast 或任何你想做的事情上免费收听。我是 Saron Yitbarek。坚持编程，下期再见。什么是 LCTT SIG 和 LCTT LCRH SIGLCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。欢迎加入 LCRH SIG 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。via: https://www.redhat.com/en/command-line-heroes/season-2/the-one-about-devsecops作者：Red Hat 选题：bestony 译者：mrpingan 校对：bestony, wxy本文由 LCRH 原创编译，Linux 中国 荣誉推出
你更专注于安全性还是软件交付，还是可以两者兼得？技术社区中存在一种趋势，经常互换地使用 DevSecOps 和敏捷软件开发这两个术语。尽管它们有一些相似性，例如都旨在更早地检测风险，但在改变团队的工作方式层面有很大不同。DevSecOps 建立在敏捷开发建立的一些原则上。但是，DevSecOps 特别专注于集成安全功能，而敏捷开发则专注于交付软件。知道如何保护你们的网站或应用程序免受勒索程序和其他威胁的侵害，实际上取决于你使用的软件和系统开发。这可能会影响你选择使用 DevSecOps、敏捷软件开发还是两者兼而有之。DevSecOps 和敏捷软件开发的不同之处两者的主要区别可以归结为一个简单的概念：安全性。这取决于你的软件开发实践，你们公司的安全措施 —— 以及何时、何地以及由谁实施，都可能会有很大不同。每个企业都需要 IT 安全来保护其重要数据。如果企业真正重视 IT 安全，一般都会采取虚拟专用网（VPN）、数字证书、防火墙保护、多因子身份验证、安全的云存储，包括向员工介绍基本的网络安全措施。当你信任 DevSecOps 时，你就会把公司的安全问题，本质上使其等同于持续集成和交付。 DevSecOps 方法论在开发之初就强调安全性，并使其成为整体软件质量不可或缺的组成部分。基于 DevSecOps 安全性的三大原则：平衡用户访问难易程度及数据安全性使用 VPN 和 SSL 加密数据可防止数据在传输过程中受到入侵者的攻击使用可以扫描新代码的安全漏洞并能通知开发人员该漏洞的工具来预测防范未来的风险尽管 DevOps 一直打算包含安全性，但并非每个实践 DevOps 的组织都牢记这一点。DevSecOps 在 DevOps 的演进形式中，可以提供更加清晰的信息。尽管它们的名称相似，但这两个[不应混淆] 6。在 DevSecOps 模型中，安全性是团队的主要驱动力。同时，敏捷开发更专注于迭代开发周期，这意味着反馈意见会不断融入到持续的软件开发中。敏捷的关键原则是拥抱不断变化的环境，为客户和使用者提供竞争优势，让开发人员和利益相关者紧密合作，并在整个过程中始终保持关注技术卓越，以提升效率。换句话说，除非敏捷团队在其定义中包括安全性，否则安全性在敏捷软件开发中算是事后思考。国防机构面临的挑战如果要说专门致力于最大程度地提高安全性的组织，美国国防部（DoD）就是其中之一。在 2018 年，美国国防部发布了针对软件开发中的“假敏捷”或“以敏捷为名”的指南。该指南旨在警告美国国防部高管注意不良编程的问题，并说明如何发现它以避免风险。使用这些方法不仅可以使美国国防部受益。医疗保健和金融部门也保存着必须保证安全的大量敏感数据。美国国防部通过其现代化战略（包括采用 DevSecOps）来改变防范形式至关重要。尤其在这个连美国国防部容易受到黑客攻击和数据泄露的时代，这一点在 2020 年 2 月的大规模数据泄露中已经得到了证明。将网络安全最佳实践转化为现实生活中的开发仍然还存在固有的风险。事情不可能 100％ 完美地进行。最好的状况是稍微有点不舒服，最坏的情况下，它们可能会带来全新的风险。开发人员，尤其是那些为军用软件编写代码的开发人员，可能对所有应该采用 DevSecOps 的情境没有透彻的了解。学习曲线会很陡峭，但是为了获得更大的安全性，必须承受这些必不可少的痛苦。自动化时代的新模式为了解决对先前安全措施日益增长的担忧，美国国防部承包商已开始评估 DevSecOps 模型。关键是将该方法论部署到持续的服务交付环境中。应对这个问题，出现了三个方向。第一种涉及到自动化，自动化已在大多数隐私和安全工具中广泛使用，包括 VPN 和增强隐私的移动操作系统。大型云基础架构中的自动化无需依赖于人为的检查和平衡，可以自动处理持续的维护和进行安全评估。第二种专注于对于过渡到 DevSecOps 很重要的安全检查点。而传统上，系统设计初期对于数据在各个组件之间移动时依旧可以访问是不做期望的。第三种也是最后一种涉及将企业方式用于军用软件开发。国防部的许多承包商和雇员来自商业领域，而不是军事领域。他们的背景为他们提供了为大型企业提供网络安全的知识和经验，他们可以将其带入政府部门职位中。值得克服的挑战转向基于 DevSecOps 的方法论也提出了一些挑战。在过去的十年中，许多组织已经完全重新设计了其开发生命周期，以适应敏捷开发实践，在不久之后进行再次转换看起来令人生畏。企业应该安下心来，因为即使美国国防部也遇到了这种过渡带来的麻烦，他们在应对推出新流程使得商业技术和工具广泛可用的挑战上并不孤独。展望一下未来，其实切换到 DevSecOps 不会比切换到敏捷软件开发更痛苦。而且通过将创建安全性的价值添加到开发工作流程中，以及利用现有敏捷开发的优势，企业可以获得很多收益。via: https://opensource.com/article/20/7/devsecops-vs-agile作者：Sam Bocetta 选题：lujun9972 译者：windgeek 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
DevOps 专业人员如何成为网络安全拥护者
打破信息孤岛，成为网络安全的拥护者，这对你、对你的职业、对你的公司都会有所帮助。安全是 DevOps 中一个被误解了的部分，一些人认为它不在 DevOps 的范围内，而另一些人认为它太过重要（并且被忽视），建议改为使用 DevSecOps。无论你同意哪一方的观点，网络安全都会影响到我们每一个人，这是很明显的事实。每年，黑客行为的统计数据 都会更加令人震惊。例如，每 39 秒就有一次黑客行为发生，这可能会导致你为公司写的记录、身份和专有项目被盗。你的安全团队可能需要花上几个月（也可能是永远找不到）才能发现这次黑客行为背后是谁，目的是什么，人在哪，什么时候黑进来的。运维专家面对这些棘手问题应该如何是好？呐我说，现在是时候成为网络安全的拥护者，变为解决方案的一部分了。孤岛势力范围的战争在我和我本地的 IT 安全（ITSEC）团队一起肩并肩战斗的岁月里，我注意到了很多事情。一个很大的问题是，安全团队和 DevOps 之间关系紧张，这种情况非常普遍。这种紧张关系几乎都是来源于安全团队为了保护系统、防范漏洞所作出的努力（例如，设置访问控制或者禁用某些东西），这些努力会中断 DevOps 的工作并阻碍他们快速部署应用程序。你也看到了，我也看到了，你在现场碰见的每一个人都有至少一个和它有关的故事。一小撮的怨恨最终烧毁了信任的桥梁，要么是花费一段时间修复，要么就是两个团体之间开始一场小型的地盘争夺战，这个结果会使 DevOps 实现起来更加艰难。一种新观点为了打破这些孤岛并结束势力战争，我在每个安全团队中都选了至少一个人来交谈，了解我们组织日常安全运营里的来龙去脉。我开始做这件事是出于好奇，但我持续做这件事是因为它总是能带给我一些有价值的、新的观点。例如，我了解到，对于每个因为失败的安全性而被停止的部署，安全团队都在疯狂地尝试修复 10 个他们看见的其他问题。他们反应的莽撞和尖锐是因为他们必须在有限的时间里修复这些问题，不然这些问题就会变成一个大问题。考虑到发现、识别和撤销已完成操作所需的大量知识，或者指出 DevOps 团队正在做什么（没有背景信息）然后复制并测试它。所有的这些通常都要由人手配备非常不足的安全团队完成。这就是你的安全团队的日常生活，并且你的 DevOps 团队看不到这些。ITSEC 的日常工作意味着超时加班和过度劳累，以确保公司，公司的团队，团队里工作的所有人能够安全地工作。成为安全拥护者的方法这些是你成为你的安全团队的拥护者之后可以帮到它们的。这意味着，对于你做的所有操作，你必须仔细、认真地查看所有能够让其他人登录的方式，以及他们能够从中获得什么。帮助你的安全团队就是在帮助你自己。将工具添加到你的工作流程里，以此将你知道的要干的活和他们知道的要干的活结合到一起。从小事入手，例如阅读公共漏洞披露（CVE），并将扫描模块添加到你的 CI/CD 流程里。对于你写的所有代码，都会有一个开源扫描工具，添加小型开源工具（例如下面列出来的）在长远看来是可以让项目更好的。容器扫描工具：Anchore EngineClairVulsOpenSCAP代码扫描工具：OWASP SonarQubeFind Security BugsGoogle Hacking Diggity ProjectKubernetes 安全工具：Project CalicoKube-hunterNeuVector保持你的 DevOps 态度如果你的工作角色是和 DevOps 相关的，那么学习新技术和如何运用这项新技术创造新事物就是你工作的一部分。安全也是一样。我在 DevOps 安全方面保持到最新，下面是我的方法的列表。每周阅读一篇你工作的方向里和安全相关的文章.每周查看 CVE 官方网站，了解出现了什么新漏洞.尝试做一次黑客马拉松。一些公司每个月都要这样做一次；如果你觉得还不够、想了解更多，可以访问 Beginner Hack 1.0 网站。每年至少一次和那你的安全团队的成员一起参加安全会议，从他们的角度来看事情。成为拥护者是为了变得更好你应该成为你的安全的拥护者，下面是我们列出来的几个理由。首先是增长你的知识，帮助你的职业发展。第二是帮助其他的团队，培养新的关系，打破对你的组织有害的孤岛。在你的整个组织内建立由很多好处，包括设置沟通团队的典范，并鼓励人们一起工作。你同样能促进在整个组织中分享知识，并给每个人提供一个在安全方面更好的内部合作的新契机。总的来说，成为一个网络安全的拥护者会让你成为你整个组织的拥护者。via: https://opensource.com/article/19/9/devops-security-champions作者：Jessica Repka 选题：lujun9972 译者：hopefully2333 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
DevSecOps 对 DevOps 进行了改进，以确保安全性仍然是该过程的一个重要部分。到目前为止，DevOps 在 IT 世界中已广为人知，但其并非完美无缺。试想一下，你在一个项目的现代应用程序交付中实施了所有 DevOps 工程实践。你已经到达开发流程的末尾，但是渗透测试团队（内部或外部）检测到安全漏洞并提出了报告。现在，你必须重新启动所有流程，并要求开发人员修复该漏洞。在基于 DevOps 的软件开发生命周期（SDLC）系统中，这并不繁琐，但它确实会浪费时间并影响交付进度。如果从 SDLC 初期就已经集成了安全性，那么你可能已经跟踪到了该故障，并在开发流程中就消除了它。但是，如上述情形那样，将安全性推到开发流程的最后将导致更长的开发生命周期。这就是引入 DevSecOps 的原因，它以自动化的方式巩固了整个软件交付周期。在现代 DevOps 方法中，组织广泛使用容器托管应用程序，我们看到 Kubernetes 和 Istio 使用的较多。但是，这些工具都有其自身的漏洞。例如，云原生计算基金会（CNCF）最近完成了一项 kubernetes 安全审计，发现了几个问题。DevOps 开发流程中使用的所有工具在流程运行时都需要进行安全检查，DevSecOps 会推动管理员去监视工具的存储库以获取升级和补丁。什么是 DevSecOps?与 DevOps 一样，DevSecOps 是开发人员和 IT 运营团队在开发和部署软件应用程序时所遵循的一种思维方式或文化。它将主动和自动化的安全审计以及渗透测试集成到敏捷应用程序开发中。要使用 DevSecOps，你需要：从 SDLC 开始就引入安全性概念，以最大程度地减少软件代码中的漏洞。确保每个人（包括开发人员和 IT 运营团队）共同承担在其任务中遵循安全实践的责任。在 DevOps 工作流程开始时集成安全控件、工具和流程。这些将在软件交付的每个阶段启用自动安全检查。DevOps 一直致力于在开发和发布过程中包括安全性以及质量保证（QA）、数据库管理和其他所有方面。然而，DevSecOps 是该过程的一个演进，以确保安全永远不会被遗忘，成为该过程的一个重要部分。了解 DevSecOps 流程典型的 DevOps 流程有不同的阶段；典型的 SDLC 流程包括计划、编码、构建、测试、发布和部署等阶段。在 DevSecOps 中，每个阶段都会应用特定的安全检查。计划：执行安全性分析并创建测试计划，以确定在何处、如何以及何时进行测试的方案。编码：部署整理工具和 Git 控件以保护密码和 API 密钥。构建：在构建执行代码时，请结合使用静态应用程序安全测试（SAST）工具来跟踪代码中的缺陷，然后再部署到生产环境中。这些工具针对特定的编程语言。测试：在运行时使用动态应用程序安全测试（DAST）工具来测试您的应用程序。 这些工具可以检测与用户身份验证，授权，SQL 注入以及与 API 相关的端点相关的错误。发布：在发布应用程序之前，请使用安全分析工具来进行全面的渗透测试和漏洞扫描。部署：在运行时完成上述测试后，将安全的版本发送到生产中以进行最终部署。DevSecOps 工具SDLC 的每个阶段都有可用的工具。有些是商业产品，但大多数是开源的。在我的下一篇文章中，我将更多地讨论在流程的不同阶段使用的工具。随着基于现代 IT 基础设施的企业安全威胁的复杂性增加，DevSecOps 将发挥更加关键的作用。然而，DevSecOps 流程将需要随着时间的推移而改进，而不是仅仅依靠同时实施所有安全更改即可。这将消除回溯或应用交付失败的可能性。via: https://opensource.com/article/19/10/devsecops-pipeline-and-tools作者：Sagar Nangare 选题：lujun9972 译者：lnrCoder 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
DevSecOps 的实践之旅开始于 DevSecOps 增权、赋能和培养。下面就介绍如何开始学习使用 DevSecOps。Stephen Streichsbier 说过： DevSecOps 使得组织可以用 DevOps 的速度发布内在安全的软件。DevSecOps 是一场关于 DevOps 概念实践或艺术形式的变革。为了更好理解 DevSecOps，你应该首先理解 DevOps 的含义。DevOps 起源于通过合并开发和运维实践，消除隔离，统一关注点，提升团队和产品的效率和性能。它是一种注重于构建容易维护和易于平常自动运营的产品和服务的新型协作方式。安全在很多团队中都是常见的隔离点。安全的核心关注点是保护团队，而有时这也意味着创建延缓新服务或是新产品发布的障碍或策略，用于保障任何事都能被很好的理解和安全的执行，并且没有给团队带来不必要的风险。因为安全隔离点方面的明显特征和它可能带来的摩擦，开发和运维有时会避开安全要求以满足客观情况。在一些公司，这种隔离形成了一种产品安全完全是安全团队责任的期望，并取决于安全团队去寻找产品的安全缺陷或是可能带来的问题。DevSecOps 看起来是通过给开发或是运维角色加强或是建立安全意识，或是在产品团队中引入一个安全工程师角色，在产品设计中找到安全问题，从而把安全要求汇聚在 Devops 中。这样使得公司能更快发布和更新产品，并且充分相信安全已经嵌入产品中。坚固的软件哪里适用 DevSecOps？建造坚固的软件是 DevOps 文化的一个层面而不是一个特别的实践，它完善和增强了 DevSecOps 实践。想想一款坚固的软件就像是某些经历过残酷战斗过程的事物。有必要指出坚固的软件并不是 100% 安全可靠的（虽然它可能最终是在某些方面）。然而，它被设计成可以处理大部分被抛过来的问题。践行坚固软件最重要的原则是促进竞争、实践、可控的失败与合作。你该如何开始学习 DevSecOps ？开始实践 DevSecOps 涉及提升安全需求和在开发过程中尽可能早的阶段进行实践。它最终在公司文化上提升了安全的重要性，使得安全成为所有人的责任，而并不只是安全团队的责任。你可能在团队中听说过“ 左上升 shift left ”这个词，如果你把开发周期线扁平化到一条横线上，以包括产品变革的的关键时期：从初始化到设计、建造、测试以及最终的运行，安全的目的就是尽早的参与进来。这使得风险可以在设计中能更好的评估、交流和减轻。“左提升”的含义是指促使安全能在开发周期线上更往左走。这个过程始于三个关键要素： 增权 empowerment 赋能 enablement 培养 education 增权，在我看来，是关于释放控制权以及使得团队（在理性分析下）做出独立决定而不用害怕失败或影响。这个过程的唯一告诫信息就是要严格的做出明智的决定（不要比这更低要求）。为了实现增权，商务和行政支持（通过内部销售、展示来建立，通过建立矩阵来展示这项投资的回报）是打破历史障碍和割裂的团队的关键。合并安全人员到开发和运维团队中，提升交流和透明度有助于开始 DevSecOps 之旅。这个整合和移动使得团队只关注单一的结果：打造一个他们共同负责的产品，让开发和安全人员相互依赖合作。这将引领你们共同走向增权。这是产品研发团队的共同责任，并保证每个可分割的产品都保持其安全性。赋能涉及正确的使用掌握在团队手中的工具和资源。这是建立一种通过论坛、维基、信息聚合的知识分享文化。打造一种注重自动化、重复任务应该编码来尽可能减少以后的操作并增强安全性的理念。这种场景不仅仅是提供知识，而是让这种知识能够通过多种渠道和媒介（通过某些工具）可获取，以便它可以被团队或是个人以他喜欢的方式去消化和分享。当团队成员正在编码时一种媒介可能工作的很好，而当他们在进行中时另一种可能更好。让工具简单可用，让团队用上它们。不同的 DevSecOps 团队有不同的喜好，因此允许他们尽可能的保持独立。这是一个微妙的平衡工作，因为你确实希望实现规模经济和产品间共享的能力。在选择中协作和参与，并更新工具方法有助于减少使用中的障碍。最后，也可能是最重要的，DevSecOps 是有关训练和兴趣打造。聚会、社交或是组织中通常的报告会都是让同事们教学和分享他们的知识的很棒的方式。有时，这些会突出其他人可能没有考虑过的共同挑战、顾虑或风险。分享和教学也是一种高效的学习和指导团队的方法。在我个人经验中，每个团队的文化都是独一无二的，因此你不能用一种“普适”的方法。走进你的团队并找到他们想要使用的工具方法。尝试不同的论坛和聚会并找出最适用于你们文化的方式。寻找反馈并询问团队如何工作，他们喜欢什么以及对应的原因。适应和学习，保持乐观，不要停止尝试，你们将会有所收获。下载 DevSecOps 的入门手册via: https://opensource.com/article/19/1/what-devsecops作者：Brett Hunoldt 选题：lujun9972 译者：PandaWizard 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
安全必须进化以跟上当今的应用开发和部署方式。对于我们是否需要扩展 DevOps 以确实提升安全性，我们一直都有争议。毕竟，我们认为，DevOps 一直是一系列的新实践的简写，使用新工具（通常是开源的）并且在这之上构建更多的协作文化。为什么 DevBizOps 不能更好地满足商业的需求？或者说 DevChatOps 强调的是更快更好的沟通？然而，如 John Willis 在今年（LCTT 译注：此处是 2018 年）的早些时候写的关于他对 DevSecOps 术语的理解，“我希望，有一天我们能在任何地方都不再使用 DevSecOps 这个词，安全会是所有关于服务交付的讨论中理所应当的部分。在那一天到来前，在这一点上，我的一般性结论是，这个词只是三个新的特性而已。更重要的是，我们作为一个产业，在信息安全方面并没有做的很好，而这个名称切实地区分出了问题的状况。”所以，为什么我们在信息安全方面做的不好，在 DevSecOps 的语境下安全做的好又是什么意思呢？尽管（也可能是因为）庞大的复杂行业的单点产品解决了特定方面的问题，但我们可以说是从未做好过信息安全。我们仍然可以在这个时代把工作做得足够好，以此来防范威胁，这些威胁主要集中在一个范围内，网络的连接是受限的，而且大多数的用户都是公司的员工，使用的是公司提供的设备。这些年来，这些情况并没有能准确地描述出大多数组织的真实现状。但在现在这个时代，不止引入了 DevSecOps，也同时引入了新的应用架构模型、开发实践，和越来越多的安全威胁，这些一起定义了一个需要更快迭代的新常态。与其说 DevSecOps 孤立地改变了安全，不如说信息安全公司在 2018 年需要新的方法。请仔细思考下面这五个领域。自动化大量的自动化通常是 DevOps 的标志，这部分是关于速度的，如果你要快速变化（并且不会造成破坏），你需要有可重复的过程，而且这个过程不需要太多的人工干预。实际上，自动化是 DevOps 最好的切入点之一，甚至是在仍然主要使用老式的 独石应用 monolithic app 的组织里也是如此。使用像 Ansible 这样易于使用的工具来自动化地处理相关的配置或者是测试，这是快速开始 DevOps 之路的常用方法。DevSecOps 也不例外，在今天，安全已经变成了一个持续性的过程，而不是在应用的生命周期里进行不定期的检查，甚至是每周、每月的检查。当漏洞被厂商发现并修复的时候，这些修复能被快速地应用是很重要的，这样对这些漏洞的利用程序很快就会被淘汰。“左移”在开发流程结束时，传统的安全通常被视作一个守门人。检查所有的部分确保没有问题，然后这个应用程序就可以投入生产了。否则，就要再来一次。安全小组以说“不”而闻名。因此，我们想的是，为什么不把安全这个部分提到前面呢（在一个典型的从左到右的开发流程图的“左边”）？安全团队仍然可以说“不”，但在开发的早期进行重构的影响要远远小于开发已经完成并且准备上线时进行重构的影响。不过，我不喜欢“左移”这个词，这意味着安全仍然是一个只不过提前进行的一次性工作。在应用程序的整个生命周期里，从供应链到开发，再到测试，直到上线部署，安全都需要进行大量的自动化处理。管理依赖我们在现代应用程序开发过程中看到的一个最大的改变，就是你通常不需要去编写这个程序的大部分代码。使用开源的函数库和框架就是一个明显的例子。而且你也可以从公共的云服务商或其他来源那里获得额外的服务。在许多情况下，这些额外的代码和服务比你给自己写的要好得多。因此，DevSecOps 需要你把重点放在你的软件供应链上，你是从可信的来源那里获取你的软件的吗？这些软件是最新的吗？它们已经集成到了你为自己的代码所使用的安全流程中了吗？对于这些你能使用的代码和 API 你有哪些策略？你为自己的产品代码使用的组件是否有可用的商业支持？没有一套标准答案可以应对所有的情况。对于概念验证和大规模的生产，它们可能会有所不同。但是，正如制造业长期存在的情况（DevSecOps 和制造业的发展方面有许多相似之处），供应链的可信是至关重要的。可见性关于贯穿应用程序整个生命周期里所有阶段的自动化的需求，我已经谈过很多了。这里假设我们能看见每个阶段里发生的情况。有效的 DevSecOps 需要有效的检测，以便于自动化程序知道要做什么。这个检测分了很多类别。一些长期的和高级别的指标能帮助我们了解整个 DevSecOps 流程是否工作良好。严重威胁级别的警报需要立刻有人进行处理（安全扫描系统已经关闭！）。有一些警报，比如扫描失败，需要进行修复。我们记录了许多参数的志以便事后进行分析（随着时间的推移，哪些发生了改变？导致失败的原因是什么？）。分散服务 vs 一体化解决方案虽然 DevSecOps 实践可以应用于多种类型的应用架构，但它们对小型且松散耦合的组件最有效，这些组件可以进行更新和复用，而且不会在应用程序的其他地方进行强制更改。在纯净版的形式里，这些组件可以是微服务或者函数，但是这个一般性原则适用于通过网络进行通信的松散耦合服务的任何地方。这种方法确实带来了一些新的安全挑战，组件之间的交互可能会很复杂，总的攻击面会更大，因为现在应用程序通过网络有了更多的切入点。另一方面，这种类型的架构还意味着自动化的安全和监视可以更加精细地查看应用程序的组件，因为它们不再深埋在一个独石应用程序之中。不要过多地关注 DevSecOps 这个术语，但要提醒一下，安全正在不断地演变，因为我们编写和部署程序的方式也在不断地演变。via: https://opensource.com/article/18/9/devsecops-changes-security作者：Gordon Haff 选题：lujun9972 译者：hopefully2333 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
DevSecOps 也许不是一个优雅的词汇，但是其结果很吸引人：更强的安全、提前出现在开发周期中。来看看一个 IT 领导与 Meltdown 的拼搏。如果 DevOps 最终是关于创造更好的软件，那也就意味着是更安全的软件。而到了术语 “DevSecOps”，就像任何其他 IT 术语一样，DevSecOps —— 一个更成熟的 DevOps 的后代 ——可能容易受到炒作和盗用。但这个术语对那些拥抱了 DevOps 文化的领导者们来说具有重要的意义，并且其实践和工具可以帮助他们实现其承诺。说道这里：“DevSecOps”是什么意思？“DevSecOps 是开发、安全、运营的混合，”来自 Datical 的首席技术官和联合创始人 Robert 说。“这提醒我们，对我们的应用程序来说安全和创建并部署应用到生产中一样重要。”想阅读其他首席技术官的 DevOps 文章吗？查阅我们丰富的资源，[DevOps：IT 领导者指南]向非技术人员解释 DevSecOps 的一个简单的方法是：它是指将安全有意并提前加入到开发过程中。“安全团队从历史上一直都被孤立于开发团队——每个团队在 IT 的不同领域都发展了很强的专业能力”，来自红帽安全策的专家 Kirsten 最近告诉我们。“不需要这样，非常关注安全也关注他们通过软件来兑现商业价值的能力的企业正在寻找能够在应用开发生命周期中加入安全的方法。他们通过在整个 CI/CD 管道中集成安全实践、工具和自动化来采用 DevSecOps。”“为了能够做的更好，他们正在整合他们的团队——专业的安全人员从开始设计到部署到生产中都融入到了开发团队中了，”她说，“双方都收获了价值——每个团队都拓展了他们的技能和基础知识，使他们自己都成更有价值的技术人员。 DevOps 做的很正确——或者说 DevSecOps——提高了 IT 的安全性。”IT 团队比任何以往都要求要快速频繁的交付服务。DevOps 在某种程度上可以成为一个很棒的推动者，因为它能够消除开发和运营之间通常遇到的一些摩擦，运营一直被排挤在整个过程之外直到要部署的时候，开发者把代码随便一放之后就不再去管理，他们承担更少的基础架构的责任。那种孤立的方法引起了很多问题，委婉的说，在数字时代，如果将安全孤立起来同样的情况也会发生。“我们已经采用了 DevOps，因为它已经被证明通过移除开发和运营之间的阻碍来提高 IT 的绩效，”Reevess 说，“就像我们不应该在开发周期要结束时才加入运营，我们不应该在快要结束时才加入安全。”为什么 DevSecOps 必然出现或许会把 DevSecOps 看作是另一个时髦词，但对于安全意识很强的IT领导者来说，它是一个实质性的术语：在软件开发管道中安全必须是第一层面的要素，而不是部署前的最后一步的螺栓，或者更糟的是，作为一个团队只有当一个实际的事故发生的时候安全人员才会被重用争抢。“DevSecOps 不只是一个时髦的术语——因为多种原因它是现在和未来 IT 将呈现的状态”，来自 [Sumo Logic] 的安全和合规副总裁 George 说道，“最重要的好处是将安全融入到开发和运营当中开提供保护的能力”此外，DevSecOps 的出现可能是 DevOps 自身逐渐成熟并扎根于 IT 之中的一个征兆。“企业中的 DevOps 文化已成定局，而且那意味着开发者们正以不断增长的速度交付功能和更新，特别是自我管理的组织会对合作和衡量的结果更加满意”，来自 [CYBRIC] 的首席技术官和联合创始人 Mike 说道。在实施 DevOps 的同时继续保留原有安全措施的团队和公司，随着他们继续部署的更快更频繁可能正在经历越来越多的安全管理风险上的痛苦。“现在的手工的安全测试方法会继续远远被甩在后面。”“如今，手动的安全测试方法正被甩得越来越远，利用自动化和协作将安全测试转移到软件开发生命周期中，因此推动 DevSecOps 的文化是 IT 领导者们为增加整体的灵活性提供安全保证的唯一途径”，Kail 说。转移安全测试也使开发者受益：他们能够在开放的较早的阶段验证并解决潜在的问题——这样很少需要或者甚至不需要安全人员的介入，而不是在一个新的服务或者更新部署之前在他们的代码中发现一个明显的漏洞。“做的正确，DevSecOps 能够将安全融入到开发生命周期中，允许开发者们在没有安全中断的情况下更加快速容易的保证他们应用的安全”，来自 SAS 的首席信息安全员 Wilson 说道。Wilson 指出静态（SAST）和源组合分析（SCA）工具，集成到团队的持续交付管道中，作为有用的技术通过给予开发者关于他们的代码中的潜在问题和第三方依赖中的漏洞的反馈来使之逐渐成为可能。“因此，开发者们能够主动和迭代的缓解应用安全的问题，然后在不需要安全人员介入的情况下重新进行安全扫描。” Wilson 说。他同时指出 DevSecOps 能够帮助开发者简化更新和打补丁。DevSecOps 并不意味着你不再需要安全组的意见了，就如同 DevOps 并不意味着你不再需要基础架构专家；它只是帮助你减少在生产中发现缺陷的可能性，或者减少导致降低部署速度的阻碍，因为缺陷已经在开发周期中被发现解决了。“如果他们有问题或者需要帮助，我们就在这儿，但是因为已经给了开发者他们需要的保护他们应用安全的工具，我们很少在一个深入的测试中发现一个导致中断的问题，”Wilson 说道。DevSecOps 遇到 MeltdownSumo Locic 的 Gerchow 向我们分享了一个在运转中的 DevSecOps 文化的一个及时案例：当最近 [Meltdown 和 Spectre] 的消息传来的时候，团队的 DevSecOps 方法使得有了一个快速的响应来减轻风险，没有任何的通知去打扰内部或者外部的顾客，Gerchow 所说的这点对原生云、高监管的公司来说特别的重要。第一步：Gerchow 的小型安全团队都具有一定的开发能力，能够通过 Slack 和它的主要云供应商协同工作来确保它的基础架构能够在 24 小时之内完成修复。“接着我的团队立即开始进行系统级的修复，实现终端客户的零停机时间，不需要去开工单给工程师，如果那样那意味着你需要等待很长的变更过程。所有的变更都是通过 Slack 的自动 jira 票据进行，通过我们的日志监控和分析解决方案”，Gerchow 解释道。在本质上，它听起来非常像 DevOps 文化，匹配正确的人员、过程和工具，但它明确的将安全作为文化中的一部分进行了混合。“在传统的环境中，这将花费数周或数月的停机时间来处理，因为开发、运维和安全三者是相互独立的”，Gerchow 说道，“通过一个 DevSecOps 的过程和习惯，终端用户可以通过简单的沟通和当日修复获得无缝的体验。”via: https://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders作者：Kevin Casey 译者：FelixYFZ 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出