Cloud Native Computing Foundation SupplyChainSecurityCon hosted by CNCF + CDF 2021, 30 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: Approaching the SBOM: Best Practice for Software Supply Chain Security - Daniel Nurmi

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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: Approaching the SBOM: Best Practice for Software Supply Chain Security - Daniel Nurmi, Anchore

The software bill of materials (SBOM) has quickly become a critical foundation for software supply chain security. Gaining the ability to see and process the full picture of all software components included in your applications is the first step in preventing vulnerabilities and malware from reaching production systems.

The recent United States Executive Order on Improving the Nation's Cybersecurity details the need for software producers to supply SBOMs, as well as maintaining controls on the provenance of software components and tools. The U.S. NTIA has subsequently released minimum elements for a compliant SBOM. This highlights the important role of an SBOM for open source projects, whether they are incorporated in software applications or used as part of the development toolchain.

Multiple Linux Foundation and CNCF projects including SPDX, In-Toto, and SigStore are providing critical frameworks and specifications designed to advance the security of the software supply chain.

This session will explore best practices for generating SBOMs for both open source projects and software producers, we will share insights and lessons learned from creating SBOMs for CNCF projects using Syft, an open source SBOM generator, and predict ways that we see the role of the SBOM in securing software supply chains evolving over time.

A

All right, thank you all very much for um attending. Today. My name is daniel nermey, I'm, the cto co-founder of a company called encore. We've been working in the security space for a bit largely. We work with customers to add security tooling into their development processes, and today I was going to focus in a little bit on this intersection between discussion. That's been going on, you know with more focus over the last half year or so even really, between supply chain security and the concept of s bombs.

A

We see these things talked about a lot and I was going to explore a little bit the relationships between these things and so, first of all, you know we did a an interesting survey where we went out to a number of larger enterprises, not not anybody, but very large enterprises and actually asked quite a few questions. Some of them focused specifically on supply chain security, and I thought I'd share a couple of these results pretty interesting stuff in our opinion, and one of them was asking about the past. You know over the last 12 months.

A

You know how many large enterprise respondents were affected by something you identify specifically as a software supply chain attack, and you know overwhelmingly, a lot of respondents came back with yep, yes, indeed, some form of yes, whether it's a minor impact based on the fact that something happened and we had to spend a lot of time on it or a major impact we were significantly impacted, probably actually hacked. You know that kind of thing and the second question we asked was actually more about the future.

A

You know now you know given where we are, uh you know, are you focused? Do you have a specific focus on in cure, improving your supply chain, security stance and again you know we were a little bit surprised to find. You know over 50, you know closer to 60 of our respondents came back and said this is a significant area of of focus for us in the next 12 months.

A

Just a little bit of context. Kind of you know putting some facts and a little bit of evidence towards a lot of the discussion. That's been going on about improving supply chain security.

A

Now I think a lot of folks in this room probably have something in mind when it comes to what a supply chain is- and I think you know- operation salsa can get it out for us a little bit, but you know another way to just sort of ground this discussion, we kind of think of a supply chain more like a graph right when it comes to software. There's open source projects there's vendor projects.

A

All of this stuff is related, there's cycles in this graph, but at the end of the day, it's in kind of a you look at it. This way from a malicious, actor's perspective, you can see some obvious. You know ways to influence what ultimately ends up running in production. You can find anywhere in this complex graph to come in and make a problem happen, but if we kind of look closely at one of those boxes, you know everybody that's trying to infiltrate.

A

A supply chain is looking for the weakest link in the chain or the graph, and if we kind of look closely at this stuff, this is a depiction of kind of a standard left-hand side. We've got a bunch of external software coming in you know, from from earlier in the supply chain, on the right-hand side, we're publishing or running some software, that's kind of the other side of the chain in between you know. Nowadays, we've got a fairly modern setup. A lot of automation containers are in here a lot of software builds.

A

A lot of things are happening automatically very quickly, there's a lot of dynamic stuff happening and at any point in this, in this process of left to right for any given software project, there are opportunities to come in and either get some credentials leaked or insert some malicious code. There's a lot of opportunity in here, which is why this is a significant problem, something worth all of us thinking, thinking about how to how to improve.

A

Now, I'm going to jump over to the s-bomb. So we look at that previous picture and there's a lot of places where we can. We can have problems. How do s-bombs actually help like what? What is this? You know, what do we do with an s-bomb and how does it apply to this problem? Well, there's a couple ways of thinking about it: one way is probably a little bit more obvious based on existing tooling and the kind of technology that's been out there, which is to say if we do a softer bill of materials.

A

If we generate an s-bomb for all of the artifacts in this software development process, you know we can, we can think of it as a manifest right. It's a it's a list of software right, it's our dependencies. It's our application, software, it's names and versions of things and just by itself, that's really useful. A lot of times, folks that aren't necessarily in this space, don't realize that one way or another that piece of information is an important input to tooling that does vulnerability scans.

A

It does license checks, it does things like provenance checks to figure out what what dependencies do you have so that I can do something in a security or compliance function? On top of that, so s-bombs already have been used for a very long time as one of the inputs to some of the standard security tools. We tend to build into these development processes, but now moving forward. I think there's some additional opportunities to kind of extend the definition of an s bomb from being.

A

You know something that's a list of dependencies to add a lot more context. You know when we go in and start looking at source code or container images or binaries, we can generate lists of of dependencies, but we also have access to a lot of other information. We have access to the files we have access to their checksums. We can look at configuration files inside of containers that define how things might operate when they're executed.

A

We can look at all sorts of information, and one perspective here is to say we can add that additional information to an s-bom and if we start to do that, we start to unlock some additional security functions.

A

Is our prediction, for example, if we go in and generate this richer s-bomb document against a bunch of these artifacts being generated, we can we can codify that one of them as an intention. This is something that we can review. We can run our vulnerability scans on we're. Okay, with this s-bomb, we have that codified. Now in our development automated process, we can start to observe everything else, that's happening and generate a comparable, s-bomb start to compare them, and that gives us a notion of say drift right. We can look at.

A

This is what it's supposed to be. We can generate a new s-bomb for what actually is and start to compare right. This is a an interesting function that we can start to look at as well between all of the artifacts generated by these by these stages.

A

So now, if we start to do this, we have our vulnerability scanning and our license checks, and then we start to add some more advanced comparison functions all based on software build materials coming into a system, then, ultimately, we can start to improve as any one element of a software supply chain, global software supply chain.

A

Our stance- and we think you know one thing- that's likely to happen if you know if we all start to kind of orient around this kind of tooling, especially off of the back of some new regulations like from the the us executive order, for example, specifying best moms and other types of security, tooling proof being required for various regulated industries and projects to use software.

A

We predict the world's going to start to look something like this. Where not only do we use these software bill of materials and other tooling within our development process, but we can start to generate them and share them across organizational boundaries and that's easier said than done. But if we can figure that out, then the global supply chain starts to improve substantially, because we don't have to inspect things necessarily anymore.

A

We can take what's given, prove that that's valid and then move on from there use those to trust but verify what we thank you very much. If you'd like to learn more, we've got a booth here, um encore at kubecon and uh we've got a couple of events, but I just thought I'd say you know. Thank you again for attending it's it's great to see everybody in person. Thank you.