WEBVTT 00:00.000 --> 00:13.600 OK, sorry for the delay. Hello, I'm nice to be here, I had first them, so my name is Sebastian 00:13.600 --> 00:20.600 Valer, and I will present you some listen learn about integrating S-Bomb in supply chain, 00:20.600 --> 00:29.600 so name the redness factory. So, short about me, I'm a technical director at... 00:29.600 --> 00:37.600 OK, no, no, no, no. So the microphone needs for the recording. 00:37.600 --> 00:45.600 So I'm a technical director at Hayote Busy-Dage, and I work before in low-world part of Software. 00:45.600 --> 00:56.600 You bought big swaps, I spent ten times working embedded word, developing tools on the drivers at Renewer. 00:56.600 --> 01:09.600 And I use LINEX for a long time, and I'm not always behind my keyboard, I also, hiking or cycling trip. 01:09.600 --> 01:15.600 So, company IOTB-Dage, we are French company located in west of France. 01:15.600 --> 01:28.600 We are both 25 engineers, and we mostly focusing on embedded development and embedded word on the security. 01:28.600 --> 01:39.600 Many guys will work at AOTB-Dage, contribute to Tizen, the application framework, so the security part of Tizen, 01:39.600 --> 01:49.600 and we reuse this model and contribute a lot to automotive red Linux pastures. 01:49.600 --> 01:58.600 And we also developed red-pesk, I will talk more details later in the slide, 01:58.600 --> 02:06.600 and we propose some services to many well-known partners that you can see here. 02:06.600 --> 02:17.600 So this talk is about this bomb, so I will not, again, give a definition, I think, or as know what is exactly. 02:17.600 --> 02:28.600 What, as why is bomb is crucial, so is really crucial to identify first vulnerabilities of the software you deliver. 02:28.600 --> 02:37.600 But it also helped you to have a clear view about the components that are involved in your product. 02:37.600 --> 02:45.600 It also helped to quickly identify which components are affected by vulnerabilities. 02:45.600 --> 02:55.600 And you also help stakeholders to identify potential risk of your supply chains. 02:55.600 --> 03:18.600 So as bomb is also a solution to answer to legal obligations that are raised in Europe, for example, with directive and IIS2 and the CRA, so what is CRA, cyber resilient act is now reality. 03:18.600 --> 03:33.600 As you can see, the effective date was December pastures and the notification on penalty date are coming for next year and year after. 03:33.600 --> 03:38.600 So many types of bomb are defined on existing. 03:38.600 --> 03:45.600 You may know all of them like a cryptography bomb. 03:45.600 --> 04:02.600 And for us, the main important one is about VECs and the idea about vulnerability and also disclosure. 04:02.600 --> 04:05.600 Disclosure report. 04:05.600 --> 04:14.600 So all this bomb are well described in the Cyclone DX present website. 04:14.600 --> 04:16.600 The link is below. 04:16.600 --> 04:23.600 So the two most popular you should know is SPDX on Cyclone DX. 04:23.600 --> 04:32.600 So SPDX is listed by the line-up foundation and was initially designed to track only software license. 04:32.600 --> 04:43.600 But this involve with the latest version, the free dot X, there is more flexibility on more supported stuff. 04:43.600 --> 04:55.600 And on the other part, Cyclone DX is listed at OS foundation, initially focusing only on security vulnerabilities. 04:55.600 --> 05:06.600 And also designed to be a lightweight and easily extendable. 05:06.600 --> 05:20.600 So another interesting feature for Cyclone DX is the support of complex multi-modal system like we can have in our cases. 05:20.600 --> 05:25.600 So there is a large competition between these two bombs. 05:25.600 --> 05:32.600 It's up to you to support both or only select one. 05:33.600 --> 05:48.600 So as I mentioned, there is a bomb plus VECs that is only focusing on vulnerability part. 05:48.600 --> 06:01.600 And the combination of both having the list of material plus the list of vulnerabilities really important. 06:01.600 --> 06:13.600 And I say materials for software in more identifying packages, the name, the versions, the license and so on. 06:13.600 --> 06:24.600 So short presentation about the work desk, so red desk is both an OS and a factory to build this OS. 06:24.600 --> 06:30.600 So red desk OS is based on red dot centOS stream. 06:30.600 --> 06:46.600 So we have a long-term support regarding this base basis and like red dot it's based on RPM packages. 06:46.600 --> 06:58.600 We add the notion of BSP to simplify integration of values both like you can have with yokto. 06:58.600 --> 07:13.600 So you can see red desk like a mix between yokto that support embedded board and stormed our red dot or centOS distribution. 07:13.600 --> 07:20.600 And we propose or we enrich this OS with the application framework. 07:20.600 --> 07:31.600 So the security part that I mentioned before that is in Tyson and also in HGL project is also available in red desk. 07:31.600 --> 07:38.600 And also spot available on GitHub and on free. 07:38.600 --> 07:44.600 And the other part, the factory is here to build your line exercise. 07:44.600 --> 07:54.600 So the factory is built on top of the built system of federian gene, that is named Koji. 07:54.600 --> 08:07.600 And we added to Koji the notion of cross building or emulated build so that you can cross build your software. 08:07.600 --> 08:11.600 For embedded board. 08:11.600 --> 08:21.600 There is a community edition of this factory that is available for free here. 08:21.600 --> 08:25.600 You can have a try using this link. 08:25.600 --> 08:30.600 So here is a short picture of the factory. 08:30.600 --> 08:38.600 So just to say that is built on top of many well known open source software. 08:38.600 --> 08:48.600 And you can interact with the factory with web UI or CLI command line. 08:48.600 --> 08:56.600 So it is our goal was to integrate SBOM support in this factory. 08:56.600 --> 09:06.600 So that's factory can generate SBOM by the end with your artifact that is an image. 09:06.600 --> 09:13.600 So short picture about the web UI on the CLI. 09:13.600 --> 09:21.600 So what was the challenge is to for integrating or generating SBOM in this factory. 09:21.600 --> 09:28.600 The first challenge was to identify how to easily and where to collect information. 09:28.600 --> 09:35.600 Because in such complex factory you have several steps during build. 09:35.600 --> 09:37.600 And you have also constraints. 09:37.600 --> 09:41.600 The build system of Koji is built in what we call a mock. 09:41.600 --> 09:43.600 It can see as a container. 09:43.600 --> 09:45.600 So you don't have network. 09:45.600 --> 09:48.600 You don't have specific access to the disk. 09:48.600 --> 09:52.600 So it may be problematic. 09:52.600 --> 09:57.600 And we don't want to rerun the will. 09:57.600 --> 10:04.600 So we just want to rely on already existing manifest files. 10:04.600 --> 10:08.600 Because the build system is based on RPM. 10:08.600 --> 10:10.600 The generate metadata. 10:10.600 --> 10:16.600 Images also have some manifest files describing the image. 10:16.600 --> 10:26.600 So we want to just convert or take the information here and convert to SBDX or second X format. 10:26.600 --> 10:37.600 So one of the challenges is that all code in this build by this factory is not always based on C or C++ code. 10:37.600 --> 10:44.600 But also on other languages that have own command line. 10:44.600 --> 10:47.600 Calgo, SBOM for rest. 10:47.600 --> 10:52.600 S-I-Y-F-R for go and turn. 10:52.600 --> 11:00.600 So finally, we need to adjust some specific, 11:00.600 --> 11:03.600 you need to do some specific adjustment. 11:03.600 --> 11:10.600 For example, an example about federal license, SBDX ID. 11:10.600 --> 11:15.600 That are currently migrate to a new model. 11:15.600 --> 11:20.600 So we need to address such, or adjust such support. 11:21.600 --> 11:23.600 Challenging about Vex. 11:23.600 --> 11:28.600 As we rely on redat. 11:28.600 --> 11:29.600 Baseless. 11:29.600 --> 11:33.600 We can rely on redat database, CV. 11:33.600 --> 11:38.600 But we added some patches to support on BDX, 11:38.600 --> 11:42.600 or patches to fix some bugs. 11:42.600 --> 11:47.600 So as we recompile, we need to do some adjustment. 11:47.600 --> 11:56.600 So we need to have our own database to match, 11:56.600 --> 12:01.600 in fact, the package name on what we call NVR. 12:01.600 --> 12:03.600 Name version release. 12:03.600 --> 12:11.600 Coming from redat with the new one that we have on the output of the build. 12:11.600 --> 12:15.600 So SBOM generation is good enough, 12:15.600 --> 12:19.600 but it's not enough. 12:19.600 --> 12:22.600 You need to add some other technology, 12:22.600 --> 12:26.600 like some salsa, salsa where you, 12:26.600 --> 12:29.600 that is a framework, 12:29.600 --> 12:35.600 specially designed to ensure your integrity of your artifact. 12:35.600 --> 12:40.600 So I let you read the afters this spot. 12:40.600 --> 12:43.600 And you need also to add in total. 12:43.600 --> 12:45.600 So salsa, please in total, 12:45.600 --> 12:50.600 we'll allow you to create 12:50.600 --> 12:54.600 what we call provenance attestation. 12:54.600 --> 13:01.600 And you will build your attestation 13:01.600 --> 13:07.600 and integrate relevant data. 13:07.600 --> 13:09.600 So for example, for us, 13:09.600 --> 13:13.600 that's mean we use a field like external parameters 13:13.600 --> 13:19.600 to identify the exact factory, exact project on all useful 13:19.600 --> 13:24.600 on data that are linked to the build. 13:24.600 --> 13:29.600 So the two community maintained build type, 13:29.600 --> 13:32.600 are currently available. 13:32.600 --> 13:35.600 That is a GitHub action workflow, 13:35.600 --> 13:38.600 and trigger the Google Cloud build. 13:38.600 --> 13:42.600 That is not what we really want to use. 13:42.600 --> 13:44.600 Okay, so. 13:44.600 --> 13:47.600 Yeah, I will add it. 13:47.600 --> 13:51.600 So here is an example of the attestation you have, 13:51.600 --> 13:56.600 and you need to sign it to obtain a signature 13:56.600 --> 14:01.600 that is directly uploaded to 6th or so. 14:01.600 --> 14:04.600 So the tool used to do that is cosine. 14:04.600 --> 14:12.600 And then when you have your artifact on your sine signature, 14:12.600 --> 14:15.600 you can use tools like salsa, 14:15.600 --> 14:19.600 very, very far your cosine to check the verification. 14:19.600 --> 14:24.600 So check them on to check is here. 14:24.600 --> 14:27.600 So what are the challenges? 14:28.600 --> 14:31.600 Okay, the challenge is just one word. 14:31.600 --> 14:36.600 The challenge is that the problem is that many example 14:36.600 --> 14:40.600 on the existing part only rely on GitHub. 14:40.600 --> 14:43.600 And if you don't want to rely on GitHub, 14:43.600 --> 14:45.600 it's really problematic. 14:45.600 --> 14:48.600 And there is also article in part, for example, 14:48.600 --> 14:52.600 that refer explicitly to GitHub. 14:52.600 --> 14:56.600 So that's all that's a summarized. 14:56.600 --> 15:01.600 If you want to test it, you can use community additions 15:01.600 --> 15:05.600 that will include the basic support of Hasbomb, 15:05.600 --> 15:09.600 and we will improve that in the next releases. 15:09.600 --> 15:11.600 Thank you for listening. 15:11.600 --> 15:16.600 Thank you.