WEBVTT 00:00.000 --> 00:17.280 Hi everyone, I'm waiting for everyone to take a good seat, so this is going to be about 00:17.280 --> 00:23.720 embedded and not embedded as well, embedded software, but we have. 00:23.720 --> 00:28.160 So how embedded looks like, it can look differently. 00:28.160 --> 00:38.120 There are many shapes, many colors from your phone to your hit-exystem or your car, your 00:38.120 --> 00:46.720 weather station, and what is interesting about embedded products that they usually have multiple 00:46.720 --> 00:56.360 pieces, and we have that multiple pieces, partially in this year way, with the remote processing, 00:56.360 --> 00:59.240 but of course not everything. 00:59.240 --> 01:09.040 So to simplify, you typically have the device itself, frequently running a hidden processor, 01:09.040 --> 01:14.600 or not many high end, but still processor running Linux. 01:14.600 --> 01:25.280 You have a microcontroller, for example, to control power, or to control additional elements, 01:25.280 --> 01:31.920 you may have a GPU in an embedded system, and you may have things that Bluetooth Wi-Fi, 01:31.920 --> 01:37.840 FWG5G, that are also having their own processors running the big software stock and so on 01:37.840 --> 01:38.840 and so on. 01:38.840 --> 01:48.280 So you may have a dozen or more processors just on the device side, then you may have more 01:48.520 --> 01:56.000 frequency in the server side, so the famous remote processing, for different things, 01:56.000 --> 02:01.720 for data integration, for remote control, and so on and so on, and quite frequently you 02:01.720 --> 02:09.560 also have a more up-on-the-phone, either talking directly to the device or talking to the remote 02:09.600 --> 02:10.560 service. 02:10.560 --> 02:18.720 So let's create an S-bomb, for an example of an embedded product. 02:18.720 --> 02:26.480 So one S-bomb that's going to be tricky, because there will be multiple files at least. 02:26.480 --> 02:30.520 And the trolling is already there, people are telling me we can generate S-bomb for 02:30.520 --> 02:35.480 basically everything, so we are mature, we are one year and a half from the series, so 02:35.560 --> 02:39.160 everything should go fine. 02:39.160 --> 02:45.400 And let's try to follow the CRA recommendations, generate all those S-bombs, put them 02:45.400 --> 02:51.800 into a vulnerability management tool, and let's manage vulnerabilities in our embedded product 02:51.800 --> 02:58.040 as the CRA recommends us to do what could go wrong. 02:58.040 --> 03:09.080 The first, why a little bit about me, PhD in telecommunications, I'm mostly in embedded, 03:09.080 --> 03:17.160 as you can guess, 20s plus an open source, contributed to various, to everything from the 03:17.160 --> 03:27.560 Linux Canada to the KD environment, those days typically in the, I run the Yachter project, 03:27.560 --> 03:36.120 and security teaching, and contributing to the series standardization of those days. 03:36.120 --> 03:47.240 So in our case, this is a simplified version of a weather station scenario, what building 03:47.240 --> 03:57.400 weather station product had to simplify the configuration, because it was too complicated 03:57.400 --> 04:07.240 to explain, but what do we have? We have the base station, which is Linux-based system built 04:07.240 --> 04:16.840 using the project, then we have sensors running Z-Fi, and I have the server application running, 04:18.440 --> 04:26.120 running a custom Python application, that is expected to receive the sensor data and do the processing 04:26.120 --> 04:32.920 dashboards, and set. That doesn't look bad, complicated, and I really, really, really 04:32.920 --> 04:44.760 simplified all external portfolios. So, what do we have now on the SBO level, the Yachter project 04:45.720 --> 04:57.000 with Winlata, Generating SPD X3. The sensors running Z-Fi, so it's SPD X2.3, in fact, 04:57.000 --> 05:06.120 and our server application Python native tooling, I went on cyclone to tell you in a moment, 05:07.320 --> 05:13.400 and for the choice of what I'm going to use for vulnerability management, go for dependency track, 05:14.120 --> 05:20.120 and here already I was asking for travel, because I have a part of the software stack 05:21.160 --> 05:25.800 based on Linux Foundation, and I go for an OSP tool, asking for travel. 05:29.000 --> 05:35.560 On the Yachter project site, the Yachter project is a way to build a Linux distribution 05:35.560 --> 05:43.000 from a weathered system, a Linux Foundation project you can extend it as you want, and every package 05:43.000 --> 05:48.280 that you build is described in a recipe, and the whole tooling can generate a SBO no matter how 05:48.280 --> 05:56.120 you configure your fan. What is interesting is that you get a SBOm generated at the build level 05:56.120 --> 06:07.000 with all the bit information that you have, so it can get gigantic, and builds everything, 06:07.640 --> 06:13.640 the bootloader, the Linux kind, and so. So there's no direct thing to any existing 06:13.640 --> 06:20.760 standard of the new distribution. On the SBOm site, it's generating SPD X3. By default, 06:22.440 --> 06:31.000 you can also have classes to generate SPD X2.2. There are third-party cyclone 06:31.320 --> 06:39.640 the X patches that are flowing around that are unofficial. On the SBOm site, so what is 06:39.640 --> 06:46.280 the FFS? The FFS is a real-time operating system, also an installation project, and it supports 06:46.280 --> 06:56.440 all kinds of small microcontrollers that you want to write a small sensor on, and there are multiple 06:56.440 --> 07:05.400 examples if you want to start running. Could have used any other methods for this XSS. So ZF is 07:05.400 --> 07:16.840 generating SPD X2.3, that can be generated by its build tool. It is in the official documentation, 07:16.840 --> 07:22.920 but you need to dig a little bit how to generate it, and there's a talk from from Bajana, 07:23.080 --> 07:27.960 describing how to do. There's no second-dakes support I'm aware of. 07:29.880 --> 07:37.880 And that's how you generate the SBOm from with the west build system. So you need to 07:37.880 --> 07:44.520 fill a few options to make it running, and then you get it in build SPD X2, you get four 07:44.520 --> 07:56.760 files that contain various types of SBOm. Okay, on my Linux Python applications, 07:56.760 --> 08:06.600 so typical Python code with rest API, the dependencies in the requirements point takes 08:07.400 --> 08:16.280 the SD. So I haven't tried generating SPD X4. This test wanted to go with cyclone, 08:16.280 --> 08:25.400 why with cyclone they expire. Otherwise, but this is pretty easy to do. I install and start 08:25.720 --> 08:33.000 with PIP, and then fill the requirements and generate an SBOm. And then I had the 08:34.760 --> 08:44.040 reflection to have a look into that SBOm. And I saw that it's only containing the exact 08:45.640 --> 08:53.000 first level dependencies that were there in the requirements point to XT. So yeah, okay, so 08:53.720 --> 09:01.000 let's generate better dependencies here. I went with PIP 3 to generate more complete 09:01.000 --> 09:07.960 dependencies, and then regenerate the whole SBOm, and that looked where well, well, well better. 09:10.120 --> 09:20.200 Okay, now a dependency truck deployed as a container, no much to say, it deployed as a container, 09:20.360 --> 09:29.800 it was working. Now, let's go, let's import let's import all my SBOm's to 09:29.800 --> 09:41.000 depend, see truck, and it was like that. I probably saw half of the error messages that they have. 09:41.960 --> 09:55.160 So what happened? So the second day from my Python service that imported. Okay, same ecosystem, 09:55.160 --> 10:05.640 okay, and now for SPD X different types of stories. So the 3-0 from from the Yachter project 10:05.720 --> 10:14.280 has written in dependency truck documentation, not to put it, don't even try. But Zephyr generates 10:15.160 --> 10:21.240 SPD X 2.3. So it should have worked because the documentation says it should have. 10:23.640 --> 10:35.000 And then realized that Zephyr generates the tag value format of the SPD X 2.3 that I honestly, 10:35.080 --> 10:44.360 I didn't expect I'm going to see it anyway. So, okay, so let's convert the tag value to something else. 10:45.960 --> 10:53.320 And I tried to convert it to the JSON and to the XML and not, didn't work neither, one important. 10:54.520 --> 11:04.760 There were simple problems, but to be to say it in a binary way, the important test was 11:05.480 --> 11:16.360 to say it. So what I decided to do, so let's try to convert the SPD X 2.3 of Zephyr to cyclone, 11:17.720 --> 11:27.160 using Swift in this case because I have Swift in start for other things. So I did convert the SPD X 2 to 11:27.160 --> 11:37.480 cyclone with Swift and that did import. And now on the SPD X 3, what I'm going to do? I tried, 11:39.240 --> 11:46.680 I didn't want to write a conversion to myself. I think they are already too many. So let's try to 11:46.680 --> 11:54.440 find something. I didn't find anything that could convert SPD X 3 to something. Okay, so 11:57.240 --> 12:04.760 what I did, I went back to my vector project configuration and changed the generated SPD X 12:04.760 --> 12:14.520 X 2 to 2.2. Okay, and now the SPD X 2.3 in the vector project, it has a specific format with an 12:14.520 --> 12:20.200 index file and hundreds of files around the place. Of course, no conversion to support it. 12:21.160 --> 12:31.240 It's illegal format, but it's not, nobody supports it. So what I did is I wrote a follow-up to convert 12:31.240 --> 12:41.560 all of the SPD X 5 to cyclone and then then, and then, and then match the, match the 12:41.560 --> 12:53.400 cyclone files together. Okay, and then I, after all that, I managed to import it all from all 12:53.400 --> 13:01.160 applications to the battle track. And now let's start the vulnerability analysis. And that's the 13:01.160 --> 13:09.880 result of my vulnerability analysis. That gives one vulnerability. How does it look for that kind 13:09.960 --> 13:19.320 of, of a, of a software stack? Something's wrong, right? Too good to be true. But if you, 13:19.720 --> 13:24.600 if you had your manager probably, some people may be tempted to show to the managers and say, 13:26.440 --> 13:35.000 it's all fine. Now, it's not all fine. So, so I had, I had a look about, into what happened, 13:35.000 --> 13:45.720 actually. So, the details were absolutely not equal for all of those S bombs. So, on the Python 13:45.720 --> 13:52.440 application side, we have already seen that the requirements for takes to have you, how you fill 13:52.440 --> 14:00.040 it, it really matters. On the other side, on the vector project. So, at the conversion time, 14:00.040 --> 14:09.400 we've lost all the updates of package names. For example, the Linux kernel in the, in the, 14:09.400 --> 14:18.280 that built a hat, it's called Linux Yachter. So, dependency track did then realize that this Linux 14:18.280 --> 14:24.360 kernel. So, I basically had had zero vulnerabilities in the Linux kernel, even if the kernel was 14:24.440 --> 14:32.440 like a moment of thought. And that was all the place for all the annotations and all the 14:33.560 --> 14:39.400 additional information that the vector project gives in the S bomb. So, basically, 14:41.240 --> 14:47.480 the result doesn't think much sense. And there were missing version numbers that were lost 14:47.560 --> 14:55.640 in transition. Also, especially on the SFSites, I saw that the original SFS bomb had quite 14:55.640 --> 15:05.560 many version numbers as coming hashes. And unfortunately, that isn't handled at the dependency 15:05.560 --> 15:13.880 track level, because you would need to look into the git trees of all those projects and figure 15:13.960 --> 15:30.200 out where you are, so that doesn't work. So, this work to do. So, what are my takeaways? 15:31.960 --> 15:41.720 If you use tools from one ecosystem, it usually works. Mollies. But we have multiple 15:41.720 --> 15:49.240 S-moformas and also multiple binary formats, probably too many. I didn't expect that 15:49.240 --> 15:55.320 that values to be seen. And the conversion is complicated. You need various tools to make 15:56.600 --> 16:05.240 to make different transitions to get true. And if you have ecosystem specific, not totally 16:05.240 --> 16:11.720 mainstream options used in your S-bomb, they are just lost in transition or they are not supported 16:11.720 --> 16:17.640 by tools. So, they are the enderogenophile, but if nobody knows they are there, they are not just. 16:21.720 --> 16:27.640 What we need is cross-checking between vulnerability tools for such cases, 16:27.960 --> 16:38.200 because S-bombs looked valid. They were close. They are quite good when very faring for 16:38.840 --> 16:46.200 existence of fields, but actually they were not accurate after all the conversion at all, 16:46.200 --> 16:56.280 and not totally used for adiant. And especially to check all those requirements, to check all that, 16:57.640 --> 17:02.600 accuracy of S-bombs, if you have hundreds of packages, you probably do not want to do it 17:02.600 --> 17:09.960 manually. So, needs tooling. And definitely what is absolutely needed is more integration and testing 17:09.960 --> 17:19.400 between tools, because as we can show, that just doesn't work. And real embedded products are 17:19.480 --> 17:28.200 way more complex than that. I did it at one of the popular S-bombs format code C-S-V. 17:38.040 --> 17:39.640 So, do you have questions? 17:40.600 --> 17:47.400 Yeah. As a side note, we are using a fancy-track tool. And so, if you have a using live-resolution, 17:47.400 --> 17:53.400 for example, if you want to get a name matching, because depends on the moment, it doesn't 17:53.400 --> 17:59.640 respect source, source code names, name hints in the course, neither on the OSB side note, 17:59.640 --> 18:06.520 nor anything supplied, so it doesn't do a match. If you then include virtual dependencies on your own, 18:06.840 --> 18:15.640 just to have the right name in, you get much, many false positives on operator, on deviant, 18:15.640 --> 18:22.200 on Google to whatever, just because they don't know really about release tracks, 18:22.200 --> 18:27.640 and put everything in the section unless you're using live-resolution unstable. You're always, 18:27.640 --> 18:35.080 for the coding, I'm trying to summarize. Yes. So, audience member shared an experience using 18:35.080 --> 18:41.960 dependent track on libraries, there are problems with dependencies, there are also issues. 18:41.960 --> 18:46.520 And if they add virtual dependencies, they run into other problems. 18:48.520 --> 18:53.320 With false positives this time, on standard operating system. 18:53.320 --> 18:57.320 They're really victim-serious. And they are searching for other victims of those problems. 18:57.320 --> 19:03.080 Yeah. So, one of the things this conversion is not there. So, what I recommend people to do 19:03.080 --> 19:09.320 is to generate natively using a true format and speedy exercise on the edge, not to the 19:09.320 --> 19:15.560 conversion. And okay, then you've got multiple response to manage, but actually that seems to be 19:15.560 --> 19:20.200 better than the conversion process of the conversion process is lossy, not lossless, which I think is 19:20.200 --> 19:25.160 my drawing, what you're finding. But when you've got things like problems that only support, 19:25.160 --> 19:28.760 generated all these support, native one format, then you've got problems. 19:29.160 --> 19:36.520 Yeah. So, we have a few more, I remember the question to generate a natively in the 19:36.520 --> 19:43.560 correct format. From my experience, projects are really reluctant to generate multiple formats 19:43.560 --> 19:48.440 of S-bombs. They want to stick to generating one, assuming that people will manage to call 19:48.440 --> 19:52.760 them about things if they want to, but you have seen that doesn't work. 19:53.240 --> 19:58.840 And actually, say, generate using two different tools as well. Yeah. Yeah. The other side is 19:58.840 --> 20:05.240 the deep level of detail available in the different S-bombs you generated was quite different. 20:05.960 --> 20:10.680 The development, the cycle of the experience was only really the moment the top level was 20:10.680 --> 20:15.880 said. The ones that you were getting out of go and go, and, etc, were very deep, held down 20:15.880 --> 20:21.960 the source by a level, which the dependency track would not even understand it. Okay. So, 20:21.960 --> 20:27.240 I would sort of question, are you really getting the numbers out? Was it more like putting those 20:27.240 --> 20:35.400 in and getting the ones down? Yeah. I know the remark, I would say, a comment about the detail level 20:36.360 --> 20:42.200 that we, with all those tools, we are getting completely different details level. So, 20:42.200 --> 20:48.600 add the S-bombs and add the vector project level, we get down to the S-bombs and on my 20:48.600 --> 20:56.920 Python app, we are at the package level. So, definitely it doesn't contain the same granularity 20:56.920 --> 21:02.760 of information. And that's also going back to the previous presentation, 21:03.080 --> 21:09.960 type of S-bombs and what it contains probably matters. More questions. 21:10.600 --> 21:34.600 So, the question is, what they suggest to get to get to get that better interoperability? 21:34.600 --> 21:43.480 I think that this talk is a starting discussion. People who know me know that I post a lot of 21:43.480 --> 21:50.680 stuff everywhere. So, if you are interested in discussing and doing other experiments, 21:50.680 --> 21:57.160 posting results and shaming people for stuff that doesn't work, I'm all for doing that. 22:04.600 --> 22:15.480 Did you play with those that are sitting up on the S-bombs between those format that work? 22:21.000 --> 22:22.120 Any other questions? 22:34.680 --> 22:40.360 They have a whole round of trees and proponents of the development manner of proper 22:42.360 --> 22:49.160 pre-垊ural pathologies. So, we are different into what we work for. 22:51.320 --> 22:52.840 Could you take from theress on a second up on deducting these 22:52.840 --> 22:57.800 templates in the next 3 or is it see how different they are or how? 22:57.800 --> 23:04.800 I think we should have been recommending the whole, the whole because the place is not there, 23:04.800 --> 23:09.800 the place is right, okay. 23:09.800 --> 23:13.800 Questions? 23:13.800 --> 23:18.800 Let's all thank you.