Cloud Native Computing Foundation Cloud Native Security Day EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: Securing Open Source - David A. Wheeler, Director, Open Source Supply Chain Security

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Keynote: Securing Open Source - David A. Wheeler, Director, Open Source Supply Chain Security, The Linux Foundation

The subversion of SolarWinds’ Orion build system, dependency confusion attacks, and event-stream's subversion make it clear that attackers can successfully attack systems by attacking their supply chains, and attackers have not stopped attacking vulnerabilities in software developed & deployed. This talk will briefly discuss the software supply chain environment, some countermeasures, and some ongoing activities to reduce risks from software vulnerabilities and the software supply chain. The good news is that there are ways to counter such attacks, but they will require changes in how we do software development, selection, and deployment.

A

Hello, my name is david, a wheeler and I'm here to talk about securing open source.

A

I hope to convince you about four key points: attacks, weakness, hope, change, attacks, hope, weakness, hope change. What do I mean by that? Well, the first part part, I hope you already are convinced of attackers- are attacking systems they're attacking those systems via the vulnerabilities that they have when they are deployed and also through their supply chains weakness.

A

Sadly, those attackers are often succeeding, um and this is primarily because current development and supply chain processes really often don't adequately counter attacks and even when they're fixed, they often don't get deployed in a timely way. But I don't want you to leave without hope. There is hope there are counter measures to attacks and there's ongoing work to ease their deployment for change.

A

We need to change how we develop software, how we select it, how we deploy it, uh things like making sure that things are secure by default and we're going to need to continuously learn from adversaries and anticipate adversaries.

A

I think that first point about software's under attack is pretty obvious. um I mean these are just some logos and and some indications of examples of software under attack uh the top left symbol. There is heart bleed um but in fact, there's a whole bunch of different attacks and vulnerabilities, um but of course, repositories have been under attack. um The more recent solarwinds orion subversion was caused through a subverted, build environment. It didn't matter what the software developers wrote because the code they wrote wasn't what was going to be used for shipping.

A

um There's a an interesting paper called the backstabbers knife collection that reviewed over 174 supply chain attacks, found a dominance of type of squatting attacks, for example,.

A

A good part of this problem is that most projects and organizations simply cannot accurately summarize what software is within their system.

A

And some of you may say: oh hey, we use cloud, therefore, somehow we're immune to all this. So of course that's ridiculous. um Dan lawrence has this interesting um article, where uh he notes that today's cloud infrastructure is still being built out of duct tape and kite strings, um so he played around with um uh helm3. He looked at a particular helm chart and tried to answer what you would think would be simple questions. You know exactly what software was installed. Where did it come from?

A

How was it built and he could not answer those questions and, as a result, you know he he made some interesting observations. One, of course, is if you think your container scanning setup is catching everything think again, he found 25 vulnerabilities in just that one package um and he noted that hey package managers add convenience, but every layer adds trust and I would also add adds time it can take a long time for a vulnerability. That's been fixed to get through all those layers.

A

So it's I think it's helpful to think about how is software developed um you know, and so this is a simple model of the software supply chain, called a supply chain integrity map. As you can see, you know it's a simple map: what's what goes on developers? Work within their local environments then send their changes and so on off to source and data repositories.

A

Then they that software gets built and verified. Eventually, it's approved for release to be sent out to various package repositories and distribution platforms. uh Hopefully they're that's assessed in various ways, both the builds and the eventual packages.

A

Finally, people select and acquire them and then bring them into their environments to be uh to go through the cycle all again and eventually things get deployed out to operations and of course, there are cycles here, because smaller components get brought into larger components which get into larger components.

A

But of course, if you look at this from the point of view of an attacker, that's a system and systems can be attacked and a great way to learn how to attack them is to look at those parts and see how those various parts of the system can be attacked and those these red squares are just sample kinds of attacks and there's a lot of them.

A

uh Typo squatting, which is basically confusing uh acquirers and developers uh into thinking they're, installing one package when they're installing another dependency confusion where they think it's the software's coming from one repository, but it's actually coming from another there's malicious software, um there's all sorts of vulnerabilities that go in as part of developments and just there's a whole host of problems, but I don't want you to leave with oh my gosh. There are so many problems because in fact there are counter measures, and these are again just a sample of counter measures.

A

Various approaches where you can do various things to counter some of those attacks. I certainly can't talk about all of them, but a trivial one. I'll note, for example, is you know one of the big problems right now is developers often don't understand a lot of things? Nobody teaches them in classes, and so a little education and training can go a long way and of course that's not enough. There's various tools, you can add to say the build verification processes and so on to really help.

A

There's no silver bullet. There is no one thing: if you do the one thing: congratulations, you have solved all problems, that's not how it works. Instead, you need to bring a variety of approaches to bear to counter the different kinds of attacks that attackers can do.

A

So. What can open source software developers and users do well if you're not already doing these already here's some first starting steps, you'll learn how to develop and acquire secure software. uh If you don't have, if you, if nothing else, take a look at the secure software development fundamentals. Course it's free, it's on edx, go take it there's others take those but learn how to do this stuff.

A

Make the software secure by default, make it easy to use securely harden it up against attacks if you're doing open source software development work to earn an open source, I'm sorry cii best practices, badge. There's the url use many tools to find vulnerabilities in your build and verification environment. No tools will not find everything but they're helpful as part of a solution, of course monitor for known vulnerabilities in the in whatever you depend on, so that you can immediately respond and immediately update.

A

Of course, in order to do that, rapid update, you need to use package managers and automated tools, so you can rapidly respond when a vulnerability is found- and I mentioned these tests- those need to include negative tests. In other words, there are some things that should not be allowed test for that make sure they stay not allowed. This is something that people often forget, particularly if they're using tdd finally evaluate software before you select it, you know, look for typo squatting. Is that really the right name? Is that software malicious?

A

Do you have reason to believe it secure and when you're evaluating here's some sample things to consider? Is it easy to use securely? Is there evidence that developers work to make it secure is it maintained? Has significant use what's the license um if it has a not an open source license? Shockingly, it's not going to be collaboratively developed like an open source project.

A

If it's important, what is your own evaluation of it?

A

The good news is lots of folks are working to make things better. The open ssf, for example, open source security foundation, uh is working on this there's a number of other projects here. In fact, this is a short list. There's many more uh uh projects and foundations and organizations working to make things better.

A

So if you are an open source software developer user, you need to do all those things I mentioned earlier, but you also need to prep for the future. Here's some things that I see coming down the pike um you need to start being prepared to generate and request software build materials, uh there's a lot of pressure in even high levels of government and so on. To start saying, we need to know what's in our software and we need to be prepared to answer that question. It's a reasonable question.

A

Look for more information about the software before you select it. There's organizations like those within the open ssf that are working to improve information about the software uh that you're to improve information about the software. So you can have better information when you select it, I think verified reproducible builds are important. That's particularly useful for countering uh subverted, builds, um improved cryptographic, signature verification.

A

um You know, we've had this for a long time, but it's challenging to do verification.

A

I think sigstor has a lot of promise, um but you know we'll see, but no matter what I think this is something we need to see more of more generally integrity, attestation, approaches like in toto and increasing use of memory, safe and more generally safe languages and, more broadly working with others to help things to help make things better.

A

There's a lot of opportunity, and frankly there are folks who could really use your help to speed these up.

A

So let me do a quick recap. I came and said there are four key points I wanted to talk about, attacks, weakness, hope change and I hope that you'll see that it's yes, they're attacks and yes, there's weakness, but there is hope and but will need to change, to take advantage of that hope.

A

A quick parting thought developing and deploying secure software is a journey of learning and improving. It's not a single event, but that's okay. We just need to get started. Thank you very much for your time.