With high-profile attacks becoming more frequent and more commonly attributed to software supply chain issues, the topic has moved to the front of a lot of developers’ minds. Defining a software supply chain and addressing its security concerns is a complex undertaking, and Intel software security experts are actively engaged in this critical conversation.
Marcela Melara, a research scientist in the Security and Privacy Research Group at Intel Labs, and Bruno Domingues, CTO, Worldwide Financial Services Industry at Intel and SLSA project contributor share their deep knowledge about software supply chain security.
Katherine Druckman:
When most people think of supply chains, they think of physical goods: boats, trucks, trains, food supply etc., especially since the pandemic. What is a software supply chain?
Marcela Melara:
Through the work that I've been doing both on the research side and on the open source side, it's actually a really hard question. In my experience, different people mean different things when they think about the software supply chain...
There are three aspects: There are the people who make software, there are the actual software components, and then there are the operational bits.
You have people writing code, organizations giving you services, and people who decide how your code is built...
The software component side includes anything from the software dependencies that you might pull into your applications, your libraries or packages (things like Docker* container images) and it's all that software stuff that goes into your product.
And the final aspect is the operational part, or the tools you use to build and to test code, but also what you do to get from source code to final product.
This is a long answer, but I hope it shows that it's a very complex thing.
Katherine Druckman
I think that's why this conversation can be overwhelming for people, especially when you're not familiar with it or immersed in it every day.
Bruno Domingues:
Most people when talking about supply chains think about goods and physical things. When you're talking about the market supply chain you’re used to talking about atoms and electrons. Atoms are physical things. You have a flow when you build something, for example. If you build a phone, you have glass, the CPU and everything to build the assembly. Of course, it's created in a very different way.
And software is not new, but it has become more and more critical. In the past, to create software the only thing you needed was a computer and a compiler...
But with more complex systems, there are a lot of parts that must fit together and you start reusing most of the parts. And why has it become more important? With cloud distributed systems you’re using APIs, with calls to different services.
To build a platform now or even a software system, there are hundreds or thousands of calls to different pieces of code from different services that run in different parts of the internet.
So how do you know that every piece you’re using is trusted? Because if you're making a call, for example an API and send some data, you’d like to make sure that the data you’re sending out to these services is trusted. So that's the reason that it’s become a lot more complex and a lot more important because an attack in the software supply chain has become a major vector. In the last few years, we’ve seen attacks in the supply chain growing in the double digits.
Katherine Druckman:
Now that we've defined what we're talking about, let's go a bit more in depth. How has the way software is made and its complexity evolved brought the conversation about supply chain security hurtling into the forefront as we're seeing right now?
Bruno Domingues:
First, there are several aspects that come together. One is the tech used to develop software currently. If you look at 20 years ago, most applications that were developed were compiled.
That means I have the dependency on my computer, I compile, and everything is under my control. Now, when you're talking about containers and runtime applications, for example, most of the applications running worldwide these days are runtime.
So if I have my code and some dependencies, it's going to download the dependencies most of the time in real time. Those are the kind of things that become a lot looser in that you can get productivity, but at the same time, there are a lot dependencies where you have no direct control.
For example, if I build my application and define all the dependencies that I have and I upload it to a cloud service provider (CSP), I'm assuming the CSP has the infrastructure to bring those dependencies from a trusted source. That’s not always true, and that has changed.
First, it's the tech used to write applications. The second is something that we’ve been struggling with in tech for many years. How can we effectively reuse code?
Because if I need, for example, a function in my application, I just can't consume through an API to someone who’s providing me with that capability.
If want my application to do facial recognition, I just call an API and but I must be sure the API is sending this data through a trusted party. That's also part of the software supply chain.
So, when we're talking about why it’s now a lot more critical, this is one aspect. The first is the tech and how we deploy the technology. When you're looking at a continuous integration and continuous delivery CI/CD pipeline, you’re already speeding up this process and sometimes security becomes an afterthought. The way that we speed up development, reuse code, abstracting, using more and more tech and of course using code that was developed by someone else, I need to make sure everything that I'm using comes from a trusted source as well...
We’d like to have security in this pipeline, but we also don't want to slow down the pipeline.
Marcela Melara:
The speed of development has really exacerbated some of these trust problems and these security problems. But it’s also so easy to access tools to build code as well as to distribute code.
Thinking about how I write code myself, I’ll often Google* and ask, ‘How do I do XYZ?’ And there's a lot of little code snippets on random forums, random blogs. It’s very easy to find other people's code and build it as part of your app. So, there's easy access to code though honestly it’s often pretty crappy – that’s made the problem worse because in some cases, you're prioritizing speed over security, you don't actually check who wrote it or if it's following security practices.
Another big change has just been the fact that we’re even talking about software supply chain security as a topic because a lot of these problems aren't new...
At the same time, because security hasn't been a priority, nobody was talking about it, even if there are people who've been working on it for years.
Katherine Druckman:
Modern software has a whole lot of open source code in it, and yet open source frequently gets singled out as a security risk. I keep seeing “the problem with open source” and heightened scrutiny. Why the distinction of open source as a unique source of vulnerability?
Bruno Domingues:
Both proprietary software and open source have vulnerabilities.
I think the point with open source and the reason many regulated industries still resist adopting open software is because they’d like to make sure there’s good governance behind the software. That’s a good practice. So, it's not uncommon, for example, in financial institutions to start looking first for the governance of what that they’d like to adopt before they really look into the software itself because security in those regulated industries comes first.
That's the reason that when you're talking about open source, usually there's an open development community as well so everybody can write a piece of code, submit it and then there are committers who review that code and accept it or not. Not all open source organizations have good governance. That's where they're looking at something as a good opportunity, it's not because it's open or not, it's the governance. How do you write the code and maintain the code and how you deal with a vulnerability that you have to fix quickly?
Of course, proprietary software also has that problem, but most of that code is behind a certain service-level agreement (SLA). If I buy software, there's an agreement that I can expect, for example, that if there’s a vulnerability, the company will notify me and provide the fix in X amount of time.
Katherine Druckman:
It's also useful to note that a maintainer can have a fix out the next day, but if you don't pick that fix up and make an update, it's not going to help you.
Marcela Melara:
It comes back to this easy access to putting your code out as open source where you can set up a free GitHub* account and just upload as many public repositories as you want and it's free, so it's very low cost to get your code out there and because so many people share code even outside GitHub, that's why it’s difficult to govern. And there's just so much of it. It's difficult to figure out who did what and even when you do have a better governed organization, if you have a bunch of random contributors, how do you make sure this code is being reviewed properly?
For more of this conversation and others, subscribe to the Open at Intel podcast:
- Openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Or your favorite podcast player (RSS).
About the Author
Katherine Druckman, an Intel Open Source Evangelist, is a host of podcasts Open at Intel, Reality 2.0 and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards.