开源正在遭受攻击

我现在正在整个行业范围内努力帮助每个人确保开源供应链的安全。这两个我以后都会讲到。这是我第一次参加虚拟活动。我希望能有一点乐趣。稍后我们会做一些小测验和投票，我希望你们能在聊天中互动回答问题。请诚实地回答你的问题。这是一个没有评判的谈话。这就是我今天要讲的内容。首先，我将介绍开源供应链安全的现状。不幸的是，它受到了攻击。 I’ll cover how, by who and what you can do to protect yourself today. I’ll also discuss what we’re doing as an industry to help solve this for everyone. And then at the end, I’ll finish with with some links and pointers for how you can get involved to help out if you’re interested.
在我开始之前，开源软件是惊人的。首先，我职业生涯的大部分时间都在使用和构建它。但作为一个社区，我们确实需要面对事实。隐藏我们目前面临的问题并不是解决问题的办法。我将首先解释当今开源面临的最可怕和最紧迫的问题之一。如果你这次还没被吓到，课程结束了，请倒回去再看一遍。这是用预先录制的方式做这件事的好处之一。好了，今天讲座的第一个互动部分，我们来做个小测验。首先，我将用一个比喻来解释开源安全和开源供应链所面临的问题。希望在座的一些人能认出这些。 These are USB thumb drives, before Dropbox and Google Drive.
这些是人们在计算机之间存储和传输文件的实际方式。疯狂的,正确的。好了，让我们从几个问题开始。我想让你在聊天中输入“是”或“否”来回应这些，对吧?如果你在街上发现了一个，如果你只是四处走动，发现一个放在地上，你会捡起来吗?把它拿进去，插到你的个人笔记本电脑上?好吧，我在这等你的回答。请参加。别让我一个人去拜访。好了,好了。 All right. Question number two: let’s pretend you were heading into your office at work and you found one of these on the sidewalk. Would you bring this into your office? Plug this into a work computer? Okay, hopefully people are starting to get the theme here. All right. Now one final one.
让我们把它发挥到极致。让我们假设您在数据中心工作，在前往生产数据中心的途中，看到生产数据中心外的人行道上有一个闪存盘。听起来很愚蠢。再解释一下。您会将其带入生产数据中心并将其插入服务器吗?好了，最后一个结束。因为每个人都希望能正确地回答这些问题，你是否接受过任何公司的安全培训，以及在这种情况下该怎么做?你接受过培训吗?他们告诉我不要把不受信任的设备插入你的电脑。好的，希望大多数人都接受过这方面的培训并理解为什么不应该这样做。 Never tried to do a q&a in a recorded talk before.
希望结果不错。我们可以在整个演讲中继续讲下去。希望。这里有一些例子。希望每个人都知道不要将不受信任的设备插入他们的机器，特别是在生产环境中。因为我们所有的安全部门都向我们灌输了这一点。不过，这并不愚蠢。这是一种实际的攻击，已经被使用了很多很多次。它甚至在国际层面上进行。如果有人记得被用来破坏伊朗铀浓缩的斯特拉斯特蠕虫病毒，据说就是这样进行的。
u盘被扔在设施附近，以突破一个空气间隙，让Stusts网蠕虫进入这些浓缩设施，破坏生产。就我个人而言，我甚至不得不跑出去，这几乎表明我的公司谷歌对这种威胁有多重视。我当时住在旧金山，大概是2013年或2014年。我的一个朋友刚买了一架全新的无人机飞到英巴卡德罗的海湾大桥附近。就在谷歌办公室的旁边。当时无人机技术还不太成熟，他没有驾驶经验，我猜他起飞的时候有点风。它让无人机飞了起来，有点失控，最终撞上了街对面的一栋大楼。他很幸运，击中了我当时工作的那栋楼。
事实证明，他在这方面相当幸运。我回到家，拿了我的警徽，走进办公室，试图寻找驱动器。我进去的时候，无人机已经被我们的安全小组没收了。他们有点担心他试图监视办公室，但因为我是他的员工，为他做了担保，他们同意把无人机还给他只要你给他们看上面的照片，而且他没有拍办公室的任何照片。但这在当时让我很惊讶，我甚至没有想过这个。他们很聪明，没有自己把他的SD卡插到他们的机器上。
他们让他去找自己的笔记本电脑，插上插头，给他们看。这就是把不受信任的设备插入计算机的可怕之处。这就是其中一些攻击的创意之处，它们试图让人们把设备插入电脑。我们的安保给我留下了深刻的印象。好吧，我为什么要谈论无人机和铀，这和开源软件有什么关系?下一个测试时间。这个更开放一些。不，是的，这里没有问题。与之前相同的规则要求您在聊天中输入您的猜测。将你在街上找到的USB闪存驱动器插入你的笔记本电脑，和使用你最喜欢的包管理器输入这样的命令来安装开源依赖有什么区别? Type your guesses into the chat here.
这两种情况有什么不同?我的回答是，在生产环境中只有一个以根用户身份运行。这有点好笑。但这真的不是一个笑话。在这两种情况下，你获取代码或二进制文件，你在某个地方找到它，可能是互联网，也可能是人行道上，然后在电脑上运行。唯一的区别是通常NPM install express或任何你想要使用的包管理器，被打包并在生产环境中与你的代码一起运行。优盘卡在你工作用的笔记本电脑上了。这就是我们要讲的主题。
运行不受信任的代码，无论您如何发现它都是危险的。这里有一个NPM install Express案例的例子，一些数字被打破了。当你输入这个命令时，在你开始编写一个节点应用程序，安装53,000行你可能没有看过的代码之前，先开始编写一个简单的node JS应用程序。这包括来自37个不同的人的代码。这里的传递依赖树有超过126个包，在你写一行代码之前就安装一个包。再说一次，我并不是要在这里挑NPM的毛病，我只是用这个作为例子。
嗯，接下来我们将看看我最喜欢的编程语言Go，并展示它是如何遭受一些相同的问题。好的，在下一节课中，我将做一个快速演示，展示实施这些供应链攻击是多么容易，而作为开源维护者，发现攻击是多么困难。对于这个演示，我将使用一个名为numbers CI的示例应用程序。这是用Go编程语言编写的，并使用了新的Go模块补丁管理系统。它基本上运行一个简单的命令行应用程序，将输入作为一个数字，并告诉你它是偶数还是奇数。你在这里运行这个。演示之神今天和我在一起，它将通过4，一个偶数，所以希望它输出的4是偶数。太好了。它工作，这是掌声应该来自我的现场演示工作。
好吧，我们试着用一个奇数来确保它在两种情况下都成立。我不知道你怎么想，如果这对我来说就足够了，我很乐意将它交付生产。幸运的是，如果我的队友不喜欢自定义逻辑，我这里有模运算符，我明白了，已经有一段时间了。如果你没有上过计算机科学课，你可能不记得这个百分号的作用。我的队友派了一个PR来使用这里的第三方库，希望它经过了更好的测试。它告诉我们一个数字是偶数还是奇数。所以让我们跳过PR来看看。这是我在GitHub上的回购，编号CLI，这是一个拉请求。我将切换到使用库，而不是我们的自定义逻辑。我的队友说这个库经过了很好的测试，它应该使我们的代码更容易维护和长期使用。
好了，我的自定义逻辑在这里之前没有任何测试。让我们来看看diff，这里我们可以看到它使用了go。mod文件中很棒的库is odd来查看diff，酷，我们使用了那个依赖而不是我们自己的依赖。现在，如果您想成为一个认真的审查者，我们可以查看代码并检查测试，并确保它按照描述的那样工作。我们把它拉上来。是奇数。酷。它似乎有一些测试，你可以看看那些不错的测试用例，我甚至会讲到我在我的测试中忘记测试的零。让我们来看看它是如何工作的。我们要特别小心，很酷，它使用了另一个库，叫做，iseven，我们今天要非常小心路由器，甚至看一下这个库，以确保它在合并这段代码之前做了它说要做的，看一下这个，iseven，库。太棒了。 This has its own tests to guess about that zero case we forgot about before and it seems pretty simple.
偶点也是偶，这和我们之前做的模算子一样。但是希望由于这个已经测试、检查和维护，它应该比使用我们自己的函数更好。我们今天会非常小心在本地合并这个PR并在合并分支之前做一些测试。回到我的编辑器，我要检查use library分支然后再运行一次，以确保得到相同的结果。哎呀，我看到了，这个图书馆开设了加密辅修课程。现在我的笔记本电脑可能正在挖掘加密货币，它可能已经利用了我所有的密码，不知道发生了什么。这怎么可能?我们真的很小心。
我们查看了添加的第三方库。我们没有查看它的依赖关系来了解发生了什么。这只是表明，如果您不审查所有依赖项，那么执行开源维护者的工作是多么容易，多么困难，即使您审查了所有依赖项，也非常棘手。在这里，我给大家一点时间来思考我是如何在不给出答案的情况下做到这一点的，并展示加密挖掘代码的来源。好吧，让我们来猜一下。如果你在这里有任何猜测，把它们输入聊天。现在我将展示这里到底发生了什么以及你本可以如何避免这种情况。新的Go模运算系统不检查你的依赖项，它默认将它们检入供应商目录。所以很难算出到底哪个版本你使用只需单击在存储库如果我做了,如果我们想供应商,我们不一定需要检查这些,但如果供应商更容易复习什么,我们可以去国防部供应商类型,它会下载版本的模块代理并把它们放在我们回购命令我们可以看看,现在我们有一个供应商目录。让我们打开这个。 The “Is odd code” code is still pretty simple.
这算是扯平了。Iseven，我们可以跳过这个。哎哟VS代码现在不能工作了。太棒了。所以即使。Iseven函数仍然很简单，加密挖掘代码从哪里来?好吧，如果我们看一下剩下的文件，这里还藏着另一个文件utils。go。这不是直接调用的，它使用了Go里面的init函数来挂钩一些逻辑实际上并没有挖掘加密，我不会对自己这么做。但希望它能打印出来。如果打印行没有发生，那么我就没有办法检测到它。 So how did this sneak in, given that we even looked at the is even code and couldn’t find this. Let’s go back to that repo. Well, because there can be a whole bunch of different versions of this package published, and we didn’t necessarily look at the right one. So look through all the commits. This is the one that we’re using in our dependency manager. And you can see that this added that file to make it a little bit harder to find this was removed in the next few minutes. So if you just look at the head branch of this repo, you would miss that and see that I removed it right after. Now, if I wanted to be even worse, could have actually forced pushed over this branch and master deleting all records from GitHub and the Go module proxy system was still preserved that version. So my build would have worked in the future.
这个演示的目的是吓吓你们。假设您是一个开源项目的维护者，每周都会收到几十个pull请求。其中一些可能会更改一个、两个甚至数百个依赖项。如果您没有花时间仔细检查每一行代码，即您在包管理系统中引入的第三方代码，那么这些供应链攻击就可能发生在您身上，特别是如果您没有检查供应商目录的话。如果您不确切地知道系统中的代码是什么，那么您就不知道是否打包了这样的东西。好了，现在我们来总结一下刚才用示例应用程序演示的供应链攻击。
首先，我通过标准的GitHub pull request向一个开源项目引入了一个新的依赖项。如果您是任何开源产品的维护者，那么您应该熟悉如何从第三方贡献者那里获得这些产品。hth华体会最新官方网站我添加的这个依赖本身不包含恶意代码，但它声明了另一个包含恶意代码的依赖，这个依赖反过来隐藏了恶意代码，它只出现在一次提交中。其他提交在此之后分层。所以即使你在找也很难找到。这是由于GitHub拉请求流和Go模块包管理系统所特有的几个原因。首先，在GitHub拉请求中的代码审查，当你使用Go模块包管理系统时，默认情况下只显示依赖元数据。代码不提供，也不签入存储库。因此，在代码审查流程中没有内置的方法来查看你所引入的所有供应商依赖关系，而不需要使用存储库，在本地生成拉取请求并自己构建它。这很耗费时间。
我敢打赌，绝大多数开源维护者不会对每个pull请求都这样做，他们会合并。To Go模块代理实际上是在系统中存储代码。所以即使我把它留在GitHub上，只是为了演示，我可以删除该提交，仍然有Go模块代理的恶意版本搜索。这样做有很多很好的理由。这使得构建是可复制的，并且作者删除或重命名存储库不会破坏每个下游包的构建。但它确实有一个副作用，通过能够从git历史记录中删除攻击，使攻击更难被发现。最后，Go生态系统和所有编程语言生态系统中大多数项目的依赖关系正在迅速增长。即使我们有允许我们逐行检查代码的工具，开源项目的维护者也很难花时间在这上面。因此，以语言不可知的方式来总结这个问题，我们真的需要认真对待代码审查。希望每个人都已经为第一方代码这样做了。 Everyone working on a team.
现在，检查您的队友正在编写的代码是非常标准的实践。但是我们在某种程度上使用了开源代码，让第三方依赖关系从这里的裂缝中溜走了。总的来说，我们希望有很多人关注这个问题。因为我们正在使用一个可信的库。我们希望其他人正在查看它并审查代码。但一般来说，当每个人都负责查看代码和开源系统时，这意味着没有人负责。没有一个人会审查GitHub上的每一个图书馆，这是不可能的。我的意思是，我们只是希望有人正在审查它，或者有人会注意到这样的事情，并让我们知道。这不是解决这个问题的好办法。为了展示一个流行的开源项目的依赖关系管理问题的规模，这里是Kubernetes的依赖关系图的快照，Kubernetes是GitHub上今天最活跃的存储库之一。 Again, this uses the Go programming language and Go package management systems. So this graph is a printout of the Kubernetes dependency tree from a couple months ago, when the snapshot was taken. You can see just the vast scale is problem, every single one of these nodes, you can see how deeply interlinked they are.
这些节点中的每一个都代表Kubernetes树的一个潜在攻击向量。恶意代码被插入其中任何一个，都有机会进入Kubernetes主线，成为Kubernetes发行版的一部分。你可以想象那有多可怕。Kubernetes默认提供他们的代码，这对他们的审查过程有很大帮助。在幻灯片的右侧，我们可以看到Kubernetes供应商目录的快照。它的工作方式是代码由URL组织。通常是github.com，斜杠一些组织名称，斜杠仓库。这是最顶层显示的组织，一些进来的包看起来像是来自值得信赖的来源，比如微软。其他人呢?我不是要挑这些。
但我们不知道这些代码是从哪里来的。一般来说，当我们不相信代码的作者时，它没有被逐行检查。甚至对于声称来自微软的代码，我们也没有真正的方法来验证它是否在任何地方都没有签名。我们无法确保微软发布了这些代码。这只是放在一个供应商目录的文件夹中，声称它来自微软，贡献者在拉请求中发送代码到Kubernetes可能已经修改了这个。所以我们有无数的攻击点和非常糟糕的工具来捕捉这样的问题。我们真的需要新的工具、新的实践和新的系统来解决这个问题，帮助整个行业解决这个问题。好像2020年不会更糟了。为什么现在会发生这种情况?开源已经存在很久了。
包管理已经存在很久了。为什么这突然成了一个问题?这是供应链攻击的一个小时间表，包括最近的一些。我们对这种攻击已经了解了几十年，几十年，几十年。这一发现首次发表在一篇名为《关于信任的思考》的论文中，该论文详细阐述了自举问题。您不仅必须知道所使用的所有代码的确切来源，还必须知道用于构建和转换这些代码的所有二进制文件的确切来源。如果一个编译器被黑客攻击变得脆弱，这个编译器可以进入后门，在那之后构建每一个二进制代码，你甚至可能在代码审查中看不到它。这演示了一些新颖的攻击，其中代码隐藏在编译器中，很难找到它。很久以后，我们在2006年开始看到更多这样的攻击，Debian和Red Hat内部操作系统级别补丁管理的大量存储库，Linux发行版中毒。这是一个凭证泄漏，因此人们能够直接将包插入到包管理器中。
2010年晚些时候是我之前讲过的Struts网络。使用u盘作为进入供应链的一种方式，那里有一个空气间隙，甚至没有被使用。2011年晚些时候，现在的dot org，其中Linux内核源代码被泄露。大规模的审计显示没有做什么严重的事情。但是想象一下，如果Linux内核从2011年一直到今天都被泄露，会发生什么。这并不一定是2016年的袭击。左边的pad问题，但这确实表明在编程社区中，与第三方包管理系统的联系是多么深入，特别是节点。Js，它倾向于有一堆相互依赖的小包，而不是大包。左垫是一个包类似于我的奇数是偶数样本之前，它只包含一个函数，左垫，它添加填充到左侧的字符串或行。此包已被删除。 From the NPM package repository, which broke the builds of pretty much everything in the node ecosystem, because this package was a dependency of a dependency of a dependency of something that was used everywhere. The NPM package repository made some changes after that to prevent deletion outside of extreme cases. This was one of the biggest shocks to people using third party packages in NPM. To help kick off awareness of this issue. In 2017, there’s a very serious supply chain attack called Docker 123321.
有人在Docker Hub上建立了这个存储库，命名了一大堆有用的映像，比如MySQL和Tomcat都在Docker 123321下发布。之后，这些图片得到了相当多的使用，部分原因是Docker图片越来越受欢迎。供应链攻击被插入其中以安装加密辅币。我们之前讲过的Go的例子，如果你真的想花时间看看这些东西是从哪里来的，浏览代码是很容易的。在Docker映像内部，它通常在1gb左右，并获得表明文文件和二进制文件。如果你不花时间实事求是地审视二进制文件的每一个部分，你将如何做到这一点?你不知道里面有什么，你必须确保你信任你使用的源代码源代码来自的包管理器，以及负责维护发布这些限制的组织。在这之后还有一大堆。
Bootstrap sass是另一个没有在这里的例子。最近，还有一个叫webmin的。Webmin是一个流行的web管理工具。它被广泛用于管理服务器。一个后门被插入到web=min版本中，在构建服务器本身受到损害。是的，即使你能完全访问源代码并审查它，二进制文件也会被破坏。因此，您必须相信组织也在发布这些二进制文件。这里还有一些坏消息。抱歉，希望2021年能好一点。我真的不想火上浇油，但2020年的开源供应链攻击看起来不太好。 This is looking like the worst year on record. Any interpretation of these numbers, this is a massive problem that is only going to get worse over time. 11 million developers are using NPM. Each month manage node.js packages. There’s been almost an 80% rise in supply chain attacks in 2019. And 2020 is looking worse so far. Pretty much everyone is using open source software. Surveys carried out by different groups like black duck, Linux Foundation, have shown this to be true. And this isn’t a trend that’s declining, this is increasing. Organizations are not reducing dependency and open source is increasing over time.
那么，为什么现在我们只看到这些攻击呢?这是多种因素共同作用的结果。每次入侵软件的成本越来越低。随着人们使用更多的开源软件，每天都有更多的目标被发布。这意味着这些是更好的目标，这将导致更多的袭击。开源再次崛起，开源使用越多，开源供应链受到攻击的风险越大，最后，提高总体安全性。黑客和攻击者希望采用最简单的方法。当我们最终得到工具，以加强所有其他入口点，并使其更难插入后门。开源供应链攻击正变得越来越有吸引力，因为它们是迄今为止剩下的最简单的方法。这次谈话中可怕的部分已经结束了，大家可以放松了。
如果您需要在这里暂停，并查看您的供应商代码的每一行，请这样做，记录将等待您。现在我们跳到乐观建设性的希望部分。今天我们将讨论如何保护自己。作为一个行业，我们所做的是帮助保护每个人。所以，让我们从一些简单的建议开始，关于如何保护你自己的源代码和你的客户。首先，你需要锁定你的回购。repo是软件开发中存储代码的起点，也是所有依赖关系的真实来源。您希望尽可能地锁定这些内容，限制有权将内容合并到存储库的贡献者和维护者的数量，并执行基本的其他保护措施，如启用和要求双因素身份验证。禁用强制推送，使人们更难重写历史，并要求代码审查，这样任何人都不能单方面对存储库进行更改。其次，保护自己免受攻击和第三方依赖的简单方法是减少第三方依赖的数量。 This can be a little bit painful. Using open source libraries is easy and a quick way to get started.
但是这些，这总是要付出代价的。通过使用这些开源库，您可以信任作者和维护者。一定要批判性地思考每一个问题，并决定使用它的好处是否值得花费，以及潜在的安全问题。每个依赖关系都是一个攻击向量。然后评估你是否真的需要它们。有时复制一小部分代码比依赖整个库要好。对于那些你记不住的，如果你想审计这些，你需要逐行仔细检查以确保在依赖树中没有你不想要的东西。当你进行更新时，确保你也在跟踪这些更新。一旦你有了一个良好的稳定的基础，能够每周或每月检查依赖项的更改就不那么痛苦了，而且作为一个团队来做也容易得多。您希望像检查第一方代码一样检查这些更新中的这些更改。 Nobody on your team can commit code without it being reviewed.
那么，为什么你要信任一个互联网上的陌生人，让他能够在不经过审查的情况下对你的代码进行更改呢?最后一种帮助方法是将可观察性添加到CI/CD管道中。持续集成持续部署系统是将源代码一直带到生产环境的系统。你要确保它是可观察和可审计的，这样在出现问题的情况下，你有足够的信息存储，能够弄清楚你有多脆弱，以及到底发生了什么。例如，如果您不知道确切地知道哪些版本的源代码被打包并在生产环境中运行，那么您就不知道如何发现是否发生了类似的事情，以及您有多容易受到攻击。想象一个CVE报告和第三方依赖关系。您是否有工具来知道您是否曾经部署过带有第三方依赖关系的版本，您可以选择知道该版本今天是否正在生产环境中运行。如果你没有这个，你没有你的CI/CD系统，那么如果类似的事情真的发生在你身上，你就会处于一个受伤的世界。所以希望你能采取措施保护自己。我将谈论我们正在做什么来帮助解决这个问题，作为一个行业，使它更容易，并减少维护者的负担。 The first piece here is identity in software development. By removing a lot of the anonymity for critical open source software and understanding who the developers are, then it’s easier to place trust in these people. Today, a lot of artifacts are just signed and we have some weak pki infrastructure or know where code and binaries are coming from. But it’s hard to use and it’s not enough. We’re looking at this and kind of three main parts as an industry wide solution.
首先，我们需要某种数据库和贡献者的最新标识。例如，在GitHub上使用默认头像的匿名者不应该能够单方面地对Linux内核驱动程序进行更改。我们需要某种联邦数据库，它不属于任何一家公司。提供最新的身份信息、公钥信息、关键开源软件的贡献者和维护者的联系信息。接下来，我们还需要为关键维护者提供身份验证服务，你可以在手机上注册并创建一个银行账户，只需拍下你的身份证照片。但是今天你不能对任何一种开源软件这样做。一大堆关键基础设施受到关键交换方的保护，这在过去10年里从未发生过。我们需要这些服务来验证你的身份。人们可以信任这个身份，而不仅仅是目前现有的任何服务。然后我们需要一大堆的基础工作来让这一切成为可能。 We need formats and tooling to securely manage this identity metadata.
所以如果人们能查到它，人们的身份就不会被泄露，而且注册和使用它也很容易。这里正在进行一些不同的努力。签名提交和Git现在是可能的，但设置起来有点棘手。在核心Git内部有一些工作正在进行，以使这更容易。每个人都已经将SSH密钥添加到他们的GitHub帐户中，没有理由不能使用这些SSH密钥来签名提交，而不是必须生成单独的GPG密钥并跨机器管理它们。我们也看到了一些上游工作，允许SSH密钥签名进入Git，并使在GitHub上签名提交变得更容易、更普遍。下一个大问题是无处不在的双因素认证。在源代码控制系统和补丁管理系统上发生了如此多不同的妥协，因为开发人员没有在可用的地方使用双因素身份验证。我们提倡在任何源代码控制管理系统和工件管理系统上都可以使用这个特性。
然后帮助标记存储库不使用双因素身份验证。即使您信任您正在使用的开源包的维护者。如果该维护者没有使用双因素身份验证，那么您就信任了他们的密码和今天可能使用该密码的所有其他站点，没有工具可以查看它是否被维护。
如果你使用双因素身份验证，使其可见，我们真的需要采用这些已经存在于整个行业的安全实践。因此，一旦我们超越了信任贡献者和相关个人以及身份，从而知道他们是谁，我们就需要开始构建工具来信任源协议。这是一堆我们需要回答的基本问题。如果你从互联网或容器图像中获取二进制文件，二进制文件中包含什么代码，使用什么工具从这些代码中生成二进制文件?今天，这些都没有被打包成二进制文件，有可能找出一大堆逆向工程。这里正在进行一些工作，软件材料清单空间，BoM，标准格式，以描述二进制文件是如何构建的，以及这些二进制文件中究竟有哪些源代码和库。这对审计和CVE监视器都很有用。如果你使用的工具有一大堆依赖项，并且在这些依赖项中发现了CVE，你应该注意这一点。
我之前谈到了身份，但是能够附加关于谁编写它，谁构建它，谁生产它，谁分发二进制文件和源代码的信息是另一个巨大的问题。最后，它安全吗?并不是所有的漏洞都是有意引入的，有些漏洞也是偶然引入的，通过众包审查，发布调查结果和安全审计，并为所有这些项目设立资金，我们可以以一种可扩展的方式帮助确保安全。每个公司都不应该必须审计他们使用的每个依赖项的每一行，我们应该能够以集体的方式做到这一点。信任消息来源是必要的，但这是不够的第一步。您还需要信任用于将源代码转换为所使用的工件的构建过程。如果您不知道谁构建了代码，那么即使您知道谁编写了代码，也不能真正信任该工件。这需要我们构建我前面提到的这些联邦强标识程序。您还需要知道用于构建该代码的工具链。即使你信任建造它的人。 If you don’t know which version of the compiler which version of the built environment was used, and it could still be issues.
在编译器中一直可以找到cve。如果您没有元数据，并且不能相信用于构建二进制文件的确切数据，那么您在这里仍然遇到麻烦。最后，建筑安全吗?想想GitHub和Docker Hub上的那些curl pipe bash行和Docker文件吧?你不知道它们到达了什么端点，也不知道从这些端点返回了什么，那么你就不能真正信任整个构建过程。有一大堆工作正在进行中，以使密封可复制的构建对每个人来说都容易和可用。工件管理系统是这里的最后一部分。当拥有工件管理系统凭据的人没有很好地输入它们时，攻击就会发生，并且这些凭据会被泄露，恶意攻击者能够跳过CI/CD系统和源代码管理系统，将已经被破坏的工件直接上传到包管理器。因此，您可以保护那些有权访问这些工件和包管理器的人的身份信息。还有一大堆针对更新过程的攻击。 Imagine if you had a way to block an update notification or update detection from a certain individual.
然后，一旦发现已知的CVS，就可以强制它们使用旧版本并利用这些漏洞。这里有一大堆系统和研究正在进行，以帮助防止这类攻击。网络正在进行，更新框架和容器图像的公证v2项目。然后回火。我上传了一个藏物，你下载了一个藏物并不意味着它中间没有被篡改过。签名已经有一段时间了。但它们并不是那么普遍，尤其是在语言生态系统中。所以我们得让这些监护权变更的签字变得容易些这样当你拿到东西的时候你就知道是我做的。同样，标准的软件材料清单格式对于确保我们知道包的问题是很重要的。如今，包管理器无处不在，而且每天都有新的包管理器出现。 There’s also a bunch of work that we need to do to improve package managers state of the art for them and get those improvements into all the new ones that are appearing for languages. In Go modules, I picked on them a little bit before my demo, but they have done some major improvements here. The new version selection algorithm helps prevent developers from accidentally upgrading something if you have changes they didn’t intend. In the module proxy server and transparency log make it easier to detect changes and prevent people from distributing malicious packets.
这项工作已经产生了一些很酷的透明日志系统。我们需要将其扩展到现在的在线合同管理系统和集装箱图像。最后，我之前说过，我们需要让CVE报告对所有的语言包管理器都是可访问和可扩展的。这只是我们需要做的一些工作的高水平概述，以总结其他正在进行的工作。现在的编程语言都不允许你在依赖级上应用权限。想象一下，Android应用程序商店或应用程序开发人员必须请求权限才能访问网络或设备上的文件。管理员，你可以用NPM安装一个包，但不给它文件系统权限，因为你认为它不需要它们。这将使防止加密货币、挖矿、出口和凭证等事情变得更加困难。然后就是我说过的那种无聊的，一般的卫生改善工作。我们有双因素认证，你知道签名是如何工作的，但人们不使用它，因为它很难。 We need to encourage them, teach them the importance of it and make it as easy to use as possible. All right, so hopefully I’ve scared you. But then given you a little bit of hope that this is going to be alright.
我将谈谈你如何参与，以及为什么你应该参与。供应链攻击对于开源软件和一般软件来说是一个严重的问题，如果你正在使用它的话。这是你们应该感兴趣的问题。这里没什么新东西。这是一个标准、自动化和数据问题，没有什么突破性的，我们只需要做我们知道需要做的工作。因此，如果我们大家共同关注这个问题，我认为我们能够解决这个问题，并帮助防止此类袭击继续发生。如果你感兴趣的话。我们在很多不同的地方都在努力。如果你想帮助构建可复制的构建并信任构建过程，GitHub上的tecton cd斜杠更改存储库是一个很好的地方。好的，感谢大家收听我的第一次虚拟演讲。 And thanks for having me at swampUP. Here’s my contact information. And feel free to reach out if you’re interested in this talk or any of the things I mentioned.