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

