WEBVTT 00:00.000 --> 00:10.000 So, as you could have imagined that's going to be a security talk, right? 00:10.000 --> 00:18.000 So, my name is Marta, and I do a lot of security stuff around the bed at, and this is Samantha. 00:18.000 --> 00:20.000 Hi, everyone. 00:20.000 --> 00:28.000 And we are going to talk about the extensions we are working on on the Werneribit Management for the Yachter Project. 00:28.000 --> 00:34.000 So, okay, the clicker doesn't work, there we go. 00:34.000 --> 00:39.000 So, the Yachter Project has a tool called CVE Check. 00:39.000 --> 00:42.000 Who of you has already used that? 00:42.000 --> 00:46.000 Yep, about half of the room it looks, and side up. 00:46.000 --> 00:53.000 So, it's a tool to check for non-verneribitis in a Yachter Project build. 00:53.000 --> 01:04.000 And it has some interesting features, like it's pretty fast, because in a four-bit you are adding like two or three minutes to the time. 01:04.000 --> 01:09.000 It uses the metadata from the recipes you already have in the Yachter Project. 01:09.000 --> 01:22.000 And it has some specific options that allow you to do an override of certain results for either a specific vulnerability or a specific package, for example. 01:22.000 --> 01:29.000 And it supports the fact that you are patching a CV in a package. 01:29.000 --> 01:38.000 So, the fact that you have a patch, it is reflected inside the report. 01:38.000 --> 01:41.000 The tool has a few limitations still. 01:41.000 --> 01:47.000 So, it is using package versions as they declared only. 01:47.000 --> 01:52.000 So, it doesn't look if that package actually has this vulnerability. 01:52.000 --> 02:05.000 Then, if someone copies code, library or parts of a code inside the different package, this composition isn't handled. 02:05.000 --> 02:11.000 And for the same reasons, some of the package managers do not work neither with that. 02:11.000 --> 02:17.000 So, if you want to learn more about the CV check, I'm doing a lot of talks about that. 02:17.000 --> 02:21.000 I think that the one from 23 was a pretty much complete. 02:21.000 --> 02:30.000 And just after for them, 2024, there was something called NVD crisis. 02:30.000 --> 02:32.000 It started in February. 02:32.000 --> 02:40.000 The NVD database that we use for the report of pending vulnerabilities, they just stopped adding new entries. 02:41.000 --> 02:49.000 The CV program was still working, but NVD wasn't filling up with new data. 02:49.000 --> 02:58.000 It was a little bit visible before, but we still do not know what exactly happened. 02:58.000 --> 03:03.000 They restarted work, but they still have big backlog. 03:04.000 --> 03:06.000 But that wasn't yet. 03:06.000 --> 03:10.000 They had also big API issues in December. 03:10.000 --> 03:14.000 At that time, people were reporting and me too. 03:14.000 --> 03:21.000 Don't load lasting for like 24 hours when you restarted it multiple times. 03:21.000 --> 03:23.000 It was very complicated. 03:23.000 --> 03:26.000 And we are in 2025. 03:26.000 --> 03:32.000 The NVD database is handled by a US governmental organization. 03:32.000 --> 03:36.000 As you may have heard, they have cut budget. 03:36.000 --> 03:37.000 Right? 03:37.000 --> 03:43.000 And we do not have official information, but from just looking what NVD is doing right now, 03:43.000 --> 03:48.000 you can see that NVD is not doing much. 03:48.000 --> 03:53.000 In January, they have added information to less than 10% of the entries. 03:53.000 --> 03:57.000 And we can assume that it's going to continue this way. 03:58.000 --> 04:05.000 This work that we have started that has a few ideas behind. 04:05.000 --> 04:10.000 The first idea was the risk of the pending NVD. 04:10.000 --> 04:20.000 And we were in a good situation that CV database itself started adding machine readable package format in 2024. 04:20.000 --> 04:24.000 Not enough entries, but still it is now possible. 04:24.000 --> 04:30.000 Another point is that with the recent regulations and all the geopolitics, 04:30.000 --> 04:39.000 we have a real risk to see national or continent of NVD databases that you would be obliged to use. 04:39.000 --> 04:40.000 Right? 04:40.000 --> 04:44.000 Then, we have also the rise of Asmond Generation. 04:44.000 --> 04:48.000 So, can we reuse the work done by S1? 04:48.000 --> 04:51.000 People too, for vulnerabilities. 04:51.000 --> 04:56.000 And there is a very big practical problem. 04:56.000 --> 04:58.000 You have your product. 04:58.000 --> 05:01.000 You have done the CV analysis when you were releasing it. 05:01.000 --> 05:05.000 And then you want to redo it. 05:05.000 --> 05:08.000 For example, five years later. 05:08.000 --> 05:15.000 Do you want to keep the exact build five years ago, 05:15.000 --> 05:20.000 or well not very practical, and probably it's going to be lost for some reason? 05:20.000 --> 05:25.000 And for the security check, we just need some of the information not everything. 05:25.000 --> 05:29.000 So, really, there's no need to keep that build directory. 05:29.000 --> 05:32.000 So, there are a few abbreviations in the whole story. 05:32.000 --> 05:35.000 So, the CV command vulnerability and remuneration. 05:35.000 --> 05:40.000 That's the database of vulnerabilities those days. 05:40.000 --> 05:43.000 As well as software build materials. 05:43.000 --> 05:47.000 Data format containing list of packages, 05:47.000 --> 05:52.000 reservation, dependencies, licensing, and well. 05:52.000 --> 05:54.000 You can add a lot of stuff. 05:54.000 --> 05:58.000 They are basically two variants, SPDX, second eggs. 05:58.000 --> 06:01.000 In the Octo project, there is SPDX. 06:01.000 --> 06:05.000 And then, finally, something less common. 06:05.000 --> 06:08.000 The Vx vulnerability exchange. 06:08.000 --> 06:13.000 This is kind of annotations for vulnerabilities. 06:13.000 --> 06:19.000 In a Vx report, you can say, what, how does it affect your product? 06:19.000 --> 06:23.000 For example, you can say that your product is vulnerable to this one. 06:23.000 --> 06:29.000 But you can also say, the vulnerability is present, but I am not vulnerable. 06:29.000 --> 06:34.000 Because in the setting, in the configuration options, 06:34.000 --> 06:39.000 I use it will never be possible to exploit. 06:39.000 --> 06:44.000 Or, I compiled out the vulnerability code, it's just not there. 06:44.000 --> 06:50.000 They are still, as you read the multiple formats, 06:50.000 --> 06:54.000 the two most popular CSF and OpenVx. 06:54.000 --> 07:00.000 So, on the technical side, our idea was to run the check externally 07:00.000 --> 07:05.000 from a Octo build, grab the data from the build, 07:05.000 --> 07:12.000 and then run the check, and it could be five years, 10 years, 20 years later. 07:12.000 --> 07:18.000 We wanted to have a possibility to plug in different databases. 07:18.000 --> 07:23.000 If we need to add all the elements in the data flow. 07:23.000 --> 07:29.000 And we wanted to support the metadata that is available right now in the Octo project, 07:29.000 --> 07:34.000 or the work that has been done to fix the CPEs to do overrides 07:34.000 --> 07:38.000 for certain vulnerabilities and so on and so on. 07:38.000 --> 07:46.000 So, Samantha is going to work through the architecture part. 07:46.000 --> 07:49.000 Thank you. 07:49.000 --> 07:53.000 So, can you hear me well? 07:53.000 --> 07:55.000 Yeah, sorry, okay, thanks. 07:55.000 --> 08:00.000 So, on the technical side of this project, what we initially had in mind 08:00.000 --> 08:05.000 while designing this external checker was to add first extract 08:05.000 --> 08:09.000 and gather packages information of a district, 08:09.000 --> 08:14.000 especially packages names and version, which is information 08:14.000 --> 08:18.000 available by reading the SPDX summary file. 08:18.000 --> 08:21.000 You can generate by. 08:22.000 --> 08:25.000 Okay. 08:25.000 --> 08:30.000 So, you can get this information from the SPDX summary file. 08:30.000 --> 08:38.000 You can generate by inheriting the Create SPDX BB class. 08:38.000 --> 08:44.000 So, using this packages list, we could then request either NVD database 08:44.000 --> 08:50.000 or CV roll database package per package to get every related CVs. 08:51.000 --> 08:56.000 Then combining both texts of information, you can then generate a fixed report. 08:56.000 --> 09:03.000 It can either be individual files, each representing one vulnerability 09:03.000 --> 09:06.000 or a summary of both. 09:06.000 --> 09:13.000 In addition, we wanted to add a task that can update the SPDX files 09:13.000 --> 09:16.000 to just add the link to a VX file. 09:16.000 --> 09:22.000 So, it could ease a bit parsing and navigation through all those files. 09:22.000 --> 09:27.000 So, this is quite a straightforward approach to generate a VX report. 09:27.000 --> 09:33.000 So, let's jump right into the issue and limitation we've came across. 09:33.000 --> 09:39.000 So, first thing we've noticed at that the SPDX generation is designed 09:40.000 --> 09:47.000 to generate SPDX reports on built images. 09:47.000 --> 09:52.000 So, you cannot run a partial build to get those information. 09:52.000 --> 09:57.000 It is a little bit time consuming and it is definitely something you should keep in mind 09:57.000 --> 10:02.000 when you want to generate either SPDX or VX report. 10:02.000 --> 10:11.000 So, now on two bigger issues, we had many parsing issues on CVs, 10:11.000 --> 10:16.000 especially using the ROCV database. 10:16.000 --> 10:22.000 So, as you can see this is just an example, but we had quite a few instances 10:22.000 --> 10:25.000 of CVs like this one. 10:25.000 --> 10:31.000 So, every critical information is written out in the description text. 10:31.000 --> 10:36.000 And nowhere else. 10:36.000 --> 10:42.000 It is also the case for the version description which was described as well 10:42.000 --> 10:48.000 which announced in order to describe more of the ranges that were affected. 10:48.000 --> 10:54.000 It was long sentences in written in various ways. 10:54.000 --> 11:02.000 So, it was quite difficult to find a way to pass automatically all of this. 11:02.000 --> 11:09.000 And then we entered the last category of limitation with KM across which is the metadata. 11:09.000 --> 11:17.000 So, within the VX standard there is only four available statuses. 11:17.000 --> 11:20.000 You can flag a CV. 11:20.000 --> 11:27.000 So, it can be either affected, not affected, fixed or under investigation. 11:27.000 --> 11:33.000 Which does not reflect in that situation's centuries wrong 11:33.000 --> 11:38.000 and we are waiting on the update or this vulnerability is disputed and so on. 11:38.000 --> 11:40.000 That's one limitation. 11:40.000 --> 11:49.000 And the last one is that we had unexpected results when using O2. 11:49.000 --> 11:56.000 So, at first the results we had the CV results we had when using O2 11:56.000 --> 12:03.000 differed a bit from the CV check results we can get from the CV check baby class. 12:03.000 --> 12:10.000 So, some CVs were flagged as affected in one case and not affected in the other. 12:10.000 --> 12:18.000 So, we found that we were missing some critical information that we can get by the metadata. 12:18.000 --> 12:22.000 So, metadata collected by the CV check. 12:22.000 --> 12:30.000 And so, our error was due to the fact that in some specific cases packages were flagged as affected 12:30.000 --> 12:39.000 whereas, in reality, the issue was the issue is not applicable in the context of a youtube project build. 12:39.000 --> 12:45.000 So, you probably guessed the improvement we've made to our architecture. 12:45.000 --> 12:50.000 We added the metadata of the CV check as an input of O2. 12:50.000 --> 12:55.000 And this way it was fixed the discrepancy we've just talked about. 12:55.000 --> 13:04.000 And it also fixed the not too detailed, vex status situation. 13:04.000 --> 13:11.000 Meaning that vex does support only for kind of CV status. 13:11.000 --> 13:19.000 But the standard supports additional annotations such as the status notes and justification. 13:19.000 --> 13:29.000 So, that's where we drifted away a bit from the open vex standard by adding your own custom status note and justification. 13:29.000 --> 13:33.000 We got from the CV check metadata. 13:33.000 --> 13:38.000 So, for example, you can have a CV flagged as affected. 13:38.000 --> 13:47.000 The status note stating extreme one fix and the justification such as this is from an abandoned project and so on. 13:47.000 --> 13:52.000 And as for the CV parsing issue, fortunately we have a good news. 13:52.000 --> 13:58.000 There is a new format that had Blossom which is called ADP entry. 13:58.000 --> 14:06.000 It is easy to parse and it is progressively implemented into the raw CV database. 14:06.000 --> 14:09.000 And I will let my title continue. 14:09.000 --> 14:12.000 To rush to the rest of the presentation. 14:12.000 --> 14:14.000 So, the status today. 14:14.000 --> 14:19.000 We have the vex Bb because of the metadata information indexed in the format. 14:19.000 --> 14:21.000 That is available in the other project today. 14:21.000 --> 14:26.000 The tooling is currently hosted separately. 14:26.000 --> 14:35.000 And we are working on the overhead format so that then we can reintegrate it in the. 14:36.000 --> 14:38.000 In the vector project. 14:38.000 --> 14:41.000 Short instruction how if you want to try it. 14:41.000 --> 14:45.000 Basically, in your local conf you need to add in her it vex. 14:45.000 --> 14:47.000 Entrem of CV check if you have it. 14:47.000 --> 14:48.000 You bid as usual. 14:48.000 --> 14:51.000 You download the databases. 14:51.000 --> 14:56.000 So, we have a separate script to download NVD and you have the overheads of CV. 14:56.000 --> 14:58.000 Then the tool. 14:58.000 --> 15:00.000 There are few options to give. 15:00.000 --> 15:03.000 So, the input file that you get from the vector build. 15:03.000 --> 15:07.000 They output directory when you want to have the result files. 15:07.000 --> 15:11.000 We need to separate the directory directory. 15:11.000 --> 15:16.000 And you point to the database type and the database location that you want to use. 15:16.000 --> 15:19.000 And then it goes and generates file files. 15:19.000 --> 15:24.000 Then we have also post processing scripts that you can use to. 15:24.000 --> 15:27.000 To show up the results in a. 15:27.000 --> 15:31.000 You can also generate it to CSV. 15:31.000 --> 15:33.000 If you want to. 15:33.000 --> 15:36.000 That is a simple input from core image. 15:36.000 --> 15:38.000 Minimal pretty up to date or not many. 15:38.000 --> 15:40.000 CV is present. 15:40.000 --> 15:43.000 Our future plans is to bring that. 15:43.000 --> 15:46.000 To link to the official repo integrate with the octobio. 15:46.000 --> 15:48.000 As usual, not testing documentation. 15:48.000 --> 15:53.000 It really will come and we have a lot of possibilities for new features. 15:53.000 --> 15:57.000 For multiple databases, the database is like OSV. 15:57.000 --> 16:00.000 I guess that you cannot hear. 16:00.000 --> 16:04.000 And working on how we can integrate. 16:04.000 --> 16:08.000 Overall, that is plus specific product. 16:08.000 --> 16:12.000 This is some research work that we want to do in the future. 16:12.000 --> 16:15.000 Probably you won't have time for questions, right? 16:15.000 --> 16:16.000 No. 16:16.000 --> 16:19.000 So, we can talk outside. 16:23.000 --> 16:25.000 Thank you.