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