开源正在遭受攻击

我现在正致力于一个全行业范围的工作，以帮助确保每个人的开源供应链。这两个我稍后会讲到。这是我第一次参加虚拟活动。我希望能从中得到一点乐趣。稍后我们会做一些测验和投票，我希望你们参与互动，在聊天中回答问题。请诚实回答你的问题。这是一个不带评判的谈话。这就是我今天要讲的内容。我将从介绍开源供应链安全的状态开始。不幸的是，它受到了攻击。 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.
希望你们解决得很好。我们可以在整个演讲中继续这个话题。希望。这里有一些例子。希望每个人都知道不要将不受信任的设备插入到他们的机器中，特别是在生产环境中。因为我们所有的安全部门都强烈地向我们灌输了这一点。不过，这并不愚蠢。这是一种实际的攻击，已经被使用过很多次了。它甚至在国际层面上进行。如果有人还记得用于破坏伊朗铀浓缩的蠕虫病毒，据称是这样进行的。
USB闪存盘被放置在铀浓缩设施附近，目的是突破一个气隙，让Stusts网络蠕虫进入这些铀浓缩设施，破坏生产。就我个人而言，我甚至不得不带着这个跑出去，这几乎表明了我的公司谷歌对这个威胁的重视程度。我当时住在旧金山，大概是2013年或2014年。我的一个朋友刚买了一架全新的无人机，在英巴卡德罗的海湾大桥附近飞行。就在谷歌办公室的旁边。当时无人机技术还很新，他对飞行还没有多少经验，我猜他起飞的时候刮起了风。它让无人机飞起来，有点失控，最终撞上了街对面的一栋建筑。他很幸运，撞到了我当时工作的谷歌大楼。
事实证明，他很幸运。我回到家，拿了警徽，走进办公室，试着找那辆车。我进去的时候，无人机已经被我们的安全团队没收了。他们有点担心他想监视办公室，但因为我是员工，为他做了担保，他们同意把无人机还给他只要你把上面的照片给他们看，而且他没有拍办公室的照片。但这让我当时很惊讶，我甚至没有想过这个。他们很聪明，不会自己把他的SD卡插到他们的机器上。
他们让他去拿自己的笔记本电脑，插上电源给他们看。这就是将不受信任的设备插入计算机的可怕之处。这就是这些攻击有多么有创意，试图让人们将设备插入他们的电脑。我们的保安给我留下了深刻的印象。好吧，那么我为什么要谈论无人机和铀，这和开源软件有什么关系呢?下一个测试时间到了。这个更开放一些。不，是的，这里没有问题。与前面相同的规则要求您在聊天框中输入您的猜测。将您在街上找到的USB闪存驱动器插入您的笔记本电脑与使用您最喜欢的包管理器输入这样的命令来安装开源依赖项之间的区别是什么? Type your guesses into the chat here.
这两种情况的区别是什么?我的回答是，在生产环境中只有一个是作为根运行的。这有点好笑。但这并不是一个玩笑。在这两种情况下，你都拿着代码或二进制文件，你在某个地方找到的，可能是互联网，也可能是人行道上，然后在电脑上运行它。唯一的区别是，通常NPM install express或任何你想要使用的包管理器都会打包并在生产环境中与你的代码一起运行。闪存盘就在你的工作笔记本上。这就是我们要讨论的主题。
运行不受信任的代码，无论您如何找到它，都是危险的。下面是我们正在研究的NPM快速安装案例的一个例子，其中出现了一些数字。当你输入这个命令时，在你开始编写一个节点应用程序之前，安装53,000行你可能没有看过的代码，只是开始编写一个简单的node JS应用程序。这包括来自37个不同的人的代码。然后，这里的传递依赖树有超过126个包，在您编写一行代码之前，只需安装一个包。再次强调，我不是要挑NPM，我只是用这个作为例子。
嗯，接下来我们来看看Go，我最喜欢的编程语言，并展示它是如何遭受一些同样的问题。好了，在下一节课中，我将做一个快速的演示，展示实施这些供应链攻击是多么容易，而发现一个开源维护者是多么困难。在这个演示中，我将使用这里的一个示例应用程序，名为numbers CI。这是用Go编程语言编写的，并使用了新的Go模块补丁管理系统。这基本上运行一个简单的命令行应用程序，它接受一个数字输入，并告诉你它是偶数还是奇数。你继续在这里运行。演示神今天和我在一起，将传递4，一个偶数，所以希望它打印4是偶数。太好了。它是有效的，这是掌声应该从我的现场演示中响起的地方。
好了，我们用一个奇数来试一下确保这两种情况都适用。我不知道你怎么想，如果这对我来说足够的话，我很乐意把这个送到生产部门。幸运的是，如果我的队友不喜欢这个自定义逻辑，我这里有，模运算符，我懂了，已经有一段时间了。如果你没有上过计算机科学课，你可能不记得这个百分号是做什么的。我的队友发送了一个PR来使用第三方库，希望它能得到更好的测试。它告诉我们一个数是偶数还是奇数。所以让我们跳到那个PR，看一看。这是我在GitHub上的repo，编号CLI，这是一个pull request。我将切换到使用库而不是自定义逻辑。我的队友说，这个库经过了很好的测试，它应该使我们的代码更容易维护和长期使用。
好的，我得到了我的自定义逻辑之前这里没有任何测试。让我们来看看diff，这里我们看到它使用了go。mod文件中很棒的库isodd来看看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 modulo系统不会检查你的依赖项，它会在默认情况下将它们检入供应商目录。所以很难算出到底哪个版本你使用只需单击在存储库如果我做了,如果我们想供应商,我们不一定需要检查这些,但如果供应商更容易复习什么,我们可以去国防部供应商类型,它会下载版本的模块代理并把它们放在我们回购命令我们可以看看,现在我们有一个供应商目录。让我们打开这个。 The “Is odd code” code is still pretty simple.
这才算扯平。还是那句话，我们甚至可以跳到那句。哎呀VS code现在不工作。太棒了。所以即使。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.
这个演示的目的是吓吓你们。想象一下，您是一个开源项目的维护者，每周会收到数十个拉取请求。其中一些可能会更改一个、两个甚至数百个依赖项。如果你没有花时间仔细检查每一行代码，也就是包管理系统中的第三方代码，那么供应链攻击就可能发生在你身上，尤其是在你没有查看供应商目录的情况下。如果您不确切地知道系统中有哪些代码，那么您就不知道自己是否在打包这样的东西。好了，现在我们来总结一下刚才用示例应用程序演示的供应链攻击。
首先，我通过标准的GitHub拉取请求向开源项目引入了一个新的依赖项。如果您是任何开源产品的维护者，那么您应该熟悉从第三方贡献者那里获得这些产品。hth华体会最新官方网站我添加的这个依赖项本身不包含恶意代码，但它声明了另一个包含恶意代码的依赖项，该依赖项反过来隐藏了恶意代码，它只出现在一次提交中。其他提交在此之后分层进行。所以即使你在找也很难找到。这是由于GitHub的pull request流和Go模块包管理系统所特有的几个原因。首先，当你使用Go模块包管理系统时，在GitHub拉取请求中进行代码审查，默认情况下只显示依赖元数据。代码不是供应商提供的，也不是签入存储库的。因此，在代码审查流程中没有内置的方法来查看您正在导入的所有供应商依赖关系，而不需要使用存储库，在本地发起pull请求并自己构建它。这很耗时。
我敢打赌，绝大多数开源维护者不会对每个拉取请求都这样做，他们会合并。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，斜杠组织名，斜杠存储库。所以这只是显示组织的顶层，一些进来的软件包看起来像是来自值得信赖的来源，比如微软。其他人呢?我不是想挑他们的毛病。
但我们不知道这些代码是从哪里来的。一般来说，当我们不一定信任这些代码的作者时，它并没有被逐行审查。即使对于声称来自微软的代码，我们也没有真正的方法来验证它没有在任何地方签名。我们无法确保微软发布了这个代码。它只是被放置在供应商目录的一个文件夹中，声称它来自微软，贡献者通过pull请求向Kubernetes发送代码可以修改它。所以我们有大量的攻击点和非常糟糕的工具来捕捉这类问题。我们真的需要新的工具、新的实践和新的系统来解决这个问题，帮助整个行业解决这个问题。好像2020年不会更糟似的。为什么现在会发生这种情况?开源一直存在。
包管理一直存在。为什么这突然成了一个问题?这是供应链攻击的一个小时间表，包括最近的一些。所以我们知道这种类型的攻击已经有几十年了。这首先发表在一篇名为“信任信任的反思”的论文中，该论文详细介绍了自举问题。你不仅要知道你所使用的所有代码的确切来源，你还必须知道用来构建和转换这些代码的所有二进制文件的确切来源。如果编译器被黑客攻击，那么编译器就会进入后门，之后的每个二进制代码都可以构建，您甚至可能不会在代码审查中看到它。这演示了一些新颖的攻击，其中代码隐藏在编译器内部，使其非常非常难以找到。很久以后，我们在2006年开始看到更多这样的攻击，Debian和Red Hat内部的一大堆操作系统级补丁管理库，Linux发行版中毒。这是一个凭证泄漏，因此人们能够将包直接插入到包管理器中。
2010年晚些时候是我之前谈到的Struts网络。他们使用USB闪存盘作为进入供应链的一种方式，那里有一个空气缺口，甚至没有被使用。后来在2011年，当前。org, Linux内核源代码被泄露。大规模审计显示，没有什么严重的事情发生。但是想象一下，如果Linux内核从2011年一直到今天都被入侵，会发生什么。这并不一定是2016年的袭击。左键问题，但这确实显示了与第三方包管理系统在编程社区(尤其是node)中的紧密联系。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.
那么，为什么现在为什么我们只看到这些袭击?这是多种因素共同作用的结果。每次入侵软件的成本越来越低。随着人们使用越来越多的开源软件，每天都有更多的目标被发布。这意味着这些是更好的目标，这将导致更多的攻击。开源再次崛起，使用开源越多，受到开源供应链攻击的风险就越大，最后提高通用安全性。黑客和攻击者想要采取最简单的方式。当我们最终获得工具来强化所有其他入口点并使其更难插入后门时。开源供应链攻击正变得越来越有吸引力，因为它们是迄今为止最简单的方法。这次演讲的可怕部分结束了，大家可以放松了。
如果您需要在这里暂停并查看您的供应商代码的每一行，请这样做，录音将等待您。现在我们跳到乐观，建设性，充满希望的部分。今天我们来谈谈如何保护自己。然后我们作为一个行业要做的是保护每个人。因此，让我们从一些简单的建议开始，告诉您如何保护自己的源代码和客户。首先，你需要锁定你的回购。Repos是软件开发中存储代码的地方，也是所有依赖项的真实来源。您希望尽可能地锁定它们，限制有权限将内容合并到您的存储库的贡献者和维护者的数量，并进行基本的其他保护，如启用和要求双因素身份验证。禁用强制使得人们很难重写历史记录，并要求进行代码审查，这样就没有人可以单方面地对存储库进行更改。接下来，保护自己免受攻击和第三方依赖的一个简单方法是减少第三方依赖的数量。 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 / slash change repository是一个很好的地方，如果你想帮助你进行可复制的构建和信任的构建过程。好了，谢谢大家听我的第一次虚拟演讲。 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.