Hi everyone, I'm waiting for everyone to take a good seat, so this is going to be about
embedded and not embedded as well, embedded software, but we have.
So how embedded looks like, it can look differently.
There are many shapes, many colors from your phone to your hit-exystem or your car, your
weather station, and what is interesting about embedded products that they usually have multiple
pieces, and we have that multiple pieces, partially in this year way, with the remote processing,
but of course not everything.
So to simplify, you typically have the device itself, frequently running a hidden processor,
or not many high end, but still processor running Linux.
You have a microcontroller, for example, to control power, or to control additional elements,
you may have a GPU in an embedded system, and you may have things that Bluetooth Wi-Fi,
FWG5G, that are also having their own processors running the big software stock and so on
and so on.
So you may have a dozen or more processors just on the device side, then you may have more
frequency in the server side, so the famous remote processing, for different things,
for data integration, for remote control, and so on and so on, and quite frequently you
also have a more up-on-the-phone, either talking directly to the device or talking to the remote
service.
So let's create an S-bomb, for an example of an embedded product.
So one S-bomb that's going to be tricky, because there will be multiple files at least.
And the trolling is already there, people are telling me we can generate S-bomb for
basically everything, so we are mature, we are one year and a half from the series, so
everything should go fine.
And let's try to follow the CRA recommendations, generate all those S-bombs, put them
into a vulnerability management tool, and let's manage vulnerabilities in our embedded product
as the CRA recommends us to do what could go wrong.
The first, why a little bit about me, PhD in telecommunications, I'm mostly in embedded,
as you can guess, 20s plus an open source, contributed to various, to everything from the
Linux Canada to the KD environment, those days typically in the, I run the Yachter project,
and security teaching, and contributing to the series standardization of those days.
So in our case, this is a simplified version of a weather station scenario, what building
weather station product had to simplify the configuration, because it was too complicated
to explain, but what do we have? We have the base station, which is Linux-based system built
using the project, then we have sensors running Z-Fi, and I have the server application running,
running a custom Python application, that is expected to receive the sensor data and do the processing
dashboards, and set. That doesn't look bad, complicated, and I really, really, really
simplified all external portfolios. So, what do we have now on the SBO level, the Yachter project
with Winlata, Generating SPD X3. The sensors running Z-Fi, so it's SPD X2.3, in fact,
and our server application Python native tooling, I went on cyclone to tell you in a moment,
and for the choice of what I'm going to use for vulnerability management, go for dependency track,
and here already I was asking for travel, because I have a part of the software stack
based on Linux Foundation, and I go for an OSP tool, asking for travel.
On the Yachter project site, the Yachter project is a way to build a Linux distribution
from a weathered system, a Linux Foundation project you can extend it as you want, and every package
that you build is described in a recipe, and the whole tooling can generate a SBO no matter how
you configure your fan. What is interesting is that you get a SBOm generated at the build level
with all the bit information that you have, so it can get gigantic, and builds everything,
the bootloader, the Linux kind, and so. So there's no direct thing to any existing
standard of the new distribution. On the SBOm site, it's generating SPD X3. By default,
you can also have classes to generate SPD X2.2. There are third-party cyclone
the X patches that are flowing around that are unofficial. On the SBOm site, so what is
the FFS? The FFS is a real-time operating system, also an installation project, and it supports
all kinds of small microcontrollers that you want to write a small sensor on, and there are multiple
examples if you want to start running. Could have used any other methods for this XSS. So ZF is
generating SPD X2.3, that can be generated by its build tool. It is in the official documentation,
but you need to dig a little bit how to generate it, and there's a talk from from Bajana,
describing how to do. There's no second-dakes support I'm aware of.
And that's how you generate the SBOm from with the west build system. So you need to
fill a few options to make it running, and then you get it in build SPD X2, you get four
files that contain various types of SBOm. Okay, on my Linux Python applications,
so typical Python code with rest API, the dependencies in the requirements point takes
the SD. So I haven't tried generating SPD X4. This test wanted to go with cyclone,
why with cyclone they expire. Otherwise, but this is pretty easy to do. I install and start
with PIP, and then fill the requirements and generate an SBOm. And then I had the
reflection to have a look into that SBOm. And I saw that it's only containing the exact
first level dependencies that were there in the requirements point to XT. So yeah, okay, so
let's generate better dependencies here. I went with PIP 3 to generate more complete
dependencies, and then regenerate the whole SBOm, and that looked where well, well, well better.
Okay, now a dependency truck deployed as a container, no much to say, it deployed as a container,
it was working. Now, let's go, let's import let's import all my SBOm's to
depend, see truck, and it was like that. I probably saw half of the error messages that they have.
So what happened? So the second day from my Python service that imported. Okay, same ecosystem,
okay, and now for SPD X different types of stories. So the 3-0 from from the Yachter project
has written in dependency truck documentation, not to put it, don't even try. But Zephyr generates
SPD X 2.3. So it should have worked because the documentation says it should have.
And then realized that Zephyr generates the tag value format of the SPD X 2.3 that I honestly,
I didn't expect I'm going to see it anyway. So, okay, so let's convert the tag value to something else.
And I tried to convert it to the JSON and to the XML and not, didn't work neither, one important.
There were simple problems, but to be to say it in a binary way, the important test was
to say it. So what I decided to do, so let's try to convert the SPD X 2.3 of Zephyr to cyclone,
using Swift in this case because I have Swift in start for other things. So I did convert the SPD X 2 to
cyclone with Swift and that did import. And now on the SPD X 3, what I'm going to do? I tried,
I didn't want to write a conversion to myself. I think they are already too many. So let's try to
find something. I didn't find anything that could convert SPD X 3 to something. Okay, so
what I did, I went back to my vector project configuration and changed the generated SPD X
X 2 to 2.2. Okay, and now the SPD X 2.3 in the vector project, it has a specific format with an
index file and hundreds of files around the place. Of course, no conversion to support it.
It's illegal format, but it's not, nobody supports it. So what I did is I wrote a follow-up to convert
all of the SPD X 5 to cyclone and then then, and then, and then match the, match the
cyclone files together. Okay, and then I, after all that, I managed to import it all from all
applications to the battle track. And now let's start the vulnerability analysis. And that's the
result of my vulnerability analysis. That gives one vulnerability. How does it look for that kind
of, of a, of a software stack? Something's wrong, right? Too good to be true. But if you,
if you had your manager probably, some people may be tempted to show to the managers and say,
it's all fine. Now, it's not all fine. So, so I had, I had a look about, into what happened,
actually. So, the details were absolutely not equal for all of those S bombs. So, on the Python
application side, we have already seen that the requirements for takes to have you, how you fill
it, it really matters. On the other side, on the vector project. So, at the conversion time,
we've lost all the updates of package names. For example, the Linux kernel in the, in the,
that built a hat, it's called Linux Yachter. So, dependency track did then realize that this Linux
kernel. So, I basically had had zero vulnerabilities in the Linux kernel, even if the kernel was
like a moment of thought. And that was all the place for all the annotations and all the
additional information that the vector project gives in the S bomb. So, basically,
the result doesn't think much sense. And there were missing version numbers that were lost
in transition. Also, especially on the SFSites, I saw that the original SFS bomb had quite
many version numbers as coming hashes. And unfortunately, that isn't handled at the dependency
track level, because you would need to look into the git trees of all those projects and figure
out where you are, so that doesn't work. So, this work to do. So, what are my takeaways?
If you use tools from one ecosystem, it usually works. Mollies. But we have multiple
S-moformas and also multiple binary formats, probably too many. I didn't expect that
that values to be seen. And the conversion is complicated. You need various tools to make
to make different transitions to get true. And if you have ecosystem specific, not totally
mainstream options used in your S-bomb, they are just lost in transition or they are not supported
by tools. So, they are the enderogenophile, but if nobody knows they are there, they are not just.
What we need is cross-checking between vulnerability tools for such cases,
because S-bombs looked valid. They were close. They are quite good when very faring for
existence of fields, but actually they were not accurate after all the conversion at all,
and not totally used for adiant. And especially to check all those requirements, to check all that,
accuracy of S-bombs, if you have hundreds of packages, you probably do not want to do it
manually. So, needs tooling. And definitely what is absolutely needed is more integration and testing
between tools, because as we can show, that just doesn't work. And real embedded products are
way more complex than that. I did it at one of the popular S-bombs format code C-S-V.
So, do you have questions?
Yeah. As a side note, we are using a fancy-track tool. And so, if you have a using live-resolution,
for example, if you want to get a name matching, because depends on the moment, it doesn't
respect source, source code names, name hints in the course, neither on the OSB side note,
nor anything supplied, so it doesn't do a match. If you then include virtual dependencies on your own,
just to have the right name in, you get much, many false positives on operator, on deviant,
on Google to whatever, just because they don't know really about release tracks,
and put everything in the section unless you're using live-resolution unstable. You're always,
for the coding, I'm trying to summarize. Yes. So, audience member shared an experience using
dependent track on libraries, there are problems with dependencies, there are also issues.
And if they add virtual dependencies, they run into other problems.
With false positives this time, on standard operating system.
They're really victim-serious. And they are searching for other victims of those problems.
Yeah. So, one of the things this conversion is not there. So, what I recommend people to do
is to generate natively using a true format and speedy exercise on the edge, not to the
conversion. And okay, then you've got multiple response to manage, but actually that seems to be
better than the conversion process of the conversion process is lossy, not lossless, which I think is
my drawing, what you're finding. But when you've got things like problems that only support,
generated all these support, native one format, then you've got problems.
Yeah. So, we have a few more, I remember the question to generate a natively in the
correct format. From my experience, projects are really reluctant to generate multiple formats
of S-bombs. They want to stick to generating one, assuming that people will manage to call
them about things if they want to, but you have seen that doesn't work.
And actually, say, generate using two different tools as well. Yeah. Yeah. The other side is
the deep level of detail available in the different S-bombs you generated was quite different.
The development, the cycle of the experience was only really the moment the top level was
said. The ones that you were getting out of go and go, and, etc, were very deep, held down
the source by a level, which the dependency track would not even understand it. Okay. So,
I would sort of question, are you really getting the numbers out? Was it more like putting those
in and getting the ones down? Yeah. I know the remark, I would say, a comment about the detail level
that we, with all those tools, we are getting completely different details level. So,
add the S-bombs and add the vector project level, we get down to the S-bombs and on my
Python app, we are at the package level. So, definitely it doesn't contain the same granularity
of information. And that's also going back to the previous presentation,
type of S-bombs and what it contains probably matters. More questions.
So, the question is, what they suggest to get to get to get that better interoperability?
I think that this talk is a starting discussion. People who know me know that I post a lot of
stuff everywhere. So, if you are interested in discussing and doing other experiments,
posting results and shaming people for stuff that doesn't work, I'm all for doing that.
Did you play with those that are sitting up on the S-bombs between those format that work?
Any other questions?
They have a whole round of trees and proponents of the development manner of proper
pre-復ural pathologies. So, we are different into what we work for.
Could you take from theress on a second up on deducting these
templates in the next 3 or is it see how different they are or how?
I think we should have been recommending the whole, the whole because the place is not there,
the place is right, okay.
Questions?
Let's all thank you.