In this episode, Neil Levine of Anchore joins Kim Weins and Josh Bressers to discuss the power of SBOMs. They explore practical first steps for using SBOMs and how they can improve software supply chain security starting today.
In this episode, Neil Levine of Anchore joins Kim Weins and Josh Bressers to discuss the power of SBOMs. They explore practical first steps for using SBOMs and how they can improve software supply chain security starting today.
Announcer:
You're listening to Upstream, the software supply chain security podcast brought to you by Anchore.
Kim Weins:
Hi there and welcome. I'm Kim Weins, host of Upstream, a podcast for those curious about the security of the software supply chain. In each episode we talk with experts, practitioners and thought leaders about concrete ideas and approaches to improve software supply chain security. This podcast is for everyone, both inside and outside the world of security. On this show, we highlight ways we can work together to protect the software that we all depend on.
Kim Weins:
It's March 2022 and, boy, did this one come in like a lion, Josh Bressers.
Josh Bressers:
Indeed.
Kim Weins:
The Russian invasion of Ukraine is dominating headlines around the globe and back here in the United States, CISA, the Cyber Security and Infrastructure Security Agency issued a shields up alert warning IT departments everywhere to monitor for suspicious activity that could disrupt their business or government operations.
Josh Bressers:
Yeah, absolutely. This one I find intriguing because if you look at all of the advice that CISA is handing out, nothing is earth-shattering by any means. This is, basically, things that almost every organization should be doing or wants to be doing at some point. And so I think the importance of this is less about the actual advice and more about this is an opportunity for visibility to be raised. Everyone is hyper-aware of their cybersecurity now.
Josh Bressers:
And so this is a marvelous opportunity for everyone to obviously raise their awareness inside their organization, raise their own awareness and then also to start doing something about it. There's so many projects we all have on the back burner that it's time to pull them to the front.
Kim Weins:
Yeah. It's like somebody's screaming, "Pay attention now." So right now-
Josh Bressers:
We've been screaming that of decades.
Kim Weins:
... the question ... Just you, Josh. Just you,-
Josh Bressers:
That's fair. That's fair.
Kim Weins:
... screaming into the wind.
Josh Bressers:
Exactly.
Kim Weins:
Well threats don't wait while you consider getting your software supply chain security up to speed, and all of this highlights the need for software vendors to disclose a software bill of materials of their products.
Kim Weins:
Our guest on the show today is someone who knows a great deal about just that, Neil Levine, the VP of Products at Anchore spends a lot of time talking to organizations about how they can improve their software supply chain security.
Kim Weins:
Welcome to Upstream, Neil.
Neil Levine:
Thank you, Kim. Great to be here with you and Josh.
Kim Weins:
Well, Neil, we know that securing the software supply chain is becoming top of mind for organizations across all industries. Our recent 2022 software supply chain security survey done by Ancore says that 76% of respondents plan to increase their use of SBOMs in 2022. And Anchore recently announced a major release of an SBOM powered software supply chain management solution. What does SBOM powered mean and why is that important?
Neil Levine:
So I think, as you've covered in previous podcasts, SBOMs have really come to the fore, certainly from the executive order, which came out by the Biden administration last summer, and people are trying to understand, "Why do I need them and what do I do with them?"
Neil Levine:
Anchore have been using them for a long time. We've been using SBOMs to power our product ever since the beginning, and they've now changed from being an implementation detail to really being something that's a first class citizen in terms of what security professionals need to interact with.
Neil Levine:
So, for us, SBOM powered means you get the total transparency and visibility around all the content in your software factory, everything that's going through the source code, through the build, out to deployment. So you can monitor it, see what's there, respond to it, find out what entered the pipeline, who introduced it, when did they introduce it? So it's just giving you situational awareness. That's the first layer, just get that situational awareness and then you can take responses and actions as a follow up.
Kim Weins:
So it's not really just a once and done thing?
Neil Levine:
Yeah, exactly. I think SBOMS in the previous generation, maybe their first generation of use, were absolutely that. It was, "Let's do it once, get the information, check the box. We did it so if someone audits or asks, we can show that we did it." And then now it's a foundation for doing a cybersecurity in your organization. I think it's a real change in terms of people appreciating the power of what they can do and the executive order really opened that up for most organizations and have allowed them to really investigate this with a bit more seriousness than they have in the past.
Josh Bressers:
So can we start with the what you can do at this part, Neil? I feel like everyone's talking about SBOMs all the time now, but then often I'll hear, "Well, what do I actually do with these things?" And this is where I think some of the answers for many people start to fall apart, but I have a suspicion, you have a phenomenal answer for us.
Neil Levine:
Your confidence is not misplaced, Josh. Yeah. So the first thing that you need to do is generate the SBOMS from, again, as many stages as possible. As we just said, it's not a one shot thing. Get it from every place. Essentially, you're persisting that data and we call it SBOM management. Just get it into one place. And then, at its broadest, so its most general, you're doing data mining. You're asking questions of the data, "Am I running this? When did I add this? Who added this? Do I need this?" These are simple questions you can ask about all the contents of the software in your organization.
Neil Levine:
And the Log4j incident back in December gave people the most practical experience of trying to answer those questions and without SBOMs, it was really, really difficult. Who has brought this in? Who do I need to talk to get it out? That could be a software vendor or an internal application developer. So that's the most obvious thing.
Neil Levine:
I think if you look at things like SolarWinds which, I mean, now seems old, it was a year over a year ago, but that was a great question of when did this come in? When did a piece of software arrive down to the time and the date of when did this piece arrive and how did it get in there? Again, SBOMs can start to answer questions like that. And in our new product we refer to that as SBOM drift. How did these things change over time and place? And just seeing that can give you a lot of insight into suspicious activity.
Neil Levine:
More practically, even if you're not thinking of this from a security perspective, just getting better at doing Cloud native, you can actually spot, "Are my containers immutable?" That's often the very first thing that teams are trying to sort out right now is these containers should not change, but they do. And we go back and work with the developers to find out why they are not adhering to Cloud native best practices.
Kim Weins:
So you mentioned the example of SolarWinds. So as I understand it, what happened there is somebody got in somewhere to the development process. I don't know if it was the build system or exactly, but somewhere in the development process and tool chain, and they inserted a file that had a reasonable sounding name, but wasn't supposed to be there. And then that showed up in a build that obviously got shipped out to customers.
Kim Weins:
So I think what you're saying is with SBOM drift, you would identify that rogue file, let's say, and that could then alert somebody to, "Hey, pay attention to this. This is new. Is this what you expected? Or is this something unexpected?"
Neil Levine:
Yeah, that's exactly right. I think there's a concept of what your intention is as you're creating your application, what the intention should be of what's going to end up in this application and what the actual facts on the ground are when the thing gets deployed?
Neil Levine:
Now, a determined state actor is always going to be finding ways to get under the radar as best you can. So we said you've got to be careful about not saying generate an SBOM and you can capture everything. It's an arms race. It's a game of cat and mouse with particularly determined actors, but there's a large class of malicious activity. And, if we're frank, just incompetence around things that are being badly set up where things are getting brought in that they shouldn't do, whether it's test and development files or debug packages or just the general states that comes out of an application, shouldn't appear on a container. You should get it out.
Neil Levine:
So both the suspicious stuff and the more questionable practices can be ... You can find those when you're checking these SBOMs diligently.
Neil Levine:
Now, again, we're at the beginning of this journey. We have to be very careful not to oversell this, but the first step is to get the SBOMs and capture them. We can't start to do this more sophisticated analysis unless you're generating the data in the first place.
Josh Bressers:
Well, and I think there is another important aspect of this we haven't really even ever talked about in this space, is if we take a page from the playbook of incidents, response and security, this data gives us value in real time of what's happening right now, but there's also the forensic aspect where if something does happen, you can say, "Okay. I need to look back in time and I need to understand what just happened."
Josh Bressers:
And this is, I think, another piece of SBOM management that hasn't really been talked about but is going to be incredibly powerful.
Neil Levine:
Yeah, that's right. So we internally talk about SBOMs over time and place. That is, do they change over the place in the SDLC, which is the source code, and then there's your build where you're staging it in a registry, then you're deploying it and then the run time? So these are different times. You want to take a snapshot at every single time so you can look for drift over the course of the evolution of an application. Exactly that. So when you're doing forensics you can say, "When did this thing appear? When did this piece of content enter the system?"
Neil Levine:
And then we talk about it in time. Even if you're just looking within builds, and this was specifically the SolarWinds issue, it was just, I think, you're doing builds over and over again. They should change a little bit over time. That's natural. That's why you're getting new builds, maybe new versions or just variation of code. But maybe there shouldn't be substantive changes applied to an application, shouldn't suddenly have Java applications or a Java application shouldn't suddenly have Node applications.
Neil Levine:
So, again, checking for this variation over time and places, again, gives you huge forensic insight.
Kim Weins:
Looking for the anomalies, I would say.
Kim Weins:
You're listening to Upstream, the software supply chain security podcast. We're speaking with Neil Levine, VP of Products at Anchore.
Kim Weins:
There's a lot of talk about topics like signing and attestation to verify secure software components. What's your viewpoint on this? Is this something people are doing today or is it something they should be doing?
Neil Levine:
There's no doubt that signing is a really critical part of the supply chain security movement, if we can call it that. And I think it was even on your previous podcast you spoke to people at Microsoft who are really invested in this, and we see the Sigstore project, which we're involved in too. But we're at the very beginning of this journey right now. But I think so signing is a tough problem, like anything to do with public key cryptography and PKI, in general, it's a tough nut to crack.
Neil Levine:
Sigstore really focused heavily on the ease of use to get developers to start generating the content, but the reality is the content's not there yet. So as an enterprise organization, there's not a huge amount of checking you can do. So if you are being tasked by your board or your CSO to go and implement this stuff, you're not going to get a huge amount of bang for your buck right now, I think. It's up for the software ecosystem and the vendors to produce a lot of this content before enterprises can start acting on it.
Neil Levine:
So really useful, but we're at the very beginning of a long journey around trying to make this content very prevalent and actionable.
Kim Weins:
It seems like something the cool kids are doing right now, right? The open source community and ecosystem that are really pushing the leading edge. Josh is laughing because I'm calling-
Josh Bressers:
I am.
Kim Weins:
... open source developers cool kids.
Josh Bressers:
We are the cool kids. We've always been cool. No, I'm chuckling-
Kim Weins:
I thought so.
Josh Bressers:
... because attestation has been a topic for decades at this point, and it's really hard to do. And now there's instances where it works. When you use your web browser you have a certificate and Let's Encrypt has made that accessible to the world. I am extremely optimistic that Sigstore can do this, but they are standing in front of a 200 foot wall and they have to climb it and the wall is slippery.
Josh Bressers:
And so there is an enormous amount of work to do, but I secretly pray it works because we desperately need it.
Kim Weins:
Yeah. And, I mean, I guess this whole concept ... Let's maybe just explain what this is. What does it mean to do signing an attestation on, say, an SBOM?
Josh Bressers:
So I think sometimes attestation is confused with trust in the wrong way. What happens is, let's say I generate an SBOM and I sign it with ... There's a tooling Sigstore store called Cosign. And, in fact, you can do this today with a tool Anchore has called Syft where I can generate an SBOM, I can sign the SBOM, and now what that signature says is it doesn't say that the software is trusted. It doesn't say the container is trusted. All that does is it says, "Josh is the person who generated this SBOM." That is, literally, all it means.
Josh Bressers:
There's no other aspect of trust in the content outside of the fact that you know it came from me. I could build a container filled with viruses and then I could generate an SBOM and sign it, and that's just fine. All it proves is I did it.
Kim Weins:
Well, does that mean you become the throat to choke if something goes wrong?
Josh Bressers:
Isn't that already my job? I mean, so that's part of it, right? Is, you want to sign things. For example, when you're an organization. This happens with software updates coming from, let's pick on Microsoft. So we just talk to them. Microsoft create software updates, they distribute the software updates to their customers and then the signature is used to verify that these updates did come from Microsoft, right?
Kim Weins:
Right, which is good.
Josh Bressers:
Yeah, exactly. And that's what you want to do. It doesn't mean that the update is bug free, it doesn't mean the update doesn't have security issues. It just means Microsoft is where this came from. And in the context of SBOMs, this means if I generate an SBOM and I give it to Neil, and then, let's say, Neil changes it and he gives it to someone else, someone else can say, "Wait a minute. This doesn't check out. This is not what Josh signed." And then they ... Maybe it was a mistake. Maybe Neil's up to shenanigans. It's hard to say.
Kim Weins:
It's like the FDA ingredients label that's been signed off on. So you can maybe believe ... Well, I guess it's a little bit different because it's not. All it says is the ingredients label came from a particular person,-
Josh Bressers:
That's right.
Kim Weins:
... but there's nobody signing off that it's actually correct.
Josh Bressers:
That's right.
Neil Levine:
Yeah. And part of the other problem is when you look at the complexity of these software stacks right now, you're going to get just half or maybe a third of an ingredient label because most modern software stacks consist of, as we know, lots of dependencies and things coming in from multiple vendors. And this comes back to the ecosystem issue, which is the system really only works when perhaps you've got all the content signed, all the attestations there through the whole chain.
Neil Levine:
If you're missing a large chunk of it, which you are right now, yes, there are some big vendors like Microsoft and people who are early participants in Sigstore, but most of the content won't have attestations, they won't have signatures. And so you're only getting a very, very thin sliver of additional information. And so we're back to alert, fatigue issue, "Great. If I analyze this application, I'm going to get a whole bunch of warnings, because there's not signatures on half the dependencies." That's no good to anybody at that point.
Josh Bressers:
That's right. And I also want to stress the point that an SBOM without a signature doesn't mean that's a worthless SBOM. I think sometimes in security we end up in this space of, if you're not doing it all perfect it's not worth doing it at all, and that's completely untrue.
Josh Bressers:
I think distributing unsigned SBOMs is step one. If we don't do that step, we don't get to go to the step where we sign them. And so it's hugely important we don't obsess over attestation and ignore everything else.
Kim Weins:
Well, and if you think about open source, so we're starting to see some open source projects try to build SBOMS as part of their process, whether signed or not. But if it's an open source project, you could also take that open source and you could generate your own SBOM and then you could compare it to the one that the project gave you. Is that true?
Neil Levine:
Yeah. I mean, you can certainly check whether there's been a tampering with the content that was available in the public repository and, ultimately, what you build. And this comes back to that drift concept as exactly where you can start to see this evolution over time. But I think even from the contents is definitely the most practical place to start and that's why we are focused on SBOMs.
Neil Levine:
But a lot of these open source projects, they're not going to be doing signing an attestation any time soon because there's so many of them. Some of the bigger projects certainly will: The Kubernetes and the Linuxes of the world, maybe, but there are so many other basic security fundamentals that these open source projects are not even following. And the open SSF is, particularly, attuned to this with the, I think it's the Alpha-Omega project, trying to see, "Look, what's just general easy security these projects should be following?"
Neil Levine:
I think the signing out attestation is going to be probably down the bottom of the list compared to just some basic repository health and are they using multifactor authentication? And these basic hygiene things are some big hoops that open source community's got to get through first.
Kim Weins:
So you're talking about where to start and don't start at the most advanced step to begin with. So if you're a CSO and you're at a large enterprise and you're trying to better secure your software supply chain, and there's all these new technologies, there's emerging compliance requirements and there's evolving best practices. So that could seem a little bit daunting. What are a few practical ways that people could get started? What are the first few steps they should take?
Neil Levine:
Yeah. So this really gets to the heart of what we see of our customers, which is they know they've got to get better at supply chain security, but how do they do that in ways which are practical and don't require massive changes of systems and processes, which in most organizations are very, very hard?
Neil Levine:
So, again, this comes back to why we say SBOMs are the easiest way to start. All your existing systems can be very easily instrumented to generate the SBOM, that allows us as a vendor to go install that and start giving you insight into that. So you can keep your Jenkins Environment, keep Hub Environment or ... Doesn't need to change. We plug into that. So, absolutely, SBOMs is the first step.
Neil Levine:
If you've got a clean Green Room or it's a completely new project, yes, there are some sophisticated new build systems, which also do all sorts of additional things, as we said around signing attestation, but they're just not practical for most organizations to put in place. So generating SBOMs is the first one.
Neil Levine:
The second one, which are already ... What we'll be doing in some way is capture all those vulnerability reports. They're still the most important thing, right? CVs are still, unfortunately, despite all the problems we have with them, it's still the first step of good quality cyber hygiene. So managing those, getting them centralized, getting a good application level view is also really important for an organization.
Neil Levine:
I think what we're starting to see now is perhaps the next step around that is open source insights is really starting to come into this. Just coming back to this what's the basic health or nutrition maybe of an open source project? Should you be using it? Trying to give that insight back to the application developers who are selecting the open source is probably the most easy thing. Again, no change to process or systems, just additional context and information. And I think that's the key point. Just giving additional informational context to existing environments is the best place for an enterprise to start.
Josh Bressers:
I agree. And you touched on this a little bit at the beginning of your explanation, Neil, but I want to focus in on it. By making SBOM the foundation of a lot of this effort, SBOMs are a non-disruptive step when you first start doing them. And I think that's so vitally important. In the world of security, we are notorious for showing up and telling people to do it our way or else, and then they don't, there's nowhere else, and they're, "Well, that was a lot easier than listening to them." And I feel this is an opportunity to get it right.
Neil Levine:
Yeah, exactly. I think it's a tough time to be a buyer in their enterprise market if you're looking at all of the new vendors and the existing vendors, just the total set of technology that's available is really, really daunting. And a lot of it can be very disruptive. And I think that's the most important thing you want. No disruption and simple experience. It's got to be about ease of use for the developer who's interacting with the data. Those are the two most fundamental things. Whatever technology you are being sold, doesn't address those things, the cost may outweigh the gains.
Kim Weins:
So start with the baby steps, generate an SBOM, save your SBOM, use it to identify vulnerabilities, start to look at open source health and then everything can grow from there. But those are the first steps we're going to focus on.
Neil Levine:
That's right. And once you've got that, then you've got the foundation to then bring in all this signing and attestation information once it's available, once it's sufficient to actually go and start to act on it. So, again, this is all about a foundation for this multiyear journey we're going to go on now.
Kim Weins:
Neil Levine, thank you for joining us on Upstream. It's great to be here with you and Josh.
Kim Weins:
And thanks to everyone listening. You've come to the right place for great discussions of the big issues impacting the security of the software supply chain. Subscribe and never miss an episode. Upstream is available everywhere you get your podcast. If you learned something new, be sure to share this episode with friends and colleagues.
Kim Weins:
Thanks for joining us on Upstream, brought to you by Anchore.