Okay, so I wasn't from the schedule initially, so wherever put the schedule together,
you don't necessarily know that this is, I think, on the echo quite well, the decision
from before, for those of you who are here.
This is going to be about Zepher.
For those who know Zepher, we know Zepher, Zepher Autos.
Okay, I'll say a few words about it.
But essentially, the challenges of doing SBOMs for embedded, what is,
so specific about embedded devices, what are some of the things we do in the Zepher project,
some of the things where we are looking for collaboration opportunities.
Yeah, and I'm Benjamin, I'm a developer advocate for the project.
Among other things, I'm actually a main painter for the tooling we have around SBOMs and SPDX.
And yeah, so Zepher, you might have seen with the archives probably at the booth in building AWS.
Zepher has been around for many years, for 10 years actually, and does an operating system for small embedded devices.
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.
Really being industrial machines, like you actually see in the background, it's intentional.
Those wind turbines stay run Zepher as well, or anything in between laptops, et cetera.
I think you can imagine that for all of those, whether they are consumer, industrial devices,
SBOMs are really relevant, ATKM, CRA, that kind of stuff.
Zepher, someone that builds a Zepher-based application at a really, really high level, the stack looks a bit like this.
You have so-called hardware abstraction layers provided by the silicon vendors, the chip vendors.
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.
Application services for building your, like, GUI, your graphical user interfaces, and whatnot.
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.
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.
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.
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.
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.
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.
Because you're likely impacted, like, it's part of your, as bomb slash manifest, you're going to be impacted.
For something like Zephyr, where, again, you have those big software components, you're only really using a subsets.
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.
So, CVE X shows up. In the kernel, we have a Zephyr kernel vulnerability. Hey, look at you, you don't actually use that.
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.
And so, the way it works in Zephyr, and there's some of what we do that, again, it goes to the presentation before.
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.
As any other build system, like, it's, it's a big beast, it's really rich.
And, luckily, there is this thing in C-make, for those who don't know, it's actually pretty well hidden feature.
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.
Hey, I would like to spy on some of the steps that you will be going through.
And please, then, some JSON files that I will be later able to query to get, like, really structured information about the build.
Things like the dependency video between your different targets, information regarding the tool change that you're pulling, compiles, flags, et cetera.
It's effectively what you need, and want to capture us out of your S-bombs.
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,
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.
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.
Just fully only, I don't know, like, a couple of dozens that you're pulling.
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.
So isolate things that are effectively the sources of the zephyr kernel, the sources of your application, the sources of the various modules,
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.
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.
In zephyr, effectively, we, we have mirrors of many third-party projects, like embed TLS and, like, crypto libraries, et cetera.
We don't have any specific necessarily have any specific patches on those, except that they leave in our own GitHub repos.
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.
This GitHub.com slash zephyr slash embed TLS.
Effectively, this is GitHub.com slash arm slash embed TLS version XYZ.
And so our zephyr modules, our zephyr mirrors of things like embed TLS, they have this additional metadata where we capture.
This is embed TLS coming from arm, inversion X, so as of today, this would be three dot six dot five.
So that's what we then are able to put in the s-bombs that we generate.
And that's what, for those, we don't know.
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.
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.
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,
three dot six dot two instead of the latest, a three dot six dot X, then CDD in tool would be immediately telling me,
you have a bunch of high and critical and unknown vulnerabilities.
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,
but we make it a first class citizen as part of the s-bombs generation.
And then, of course, I mean, I should have mentioned the tooling we have, and that we've had for four years, I think,
there's actually an interesting talk.
I'll post them recording and talk available from the person, Steve Winslow, we introduced this at the time in 2021.
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,
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,
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.
But making more importantly, in terms of making it easier for us to have even better tooling,
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.
So whenever we need to add new features in the Espdx2 link in Zefer,
given that there's this dependency towards Espdx2, it's always like A.
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,
because that's kind of part of the tooling we have.
But I've been turning some time playing with Espdx3 to, well, yeah, I mean, try and embrace Espdx3,
and this is where Kage will be going, because you haven't seen that.
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,
sort of thing, I'm going to build a Zefer application which is oops, I should, with that, I guess.
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,
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,
we are pulling in some GPIO APIs to interact with LEDs.
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,
like the companion to our build system, I'm going to tell West, based on the build that I already made,
and based on what C-make and the C-make file API thingy as captured in the form of a bunch of JSON file,
please create S-bombs for me, and again, in the context of Zefer, the different S-bombs that we want to capture,
really reflect the sort of like the topology of the application, there is, and you can see this right here,
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,
and then there's one for the sources of Zefer that I'm pulling, and it's one for the build artifacts, et cetera.
And so we were to look at this more visually, what I really like also about S-bombs,
basically the context of embedded in the context of a big beast, like Zefer, in a way,
it really allows you to understand also what's going on under the hood.
I mean, it's really important for like C-b, like for being, for doing like you're improving your security posture,
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.
So let's start with, so those are the files that got generated, like I'm not cheating, right? They are from right now.
The application, let's start with that.
There's not a lot, like I said, I mean, there's one file.
Yeah, okay, I mean, I have main, it's part of my application sources.
I have captured, I mean, there's a header file that you maybe saw before, that says that it's a 72.
The copyright header should be showing somewhere as well, but there's not much.
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,
so it will start extending my graph with even more information.
Now I see interesting stuff.
I see, and I can easily visualize things like, let's see, my main, yeah, the main Zefer binary L file is right here.
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.
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.
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.
I can have insights into that, and then I can be like, oh, I ship that into products, I might have an issue, right?
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.
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,
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.
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,
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.
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.
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.
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.
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.
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.
And that's what I had, and I didn't even, yeah, so, maybe a minute for questions.
Thank you very much, and thank you for making on time. We have time for one question.
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.
So, yeah, I mean, some of the Python scripts we have for extracting licenses, et cetera, might be useful to you.
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.