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

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Vulnerability Supply Chains - Art Manion, CERT Coordination Center

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.

Vulnerability Supply Chains - Art Manion, CERT Coordination Center

If you've analyzed or responded to software vulnerabilities like BadAlloc, KRACK, or the PROTOS SNMP test suite from 2002, then you've encountered the intersection of vulnerabilities and supply chains. Without supply chain knowledge, multi-party coordinated vulnerability disclosure efforts are largely limited to manual investigation, one-offs, and guesswork. Follow-on activities like vulnerability management and risk assessment are also hindered. To what extent are vulnerabilities in upstream dependencies inherited? What happens when build tools have or create vulnerabilities? How might we effectively perform coordinated disclosure and share supply chain knowledge at scale? What part will SBOM (software bill of materials) play?

A

Hi everyone good afternoon uh glad to be here. My name is art manion. I work at the search coordination center and I'm here to talk about supply chains, particularly vulnerabilities, and how they flow down and affect supply chains. So at the cert coordination center I do a lot of coordinated vulnerability disclosure.

A

We specifically focus on multi-party or multi-vendor issues.

A

These issues underneath are entirely supply, chain problems or more specifically, problems because of lack of knowledge about supply chains who and what are affected by a vulnerability in 2002, significant manual effort and a best guess in 2021, also significant manual effort and a best guess.

A

We have not improved the state of the practice here in in 20 years or perhaps longer these numbers for these vulnerabilities, 285 vendors, 183, vendors, again manual effort, best guesses, historical anecdotal collections of who uses what software who we could reach via email or by pinging people or doing open source research uh again awful situation. Best guess is what we have as a state of the art today. um That alloc is a more recent one.

A

Just a small example: here, uh we've got the uh the kellogg function in blackberry, qnx vulnerable, so a bunch of blackberry, q and x product lines are vulnerable.

A

That in turn hits who knows how many embedded operatings embedded sort of system or iot, or, in this case ics ot suppliers and epa in the water isac. Without a particular warning about the q and x issues, q x is just one of the 18 vendors uh lit up by the bad alloc vulnerabilities.

A

um There have to be thousands of affected vendors and systems, possibly tens of thousands for bad alloc, and the answer is we don't really know who they all are.

A

So um the hope here is that software builder materials can actually really help us software build materials is exactly what it sounds like it's a bill of materials for software, so one or more identified software components you identify them with names and hashes and version numbers things. You already identify software with they're relationships, that's key. Otherwise we have no chain in the supply chain and other associated information. You would need to do things like improve vulnerability, management or improve, in my case, coordinated disclosure.

A

If, if the s-bomb phrase is giving anyone any kind of heartburn or trouble upstream, dependency tracking is a fine way to think of it, third-party inventory is a fine way to think of it. That's all. It really is um so very simple, comp very simple concept, but it's more than just your third-party dependencies.

A

You are someone else's third party, so please label and enter into the s-bomb. Your first-party created software as well in theory. If we all do this, the graph and the network work and we start to gain transparency.

A

This work- I've been involved for almost three years now comes out of the multi-stakeholder community ntia process, uh just to be clear, that is, that is distinct from the executive order uh requirement for ntia to produce a report which they also did so um my work- and my discussion here today comes from the ntia community side of that work and that's the short url for for the collection of documents coming out of that effort, um two sort of sub you know: sub sub use cases for sbom, one is before public disclosure, whom do I notify about a vulnerability who might be affected?

A

The second is post, typically post public disclosure. If I'm a deployer or a system administrator, do I have to patch do I have to do something and that's the vulnerability management use case. In the end, we want the same information right. What software it contains these components and what software is affected by these vulnerabilities as we're going to see those are potentially different. Things slight nuance on what happens before public disclosure?

A

What happens after um there's a idea and we'll explore this a bit that an upstream vulnerability is inheritable down to the supply chain and also an idea that increased s-bomb data and inventory data will reveal what's actually already there lots and lots of upstream components we didn't realize were there and their associated vulnerabilities.

A

So we've now created more of a vulnerability management problem that we already had. We haven't created a bigger one. We just have more awareness of what's already there. How do we handle that at scale? Individual human written and human red advisories probably are not going to cut it, so I typically view s bomb as a graph. It's a dependency graph, pretty pretty straightforward.

A

If you, if you're dealing with software dependencies at all, this is a toy example that comes again from the ntia work uh and the the sort of high level of abstraction dependent uh relationship is simply included in um very likely. More nuance is necessary. There you will see in the upper left.

A

Bingo buffer is meant to be source code that is compiled, modified, perhaps and compiled, to produce acme buffer. So the acme version of bingo buffer- and that's going to be key that you know built from or derived from, is different than simply included, uh and then not that it's all that important, but at the far right with frank's final good, that's sort of pointing back to itself primary relationship. Just sort of indicates that frank's final goods s-bomb, is talking about the main subject of frank's final good frank's final good could be considered a product here.

A

If that's a distinction that helps, although product is somewhat relative anywhere in this chain, one person's product is someone else's sort of component.

A

Now what happens when a vulnerability is identified in bingo buffer, so the bingo buffer developer supplier, vendor maintainer, confirms the problem, produces a fix. There's no argument: it's a true vulnerability problem is solved great there's, no question that that cv affects bingo buffer, but what does this mean through the supply chain from bingo buffer down into its use? Ultimately, in frank's final good, um I was hoping early on that. Perhaps some degree of inheritance could be assumed and there was a safe way to do that.

A

uh You know safe sort of in a conceptual belief, sort of sense. It turns out that probably instead, every node needs to investigate its own own vulnerability status.

A

Early on from the ntia work, there was a presentation from varicode and their study of at least here, ruby java and python produced a very low inheritance rate, so five percent lower than five percent um of upstream component vulnerabilities, made it down to the frank's final good level or the product level. um So this is real data. I have no reason to doubt it that's an important bit of evidence, I'm not entirely sure what other ecosystems look like.

A

This is sort of something you could apply anywhere or if it's less common in in c, or something like that, um also, even if there's a five percent chance of of inheriting the vulnerability, do you want to make that assumption? um Maybe you do, maybe you don't five percent chance of a truly expensive horrible impact might simply be too high.

A

So uh from the ntia s bomb community work comes vex. um Vex is essentially a way to record and convey vulnerability status. So, if you imagine the the nodes earlier, each one of them would have a vex could have a vex statement about that. Cve um one of the tricks of x is this first sentence here copied from the the vex one pager reduce effort spent investigating non-vulnerability non-exploitable vulnerabilities.

A

So it's one thing to certainly to convey that something is vulnerable. It's actually also very valuable to convey if it's true, that it's not vulnerable and save us all the time digging into a non-vulnerable problem problem affected not affected. Straightforward action required to remediate fixed and under investigation are perhaps a different or two different dimensions here, but they are all treated at all treated as status for vex.

A

You can read more about vex there's a one pager at the bottom of the slide here. Also there's a csaf profile for vex csaf is a structured advisory security advisory format.

A

Vex was developed with the s-bom work. However, it's designed to be used without sbom. You don't need an s-bom tied to the vex. You can simply issue a vex statement about any software whatsoever as long as you can identify it in a csaf compliant way.

A

So, despite some evidence here that inheritance is not something to assume I'm not done trying to figure out if it can be assumed. In some cases my suspicion is that non-vulnerability, certain kinds of non-vulnerability might be inheritable, so vex does not currently support this feature, but under discussion during development of x, there was the idea that I would have a status of not vulnerable and then a reason for being not vulnerable.

A

So for this example, uh if acme uh grabs, bingo buffer source code compiles out or pound defines out certain functions or certain parts of the code builds their version of it, their own component, acme buffer, that they are now responsible for which finds its way into their application, which finds its way into frank's final good if acme investigates their use of bingo buffer and can very clearly find and state that the acme buffer variant of bingo buffer is not vulnerable because the code is not present, the vulnerable code is compiled out.

A

I would argue that that that reason for being not vulnerable is transitive and the acme application and frank's final good can cross that vulnerability off their list. The code is not present, at least not from the acme buffer component, and you can move on and deal with the next cde uh in your list.

A

So uh that's the end of the slides, I'm happy to answer any questions uh and I'll turn it over to our moderator. Thank you.