WEBVTT 00:00.000 --> 00:10.000 Okay, so I wasn't from the schedule initially, so wherever put the schedule together, 00:10.000 --> 00:15.000 you don't necessarily know that this is, I think, on the echo quite well, the decision 00:15.000 --> 00:18.000 from before, for those of you who are here. 00:18.000 --> 00:20.000 This is going to be about Zepher. 00:20.000 --> 00:24.000 For those who know Zepher, we know Zepher, Zepher Autos. 00:24.000 --> 00:26.000 Okay, I'll say a few words about it. 00:26.000 --> 00:31.000 But essentially, the challenges of doing SBOMs for embedded, what is, 00:31.000 --> 00:37.000 so specific about embedded devices, what are some of the things we do in the Zepher project, 00:37.000 --> 00:42.000 some of the things where we are looking for collaboration opportunities. 00:42.000 --> 00:45.000 Yeah, and I'm Benjamin, I'm a developer advocate for the project. 00:45.000 --> 00:51.000 Among other things, I'm actually a main painter for the tooling we have around SBOMs and SPDX. 00:52.000 --> 00:59.000 And yeah, so Zepher, you might have seen with the archives probably at the booth in building AWS. 00:59.000 --> 01:07.000 Zepher has been around for many years, for 10 years actually, and does an operating system for small embedded devices. 01:07.000 --> 01:17.000 Or not so small, like I mean, it could be all the way from small wearables, bluetooth powered, or bluetooth enabled, hearing its and wearables and whatnot. 01:17.000 --> 01:22.000 Really being industrial machines, like you actually see in the background, it's intentional. 01:22.000 --> 01:28.000 Those wind turbines stay run Zepher as well, or anything in between laptops, et cetera. 01:28.000 --> 01:33.000 I think you can imagine that for all of those, whether they are consumer, industrial devices, 01:33.000 --> 01:38.000 SBOMs are really relevant, ATKM, CRA, that kind of stuff. 01:39.000 --> 01:49.000 Zepher, someone that builds a Zepher-based application at a really, really high level, the stack looks a bit like this. 01:49.000 --> 01:55.000 You have so-called hardware abstraction layers provided by the silicon vendors, the chip vendors. 01:55.000 --> 02:04.000 You have the Zepher kernel itself, and then you keep stacking up, like services, like the networking stack, the USB stack, you get from Zepher. 02:04.000 --> 02:10.000 Application services for building your, like, GUI, your graphical user interfaces, and whatnot. 02:10.000 --> 02:18.000 Third-party stuff that you might be pulling in, and that makes, I mean, it's a stack as in your other stack, I guess. 02:18.000 --> 02:30.000 Except that typically those are, like, really big modules, if you will, like, really big software components from which you only take a really, really small subset, like it's embedded. 02:30.000 --> 02:41.000 So you're only going to use, probably, like, only a very small subset of the Zepher kernel, really small subset of whatever SSL TLS library, et cetera, et cetera. 02:41.000 --> 02:51.000 So your application code is probably, like, really, like, just the tip of the iceberg, and then you're pulling in the articles, the libraries, the hardware abstraction layers, like I mentioned. 02:51.000 --> 03:10.000 Or are you actually pulling all of that? It's really important, like, when you, and again, in the context of CRA, but just in general, it's really important to know all of all those big software components, whatever the bits that you're actually using, so that when there is a CVE, you know whether you should start freaking out or whether you're fine. 03:10.000 --> 03:39.000 And, like, the previous presenter said before, there's this world in, like, JavaScript land and NPM and so on. You build a web application, you're going to pull probably way too many components and modules, but at least, and for better or worse, there is a good chance that whenever there is, like, this big CVE being announced that a component X is vulnerable, you know that you should stop freaking out. 03:39.000 --> 03:45.000 Because you're likely impacted, like, it's part of your, as bomb slash manifest, you're going to be impacted. 03:45.000 --> 03:53.000 For something like Zephyr, where, again, you have those big software components, you're only really using a subsets. 03:53.000 --> 04:08.000 In fact, you might even, like, you think that you're using your pulling in a library X, like the one at the upper right corner over there, except that, like, if you look at the build artifacts, you're not actually using those. 04:08.000 --> 04:18.000 So, CVE X shows up. In the kernel, we have a Zephyr kernel vulnerability. Hey, look at you, you don't actually use that. 04:18.000 --> 04:29.000 And maybe, in some other instances, you might be impacted. So, I mean, it's important to get, yeah, to get tooling that helps you get good visibility on your S-bombs. 04:29.000 --> 04:36.000 And so, the way it works in Zephyr, and there's some of what we do that, again, it goes to the presentation before. 04:36.000 --> 04:44.000 And some of what we do that's effectively, it could be reused by visually any project that uses C-make as the build system. 04:44.000 --> 04:48.000 As any other build system, like, it's, it's a big beast, it's really rich. 04:48.000 --> 04:54.000 And, luckily, there is this thing in C-make, for those who don't know, it's actually pretty well hidden feature. 04:55.000 --> 05:07.000 In, like, the name is really bad, C-make file API. You can effectively, like, prior to running your build, you can put a bunch of files in your build folder to tell C-make. 05:07.000 --> 05:13.000 Hey, I would like to spy on some of the steps that you will be going through. 05:13.000 --> 05:22.000 And please, then, some JSON files that I will be later able to query to get, like, really structured information about the build. 05:22.000 --> 05:31.000 Things like the dependency video between your different targets, information regarding the tool change that you're pulling, compiles, flags, et cetera. 05:31.000 --> 05:36.000 It's effectively what you need, and want to capture us out of your S-bombs. 05:36.000 --> 05:54.000 You have tooling that's part of the, the, the zephyr process, zephyr build process. You can enable those fancy C-make features so that you get the dump of the interesting build related metadata, which then we have some additional tooling for, 05:54.000 --> 06:03.000 to bring exactly like the previous prisons or set as well, extract all those like licenses, copyright headers, et cetera, to also capture that information. 06:03.000 --> 06:11.000 And of course, that would be only on the files that are relevant, out of the, like, thousands and thousands of files in the zephyr kernel. 06:11.000 --> 06:15.000 Just fully only, I don't know, like, a couple of dozens that you're pulling. 06:15.000 --> 06:33.000 We would be looking at the copyright licenses, generate the shas, the fingerprints, and then there is a pass that's kind of like the, the one that's zephyr specific, where we want to create S-bombs that really reflect the reality of what a zephyr product is. 06:33.000 --> 06:40.000 So isolate things that are effectively the sources of the zephyr kernel, the sources of your application, the sources of the various modules, 06:40.000 --> 06:51.000 that we're pulling, because in zephyr, we have this notion of modules, like, you can really, really well describe, like, modules that come from various git reports, et cetera. 06:51.000 --> 07:02.000 And so we add this metadata as we capture the S-bombs, the modules, just a small, small detail, through the, what the modules are in zephyr. 07:02.000 --> 07:13.000 In zephyr, effectively, we, we have mirrors of many third-party projects, like embed TLS and, like, crypto libraries, et cetera. 07:13.000 --> 07:20.000 We don't have any specific necessarily have any specific patches on those, except that they leave in our own GitHub repos. 07:20.000 --> 07:31.000 So we kind of need the information, what is the upstream for those, so that, again, a previous presentation, things like the CPE, the pearls, like the identifiers, that tail A. 07:31.000 --> 07:35.000 This GitHub.com slash zephyr slash embed TLS. 07:35.000 --> 07:41.000 Effectively, this is GitHub.com slash arm slash embed TLS version XYZ. 07:41.000 --> 07:50.000 And so our zephyr modules, our zephyr mirrors of things like embed TLS, they have this additional metadata where we capture. 07:50.000 --> 07:56.000 This is embed TLS coming from arm, inversion X, so as of today, this would be three dot six dot five. 07:56.000 --> 08:02.000 So that's what we then are able to put in the s-bombs that we generate. 08:02.000 --> 08:05.000 And that's what, for those, we don't know. 08:05.000 --> 08:13.000 I mean, there's plenty of tools out there for doing, for analyzing your s-bombs and looking at the, the public databases out there. 08:13.000 --> 08:22.000 If I were to run this command against the, the very s-bomb that you showed, you, you, you, you, you, you, you, so, sorry, just before. 08:22.000 --> 08:33.000 The only thing I did is that I cheated, I put, I took, I put an older version of embed TLS, just for the sake of showing you that if I were to have an embed TLS, 08:33.000 --> 08:43.000 three dot six dot two instead of the latest, a three dot six dot X, then CDD in tool would be immediately telling me, 08:43.000 --> 08:50.000 you have a bunch of high and critical and unknown vulnerabilities. 08:50.000 --> 08:58.000 So that's the kind of information we capture, so it's kind of the first specific in a sense, though, this notion of modules, 08:58.000 --> 09:03.000 but we make it a first class citizen as part of the s-bombs generation. 09:03.000 --> 09:09.000 And then, of course, I mean, I should have mentioned the tooling we have, and that we've had for four years, I think, 09:09.000 --> 09:11.000 there's actually an interesting talk. 09:11.000 --> 09:19.000 I'll post them recording and talk available from the person, Steve Winslow, we introduced this at the time in 2021. 09:19.000 --> 09:30.000 Espdx2.2 initially to that three support got added, and then Espdx3 is available now, with interesting things that could make actually our lives easier, 09:30.000 --> 09:40.000 not only make the s-bombs richer in terms of, I think, first class citizens in terms of the profiles for really describing your build artifacts really well for really, 09:40.000 --> 09:49.000 things that could be relevant as well describing things like A, what are the AI models, what's the data that I use to train my embedded ML models, etc. 09:49.000 --> 09:54.000 But making more importantly, in terms of making it easier for us to have even better tooling, 09:54.000 --> 10:06.000 the fact that Espdx3 really approaches the model in the form of a graph as opposed to Espdx2, which is very much like document-driven. 10:06.000 --> 10:12.000 So whenever we need to add new features in the Espdx2 link in Zefer, 10:12.000 --> 10:17.000 given that there's this dependency towards Espdx2, it's always like A. 10:17.000 --> 10:24.000 I want to add more information regarding compile flags, etc., tool change, but I need to think about how it's going to be serialized in my various documents, 10:24.000 --> 10:27.000 because that's kind of part of the tooling we have. 10:27.000 --> 10:34.000 But I've been turning some time playing with Espdx3 to, well, yeah, I mean, try and embrace Espdx3, 10:34.000 --> 10:38.000 and this is where Kage will be going, because you haven't seen that. 10:38.000 --> 10:46.000 But yes, so essentially if I were to look, and I want to use the demo also to illustrate what I was saying about the tip of the iceberg, 10:46.000 --> 10:55.000 sort of thing, I'm going to build a Zefer application which is oops, I should, with that, I guess. 10:55.000 --> 11:04.000 You can see that blinky, so in embedded world or in embedded land, blinky would be the kind of like the hell of world of embedded, 11:04.000 --> 11:14.000 you want to blink an LED, locally in Zefer, it's like, I don't know, like 20 lines of code, but we are pulling in the Zefer kernel, 11:14.000 --> 11:19.000 we are pulling in some GPIO APIs to interact with LEDs. 11:20.000 --> 11:31.000 But yeah, I've built this app already, and then the only thing I need to do is tell West our kind of like meta tool, 11:31.000 --> 11:41.000 like the companion to our build system, I'm going to tell West, based on the build that I already made, 11:41.000 --> 11:48.000 and based on what C-make and the C-make file API thingy as captured in the form of a bunch of JSON file, 11:48.000 --> 11:56.000 please create S-bombs for me, and again, in the context of Zefer, the different S-bombs that we want to capture, 11:56.000 --> 12:03.000 really reflect the sort of like the topology of the application, there is, and you can see this right here, 12:03.000 --> 12:11.000 there is an application S-bombs to my main file, like it's really going to be one file and maybe a bunch of informations around licenses and so on, 12:12.000 --> 12:19.000 and then there's one for the sources of Zefer that I'm pulling, and it's one for the build artifacts, et cetera. 12:19.000 --> 12:26.000 And so we were to look at this more visually, what I really like also about S-bombs, 12:26.000 --> 12:33.000 basically the context of embedded in the context of a big beast, like Zefer, in a way, 12:33.000 --> 12:37.000 it really allows you to understand also what's going on under the hood. 12:37.000 --> 12:45.000 I mean, it's really important for like C-b, like for being, for doing like you're improving your security posture, 12:45.000 --> 12:58.000 but it also allows you to visualize what's going on, and how you got to that binary and that firmware that you ended up putting in your embedded product. 12:58.000 --> 13:04.000 So let's start with, so those are the files that got generated, like I'm not cheating, right? They are from right now. 13:05.000 --> 13:08.000 The application, let's start with that. 13:08.000 --> 13:12.000 There's not a lot, like I said, I mean, there's one file. 13:12.000 --> 13:17.000 Yeah, okay, I mean, I have main, it's part of my application sources. 13:17.000 --> 13:23.000 I have captured, I mean, there's a header file that you maybe saw before, that says that it's a 72. 13:23.000 --> 13:28.000 The copyright header should be showing somewhere as well, but there's not much. 13:28.000 --> 13:40.000 If I were to add the build artifacts to the mix, so it's a different JSON-LD document, but it's manipulating the same entities, 13:40.000 --> 13:44.000 so it will start extending my graph with even more information. 13:44.000 --> 13:46.000 Now I see interesting stuff. 13:46.000 --> 13:57.000 I see, and I can easily visualize things like, let's see, my main, yeah, the main Zefer binary L file is right here. 13:57.000 --> 14:10.000 And I have a ton of information captured, like it's being composed of various static libraries, probably like the USB driver is there, the GPI driver is there. 14:10.000 --> 14:20.000 Let's see, the timer driver is there, so like the timer library, it pulled in only a couple C files, the purple ones, like cortex and whatever. 14:20.000 --> 14:33.000 It was compiled with those compiled flags, like I can really be like, okay, someone told me that in Zefer using this particular config option is actually a vulnerability issue. 14:33.000 --> 14:40.000 I can have insights into that, and then I can be like, oh, I ship that into products, I might have an issue, right? 14:40.000 --> 14:56.000 And so those are the build artifacts, and I could also add, I haven't yet, the Zefer sources, and then I get the full picture, like of how I got to where I got in terms of those are all the Zefer sources that I'm using. 14:56.000 --> 15:09.000 So it is small, I know, but like, out of all the, again, tens of thousands of files in source files in the Zefer kernel, I'm only using those, like I'm pulling, 15:09.000 --> 15:30.000 I'm pulling, so real blah, blah, blah, blah, blah. And so yeah, and so this is the speed X3, there's a few challenges to make it, like, fully, like, it's really rich, but I, a few things that I noticed is that maybe in terms of like capturing configuration data. 15:30.000 --> 15:59.000 It's not necessarily clear to me, at least, like, what should go in the S-Bomb, like, should we, like, all the configuration files that are part of the Zefer application, what's the right way, if, if there is such a way to put them in the, in the S-Bomb right now, it feels like it's more geared towards potentially putting URIs to GitHub workflows, like online artifacts, sort of configurations whereas like for embedded, it's not necessarily the case, people might have used, like, 15:59.000 --> 16:23.000 systems that are, I mean, not online, tooling wise, also, of course, tools and agents are first class citizens in S-BDX, but for us, I mean, what goes in terms of, what goes in, in the compile flags of the, and the various flags that we use to compile, they are really important, because they can cause the vulnerability, et cetera. 16:23.000 --> 16:33.000 It's not clear how to capture them in a structured way, but, I mean, as you saw, I still managed to capture those in free form comments and so on. 16:33.000 --> 16:46.000 And yeah, that's what I had, maybe time for questions, but, if you make file for those, we use the S-BDX system, again, it's a hidden feature, sort of, but really, really powerful. 16:46.000 --> 16:57.000 So, S-BDX 3, all the things you saw, I need to turn them into a series of full requests, I guess, so that's ever actually gets the S-BDX 3 support. 16:57.000 --> 17:08.000 And one thing that I have at the back of my head as well is also using this tooling to help people realize, when, intentionally or not, they have diverged from upstream. 17:08.000 --> 17:28.000 And so, like, we ship LTS versions, every, every few years, people build their own stuff on top of that. They might patch some, as ever, kernel features, et cetera, helping them realize, sort of, like, the diff, and, again, so that they know when the CV applies or not to what they do. 17:28.000 --> 17:33.000 And that's what I had, and I didn't even, yeah, so, maybe a minute for questions. 17:33.000 --> 17:48.000 Thank you very much, and thank you for making on time. We have time for one question. 17:48.000 --> 18:14.000 Question is, this is, a lot of it is, or all of it is, see, make specific. We have support for other build systems. We don't, like, refer really, the build system is, see, make based, we need, we only support and need that. 18:14.000 --> 18:21.000 So, yeah, I mean, some of the Python scripts we have for extracting licenses, et cetera, might be useful to you. 18:21.000 --> 18:37.000 It was showing up in a slide like extracting copyright information license, the reuse project as really good Python libraries for that. So, that's something we use, but it's really like just file profile sort of thing.