因此，最近备受瞩目的太阳风漏洞只是软件供应链漏洞的最新例子。
这些漏洞对商业软件和开源软件都有影响。
我们都熟悉一些著名的历史漏洞，如Equifax漏洞，但最近，这类攻击的数量不断升级。
例如，一种新型的供应链攻击不仅打击了微软，
苹果和其他33家公司。
这种情况已经变得如此糟糕，以至于CSO杂志最近称其为完美风暴。
在一些司法管辖区，这也已成为一项紧迫的政府政策重点。
几周前，美国白宫发布了一项行政命令，指示一长串机构进行供应链审查，包括供应链依赖数字产品所带来的风险，这些数字产品可能容易出现故障或被利用。hth华体会最新官方网站
最近，就在过去几天里，国家安全委员会网络安全代理高级主管杰夫·格林(Jeff Green)表示，我们将需要所有向政府销售软件的开发者实施更严格和可预测的机制，以确保他们的产品和软件的行为符合预期和设计。hth华体会最新官方网站
实际上，无论您的组织是否与美国联邦政府有业务往来，每个组织都是时候认真起来，让自己的软件供应链井然有序。
而且，由于如今几乎每个构建的应用程序都在其代码库中包含了开源软件，因此，软件供应链安全性越来越多地是相同的或包含了开源软件供应链安全性。
不幸的是，大多数组织目前都没有很好的处理方法，甚至不知道他们使用的是什么开源，更不用说它的安全状态了，特别是当您不仅考虑到应用程序构建的直接依赖项，而且还考虑到从开源社区包管理器中引入的数百甚至数千个间接依赖项时。
现在，如果你看一个典型的应用程序，通常70%或更多的代码组成它将是第三方开源代码。
当然，这是您组织中的应用程序开发团队的工作，创建应用程序的业务逻辑，实现用户界面和您要创建的业务流程。
通常，特别是现在，这些应用程序将部署在托管服务平台上，无论是第三方云提供商还是组织中的内部托管服务。
在某种程度上，对于大多数应用程序来说，70%的开源是通过这些社区包管理器来自第三方的，没有人能积极地维护它。
如果我们不认真对待，这就会成为一个问题。
开源真的很神奇，令人难以置信的是，我们已经能够创造这个丰富的、技术的和知识的公有物，我们所有人都可以在我们的组织和个人中建立。
但是关于开源维护也有一些令人不安的事实。
应用程序开发中使用的绝大多数开源项目基本上都是由志愿者的努力所驱动的
可能正在做这些事情，通常与他们的日常工作有关，或者是他们主要工作的副作用。
但这些开源包将按照不同的标准进行维护，甚至在安全等重要领域也是如此。
这给依赖它的组织带来了挑战，
您知道，在所有这些领域进行巡逻是非常耗时的，如果不进行巡逻，可能会使您容易受到软件供应链攻击，就像我们已经讨论过的那些攻击。
事实上，对于使用开放源码进行构建的组织，也就是今天的大多数软件开发团队来说，甚至很难回答关于他们正在使用的第三方开放源码的基本问题。
这可能会影响开发团队的进度。
如果您的组织不能简单地回答以下问题:这个包可以使用吗?
有人看过这个开源包的许可条款并确认它们适用于我们的业务吗?
最重要的是，这个包目前是否安全并积极维护?
如果未来出现新的安全漏洞会发生什么?
同样，开源软件只是软件，会有新的问题出现，我们只需要有一个计划、一个过程和工具来很好地应对这些问题。
因此，当我们与使用开源构建的组织讨论他们从管理角度面临的挑战时，通常会归结为这三大挑战。
维护——确保有人能够使软件处于良好的工作状态。
安全性——确保没有已知的安全漏洞，当漏洞被发现时，有一条前进的道路可以全面解决该漏洞，并在某种程度上填补漏洞。
当然还有许可证。开源软件的复杂程度可以分为几个部分
从许可的角度来看。所以，这需要一些过程和纪律。
但更有挑战性的是，您可能想要使用的单个开源项目的许可状态可能是模糊的。你知道，现在还不清楚是否有干净的数据开始。
所以所有这些都是，你知道，对于一个组织来说，以一种特殊的方式来处理的重大挑战。
当我们和团队谈论他们做得如何时，当我们问他们，你对你的组织目前使用的开源组件是最新的、安全的和维护良好的有多大信心?
我们经常听到这样的说法，组织觉得他们并没有真正控制这一点。
我们询问的39%的大型组织告诉我们，他们对他们的开源组件不是很有信心，或者根本没有信心，这些组件是最新的、安全的、维护良好的。
只有16%的人告诉我们他们非常自信。
当我们要求组织调查他们目前如何解决这个问题时，我们通常会发现他们陷入了两种极端情况中的一种。
一种是分布式方法或者快速移动人群。
这是一种，你知道，创业的心态，快速前进，打破常规。
对于采用这种方法的组织来说，应用程序开发团队在采用新的开源组件时通常没有什么障碍。
我们的理念是，你知道，让人们使用他们需要的，不要阻碍
开发商让他们快速建造。
当然，从开发人员速度的角度来看，这是很棒的，但它有一个显著的缺点，即它可能会在未来的道路上产生维护、安全和许可问题，甚至涉及到安全之类的存在问题。
其他组织则采取更为保守的集中式方法。
这就是我们所说的安全人群。
采用这种方法的组织，他们通常有某种中央审查过程，可能是通过一个票务系统实现的，或者只是简单的
旧的电子邮件、电子表格或维基页面。
并且这种风格的开发人员在使用一个包之前，需要征求对一个新许可证的批准，甚至只是一个包的单独发布。
这有一个好处，它引入了一些流程和控制，但有一个显著的缺点，那就是应用程序开发团队要应对它变得非常非常麻烦，
这降低了他们的速度，坦率地说，我们经常在现实世界中看到，这导致开发团队绕过这个控制点。
那么，我们为什么不能两全其美呢?为什么我们在使用开源时不能既快速又安全呢?
我们认为有一种方法可以解决这个问题，这就是潮汐力一直关注的地方，即构建更好的工具和流程，以及解决这个问题的新方法，为您提供两全其美的方法。
现在，我们的方法受到了我们所看到的一些最好的科技公司使用开源的方式的启发。
如果你看看像谷歌，LinkedIn, Netflix这样的公司，
当然，它们也主要是基于开源构建的，就像您的组织一样，他们已经实施了一系列流程，以确保他们所依赖的开源得到良好的管理。
我们发现它们通常都采用非常相似的方法，即创建一个预先审查的、已知的优秀开放源码包发布的集中目录。
其中一些组织将其称为铺平的道路，因为在内部应用程序开发团队中，如果他们使用集中式预先审查的目录中的组件，他们知道它将从安全性、许可和维护的角度满足他们组织的需求，这是一条很容易走下去的道路。
所以有了铺好的道路，这意味着它们可以走得更快，它们不必在树上的杂草中穿行，它们可以快速移动，但也知道它们也不会，你知道，跑进沟里或从路上掉下来。
在这些最大的组织中，只有一些真正实现了这种方法，因为坦率地说，这是一种昂贵的方法。
它不仅需要工具和流程，还需要一个团队来主动管理、调查和主动管理组织中使用的每个新组件的每个新版本。
有很多工作要做。
那么，您的组织如何从这些大型科技公司所采取的方法中学习，以创建已知优秀开源的集中目录呢?
我们建议开发人员把它比作急流。
所以如果你想想，你知道，飞机在国内或国际上飞行，进入高速气流有一个巨大的优势，如果你愿意的话，它使旅程更有效率和更快。
因此，如果你想想我们谈论过的那些传统的保持安全的方法，那些是真正的过程，当试图，你知道，确保组织的安全和保障时，他们真的制造了逆风，要么是通过官僚主义的繁文缛节风格的治理，要么是通过运行一个有很多假阳性的扫描工具，团队需要涉水处理的应用程序开发团队来执行工作。
您真正想做的是进入这样一种情况:您为您的应用程序开发团队提供了一个顺风，他们有一个
一组开源组件，他们真的不必担心所有这些研究，并弄清楚，你知道，它是否符合我们组织的标准，它在未来会发生什么。
他们放心了，他们可以从预先批准的组件目录中取出，然后就走了。
它还需要有一些扩展目录的能力，在这种情况下，可能有一个组件需要执行一些独特的功能，需要添加到集合中，而这个集合中还没有。
它不能是一个繁重的过程，也不能阻碍应用程序的开发。
因此，当我们看到组织开始为其应用程序开发团队创建高速气流时，我们通常会看到他们经历这一旅程的许多阶段。
这个旅程的第一步是盘点已经被使用的东西。
因此，让我们构建一个在整个组织的应用程序开发中使用的开源组件的列表，包括所有间接和传递依赖项，并为当前使用的开源创建一个构建材料。
这个过程的下一步是开始考虑哪些标准和策略对您的组织有意义，这些标准和策略与您想要使用的那些开源组件和未来的开源组件有关。
哪些开源许可证对您组织的业务模型或部署场景有意义?
您希望或需要执行哪些安全标准?
将这些规则编入一组规则，这些规则可以自动应用于软件开发过程。
然后，哪些组件对您的组织来说是有意义的，可以是跨越许多不同编程语言、生态系统的非常广泛的开源组件。
或者，您可能还希望实施一些技术标准，以集中您的应用程序开发团队使用某些开发工具或平台。
一旦您有了这些，在这个构建阶段，您就可以开始偿还您的组织可能已经积累的一些技术债务，方法是将您对开源的使用对准这些符合这些定义的标准的开源组件。
一旦你做到了这一点，你就有了这样的平台，一个运行良好的过程和一些工具，你就可以在你的组织中加速你对开源的管理，把更多的开发团队，更多额外的开源组件放在伞下。
最后，我们发现组织最终转变为这种模式，在这种模式中，开源已经成为整个组织的竞争优势，允许开发团队更快地前进，因为他们有这种顺风。
现在，在Tidelift，我们的商业服务可以帮助您的组织完成这一任务。
我们的服务叫做tidal订阅。
这是您的组织通过降低这一过程的复杂性来更好地管理开源供应链的一种方式。
这可以让你完成许多底线业务目标。
一个是削减成本，因为你不必自己承担所有这些负担来找出根源，调查和管理所有这些开源。
我们为您做了很多工作，并通过我们提供的工具提供给您。
它允许您的团队更快地移动，因此您可以更快地构建和交付应用程序，并确保您减轻了来自开源供应链的风险。
现在，潮水掀起订阅的方式是非常独特的。
所以有三个组成部分组成了这个解决方案。
首先是一套工具。
它是一个多租户SaaS应用程序，连接到您的软件开发生命周期，并与JFrog平台等工具一起工作，我稍后将讨论JFrog平台，基本上它的作用是使您的应用程序开发团队能够轻松地始终确保他们在任何给定应用程序中构建的组件符合组织的策略和标准。
现在，再一次从您的团队中卸载大量的工作，Tidelift正在您的组织上游工作，以研究和响应与第三方开源相关的问题。
我们目前涵盖了数千个经常使用的开源组件
在企业应用程序开发中，我们将这些组件组织到严格的开源组件管理目录中，以及我们已验证的那些组件的特定版本发布，这些版本满足一定的安全、许可和维护标准。
这些类型的托管目录涵盖了一大堆不同的应用程序开发生态系统，包括JavaScript、Java、PHP、Ruby、Python、dotnet、rust和go。
现在，解决方案类型中最独特的部分是维护者。
因此，Tidelift与其他商业开源公司有着非常非常不同的商业模式，其他商业开源公司有全职的内部工程师和开发人员，他们做所有的商业化工作，以确保软件符合标准。
Tidelift解决这个问题的方法是，我们认识到，我们所依赖的成千上万个开源组件的创建和维护是相当分散的，对吧?有很多人都在互联网上这样做。
因此，我们与各种各样的开源维护者一起工作。
我们允许他们与Tidelift合作，以确保他们的软件符合这些定义的安全、许可和维护标准，并从中获得收入分成。
所以我们让很多人在开源的基础上做这个，出于善意的精神，我们允许他们这样做，因为所有这些原因，我们给他们一个很好的借口，让他们把它带到下一个层次，确保它完全是企业级的。
通过这项工作，因为他们为依赖该软件的组织创造了价值，他们通过Tidelift平台获得了补偿，这是一种非常独特的解决问题的方式。
现在我想谈谈Tidelift与JFrog的联合解决方案，并向您介绍其工作原理。
因此，Tidelift和JFrog已经合作了近两年，以确保解决方案的标题与JFrog的人工平台非常自然地比较。
当这两个组件结合在一起时，它使开发团队能够大规模地利用企业级开源技术，而且是安全的，这样他们就可以两全其美，他们可以快速移动，并保持安全。
现在来看看Artifactory和Tidelift是如何合作的。
因此，JFrog Artifactory平台扮演着DevOps数据库的传统角色，是组织中二进制文件的唯一真实来源，以及贯穿其软件开发管道的云原生构件。
现在，tide lift补充了这一点，作为已知良好的事实的单一来源，积极维护第三方开源组件，这些组件是组织的一部分，或者我们对组织的云原生工件和二进制文件的输入。
你的组织负责你写的代码，回想一下我展示的20%的图表，你知道，这是你的业务逻辑。
Tidelift和我们的维护者网络介入，覆盖了70%的第三方开源，包括一个典型的应用程序。
这意味着你的组织从头到尾都被覆盖了，确保你的
软件满足这些企业标准。
下面是如何将其集成到JFrog artifactory平台工作流程的快速预览。
Tidelift正在通过主动管理来确保这些数以千计的开源应用程序开发组件的目录符合定义的安全许可和维护标准。
您可以使用Tidelift的工具创建一个自定义目录，这些工具可以实现您组织的任何特定策略，在某种意义上，您是在基于经过验证的干净数据过滤主Tidelift目录，您可以说，我们的组织只批准这些特定的开源许可证或在这个部署上下文中批准这些许可证。
因此您可以自定义提要。
一旦你有了开源包和版本的列表，你就可以把它插入到一些地方。
其中之一可以是用于生产应用程序的构件存储库。
因此，只有正式批准的应用程序包发布，满足所有标准，通过任何额外的内部审查，你想要到位。
我们发现许多组织也有第二个人工存储库，它是为开发人员提供服务的开发存储库。
该存储库可以包括已请求添加到组织的自定义Tidelift目录的主目录中的开源包发布。
这意味着您的应用程序开发团队不会受到阻碍，他们可以继续前进，但这也确保只有经过正式批准并证明符合您的组织标准的包才能投入生产。
所以，这是两全其美。
快速开发，安全生产。
现在，当所有这些放在一起的时候，其实是非常简单的。
事实上，这很简单，我们为此写了一本儿童读物。
我鼓励你们去看看。
这是URL，或者直接去搜索使用Tidelift和JFrog烹饪。
这是一种非常有趣的，不同的思考问题的方式，你知道，这是一种熟悉概念的好方法，同时可能会取悦你生活中的一些年轻人。
在此，我想说声谢谢，再说一次，这是事先录好的谈话，但我可以在活动当天在聊天中回答问题。
谢谢你！
