开源软件的安全性风险_认真对待开源安全性

开源软件的安全性风险

曾叱咤风云的 (A Blast From the Past)

2019 was a crazy time to be writing software. It's hard to believe how careless we were as an industry. Everyone was just having fun slinging code. Companies were using whatever code they found laying around on NPM, Pip, or Maven Central. No one even looked at the code these package managers were downloading for them. We had no idea where these binaries came from or even who wrote most of this stuff.

2019年是编写软件的疯狂时期。 很难相信我们作为一个行业多么粗心。 每个人都在享受吊索的乐趣。 公司正在使用发现在NPM，Pip或Maven Central上的任何代码。 甚至没有人看过这些软件包管理器正在为其下载的代码。 我们不知道这些二进制文件是从哪里来的，甚至不知道是谁写的。

And don't even get me started on containers! There was no way to know what was inside most of them or what they did. Yet there we were, pulling them from Dockerhub, slapping some YAML on them, and running them as root in our Kubernetes clusters. Whoops, I just dated myself. Kubernetes was a primitive system written mostly in YAML and Bash that people used to interact with before Serverless came and saved us all.

而且甚至不要让我开始使用容器！ 无法知道大多数人的内心或他们的所作所为。 但是我们在那里，将它们从Dockerhub中拉出，在它们上拍了些YAML，然后以root身份在我们的Kubernetes集群中运行它们。 哎呀，我刚刚和自己约会。 Kubernetes是一个主要由YAML和Bash编写的原始系统，在Serverless出现并拯救我们所有人之前，人们经常与之进行交互。

Looking back, it's shocking that the industry is still around! How we didn't have to cough up every Bitcoin in the world to stop our databases from getting leaked or our servers from being blown up is beyond me. Thankfully, we realized how silly this all was, and we stopped using whatever code had the most Github stars and started using protection.

回顾过去，整个行业仍然令人震惊！ 我们不必为世界上所有的比特币付出任何努力来阻止数据库泄漏或服务器被炸毁，这超出了我的范围。 值得庆幸的是，我们意识到这一切都是多么愚蠢，我们停止使用拥有Github最多星标的任何代码，并开始使用保护功能。

我们受到攻击 (We’re Under Attack)

No, really. Every time you pip install, go get, or mvn fetch something, you’re doing the equivalent of plugging a thumb drive you found on the sidewalk into your production server.

不完全是。 每次pip install ， go get或mvn fetch某样东西时，都相当于在人行道上找到一个拇指驱动器插入生产服务器。

You’re taking code from someone you’ve never met and then running it with access to your most sensitive data. Hopefully, you at least know their email address or Github account from the commit, but there’s no way to know if this is accurate unless you’re checking PGP signatures. And let’s be honest, you’re probably not doing that.

您正在从从未遇见的人那里获取代码，然后通过访问您最敏感的数据来运行它。 希望您至少从提交中知道他们的电子邮件地址或Github帐户，但是除非您正在检查PGP签名，否则无法知道这是否正确。 老实说，您可能没有这样做。

This might sound like I’m just fear-mongering, but I promise I’m not. This is a real problem that everyone needs to be aware of. Attacks like this are called supply-chain attacks, and they are nothing new. Just last month, an active RCE vulnerability was found in an open source package on PyPi that was being used to steal SSH and GPG credentials.

这听起来好像我只是在散布恐惧，但我保证不会。 这是每个人都必须意识到的一个实际问题。 这样的攻击称为供应链攻击，它们并不新鲜。 就在上个月 ，在PyPi的一个开源软件包中发现了一个活动的RCE​​漏洞，该漏洞被用于窃取SSH和GPG凭据。

There are lots of variations on this same play that make use of different social-engineering techniques in interesting ways. One attacker used a targeted version of this to steal cryptocurrency from a few specific websites. Another group performed a “long-con” where they actually produced and maintained a whole set of useful open source images on Dockerhub for years before slowly adding, you guessed it, crypto-mining.

同一戏剧有很多变化形式，以有趣的方式利用了不同的社会工程技术。 一名攻击者使用了有针对性的版本从一些特定的网站窃取加密货币。 另一个小组进行了一次“长期骗局”，他们实际上在Dockerhub上生产并维护了一整套有用的开源映像，并持续了很多年，然后才慢慢添加加密挖矿。

The possibilities are endless, terrifying, and morbidly fascinating. And they're happening more and more often. If reading about attacks like these is your kind of thing, the CNCF has started cataloging known instances of them. Snyk also just published a post detailing how easy it is to inject code like this in most major languages — Github even hides these diffs in code review by default! Russ Cox has also been writing about this problem for a while.

可能性是无尽的，恐怖的和病态的。 而且它们越来越频繁地发生。 如果读到这样的攻击是你的事情，在CNCF已开始编目已知情况他们 。 Snyk也刚刚发表了一篇文章，详细介绍了在大多数主要语言中注入这样的代码有多么容易-Github甚至默认情况下在代码审查中隐藏了这些差异！ 拉斯·考克斯(Russ Cox)也一直在撰写有关此问题的文章。

视力 (Vision)

OK, there's a bit of hyperbole up there (Kubernetes doesn't have that much bash in it), but open source is under attack, and it's not OK. Some progress is being made in this area — GitHub and others are scanning repositories, binaries, and containers, but these tools all only work on known vulnerabilities. They have no mechanism to handle intentional, malicious ones before they are discovered, which are at least as dangerous.

OK，有一个有点夸张的那里(Kubernetes没有在那么远的bash)，但开源受到攻击，而且它也不行。 该领域正在取得一些进展-GitHub和其他组织正在扫描存储库，二进制文件和容器，但是这些工具都只能在已知漏洞上起作用。 他们没有机制来处理故意的恶意恶意软件，而这些恶意软件至少是同样危险的。

The brutal fact is that there is no way to be confident about the code you find on most artifact repositories today. The service might be compromised and serve you a different package from the one the author uploaded. The maintainer's credentials might have been compromised, allowing an attacker to upload something malicious. The compiler itself might have been hacked, or even the compiler that compiler used (PDF warning)! Or, the maintainer could have just snuck something in on purpose.

残酷的事实是，对于现在在大多数工件存储库中找到的代码，没有办法充满信心。 该服务可能已被盗用，并为您提供了与作者上传的软件包不同的软件包。 维护者的凭据可能已被破坏，从而使攻击者可以上传恶意软件。 编译器本身可能已被黑客入侵，甚至可能被编译器使用 (PDF警告)！ 或者，维护者可能只是故意偷东西。

For any given open source package, we need to be able to confidently assert what code it’s comprised of, what toolchains and steps were used to produce the package, and who was responsible for each piece. This information needs to be made available publicly. A reliable, secure view of the supply-chain of every open source package will help make these attacks easier to prevent and easier to detect when they do happen. And the ability to tie each line of code and action back to a real individual will allow us to hold attackers accountable.

对于任何给定的开源程序包，我们都必须能够自信地断言其组成的代码，用于生成程序包的工具链和步骤以及负责每个程序的人。 此信息需要公开提供。 可靠，安全地查看每个开源软件包的供应链，将有助于使这些攻击更容易预防，并且更容易在发生时进行检测。 将每行代码和行动与实际人员联系起来的能力将使我们追究攻击者的责任。

我们怎么去那里？ (How Do We Get There?)

We need to work as an industry to start securing open source software, piece by piece.

我们需要作为一个行业来逐步保护开源软件。

Artifact repositories need to support basic authentication best practices like 2FA, artifact signing, and strong password requirements. DockerHub, PyPi, and NPM support 2FA, but there’s no way to see if a maintainer of a package is using it. Most container registries don't support signatures yet, though work is ongoing.

工件存储库需要支持2FA，工件签名和严格的密码要求等基本身份验证最佳实践。 DockerHub，PyPi和NPM支持2FA，但是无法查看软件包的维护者是否正在使用它。 尽管工作仍在进行中 ，但大多数容器注册表仍不支持签名。

Software build systems need to make reproducible, hermetic builds possible and easy. Debian has started doing some great work here, but they're basically alone. Every docker build gives you a new container digest. Tar and gzip throw timestamps everywhere. It's possible to get reproducible builds in Go, Java, and most other major languages, but it’s not necessarily easy. See the recently published whitepaper on how Google handles much of this internally for more information.

软件构建系统需要使可重复生成的密封构建变得容易且容易。 Debian已经开始在这里做一些很棒的工作，但是他们基本上是一个人。 每个docker构建都会为您提供一个新的容器摘要。 tar和gzip随处都带有时间戳。 可以使用Go ， Java和大多数其他主要语言获得可复制的内部版本，但这并不容易。 有关更多信息，请参阅最近发布的白皮书 ，其中介绍了Google如何在内部处理其中的大部分内容。

SCM providers need strong identity mechanisms so we can associate code back to authors confidently. Git commit logs can be easily forged, and signed commits are not in common use. Even with them, you still have no idea who is on the other end of a PR, only that the signature matches. This isn't just an issue for security. It can also be a licensing nightmare if you don't know the real author or license of code you're accepting.

SCM提供者需要强大的标识机制，因此我们可以放心地将代码关联回作者。 Git提交日志很容易伪造，签名的提交也不常用。 即使有了他们，您仍然不知道谁在PR的另一端，只是签名是匹配的。 这不仅是安全问题。 如果您不知道所接受的代码的真实作者或许可证 ，这也可能是许可证的噩梦 。

There is value in allowing developers to work anonymously, but there is also a cost. We need to balance this with systems that apply a higher level of scrutiny to anonymous code. We also need to allow other individuals to "vouch for" patches that they’ve examined, maybe similar to how Wikipedia handles anonymous edits.

允许开发人员匿名进行工作具有价值，但也有代价。 我们需要在对匿名代码进行更严格审查的系统之间取得平衡。 我们还需要允许其他人“担保”他们检查过的补丁，也许类似于Wikipedia 处理匿名编辑的方式。

And finally, all of this needs to be tied together in secure CI/CD systems and platforms that implement binary transparency for public packages. Putting the packaging steps in the hands and laptops of developers leaves way too large an attack surface. The ability to push a package that will run in prod is the same as having root in prod. By moving the build and upload steps into secure CI/CD systems, we can reduce the need to trust individuals.

最后，所有这些都需要在实现公共软件包二进制透明性的安全CI / CD系统和平台中捆绑在一起。 将包装步骤放到开发人员的手中和笔记本电脑上，会使攻击面太大。 推送将在prod中运行的程序包的能力与在prod中具有root相同。 通过将构建和上载步骤移至安全的CI / CD系统中，我们可以减少信任个人的需求。

好的，但是我现在该怎么办？ (OK, but What Can I Do Now?)

First, start by securing your code as much as possible. Make sure you have copies of every dependency you're using stored somewhere. Make sure you review all code you're using, including OSS. Set up and mandate the use of 2FA across your organization. Publish, and actually check the signatures and digests of the software you're using.

首先，首先要确保代码的安全。 确保将您正在使用的每个依赖项的副本存储在某个地方。 确保查看所有正在使用的代码，包括OSS。 在整个组织中设置并强制使用2FA。 发布并检查您正在使用的软件的签名和摘要。

Log enough information in your build system so you can trace back every artifact to the sources. And every deployment to the artifacts. Once you've done all of this, you'll be pretty far ahead of everyone else. You're not completely safe, though.

在构建系统中记录足够的信息，以便您可以将每个工件追溯到源。 以及每次部署到工件。 完成所有这些操作后，您将遥遥领先于其他所有人。 但是，您并不完全安全。

That's where we need to work together. If you're interested in helping out, there are many ways to get involved, and I'm sure there are a lot of efforts going on. We're just getting started on several initiatives inside the Continuous Delivery Foundation, like our new Security SIG. We're also hoping to make it easier to build and use secure delivery pipelines inside the TektonCD open source project.

那是我们需要共同努力的地方。 如果您有帮助的兴趣，可以有很多参与的方法，而且我敢肯定，我们会付出很多努力。 我们刚刚开始在Continuous Delivery Foundation内部开展多项举措，例如新的Security SIG 。 我们还希望简化在TektonCD开源项目中构建和使用安全交付管道的过程 。

We would love your help, no matter your expertise! For example, I'm far from a security expert, but I've spent a lot of time working on developer tools and CI/CD systems. Feel free to reach out to me directly if you have any questions or want to get involved. I'm on Twitter and Github.

无论您有什么专业知识，我们都将竭诚为您服务！ 例如，我离安全专家还很远，但是我花了很多时间在开发人员工具和CI / CD系统上。 如果您有任何疑问或想参与其中，请随时直接与我联系。 我在Twitter和Github上 。

翻译自: https://medium.com/better-programming/getting-serious-about-open-source-security-1d15609478fa

开源软件的安全性风险