WEBVTT 00:00.000 --> 00:11.720 Hello everyone and thank you for attending this presentation. 00:11.720 --> 00:17.800 My name is Benjamin Hober, I am a embedded Linux engineer working at Boutin in 00:18.040 --> 00:32.960 this talk ends to present this new tools that I developed, named SBOMCV check. SBOMCV check is a 00:32.960 --> 00:43.880 standalone and lightweight Python tooling. We're going to see later what it's for, it 00:43.880 --> 00:53.160 takes as inputs and SBOMCV in SBOMCV to or in SBOMCV formats. Optionally, the 00:53.160 --> 01:03.560 laptop VX manifest generated by the VX DB class. This tool takes also values CV databases and 01:03.560 --> 01:12.200 annotation databases. Then this tool, the goal of this tool, is to find vulnerability 01:12.200 --> 01:20.840 associated with each components listed in the SBOMCV and then compute assessments for 01:20.840 --> 01:33.360 each vulnerability phones. So why we are developing yet another tool? In today's 01:33.360 --> 01:39.560 basically landscape-mettoning awareness of non-virti is essential. This process is 01:39.560 --> 01:47.400 becoming even more critical with emergency regulation, with emerging regulation such 01:47.400 --> 01:56.000 as the CI. So we are developing, we are developing this new tool to serve the following 01:56.000 --> 02:07.520 problems. Euctose CV check, the VV class integrated in Euctose is right, but it has some 02:07.520 --> 02:16.000 flows. CV analysis is tied to the build and cannot be replicated, based only on the SBOMCV 02:16.000 --> 02:25.840 files. So our effect is, we need the world build source to run again the build. 02:25.840 --> 02:36.400 So we wanted to process and generate an XPDX three-fives, which most of the existing CV tooling 02:36.400 --> 02:45.440 are not designed or does not support this format yet. We wanted something vague like 02:45.440 --> 02:53.440 weights, not complex, without any web service or something like that. We wanted a very simple 02:53.440 --> 03:03.280 tool that takes fuel inputs and generates fuel inputs. And we wanted to build to use multiple 03:03.280 --> 03:09.280 CV databases at the same time and to merge all of the information and to be able to use 03:09.280 --> 03:19.120 all of these information at the same time. So SBOMCV check has a following design. So tools 03:19.120 --> 03:28.560 text has inputs and SPDX three on SBOMCV files, which could be in SPDX three formats. In this 03:28.560 --> 03:36.560 camera, represented in yellow, it sort of takes values, CV databases, on annotation databases, 03:36.560 --> 03:46.560 represented in pink, yeah. Some SBOM format can contain an annotation. For example, this is the case 03:46.560 --> 03:52.480 for SPDX three-file. That's why in this camera, you can see the annotation database, 03:52.480 --> 04:03.840 which included in the yellow parts. Then, again, for each SBOMCV command, the tool is going to 04:03.840 --> 04:12.960 find all associated CV and then compute CV assessments. And finally, the tool are going to 04:12.960 --> 04:29.920 generate one of multiple export files representing in blue sky. The tool spools by default from 04:29.920 --> 04:39.920 several CV databases, currently we support NVD and CV lists. It's also support multiple 04:39.920 --> 04:50.480 annotation format, like OpenVax, Yucto Custom Format, generated from the vaguely big class, 04:51.680 --> 05:02.240 also a very simple annotation format in YAML file. For the export, it supports the following format 05:02.320 --> 05:14.000 XPDX three, but only if the input file currently is also in SPDX three-file. For now, we plan later 05:14.000 --> 05:22.400 to be able to generate SPDX three-file, whatever the input formats. For the export format, we will 05:22.480 --> 05:27.200 support the VcBolt, CSV format, and also the Yucto Civic, check out the two formats. 05:34.320 --> 05:41.120 The tool, as the following extra functionality, it can be extended by loading external plugin. 05:42.400 --> 05:45.920 It's for the report, it's possible to add a new type or format that is not currently 05:45.920 --> 05:52.720 supported by the tool. For example, if you want to generate a custom report format, for example, 05:52.720 --> 06:03.280 pdf or web page, whatever. Also, the tools can automatically, automatically, mark the 06:03.280 --> 06:13.360 CV as ignored, if effective source are not compiled. This free curve on the Yucto side 06:13.440 --> 06:20.800 to set the SPDX include compiled source by able to one, in each recipe that need this extra 06:20.800 --> 06:31.440 processing. Also, you need a CV databases that provide the list of affected files. Hopefully, 06:31.440 --> 06:39.280 this is mostly the case for the CV, which provides this kind of information, but 06:40.160 --> 06:53.280 yeah, you don't have a lot of provider for that, sadly. The source code is available on Github 06:53.280 --> 07:01.840 on the RGPL V2, contribution of course welcome, and the documentation can be consulted on the 07:01.920 --> 07:15.360 hit-the-doc website. If you want to try it, you can follow this step. First, you have to 07:15.360 --> 07:21.840 install the tool using thick. If you want to install the tool with all optional dependency, 07:21.840 --> 07:27.600 you can execute the following command with pip install, it's bomb cv check with the extra flag. 07:28.320 --> 07:37.360 This is recommended to install the tools inside the Python environment, but you can do whatever 07:37.360 --> 07:45.280 you want, then you need an SBOM file and optionate again the VX, managed generated by the 07:45.280 --> 07:52.880 VXDB cloud phase. For more detail on the reason the bots are, you can take a look about the 07:52.880 --> 08:03.120 documentation. Also, since JOTO 5.2, this bomb generated by default in xpdx3 formats, 08:03.760 --> 08:14.160 so you don't need to do any extra configuration on the JOTO site. All the artifacts that you need, 08:14.320 --> 08:21.520 the ZBOM and the VX manifest can be obtained from the deploy directory of JOTO. 08:23.200 --> 08:30.400 Finally, you just need to execute this command line, which is going to 08:30.480 --> 08:39.760 generate, in this example, the same G1 file that you also need to check the 08:39.760 --> 08:49.600 night. Thank you all, if you have any questions, you can send it later.