WEBVTT 00:00.000 --> 00:13.000 All right, so we are starting, and the next stop is Rauh and Gork, we'll take about 00:13.000 --> 00:18.000 Vex, cutting through the noise in software supply chain security, we'll allow it. Isn't it close? 00:18.000 --> 00:27.000 Thanks a lot. Hi, welcome everybody. Really, thank you for being here. I really appreciate it. 00:27.000 --> 00:31.000 It has been a long day for everybody. I love the air and this room. It's fantastic. 00:31.000 --> 00:39.000 So finally, we are going to talk a bit about Vex today. The state of the technology, the maturity, 00:39.000 --> 00:45.000 adoption across the industry, where do we stand? What's the state of the nation? Who are we? 00:45.000 --> 00:51.000 My name is Kia Kunz. I'm with Ericsson. I work in Ericsson's open source program office, and besides doing 00:51.000 --> 00:58.000 the open source program office, things I also do, some things in the open SSF, just like Rauh. 00:58.000 --> 01:04.000 I gave everyone Rauh Lakakula and from Microsoft, I managed the open source ecosystem strategy. 01:04.000 --> 01:10.000 As part of that, I managed a billion of those foundations out there. 01:10.000 --> 01:18.000 Cool, thanks. So, now when we look at a typical day in the live of security team, 01:18.000 --> 01:24.000 we notice that those security teams are basically drowning in vulnerabilities. They need to handle. 01:24.000 --> 01:31.000 There is, of course, rightfully due to an increased awareness of the importance of handling vulnerabilities, 01:31.000 --> 01:37.000 regulations such as the CRA that are kindly nudging manufacturers to take this more seriously. 01:37.000 --> 01:41.000 But also contributing to this is like the architectural thing. 01:41.000 --> 01:47.000 Modern applications are built obviously on top of hundreds of open source components. 01:47.000 --> 01:53.000 With deep dependency chains, right? And if any or any of those dependencies can be hit by a vulnerability, 01:53.000 --> 01:59.000 and that can, of course, well, that is a vulnerability report the team needs to look into. 01:59.000 --> 02:05.000 Because the thing is, at the end of the day, it turns out that not all of those vulnerabilities are really harmful, right? 02:05.000 --> 02:08.000 So it really requires a human currently to look into this, 02:08.000 --> 02:11.000 and look into this, curate this, find out what's harmful, what's not. 02:11.000 --> 02:15.000 And that, of course, is a lot of tedious, stupid work. 02:15.000 --> 02:21.000 And the only real solution to that is to kind of replace this manual effort by a precise, 02:21.000 --> 02:26.000 you know, data-driven process that takes in accurate data, 02:26.000 --> 02:29.000 and allows teams to focus on what is important. 02:29.000 --> 02:32.000 They really, the problematic security issues. 02:32.000 --> 02:36.000 And this is where Vx comes in, Vx to the rescue. 02:37.000 --> 02:46.000 Vx stands for vulnerability, exploitability, X change, and it is, in a nutshell, maybe over-simplifying. 02:46.000 --> 02:56.000 But you can look at it as ideally kind of a negative security advisory in the sense that it's a document or a statement telling you that for a given application, 02:56.000 --> 03:03.000 a given vulnerability is, no, sorry, that application, given application is not affected by a vulnerability, right? 03:03.000 --> 03:08.000 It allows you to kind of sort out some of the non-applicable vulnerabilities. 03:08.000 --> 03:11.000 There's a little bit more to it, but for now, that should be it. 03:11.000 --> 03:22.000 So this is a data-based approach to say, to cut through all of that noise of all those vulnerabilities coming into the teams, to eliminate false positives, 03:22.000 --> 03:27.000 and finally to automate vulnerability and handling, of course, but also risk assessment, right? 03:27.000 --> 03:30.000 So this is the idea, this is the vision of Vx. 03:30.000 --> 03:34.000 But where do we stand really in terms of the maturity of the technology? 03:34.000 --> 03:39.000 It's adoption across the industries, ways of working, tooling. 03:39.000 --> 03:49.000 And this question or all of these questions is basically what a team of industry experts from Google, Microsoft, Redhead, and other folks wanted to find out. 03:49.000 --> 03:56.000 So a couple of months ago, they came together and conducted interviews with other industry experts, for instance, 03:56.000 --> 04:05.000 with Sousa, Debian, Ericsson, for instance, to kind of ask them questions, like, what is your perspective on Vx? 04:05.000 --> 04:11.000 How do you use it, what are the challenges, does it bring you value or only pain? 04:11.000 --> 04:22.000 So those results basically from those conversations and interviews, the team has compiled into white paper that was recently published by the OpenSSF and by OASIS, 04:22.000 --> 04:29.000 and basically the single line result of that white paper, please read it, you'll see the URLs later on. 04:29.000 --> 04:38.000 Sure, the technology is great, we definitely need it, but it is currently not yet fully rolled out, and doesn't live up obviously, 04:38.000 --> 04:40.000 yet through its full potential. 04:40.000 --> 04:46.000 Adoption is inconsistent, everybody does it a little bit differently, so they're not yet agreed ways of working. 04:46.000 --> 04:50.000 And there are different formats, it's usual, there are different standards, right? 04:50.000 --> 05:00.000 I'm not advocating for a single fifth standard, but they're currently for SPDX and SectownDXs, as bomb formats allow to embed Vx information, 05:00.000 --> 05:03.000 but then of course this open Vx and C-SF Vx. 05:03.000 --> 05:13.000 And yeah, so there are a couple of challenges that the team identified and brought down in this white paper and they're trying to briefly run through those. 05:13.000 --> 05:17.000 The first one is discovery and distribution. 05:17.000 --> 05:24.000 It is, in fact, surprisingly hard to get your hands on a Vx statement for a given application, 05:24.000 --> 05:27.000 because there's, again, no consistency in how to do this. 05:27.000 --> 05:35.000 Some vendors use an API based approach, other web pages, repositories, registries, open source projects, 05:35.000 --> 05:37.000 and I put it in the GitHub repo. 05:37.000 --> 05:41.000 So, well, that's all good and done, but it makes it hard to automate, right? 05:41.000 --> 05:45.000 Obviously, that's not yet what we need really. 05:45.000 --> 05:48.000 Verification and trust is an issue, of course. 05:48.000 --> 05:52.000 Some of the formats like open Vx, they have already atostations in mind, 05:52.000 --> 05:55.000 but this not yet an industry aligned way of saying, 05:55.000 --> 05:59.000 okay, we're going to sign these statements like this, and then you can verify it like that. 05:59.000 --> 06:04.000 Of course, there is technology to do that, but what is the recommended way of doing it? 06:04.000 --> 06:11.000 Who do you trust for a given thing, a maintainer, a distributor, a manufacturer, open questions? 06:11.000 --> 06:18.000 Tooling maturity is a thing, and that does not necessarily mean that the tools are necessarily bad or incomplete, 06:18.000 --> 06:26.000 or have bugs, well, all software has bugs, but for instance, CSF Vx is, by design, a fairly complex spec, 06:26.000 --> 06:30.000 because it is meant to model complex commercial products. 06:31.000 --> 06:34.000 That also makes the tooling harder to use, right? 06:34.000 --> 06:39.000 In an open source project, do we want to maintain it to use complex tooling maybe not? 06:39.000 --> 06:40.000 So, where's the middle ground? 06:40.000 --> 06:42.000 How can we improve that? 06:42.000 --> 06:43.000 mismatch life cycle. 06:43.000 --> 06:47.000 It's a briefly mentioned that SPDX and cycling in the access, 06:47.000 --> 06:51.000 as bomb formats allow to embed Vx information that is good, 06:51.000 --> 06:55.000 but we need to realize that there is a life cycle mismatch. 06:55.000 --> 07:01.000 As bomb is relatively static and associated with build, time, point in time, 07:01.000 --> 07:03.000 thing for an application. 07:03.000 --> 07:09.000 But Vx is supposed to be, you are supposed to have a new statement, 07:09.000 --> 07:12.000 basically, for any new vulnerability coming in. 07:12.000 --> 07:16.000 So, obviously, there are timeline issues. 07:16.000 --> 07:20.000 Software identifies, I have to admit, this is still like an industry challenge 07:20.000 --> 07:23.000 when we're making improvements and it's not solely due to Vx, 07:23.000 --> 07:27.000 but that would also be great to have sorted out. 07:27.000 --> 07:32.000 Yeah, an education, of course, obviously open source projects may not see 07:32.000 --> 07:34.000 the need yet why they should publish this. 07:34.000 --> 07:39.000 Some other manufacturers might see publishing Vx documents as a business case 07:39.000 --> 07:43.000 and not a good security means, so that needs to also be sorted out. 07:43.000 --> 07:46.000 But we have recommendations, right, Rao? 07:47.000 --> 07:50.000 This is if we fix all the challenges, thus the recommendations. 07:50.000 --> 07:55.000 So, on reality though, most all the challenges actually go out 07:55.000 --> 07:59.000 to mention those are the areas to improve. 07:59.000 --> 08:02.000 But we do have some in-place systems, right? 08:02.000 --> 08:06.000 I think what we need is a consistent to bring all those to be useful. 08:06.000 --> 08:10.000 So, first one is obviously, we need to build a common distribution system 08:10.000 --> 08:15.000 where we know for the manufacturers where we can get a trusted 08:15.000 --> 08:17.000 Vx statement for each of them. 08:17.000 --> 08:20.000 As God mentioned, like, right-hat publishers through API. 08:20.000 --> 08:23.000 Microsoft publishers through one of the websites. 08:23.000 --> 08:26.000 Obviously, everyone has their own weight of distributing. 08:26.000 --> 08:30.000 On top of it, even when you find the distribution channel, 08:30.000 --> 08:35.000 how do we verify, how do we verify this is actually coming from Microsoft? 08:35.000 --> 08:36.000 How do we trust it? 08:36.000 --> 08:41.000 So, what we're proposing is, I think, we need to build a common distribution mechanism 08:41.000 --> 08:46.000 and ideally hosting a neutral place like open SSF, like a Vx hub. 08:46.000 --> 08:51.000 We do have a new construct by aquasica, come up with a Vx hub construct. 08:51.000 --> 08:54.000 But obviously, it's not in a neutral place yet. 08:54.000 --> 08:59.000 C-suff has actually, as C-suff got IO, BSI has a Niagara gate. 08:59.000 --> 09:03.000 So, we have kind of distributed set, but they're not consistent. 09:03.000 --> 09:06.000 So, what we're proposing is how, at least for the manufacturers, 09:06.000 --> 09:10.000 couple of places where we can know consistent format and consistent 09:10.000 --> 09:11.000 way to grab those. 09:11.000 --> 09:14.000 Mechanism and also, open source, obviously, there's a big gap. 09:14.000 --> 09:18.000 We need to have that hub where we can grab the open source, 09:18.000 --> 09:19.000 Vx statement. 09:19.000 --> 09:25.000 The tooling, also, as mentioned earlier, it's a spectrum, right? 09:25.000 --> 09:29.000 Like, for if you look at the Go ecosystem, the tooling is pretty good. 09:29.000 --> 09:36.000 There's a VxCTL for open vaccination, C-suff has a support for goal libraries, 09:36.000 --> 09:39.000 Python is pretty good, but if you look at, like, 09:39.000 --> 09:46.000 Java, Rust is especially, there's very little to no tooling to actually generate 09:46.000 --> 09:47.000 this Vx statement. 09:47.000 --> 09:51.000 So, what we're looking is for most common ecosystems, 09:51.000 --> 09:55.000 we need to invest on building the tooling to make the doubt. 09:55.000 --> 09:57.000 It's easy to generate. 09:57.000 --> 09:59.000 I have to give that. 09:59.000 --> 10:02.000 The NLI and I'm the standards without excluding other. 10:02.000 --> 10:07.000 Obviously, when we studied and interviewed, most of the manufacturers 10:07.000 --> 10:11.000 that are leaning towards the C-suff, mainly because C-suff being the 10:11.000 --> 10:14.000 Defactor standard for publishing the vulnerability. 10:14.000 --> 10:15.000 So, it makes totally sense. 10:15.000 --> 10:18.000 If you are already doing that, let's go use the C-suff Vx, 10:18.000 --> 10:20.000 because it's an edition. 10:20.000 --> 10:23.000 But if you are open source, maintainer, and if it's actually 10:23.000 --> 10:26.000 you have a better tooling for your ecosystem for any of the format, 10:26.000 --> 10:29.000 go with, like, so the format doesn't matter, but I think producing 10:29.000 --> 10:32.000 the Vx statement, and then building the tooling to actually do 10:32.000 --> 10:35.000 intrapal, that's the area we have to focus on. 10:35.000 --> 10:39.000 And then, obviously, the clarify experts, I mean, we don't also 10:39.000 --> 10:41.000 don't want to overload the Vx. 10:41.000 --> 10:45.000 It's purely meant to say, am I affected or not affected? 10:45.000 --> 10:47.000 That is the main purpose. 10:47.000 --> 10:49.000 But I think we don't want to overload that too. 10:49.000 --> 10:52.000 And then, obviously, there is a great progress in the last six months 10:52.000 --> 10:56.000 on the identifier, part will be in getting standardized by Ekma 10:56.000 --> 10:57.000 and ISO. 10:57.000 --> 11:02.000 I think eventually, we need to get all these Vx formats to adapt. 11:02.000 --> 11:07.000 I identify, stick to it, and make it easy for the folks to go. 11:07.000 --> 11:11.000 And then, class, industrial collaboration, obviously, this is a time I think 11:11.000 --> 11:14.000 manufacturers, maintainer, towards need to get together, 11:14.000 --> 11:17.000 and actually start producing those, because otherwise, 11:17.000 --> 11:22.000 when the CRS start hitting, everyone going to have an issue 11:22.000 --> 11:28.000 to understand, hey, am I impacted or not, which one should I be reporting? 11:28.000 --> 11:31.000 I think the Vx is the only way we can get to it. 11:31.000 --> 11:34.000 Like, the future direction, I say, like, they're up. 11:34.000 --> 11:40.000 We're proposing few opportunity to improve the CSF for make it easy for open source 11:40.000 --> 11:42.000 developer, same way for the open Vx. 11:42.000 --> 11:45.000 How do we navigate to that good balance? 11:45.000 --> 11:49.000 And then, also, building these Vx aggregators at least, 11:49.000 --> 11:53.000 couple of them for manufacturers for the open source packages, 11:53.000 --> 11:55.000 where do we host them? 11:55.000 --> 11:58.000 And then, the second thing is, obviously, we don't want to give additional 11:58.000 --> 11:59.000 to the maintainers. 11:59.000 --> 12:02.000 But how do we embed this into the GitHub actions? 12:02.000 --> 12:06.000 And also, of the CICD pipeline, so that Vx statements are automatically 12:06.000 --> 12:10.000 generated as part of your SBOM, is something. 12:10.000 --> 12:17.000 So, open SSF already have a vulnerability management workgroup, open Vx. 12:17.000 --> 12:21.000 SIG, we're also proposing to start a Vx adoption group. 12:21.000 --> 12:26.000 Like, we would love you to come and join those groups. 12:27.000 --> 12:28.000 We'll get one minute. 12:28.000 --> 12:29.000 Yep. 12:29.000 --> 12:30.000 Okay. 12:30.000 --> 12:31.000 Gathering the cloud. 12:31.000 --> 12:32.000 Gotcha. 12:32.000 --> 12:35.000 That's how we let's go, like, okay. 12:35.000 --> 12:40.000 In conclusion, obviously, we put a lot more details in the white 12:40.000 --> 12:42.000 paper, which is published in open SSF. 12:42.000 --> 12:46.000 And also, on the way as this, you can scan the QR code here. 12:46.000 --> 12:51.000 In conclusion, obviously, Vx is the only sane way for us to get 12:51.000 --> 12:55.000 off the vulnerability strong, especially with the CIRA. 12:55.000 --> 12:57.000 Definitely for the manufacturers. 12:57.000 --> 12:59.000 I think that's where we are actually looking. 12:59.000 --> 13:03.000 Manufacturers to start the lead and invest in the tooling, 13:03.000 --> 13:06.000 involving the community so that we can make it easier for the 13:06.000 --> 13:09.000 developers and maintainers. 13:09.000 --> 13:14.000 And then, obviously, we are only to hear presenting, 13:14.000 --> 13:18.000 but this work is done by so many other people from 13:18.000 --> 13:19.000 turn off companies. 13:19.000 --> 13:23.000 We also interviewed a lot of the vendors, scanning vendors, 13:23.000 --> 13:28.000 also the package publishers, the VMs, Linux distributions, 13:28.000 --> 13:29.000 others. 13:29.000 --> 13:34.000 So, thank you for all those folks contributed to this study. 13:34.000 --> 13:38.000 Think we got time for a couple of questions. 13:38.000 --> 13:39.000 Oh, we don't. 13:39.000 --> 13:40.000 Okay, cool. 13:40.000 --> 13:41.000 Thank you, everyone. 13:42.000 --> 13:43.000 Thank you. 13:49.000 --> 13:50.000 Thank you.