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