WEBVTT 00:00.000 --> 00:29.680 Okay, afternoon, there will be no inter-active clapping, apart from at the end when you like this 00:29.760 --> 00:36.800 presentation. Okay, like this talk is about Vex and another tool that you've mentioned that we've 00:36.800 --> 00:45.120 heard all that you heard about and this is a story and I'm really representing somebody who should 00:45.120 --> 00:53.760 be here but for lots of travel reasons you couldn't get here. So who am I? I've been delivering software 00:53.760 --> 00:59.760 a long time, 40 years and I've got stills my software is still 40 years old, well before 00:59.760 --> 01:07.200 security, well before S-bomb for every even thought about. I now, for me I'm company, 01:07.200 --> 01:13.840 APX10, focusing on the world of S-bombs, trying to help educate people and how good S-bombs can be, 01:14.880 --> 01:20.880 how to use S-bombs, how to create them and how to get the insights because there's a lot of valuable 01:20.880 --> 01:28.240 data in there. I'm also a founder with Ali of S-bomb Europe where we want to try and help the community grow. 01:32.960 --> 01:37.520 Where we want to help the community grow, there's a lot as we've already heard today 01:37.520 --> 01:42.320 we're hearing a lot there's a lot of valuable information, how can we make that information valuable 01:42.400 --> 01:51.600 for everybody. I write open to software, lots of S-bomb tools, I'm a STEM ambassador, that's 01:51.600 --> 01:57.840 fine, includes the next generation of engineers and tell them how to write good secure software 01:58.560 --> 02:03.280 and then I'm actually maybe able to retire and I'm a mentor. 02:03.520 --> 02:12.400 One of the things I've been mentoring is for the Google Summer of Code and this story is about 02:12.400 --> 02:20.640 my experience with Google Summer of Code last year and I'm from Manchester, Manchester has a 02:20.640 --> 02:25.920 B, we're busy, we work and I'm also a member of O-Woss and that's not the O-Woss, 02:25.920 --> 02:30.880 that's the Manchester B and most of the weekends I end up running round ruddy fields, 02:30.880 --> 02:39.920 that's what I enjoy doing away from technology. This is about CVA Bintill, Chris mentioned it, 02:41.440 --> 02:47.520 one of the features that Chris found was just putting there to see whether anybody wanted to use it. 02:48.240 --> 02:54.160 Now I know Chris wants to use it, we may improve it, and that's one of the challenges of open 02:54.160 --> 02:59.120 source, you never know what features people use, you don't get that feedback unless people put 02:59.360 --> 03:06.240 requests or put features requests, okay? So messages from the community, that tools available 03:06.960 --> 03:14.800 make it better by contributing. So for CVA Bintill, starters as a tool in Intel, I think it's 03:14.800 --> 03:21.040 started at heartbleed when you try to find open SSL. It was to try and protect the business 03:21.120 --> 03:29.200 from shipping, vulnerable libraries. It got open source to about 2020, which is when I got 03:29.200 --> 03:35.680 interested in it, and over time it's added more and more features, I added S-Bomb features into it, 03:37.360 --> 03:43.120 and every year we have one of the Google Summer of Code projects and that's where we get 03:43.120 --> 03:49.840 students helping us add new features. So we've added S-Bomb, we've added support for the 03:49.840 --> 03:57.040 known exploitable abilities from C-S, we've added EPS support, it's on GitHub, it's got 1000 03:57.040 --> 04:01.520 plus stars, it's got 200 contributors, welcome to join our community. 04:05.440 --> 04:11.440 2020-24 we had G-Sock Project, we had two two mentees meet and sounds gone from India, 04:11.760 --> 04:19.760 three mentors, two on the west coast of the US, and we in Europe, challenge trying to get everyone 04:19.760 --> 04:26.800 to talk to each other, so we find eight o'clock in the US time, nine o'clock in the 04:26.880 --> 04:33.200 time UK, it's okay for me, sort of late afternoon, that's one of the challenges trying to keep 04:33.200 --> 04:41.760 communication to go. But we worked. So architecture, they see if you build it as a number of 04:41.760 --> 04:49.840 building blocks, we take data in, vulnerable data, we do stuff with it, we manage it, manage the 04:49.840 --> 04:57.760 list of vulnerabilities to try and make them better, and then we triars them, and then we produce 04:57.760 --> 05:04.880 various reports. So the challenge that I set the student was improving the triars process. 05:07.280 --> 05:15.840 We all know, we get lots of vulnerable, it's reported, quite a lot of them are not white, 05:16.000 --> 05:21.920 and we do process of sharing that intelligence, so the next time we do a scan, that's not 05:21.920 --> 05:26.880 again, let's market again, we want to try and a better process of marking that 05:29.200 --> 05:40.960 assessment. So the project scope and it's very vague in this list, we don't want to 05:40.960 --> 05:44.880 frighten the students too much, and also we want to give them, we don't know where we're going to 05:44.880 --> 05:52.000 get to, quite open-ended, was we wanted to get a triars file and associated with an S-bomb, 05:53.280 --> 05:59.600 because we saw the value of an S-bomb and the triars file being quite a good unit together 06:00.800 --> 06:05.600 to actually pass into the vulnerability triars in process. 06:06.560 --> 06:17.040 We also wanted to support the standards. We've got two standards for S-bombs, we seem to have four 06:17.040 --> 06:27.120 standards for Vx vulnerabilities. And we don't, you know, S-bombs have now had quite a few years 06:27.120 --> 06:35.200 of experience, Vx hasn't really got that maturity, how are we going to manage that and the 06:35.200 --> 06:39.200 adoption, are we going to get a market going to spread, because that's going to make it really 06:39.200 --> 06:42.720 hard when you're going to share vulnerabilities, when the C-R-A wants you to share vulnerability 06:42.720 --> 06:48.320 information, and you're going to have four formats, lots of people having to convert data, 06:49.280 --> 06:57.200 but we can use T, maybe, in the future. So the triars process, very simply, is we take vulnerabilities, 06:57.200 --> 07:04.400 we scan the S-bomb, we produce a candidate set of vulnerabilities, we triage them, 07:05.280 --> 07:14.160 and then we produce a triage file. The triage is always going to have a manual element. 07:14.880 --> 07:21.120 The engineer is going to have to make that decision, is the software vulnerability, 07:21.120 --> 07:25.760 a real vulnerability, is the code exploitable, is it code readable? I'm sure we're going to get better, 07:27.360 --> 07:29.920 but at the moment it's still quite a manual process. 07:30.480 --> 07:36.160 Well, then we want to feed the results of that manual process back into the triave process, 07:36.160 --> 07:41.760 so we don't forget that intelligence. So let me talk about Vx, 07:44.240 --> 07:47.760 and we hold a bit about that from as fast as you're earlier on. 07:49.920 --> 07:55.040 So it's vulnerability, exploitability, exchange, it's a variety of 07:55.040 --> 08:00.080 exchanging information about whether vulnerabilities exploitable. 08:02.800 --> 08:07.840 It is not just the list of vulnerabilities, which I increasingly see people using, 08:08.400 --> 08:14.000 it's a way of communicating, phase all of all the abilities, with no real assessment. 08:17.360 --> 08:22.880 So we want to look at it's like a security advisor, and we need to know whether that vulnerability 08:22.960 --> 08:30.240 applies to your product. And we can all think about, you know, vulnerability, 08:30.240 --> 08:35.680 depending on where it gets deployed will have a different impact. If you're internet facing, 08:35.680 --> 08:41.280 that's a different, different potential scenario for me if you don't have any internal network, 08:42.080 --> 08:45.120 same software, you need to be able to share that. 08:45.920 --> 09:00.240 So let's look at the four formats, and it's quite hard, and I've tried to find the commonality. 09:01.600 --> 09:07.360 Yes, a vulnerability identifier, a CVE, but there's lots of vulnerability identifiers. 09:09.600 --> 09:10.640 What's the status? 09:11.200 --> 09:16.880 Has it been assessed or not? 09:17.920 --> 09:25.520 The all have status fields. The all have different ways of expressing status. There's no commonality. 09:29.040 --> 09:34.560 How do you express a component? Are we down at the further lots of this morning and 09:34.640 --> 09:38.160 afternoon about Pearl? Are we talking about a component at that level? 09:38.880 --> 09:43.280 Or are we talking at the higher level, which is the integrated product? Like a router? 09:45.440 --> 09:50.880 See, South is more at the router level. The other ones are more like at a software component level. 09:52.400 --> 09:59.200 Can you link to an S-bomb? See, South really can with a bit of a bit of work, 10:00.080 --> 10:06.400 the others are a bit more flexible. And then the final two are remediation. 10:06.400 --> 10:12.800 If you have a vulnerability, what do you do about it? Is it, go to the next release of the software? 10:12.800 --> 10:14.000 Is it a worker round? 10:17.520 --> 10:21.680 I don't know. How do you express that information? Because that's all valuable information 10:21.680 --> 10:26.000 that you want to pass to your customer, whoever that customer is. 10:30.160 --> 10:34.320 And they're really what we're seeing is, these standards are looking at slightly different use cases. 10:34.320 --> 10:41.680 See, South is looking primarily at the system. SPD-action cycle and DX are really looking at this supply chain. 10:42.240 --> 10:47.280 And the open VACs, I think is a little just more about just sharing of vulnerabilities. 10:47.280 --> 10:53.280 It's not really quite at the same level of context. All valuable, but different different use cases. 10:53.920 --> 11:05.360 So I started thinking, how can we abstract them? It'd be really nice if you could make applications 11:05.360 --> 11:12.000 ignore all these complicated different formats and data and just abstract it. So I created 11:12.000 --> 11:23.200 lib for VACs and then I gave the students make it work. Nice challenge. And it follows something 11:23.280 --> 11:27.360 similar to one or another one of my packages. But basically, 11:27.360 --> 11:31.040 generate a VAC stock image in JSON format, which generally the all are, 11:32.160 --> 11:40.880 pass them and extract the common information, and then create the new document. 11:42.480 --> 11:44.960 And I had to make a constraint. 11:46.800 --> 11:49.360 See South allows you to do a whole family of products. 11:50.000 --> 11:56.720 I think because of that, it's a complicated standard. I've said, let's just focus on a single product 11:57.680 --> 12:04.720 and try and get that to work. And that probably makes life a lot simpler, 12:04.720 --> 12:10.560 the people to understand. Architecturally, it's just a layer, 12:10.560 --> 12:17.280 sits above a couple of other abstractions that I've done and that can grow. So it's trying to make 12:17.360 --> 12:24.640 it quite a simple API or the heavy lifting is done behind the scenes. 12:27.600 --> 12:32.960 And generally all we're doing is we've got metadata, very similar to what we just saw previous 12:32.960 --> 12:39.520 thing about S-bombs metadata, bit information about the products and then it's for these statements 12:39.520 --> 12:42.080 for each of the vulnerabilities. Quite simple. 12:47.920 --> 12:55.760 I had to make some decisions. The reason I wanted a link to an S-bombs was just 12:55.760 --> 12:59.280 almost like a validation check. So if I got a list of vulnerabilities, 13:00.960 --> 13:06.080 and against a number of components, if that component was not in the S-bombs, then I 13:06.080 --> 13:09.760 wouldn't go to pass it through into the VACs. It was just to try and sort of 13:10.720 --> 13:21.280 a brief sanity check. And what I also tried to do was to generate an update the document 13:21.280 --> 13:25.360 and then create it. So if you're always asked for the latest VAC documents, 13:25.360 --> 13:29.760 it was always called VACs at me wall. You would always get VACs at me one, 13:29.760 --> 13:32.640 it was the latest version. And I would keep an order to the history. 13:32.640 --> 13:40.000 Because it's probably quite useful to know at the moment in time, what did you 13:40.000 --> 13:42.880 do on where were your assessments, where was each we have for process? 13:46.640 --> 13:50.960 So very simply trying to keep it simple. Simple Python package, 13:51.600 --> 13:55.680 create a set, create a product. It's got a name, it's got a release, and it's got an S-bombs. 13:56.720 --> 13:59.120 Hopefully that's all you've already know that. 14:02.800 --> 14:09.600 You've then got some metadata. Yeah, Fred floats. I think so, it's a very important supplier. 14:09.600 --> 14:15.520 And these, the metadata, unfortunately, is not consistent among the standards. So you're probably 14:15.520 --> 14:22.560 going to have to do a little bit of what's appropriate, but generally they are, you know, 14:22.560 --> 14:29.040 reasonably sent straightforward. And the most important thing I think is really valuable for VACs, 14:29.120 --> 14:35.840 why do you make a change? So with a revision reason. See stuff is really good, it 14:35.840 --> 14:42.080 recognizes. That's a revision notes. Every time you're up a shoe, it says, why have you done that? 14:42.080 --> 14:48.320 Well, that's really, well, we need that in all of our text documents. Why somebody updating 14:48.320 --> 14:54.720 a text document as a key audit statement? Someone's done the triage or a new vulnerability is appeared. 14:55.040 --> 15:02.160 That gives you the trace of ability. You know, if the regulator wants to say to see what your 15:02.160 --> 15:06.320 process was in terms of addressing vulnerabilities, that would be a good way of capturing that 15:06.320 --> 15:14.480 information to say, well, we assessed it on last Tuesday. And then specify the vulnerabilities. 15:14.480 --> 15:18.640 It would be nice to be able to do it using Pearl or you may just do a name and version and the 15:18.640 --> 15:28.160 identifier. Quite simple. Set the status. Yeah, the status is different depending on which version 15:28.160 --> 15:34.640 at which type of VACs document you're following. Maybe we can try and come up with a nice mapping. 15:34.640 --> 15:45.200 I've tried. It's not easy. And then maybe if you've got a vulnerability that's not affected, 15:45.280 --> 15:52.880 then you can put the justification reason as well. Again, that's type of format specific. 15:58.000 --> 16:05.920 Partying with specifying what type of, you're going to read a file. 16:06.960 --> 16:12.560 I've now got it so you can just do also. So it'll automatically detect what type of VACs document is. 16:13.440 --> 16:19.200 It might be quite useful if you're just a customer. Then you can extract the metadata for the product, 16:19.200 --> 16:25.040 the vulnerabilities, or the just a general VAC document. The simple get statements. 16:28.640 --> 16:36.160 So that's where we are. This worked example as a tutorial. It needs a bit of love, please. 16:36.160 --> 16:41.440 And it needs a bit more documentation. I'll load up. It was a case of trying to get something going 16:41.440 --> 16:50.000 and see whether it would work. So please go on there. Help. Don't just throw lots of pull requests. 16:50.000 --> 16:54.160 Yeah, throw lots of pull requests. Not lots of issues, please. Yes, and make it better. 16:54.160 --> 16:57.280 Because I think something like this is valuable. It could be very valuable for us all. 17:01.440 --> 17:08.000 So how did see the event will do it? So in addition to integrating this, we came up with a load of 17:08.560 --> 17:14.960 additional command line promises. See if you've been tools to CLI? 17:16.000 --> 17:21.280 It's got a lot of command lines now because every year we add a few more. So we've added a whole load more 17:21.280 --> 17:27.440 relation to VACs. So you specify if you initially go to create a three-hour file, you specify the output 17:27.440 --> 17:32.880 file, the type of VACs you're going to produce and the name version of the product. 17:33.440 --> 17:39.920 And then when you're doing it repeatedly, you're going to say, I'm going to do an update 17:39.920 --> 17:45.360 and again specify the reason. So you can see how you could do this as part of your 17:46.640 --> 17:53.680 maybe daily update. You're going to do a scan or every time you trigger a run of it because you've 17:53.680 --> 17:56.960 got a new vulnerabilities coming to the U.D. detected a new vulnerability. 18:03.280 --> 18:10.720 Quite simple. Every new vulnerability gets to default status, which is do something. Look at it. 18:11.680 --> 18:16.800 If there are vulnerabilities already being assessed, we retain that status. Quite simple. 18:21.760 --> 18:22.960 But there are some challenges. 18:23.840 --> 18:42.720 And first of all, how do you validate a VAC document? So for CSAF, there's an interactive tool called 18:42.720 --> 18:51.040 SETVISIOGRAM. But you put a VACS a CSAF into it and it gives you a nice traffic light red or green. 18:51.040 --> 18:58.000 And that's the happy scenario when I get one to validate. It is trial and error. There's no command 18:58.000 --> 19:06.320 line to interactively play with it and eventually you get everything green. 19:10.080 --> 19:15.920 Cyclone DX, there are lots of validators. I think we've heard quite a much is a mature ecosystem 19:15.920 --> 19:23.360 there. So there are a number of options for validation, command lines or online. What you 19:23.360 --> 19:28.560 tend to find some of them like a little bit behind the latest version. So that online vulnerability 19:28.560 --> 19:33.440 hasn't been updated to 1.6 year. I know there's a pull request into update it. Sometimes there's 19:33.440 --> 19:40.880 a bit of a lag. But again, they will validate the validate against the schema increasingly they're 19:40.960 --> 19:51.440 getting quite sophisticated. Where's the doll for? He's not here. Open VACS. It's been around for a 19:51.440 --> 20:01.120 couple of years. There are example tools. There's no validator. So all I can do is look at the example 20:01.120 --> 20:09.680 and try and replace the example. It looks right. But there's no validator. We need, if we're going to 20:09.760 --> 20:15.680 use open VACS, we need validators. If we're going to create standards, we need to have 20:15.680 --> 20:20.320 reference implementations and reference standards before the standard becomes a standard. 20:20.960 --> 20:26.000 So I think it's what always trying to do with T. We'd finally build tools with the standard. 20:26.000 --> 20:32.160 Because that's the way to, I've seen being made up successful is a way of getting a standard 20:32.160 --> 20:45.200 mature quickly. And then let's be the X. So this is SPDX3. SPDX3 took a long time, didn't it? To get there. 20:48.160 --> 20:52.000 And once you've got the standard, then they started thinking about the tooling. 20:53.760 --> 21:01.200 There was need no tooling for quite some time. So when I started doing this last March April, 21:01.280 --> 21:09.600 there was no validators. So all I could do was use this specification as my reference point. 21:12.400 --> 21:16.960 To my thought, I'm creating next document, value to SPDX3. 21:21.280 --> 21:28.160 Now there's a validator. And I wasn't creating valid documents. The documentation hasn't changed. 21:28.960 --> 21:35.920 The validators are now there. The documentation that I was using doesn't match 21:36.640 --> 21:45.920 what the validators are validating against. So hint hint, it would be nice if the schema that defines 21:47.760 --> 21:52.480 the standard is also going to generate the documentation as well as documenting, 21:52.480 --> 22:00.080 generating the tooling. Yes, but maybe there's still a few, possibly. 22:00.080 --> 22:06.080 Yes, the might be. If we don't have an issue, we don't have an issue. So example, one of the things 22:06.080 --> 22:09.600 was a relationship type. I had a relationship type that's something with it. I'm asking 22:09.600 --> 22:14.480 you to have three fixed with security dash. And I have to find that by going into the schema. 22:15.760 --> 22:20.800 And I could do that, not everyone's going to be able to do that. Anyway, we get in better, 22:20.880 --> 22:26.080 which is good. Now validate. So it was validate. It took me two days to get it to validate this week. 22:26.080 --> 22:33.120 Yeah, that was a good chance. But we do need to recognize the tools I still release, 22:33.120 --> 22:36.480 candidates, Gary has been sending me stuff. So help. 22:40.400 --> 22:48.640 Second thing is about scope. How do you know that X is complete? The same questions I've 22:48.960 --> 22:54.000 read, you know, as S-bombs complete. We all know that the C-R-A is going to request you to sort 22:54.000 --> 23:00.880 of state your statements of your vulnerable components. What's the stop you saying I've only got 23:00.880 --> 23:09.840 full component for vulnerable components? There's my document. How do we ensure that the 23:09.840 --> 23:19.760 X document is the complete truth point of truth of your products? And the other question is, 23:19.760 --> 23:24.800 how do you demonstrate the opposite that I've got all the components of checked over components 23:24.800 --> 23:32.000 and that are not vulnerable? How do I demonstrate that positive response? C-V-A to actually report 23:32.000 --> 23:35.840 we found these components, we've scanned them and we can't find any vulnerabilities. That's 23:35.920 --> 23:40.640 really valuable information that you want to pass. And we think we saw that earlier on about 23:40.640 --> 23:44.960 comparing to S-bombs and say, well there's no vulnerabilities. That's really valuable information 23:44.960 --> 23:50.640 you want to want to retain. So, Vex, we don't have a way of doing that yet. 23:53.600 --> 24:02.480 And thirdly, is every Vex user fully hundreds of percent flu and ingestion and given this 24:02.560 --> 24:07.280 four standards of Vex formats are this familiar with all four JSON formats. 24:09.280 --> 24:16.880 Probably not. It's not a simple case of just changing the status from under under 3Rs to fixed. 24:18.480 --> 24:28.480 You're going to have to put other digital data. We need a new tool that can help people 24:28.480 --> 24:37.040 do this triage process. So, what we're going to do is, so this is on our G-Sect 2025 list, 24:37.040 --> 24:42.480 that's potentially one of the projects that we will maybe get students to help us do. 24:44.080 --> 24:47.840 I've maybe we need to understand what the community really wants for that. 24:49.600 --> 24:57.120 What we have done, you can document the Vex's. So you can just give a Vex, 24:57.120 --> 25:02.960 command line to give it a Vex and it produces human readable and that can be converted into 25:02.960 --> 25:12.560 marked down HTML, PDF, Excel spreadsheet, various formats. That's a start that helps people understand 25:12.560 --> 25:18.320 and gets away from the frightening room of JSON, but we do need to think about the ecosystem around 25:18.320 --> 25:24.480 Vex to help people with this process. Because it's going to become a really important process 25:24.560 --> 25:28.400 for the CRA and other regulations. 25:31.280 --> 25:35.520 I'm starting to think about where the support says from the other various open source tools 25:35.520 --> 25:39.760 that I'm aware of. SPDX has got to start because there's now a poorly-quest well, 25:39.760 --> 25:43.840 there's an issue that will now become a poorly-quest. Now I fixed it this week. 25:45.040 --> 25:50.720 What we can start seeing triavey depends on the strategy track starting to look at Vex 25:50.800 --> 25:55.200 and I'm sure there will be other tools and I know that some commercial tools are starting to look at 25:55.200 --> 26:02.320 this. Please, it would be great to build that map across all the tooling so we can see what that 26:02.320 --> 26:05.920 what support is, or where the support needs is needed. 26:08.640 --> 26:14.080 Loader tools, these slides are on the first website so you can go and happily click. 26:14.960 --> 26:19.920 Always looking for help, money, normal things that open source developers want. 26:20.720 --> 26:28.160 And you can find me on LinkedIn, let me get to the repository's various or the contacts. 26:28.960 --> 26:30.480 Thank you very much. Any questions?