我做了一辈子黑客。目前，我是标准普尔全球评级的业务信息安全官。现在，如果你不知道商业信息安全官是什么，你想知道它和首席信息安全官有什么不同，看看我整理的这个博客，它会告诉你这两个领导角色之间的各种不同。
现在，你可能会问，为什么一个安全领导者会在swampp这样的会议上谈论DevSecOps ?嗯，我做了10年的开发人员，然后在我职业生涯的最后15年里，我在各种各样的角色中度过，我想，在网络安全领域，包括笔测试员，但一直都是主要关注应用程序安全性。我曾与许多组织合作，研究如何开发DevSecOps实践，当然现在有了标普全球，我们正在经历自己的DevSecOps和云转型。因此，我将分享我从这些不同的角色中学到的很多经验。最后，我是一名作家、博主、播客。
你可以在我的网站上读到更多信息，稍后我将与你分享。但让我们从历史课开始。
你看，我开始思考DevSecOps，更常见的是，DevOps已经存在了13年了。所以我意识到，在DevSecOps或DevOps刚刚起步的时候，这里的一些人可能还没有进入这个行业。DevOps是由Patrick Diwan和Andrew Schafer这两位先生发起的，他们试图在一次会议上建立联系，他们想要讨论如何缓解运营团队中开发团队之间的摩擦并打破这些孤岛。
他们在会议上没有联系，但后来聚在一起，他们谈了很多，提出了很多不同的想法，并开始与社区分享，在2008年，不好意思，应该是2009年，Patrick Diwan发起了DevOps日，这是我们第一次听到DevOps这个术语。现在，DevOps很快被很多组织采用，开发人员非常喜欢它。但直到三年后保安才意识到，嘿，我们得做点什么了。2012年，在旧金山举行的RSA安全会议上，吉恩·金和Josh Corman，你们在右边看到的，他有一个关于DevOps世界中安全性的臭名昭著的演讲。你知道，他们创造了DevSecOps这个词。因此，当我们想到DevOps时，我们想到我们正在与谁合作，我们正在打破的筒仓，有一个关于谁负责安全的有趣问题。
我曾经在一家叫Snyka的公司工作，在2020年，我们做了开源安全状况报告。我们问受访者的一个问题是，谁负责你们公司软件的安全以及基础设施的安全。
现在，你看到的是85%的人说开发人员要对软件的安全负责。好吧，这是意料之中的，但只有55%的安全部门和35%的运营部门在其中发挥了作用。然后你看看基础设施，至少它更平衡了，但开发人员肩上仍然有很大的压力，以确保所有这些元素的安全。这是一个有趣的困境，因为我们现在要求开发人员做的比我们过去做的多得多，现在我们又加上，嘿，我们希望你对一切负责。
这与打破筒仓并构建真正的DevSecOps的想法并不相符。因此，我们在现代开发中面临的最大挑战之一就是仅仅知道我们的软件中有什么。
我们大多数人在今天的开发中利用某种形式的开源。你无法逃避，对吧?你从GitHub或任何你从开源社区获得不同功能的地方提取包。现在的问题是，我们并不总是知道这些包中包含什么。我喜欢用的一个例子是这个工作申请。这个Java应用程序，大概有280行代码是这个开发者写的。
非常小的应用程序。当你写了10万行代码的时候，这意味着你有十万行应用程序，但我们知道它不再那样工作了，因为你可以看到，这个应用程序定义了八个依赖项。但现在每个依赖项都有自己的子依赖项。所以这八个依赖关系变成了89个子依赖关系，这使得我们的280行代码达到了240万行，所以只是略有增加。那么，当我们从社区中利用越来越多的开源和可重复的包和库等东西时，开发人员应该如何跟踪这些呢?但还有更糟的。我喜欢凯尔西·海托华的这句话，我经常引用。所以你想推出自己的应用平台?好吧，嘿，你只需要知道如何使用所有这些不同的技术，你看到Linux、Docker、Kubernetes、sto和普罗米修斯……就这样没完没了没完没了。对吧?这难道不是你们今天作为开发者所生活的世界吗?当我们想到我们的运维人员，我们的sre是其中的一部分，他们需要拥有所有的专业知识。
这是个超级复杂的世界。但还有更糟的。因为所有这些技术都存在于哪里?它们都在云原生技术的世界里。现在，也许你以前见过这张来自云原生计算基金会的图表。
这很让人麻木，对吧?现在，我相信这个版本，当我截屏的时候，大概有四五个月了，你已经可以看到，读懂这个列表上的各种工具和技术的名字是多么困难。
你们可能认识很多标志，但愿你们用过很多。但现在我们要求我们的开发人员也要负责这方面的安全。我们要求的太多了，好吧，但是我们有我们的安全团队，我们的安全团队会帮助我们，对吧?
实际上，他们也有自己的麻烦要处理。我的意思是，看看这个。他们负责周边安全、网络安全和端点安全，所有这些我们每天都听到的被攻破的事情，然后他们可以担心应用程序安全，但他们也必须考虑数据安全。当然，他们必须确保我们有政策来管理这一切，我们需要确保我们在操作的基础上处理事情。
我们要防火墙规则做什么?我们如何配置云环境?所有这些都是安全团队的责任。所以在他们的世界里，对于开发人员，对于操作人员，对于sre来说，是一样复杂的。
我们都在处理自己的复空间。当然，在安全方面也有很多工具，对吧?我们在这里遇到了与云原生世界相同的问题，看看我们期望安全团队能够利用的所有这些不同的技术。反过来，如果我说软件开发人员负责安全，那么，他们也必须知道所有这些，了解所有这些不同的供应商和他们提供的工具，以及他们适合哪些利基空间。
这是不真实的，我们给现代数据环境带来的复杂性。为什么会这样呢?因为科技一直在发展。这是一件好事。正是这一点让我们能够创新，并在我们的应用程序上做很多很酷很有创意的事情。但反过来，这让我们试图应对和管理的威胁形势变得更加困难。那么我们如何回答这个问题呢?
这又回到了安德鲁·谢弗和帕特里克·达比斯我们从一开始就想做的事情。这就是打破藩篱的想法，但是我们如何打破藩篱呢?这要从文化开始。现在，你们中有多少人当我说DevSecOps这个词，或者DevOps，如果我问你们这是关于什么的，你们中有多少人会开始考虑工具和技术?
你将如何使一切自动化，你知道，使世界自动化，这似乎是我们谈论DevOps时每个人都在考虑的问题。但现实是DevOps，因此，DevSecOps总是意味着文化的改变，这意味着它不仅仅是关于技术和工具，它是关于人，它是关于流程，它是关于治理。
我们需要提供培训。是的，我确实说过治理，我们一会儿再回到这个问题上。
员工，你需要为员工提供培训，你需要提供符合你的范式的流程，并将工具和技术结合在一起。人们需要这些技能。
然后我说了治理这个丑陋的词。是的，我们需要能够确保人们遵循流程和工具，以及我们推出的所有东西，我们需要建立一个衡量其有效性的标准。这就是治理的用武之地。每次我说到治理，人们就会想到审计和所有这些可怕的调查问卷以及他们必须处理的事情。
当我谈论治理和DevSecOps,我只是谈论能力来衡量我们所做的事情,并确保我们正在做我们说我们要做什么,所以那些测量是准确的,因为我不能好转,我不能得到更多的成熟DevSecOps文化,如果我没有测量,我做什么,并确保我的计划,我相信是对的,实际上是文化产生预期的影响。
所以在这种文化中，我们要做的就是打破这些藩篱。这就是分担责任的理念的由来。我们有开发人员、运维人员和安全人员，他们通常都有自己的优先级。这就是竖井的问题所在。因此，在DevSecOps文化中，我们寻找的是每个人都负责软件的安全，快速交付，并确保它在部署到我们的生产环境时是稳定的。所以这意味着安全，是的，安全，你有责任确保软件快速交付，你有责任确保它在生产环境中是稳定的。
正如我们之前谈到的，开发人员要负责代码的稳定性和安全性，并将其快速投入生产。指挥员，你也是这事的一部分。
这就是它的全部，当我们谈论DevSecOps时，这就是我们如何处理所有的复杂性并使其易于管理，因此我们都在一起工作，以确保共同的责任成为现实。现在，我们在DevOps的现代管道中继续面临的一些挑战，当你想到DevOps或DevSecOps时，很多时候人们会想到CI\CD，我们会讲到那里。但是让我们考虑一下管道的基础知识，我们有管道的这些不同阶段，我们可以线性地布局它们，我们知道，你知道，在无限循环中，是的，我们继续循环。但是当我们看这个证券公司一直在做的事情。
我们一直试着往左推。我们在安全领域已经讨论了20年了，但现在发生的变化是相互冲突的运动，我们让开发人员越来越深入地推进管道，将基础设施作为代码和容器，我们所做的所有事情，开发人员正在定义他们的软件将在其上运行的基础设施。
所以他们越来越倾向于部署。然后我们有我们的运营团队，我们的SREs。他们正在推动堆栈，因为运维人员不能再担心裸露的金属服务器和操作系统，他们需要理解定义基础设施的代码，这些基础设施将在我们的环境中运行，通常是云环境。
现在，无论我们在这里谈到谁，谁被遗忘了?
这就是生意场。业务已经越来越多地涉及到我们管道中的粒度方面，而不是以前。
它们是测试的一部分，它们定义了我们的用户故事。他们也是每个阶段的一部分。我们想要这样，我们需要他们成为其中的一部分。因此，他们正在将堆栈向下推，他们对技术的理解以及他们如何参与构建技术方面变得更加细粒度。
现在，让我们谈谈DevSecOps中的安全性。我参加过，我不知道有多少，我数不清在会议上的演讲，关于DevSecOps的演讲都是由安全部门的人做的。通常，他们会做我们在安全领域做过的传统事情，我们谈论门的概念。
我们希望在管道的每个阶段之间都有质量闸门。所以当我们从backlog中走出来，开始计划我们的冲刺，我们想要利用这个设计时间，建立一个大的威胁模型，然后我们想要在提交代码时做静态代码分析。然后，当我们准备好测试代码时，我们正在进行部署，然后我们想要做动态安全测试。
这些在现代DevOps范式中不起作用，尤其是在我们开始转向像CI\CD这样的东西。
盖茨打破了这一模式，因为盖茨威胁着在每一个阶段都阻止我们，威胁着把我们推向后退。稍后再详细讨论。因此，从安全的角度来看，我们需要做什么呢?我们必须停止将安全视为各个阶段之间的大门，相反，我们必须看看Yuri如何安全地集成到这些阶段中。
作为backlog的一部分，我们如何进行威胁建模?我们如何引入软件组合分析，以便我们能够理解我们的开源暴露?我们如何将其带入编码和提交周期?我们如何确保静态代码分析是构建和测试过程的一部分?当我们部署时，我们如何确保容器的安全性，以及监视和渗透测试的发生，而不是作为我们正在进行的监视的大门，但它们是我们生产环境的一部分。
因此，当我们在CI\CD世界中思考这个问题时，我们思考如何带来安全，我们开始建造这些大门，我们思考构建破坏的想法。
您听过多少关于在安全测试失败时破坏构建的演讲、视频或其他东西?这看起来就像我们有了这些发展周期，对吧?
我们在编码，我们在承诺，如果我们在做CI，这就是我们想要的，对吧?我们想要持续，我们只是在编码和提交。当我们准备好了，嘿，我们会推广我们会推广到一个集成环境。然后我们将构建代码，并对其进行测试。然后当它准备好了，我们可能会有另一个测试周期，或者回归测试，我们准备好部署，我们打包并部署它。
在传统的门模型中，当我们进行安全测试时，会发生什么?我们有一个很长的反馈周期，我们把它推掉，它在这个代码扫描工具中运行，那个工具回来说，哦，天哪，你必须修复漏洞，我们把你推回去编码。当我们测试那些准备部署的包时，同样的事情也会发生，哦，我们发现了漏洞，你必须回去在你的代码中修复它。
这就是破坏DevSecOps，这就是破坏CI\CD的原因。因此，当我们想要获得真正的CI\CD时，我们需要以不同的方式思考这些事情。
当我考虑测试集成时，我不希望有如此关键的漏洞，以至于我必须在编码周期中返回并修复它们，当我发布时，我准备好了，我正在测试通过回归测试的最终包。
再一次，在这个阶段发现漏洞将我推回到开发过程。
这是什么打破了CI\CD。
我们想要做的是远离这些，我们希望这些测试能够识别出我们可以简单地添加到backlog中的漏洞。现在可以将它们添加为P个，我希望你们这样做，让它们成为第一个优先级，它们将在下一个开发周期中得到解决。
同样的，当我们进行回归测试时，我们希望这些漏洞的性质是我们可以将它们添加到backlog中，当我们转向这个模型时，我们停止破坏带有安全性的构建，CI和CD发生，因为我们没有停止管道中的当前流，我们只是在设置下一次运行以解决我们在这次中发现的漏洞。随着我们在CI\CD方面做得越来越好，我们每天甚至每天进行多次部署，这些漏洞的风险越来越低。但我如何确保这些漏洞不是他们强迫我的高风险马上去修吗?
我们来谈谈这个。所以在2019年，Circle CI和Puppet做了他们的DevOps状态报告。他们研究的其中一件事是安全措施。他们特别研究了我们实施这些做法的频率，以及它们对安全状况的影响。在左上角，你可以看到我们经常做的事情。
静态代码分析和渗透测试。但我们发现这些通常不会对安全态势产生很大影响。
在右下方，我们可以看到协作、安全、运维和开发团队在威胁建模方面共同工作，例如，这种协作可以帮助我们开始进一步向左推进，并在高严重漏洞进入测试之前消除它们。现在我说威胁建模，你们可能都想到了这样的事情，一个重量级的过程，你画出DFD图，你使用这些不同的框架，比如stride和dread，你要画出大的攻击地图，你要把它全部映射到catback。
忘记这些吧，如果我们想把威胁建模作为DevOps世界的一部分，我们需要完全不同地考虑威胁建模。我们怎么做呢?
我之前提到过，将威胁建模引入backlog。想象一下，不要试图威胁建模你的整个系统，你把每一个单独的用户故事都写进去，当你写用户故事的时候，你只需要引入基本的线程信息，让它成为用户故事的一部分。确定对特定用户故事至关重要的关键资产，然后确定威胁，而不是按照进度。
我不在乎它是欺骗，篡改，否定，那是没有意义的。让我们从业务人员、开发人员到测试人员的角度来讨论这个问题对生产支持可以理解。有被盗窃的威胁吗?是否存在欺诈的威胁?是否存在稳定性威胁或缺乏服务稳定性?
这些是我们想要记录的东西，现在谁来写你的用户故事?最常见的是商务人士，对吧?如果他们在写这些，他们就已经知道什么是关键资产了。是PII，个人身份信息吗?
我们必须保护的数据?我们有需要你保护的商业秘密吗?我们必须保护提供关键服务的能力吗?
交付是关键部分吗?所以他们可以记录这些。这就是我们如何让他们更多地参与到这个过程中。这是什么样子的?为什么这很重要?
假设我把这个线程信息放在我的用户故事中。现在，当我开始构建和计划我的冲刺时，我从backlog中获取那些用户故事作为开发人员或原型，我可以查看它，我看到那些威胁，我知道我需要定义什么安全需求。
也许我有，这就是我们在SMP所做的，我们有工程标准来帮助我们当我们看到特定类型的威胁时，帮助我们了解这些安全需求是什么，现在我可以记录它们。然后这些就进入了我的建造过程，它们是安全控制。所以现在我的开发人员从安全需求中了解到，这些是我需要构建的控件类型，他们构建了它们。这只是编码的一个固有部分。接下来会发生什么?我有威胁信息，我有那些关键资产的身份。因此，当涉及到我的测试用例时，我可以基于这些信息自动地对它们进行优先级排序。那我们部署的时候呢?
好的，当我们部署时，现在我有了信息告诉我我需要监视什么，以及我需要监视什么。
我知道我的关键资产是什么，我也知道他们面临什么威胁。因此，这就是我们开始让我们的生活更轻松的地方，通过这种文化，每个人都参与到共同的责任中来。在这个案例中，我们已经做到了，只是把威胁信息构建到我们的用户故事中。
但我们需要更进一步。当我们想到文化时，文化来自于同理心。这种同理心的缺乏是我们试图部署DevSecOps文化并打破这些竖井时所面临的最大挑战之一。那么我如何让我的安全人员，我的sre了解开发者的世界呢?
我如何让我的开发人员也理解他们的世界?我如何确保参与这一共同责任的每个人都理解并欣赏他们的计划、他们的实践如何影响其他人?
你可以从他们的角度出发，观看一个实习项目，让你的安全团队成员花一个月的时间在开发领域工作，了解这个世界，也许你可以让你的开发人员在安全团队中坐一段时间，或者与你的sre一起工作，看看操作世界是什么样的。
给他们时间来建立同理心，真正理解这些挑战，以及其他传统学科的同龄人每天面临的所有相互冲突的动机。这样他们就能看到自己所做的能让生活更轻松。不要只派初级候选人，不要只派初级开发人员，因为他们是可有可无的。
我们需要那些高级开发人员参与其中，因为他们可以从上到下进行领导，许多高级人员可能不想听初级开发人员在花了一个月的时间处理安全问题后所说的话。但如果你的高级团队成员能够以身作则，因为他们明白这样可以建立起那种文化。
第二部分归结于技术和流程。
我们怎么能在他们住的地方见他们?
在引入安全实践时，我正在寻找将安全实践集成到现有流程和现有工具中的方法。
现在我们已经做了很多，我们讨论了自动化的概念。很多时候它是由开发人员驱动的，我们需要安全团队，因为我们正在评估工具，让sre、运维人员、开发人员参与进来，并确保工具将适合他们的流程，他们的管道，并且事情将正确地自动化，这样他们就不会引入新的摩擦。
这都是关于无摩擦使能关系的想法。当我谈到使能关系时，我指的是铺平道路。
把工具放在那里，然后创造这种负责任的信任的想法，我有在我的开发团队中，在我的SRE团队中，我可以信任的人，他们知道他们对我想让他们做的安全事情负责，我相信他们能做到。但这种信任更进一步，这是我们真正铺平道路的地方，我让安全的答案成为简单的答案。但除此之外，为了让它真正发生，我正在考虑安全冠军计划，我们现在正在用SMP建立的东西。
我在想我如何确保这些人不仅有工具，还有他们需要的培训，以便做出决定，然后我让他们实现。
这就是我们提出负责任信托的原因。再一次，我让他们看到不同的决定。
如果他们看到了一种实现安全的方法，但通过走不同的路线，实现它，我想让他们能够这样做，铺设一条新的道路，为我们指明道路，把它带回来，使它成为可重复的，这创造了持续改进的想法。最后，我想要相互参与。
如果我试图建立同理心，我希望这些团队每天都在一起工作。它们不应该是孤岛。
你的开发人员会参加你的安全状态会议吗?你的安全团队，你的sre会参加你每天的Scrum会议吗?
谁是其中的一员?我们能让我们的业务人员、安全团队和sre都参与到sprint计划中吗?
那我们的回顾呢?他们是其中的一部分，所以我们都可以从上一个周期中吸取教训吗?这些都是我们可以开始做的事情，他们开始打破这些孤岛，形成一个更有凝聚力的单位。
我们用SMP来做这件事，我们有每周的Scrum会议，我们有来自安全团队的人，我们有来自开发团队的人，来自SRE团队的人，来自我们的风险管理团队的人，把他们聚集在一起，这些都给了我们非常好的回报，他们让每个人都有机会分享他们所学到的东西，也能看到正在发生的事情。
这就是我们如何开始建立一个真正的DevSecOps文化，让我们所有人的生活更轻松，我们都朝着同样的共同责任前进。现在，在我结束的时候，我想和你们分享亨利·福特的这句话，它似乎非常合适。
聚在一起是开始，保持在一起是进步，但共同努力才是成功。
我们需要共同努力，每天工作，打破这些藩篱一起承担共同的责任，这就是我们会找到成功的地方，让DevSecOps真正起作用，让我们的生活更轻松。
现在是我结束的时候了，但在我结束之前，我邀请你继续对话。如果你有问题，想法，担忧，你想对我说过的东西提出异议，无论如何都可以联系我，推特是最简单的，但LinkedIn和我的网站也是你可以联系我的其他方式。
所有的信息都在这里，我邀请你，联系我。让我们谈谈，分享我们的想法。让我们看看如何继续改进。因此，我想感谢你们所有人作为swampap的一员来到这里，来到这里参加这次会议。
我想感谢JFrog邀请我，我无法表达我有多感激。当然，我也要感谢我所在的标普全球评级公司，感谢你们让我今天有机会来到这里。
我希望你们在接下来的会议上玩得愉快。
我希望你们能从今天的讲座中获得一些真正有价值的见解，我们很快就会再见。
谢谢，保重。
