当你问他要安全带时，他们说没有。当你看向前方，你所看到的是一条泥泞的乡村道路，你会如何看待驾驶赛车，在泥泞的乡村道路上，没有必要的工具来确保你想要的速度和速度是成功的?这就是这次会议的目的。
我叫Chris Riley，我是Splunk的高级技术倡导者，这意味着我从一个糟糕的程序员变成了一个喜欢谈论软件开发的人。我不打算过多地谈论我自己。但如果你想了解更多信息，你可以扫描二维码，它会把你带到我的社交网站上。如果在这次会议上你有什么想让我扩展的，请联系我，我总是很乐意参与，我喜欢听到看过我的会议的人的声音。那么，在大多数组织中，如果他们没有为f1做好准备，他们没有为开发人员、DevOps工程师和站点可靠性工程师提供以可持续和安全的方式快速运行所需的工具，情况会如何呢?
它通常是由可见性竖井驱动的。您的安全专业人员和合规专业人员通常在应用程序进入生产环境之前无法了解应用程序的运行情况。但是在软件交付链中有很多事情会影响这些应用程序的质量和安全性。因此，从一个特性被定义的那一点开始，创建可见性在生产环境中运行的功能是绝对重要的。
现在，开发人员可能非常擅长在活动和他们所做的测试中创建可见性。DevOps工程师也一样。sre往往非常擅长生产中发生的事情。问题是，如果安全专业人员有一个问题，他们必须找到有答案的正确的人，他们通常必须停止一切来得到这些答案。更糟糕的是，如果有审计，你的交付过程可能会中断数周。因此，因为交付链是为了交付代码，所以目标是没有人需要中断这个过程来找出他们需要什么。所以我们喜欢把DevSecOps看作一种实践。
是的，DevSecOps是另一个行业术语。很多人会说，如果你正确地做DevOps，你已经在考虑安全问题了。但是将DevSecOps作为一种实践，它将不再只是一种工具你希望在使用中实现，并开始从战略角度考虑它。而且，因为它是一种实践，为了成功，它必须是可见的。
能见度是什么意思?这意味着有一个线程，从您的交付链中发生的事情，通过在生产中运行的基础设施，通过应用层，一直到用户前端。最后，你的安全sim卡。
我们称之为代码到云可见性，而代码到云可见性对于跨越这些竖井和确保组织中的每个人都能很好地理解如何构建更安全的应用程序、保护软件工厂和解决生产中的安全事件是绝对必要的。这三个正是DevSecOps实践的三个用例。
这些用例中的每一个都有不同的方法、运行它的一组不同的人以及促进它的一组不同的技术能力。所以，它正在构建更安全的应用程序。您正在做什么来检查漏洞?您正在做什么来确保您的代码质量遵循最佳实践?您正在做什么来确保您没有从开发机器到生产机器的配置漂移，从而使组织面临风险?
其次是保护软件工厂。您如何确保正确的人能够访问您的工件?您如何确保您没有从公共回收中提取工件?
你正在做什么来确保所使用的秘密被正确地使用?最后，是我们都很熟悉的领域，那就是确保生产中的应用程序安全。但是在软件交付链的早期发生的事情的好处是故障排除，生产中的安全事件有更大的上下文，更大的上下文意味着更快的解决方案和更快的根本原因分析。DevSecOps的行为既是文化的也是技术的。所以第一件事是自动化在DevSecOps中是隐含的，你必须考虑如何将安全性嵌入到软件交付链的自动化测试和交付过程中，我们也将安全考虑移到左边。
同样，这不仅仅是技术向左移动，开发人员需要考虑安全性，而不是安全成为他们的工作。有一个非常有力的论点是，你不应该让安全成为开发人员的责任，而是给他们工具和心态，让他们知道构建更安全的应用程序，对每个人都有好处。以DevOps的速度完成所有这些工作，DevSecOps实践和安全专业人员的目标不是停止软件交付。
典型的安全专业人员明白，尽快向用户交付功能是业务的关键。但他们也知道，对业务来说，不需要停止一切是关键因为出现了一个漏洞。因此，将安全性构建到开发实践中符合每个人的最大利益，而不是让它成为事后的想法，或者让它不仅仅发生在生产中。所以这种做法并不是一刀切的。
在高层次上，我们让我们的高管明白，首先，它是一种实践，而不是一种技术，你去买，然后突然，你完成了，勾选复选框，你现在已经实现了DevSecOps。不是那样的。
在这三个用例中，我们都有不同的角色来驱动它们。因此，在构建更安全的应用程序时，它往往是由开发人员和DevOps工程师驱动和实现的，其价值被交付给安全专业人员和sre。
为了确保软件工厂的安全，类似的情况通常由DevOps工程师和安全专业人员实施，有时站点可靠性工程师将参与确保工具链中工具的正常运行时间和安全性。最后，保护生产中的应用程序。
我们非常熟悉由安全专业人员驱动，由站点可靠性工程师支持。就像DevSecOps实践中有多个角色一样，也有多种技术能力。因此，构建更安全的应用程序和保护软件工厂的前提和基础往往是管道分析。
什么是管道分析?管道分析是从你的工具链中的工具收集遥测数据，这两个工具可能是他们的日志，可能是web钩子，可能是他们的API，还有你的自动化，所以你运行的自动化，你运行的脚本，可能来自terraform或其他工具用于构建基础设施。
一旦你有了这些数据，你就可以从三个不同的角度来看待它。第一个镜头是操作的，它运行了吗?它是否以一种高性能的方式运行?
第二个镜头是依从性，谁得到使用你的工具链中的工具?他们如何访问它?有人在用路由策略吗?最后是衡量成功的kpi。在保护软件工厂的同时，我们有sim卡。实际上，你可以在生产中使用你今天习惯使用的功能，在工具和交付链上使用你的sim技术，以及防止未经授权访问这些工具，可能会暴露知识产权，以及可能影响生产和应用程序安全性的交付链的其他组件。最后，确保生产一直是由Sim驱动的。但在DevSecOps模型中，您还引入了可观察性的功能，以减少识别事件所需的时间，并提供更多的上下文和事件响应，以帮助在事件发生时尽快使用正确的信息进行分类和动员人员。让我们来谈谈Splunk和JFrog是如何结合在一起的。
这两种解决方案是惊人的合作伙伴。与JFrog Artifactory一起管理工件的运输和交付，并使用X-Ray来调查这些工件的已知漏洞。
Splunk在此活动的基础上构建了可见性，这样你就可以利用Artifactory和X-Ray的数据来做出明智的决策，了解你的交付链中现在发生了什么，未来生产中可能会发生什么，还可以衡量整个发布过程的成功程度。它涉及DevSecOps实践的所有三个用例，包括构建更安全的应用程序、保护软件工厂和衡量软件交付的成功。那么JFrog和Splunk是如何构建更安全的应用程序的呢?
首先，Splunk内部的可见性可以帮助你理解和了解XRay和Artifactory的覆盖范围，并对其有信心。
我说的覆盖率是什么意思?我的意思是您有信心开发人员正在做他们需要做的事情，以确保工件有效地移动并扫描漏洞。您还可以利用它来发现工件消耗的异常。那么谁在消费藏物呢?
他们什么时候吃?从哪里?例如，该行为对于确保工件不会在不应该离开组织的时候离开组织是至关重要的。或者您没有从例如公共存储库中提取工件，而您不应该这样做，并且您正在执行与消费和使用工件相关的策略。
它还支持识别配置漂移，确保开发人员机器上的工件不会以某种方式最终出现在存在已知漏洞的工程团队的其他成员使用的存储库中。
还有一个非常有趣的用例，你可以在软件交付过程中对漏洞进行事件响应，你可以让人随时待命，可以是你的DevOps工程师，也可以是你的开发人员，当在构建过程中发现漏洞时，你可以在工件意外进入生产之前停止一切，只需要更多地关注交付过程中发生的事情，这些事情可能会影响生产应用程序的安全性。
现在保护软件工厂，如果您正在使用Artifactory和X-Ray，它们是软件交付过程中的两个绝对关键的工具。重要的是，你要确保对这些工具的访问，这些工具的正常运行时间是合适的。因此，您可以检查以确保您没有对Artifactory进行未经授权的访问或某种类型的拒绝服务攻击，从而阻止Artifactory完成其工作和支持软件交付过程。
您还可以更好地理解如何、何时以及在何处使用工件。它可以是团队的，也可以是程序的，这样您就对您的组织如何使用工件有了基本的了解，并在异常行为发生时开始发现异常行为。最后，我们来谈谈如何衡量成功。
这往往是开发人员最感兴趣的领域。那么为什么它是DevSecOps对话的一部分呢?这些指标作为问题的指示器，对于理解交付链的成功非常有用，而且还可以作为一种工具，让开发人员和DevOps工程师考虑安全性，并对这种可见性感兴趣。你现在在屏幕上看到的指标是Dora指标的一部分。
Dora并不是唯一的一套衡量标准，但它们已经成为行业的某种标准。有许多不同类型的度量标准。但是这些指标可以帮助您理解交付链在很长一段时间内的成功，组织倾向于以变更失败率作为主要指标，对于开发人员ops和开发团队来说，都是如此但是这个速度对他们交付给客户的价值的影响。这是工具运行的截图。
正如您所看到的，Splunk中JFrog的添加是按照我之前描述的相同方式设置的。它有三个关键的镜头:操作、审计和遵守。所以现在，我们正在研究Artifactory，我们正在研究Artifactory如何被使用以及被谁使用的审计视图。从x射线的角度来看，我们开始看到漏洞在整个组织中的影响。
这是测量来自x射线的日志，并为您提供错误的指示。在部署新应用程序的构建期间，通常会遇到峰值。
这是意料之中的。但它也可以帮助您非常直观地快速识别整个交付链中的异常，特别是与检测漏洞有关的异常。最后，我想讲一个额外的用例。
有一种持续验证的想法，即识别已经发布的代码中的漏洞，而这些漏洞在发布时还不知道。所以这种持续验证的想法很酷。
它使用JFrog, Splunk和Splunk的其他工具，无论是Splunk on call，还是Splunk Phantom，以便在JFrog识别现有工件中的漏洞时触发事件和理解潜在的自动补救，并且我们知道该工件已经在生产中。因此，这是一个非常酷的前沿用例，它需要大量的自动化和大量的可见性来实现。对于大多数组织来说，这将是一颗可以触及的北极星。那么你该如何开始在Splunk中使用JFrog呢?
假设您已经设置了Artifactory。如果你是Splunk现有的客户，你可以工作使用你现有的Splunk实例，但你也可以免费试用Splunk来测试JFrog应用程序。
JFrog应用程序位于Splunk基地内，URL就在那里。一旦你有你的Splunk实例设置和你的Artifactory实例设置，你下载并安装这个应用程序，你激活它，你配置它与你的JFrog Artifactory实例细节。一旦你这样做了，Splunk将开始摄取来自Artifactory和X-Ray的日志数据。你将拥有我向你展示的那些仪表板，以便开始在DevSecOps环境中最大限度地提高可见性。
所以JFrog + Splunk是你的DevSecOps可视性合作伙伴。
感谢您参观我们的展示会，并给我机会和您谈谈我们共同的解决方案。如果你想了解更多，请联系我。
你也可以访问Splunk.com来了解更多信息，或者Splunk基础JFrog应用程序，在那个页面上有一个很棒的演示和更多信息。
谢谢大家，祝大家接下来的活动愉快。
