Hello and welcome to my talk, I'm compared with the previous talks where people talked
about, I cannot louder, sorry, that's my voice.
The other presenters were talking about their company efforts or the community efforts this
time, I will present what happens in a smaller community that is the bottom of the supply
chain. More precise in the Apache Natex Real-Time Operating System.
My name is Alijer Peleau, I'm an open source advocate, number of several communities. Currently
the Apache Natex Real-Time Operating System chair and I work as an open source of the architect
in the Sony Ospo, Europe. You can contact me on the LinkedIn. Due to the time limit, I will
run through the slides, so the disclaimer is there, I will not read it. Most of you probably
didn't know about the Natex Real-Time Operating System, so I will have a small introduction
so that we set the contacts. The Apache Natex is a small footprint, Real-Time Operating System,
it uses standards and it's focused on compliance, it runs from systems, microcontrollers
that are between 8 and 64 bits. It is available and more than 400 boards, it provides documentation
and welcoming community. Also, it has been used and it is used in commercial products.
You can see a few examples of development boards. The one on the right is from Sony, it's called Sony's
presence. History, again, running quite fast, the project has been released under the permissive
BSD license by Gregory Nat. In 2007, in 2019, has been donated by Gregory Nat to the Apache
Software Foundation, thank you Gregory for this donation and we graduated in 2022 as a top-level
project. In 2024 and currently we have the governments of the project as an open governance.
We have 24 members in the committee and we vote all the big decisions. We have many products using
Natex. You see a few pictures. I hope that they are right. Since we discover what companies and
products use Natex when companies come forward to us, but otherwise we have no idea what people are doing
with Natex and he will see soon an even interesting one. Digital Records,
headphones, drones, robots, protection equipment. You can find all those examples in the
recordings for the Natex International Worktrop Conference where people come forward and they talk about
their use cases. Also, Xiaomi is using Natex in the IoT platform and the Vela is called the
platform and they are contributing a lot to the project. Sure. Also, Natex is used
was used on a small robot that landed on the moon by the Jackson Space Agency using Sony's
presence development board exactly the board that you saw previously. So you have the full announcement
and you can Google for it. Now that we have the use case for this operating system,
it probably you realize why it is important for us to be compliant and why we want to provide
as a community DSBOM. So during our transition from a BSD project to an Apache project which
changes the licenses, you can see the progression and the versions of the bottom.
Really, it is less important. It is roughly two years of work. We have to scan every bit of code
and make sure that the licenses are compliant and we do proper license transition. And then
because we identified licenses which were not Apache, we ended up having especially in the application
side. We ended up having menu item as you see it's a fairly common view for kernel where people
can select their licenses. It is impossible to build Natex without DSD and the MIT components
because they are used in the core but you can exclude everything else if you don't want it in your
applications. And then we wanted to see is that really true. So we wanted to have an SBOM to
get a list of what's actually built. We go back to that later. What is an SBOM? Because everybody
is talking about SBOM's and we as community were a bit confused. An SBOM is a softer
bill of materials, a list of all components present in the code base, including license version
metadata which allows security team to quickly identify security risk. The definition is really nice
but which as BOM do we need? According to the CSAT listing there are six. Do we need all of them?
We were groups. Design? The software is there. We don't design anything. People contribute to it.
We have no control. Source we can see the whole source is but would that help the companies
that use our product to really know what they put in their product because they will get a list
of all the licenses, files and correlations for the whole notex. They will build a subset.
So we were thinking that a build SBOM would be what would make some users, some our users,
our companies. Happy. So we decided to go with source to provide a full index of everything that we
have for every release and a build SBOM which means that when you build you get exactly what you have.
And then we were looking even further because there was little information when we started this
discussion two, three years ago that we need SBOMs. Most information that you find comes for products
that have an SBOM for packages and this is how you would have it. You download the package,
you get the package data, you get an DSBOM data, you assemble it and you put a product on the market
with the SBOM data or at least this is our own understanding. But in our case you get code,
it has nothing. The company has to generate an SBOM from whatever and then you put the SBOM
and the software release on the market. So thinking about this picture, we were thinking, okay,
that means that we have to integrate the SBOM generation in our build tools so that when you build
your binary you get also the SBOM for exactly the product that you're building. And to put a bit of
salt on the wind, we had no idea how to do that. At that point we had no idea about SBDX,
there were a few mentions of it, but we had licensees in clear text. So we started looking at
the SBDX, I joined the SBDX community and it's a really nice community, welcoming community
sharing information. And we decided that we will use this also a bit confusing in our research
which version should we go for the latest and the greatest, should we go for what the other
seems to go. So we decided to start with version 2.3 to be more exact. And then when we will see
others using the newer format, we will just update the tools. We decided to go as early as possible
and then we will see. The SBDX website provides many tools. I started looking at all of them
and from my findings, I couldn't use them for generating an SBOM for
secode for real-time operating system. So okay, then we started looking at the whole landscape of
operating systems that are having almost the same goals, from communities, from companies active or
are high. And we saw that we have free articles which implemented a build SBOM quite recently.
This slide was updated last week when we did the initial investigation three years ago. The
landscape was different. Then we have the ZFEROS which provides both source and build SBOM
and we have not text which hopefully will have the first release with a source SBOM and build
SBOM at the build time in March in the next release. So now we have an idea of what is available,
an idea of what other communities are doing, an idea of how we can do it. So we started working.
And this was the painful part. Okay, we have we are in Apache Project under the Apache Foundation.
We added the SBDX license identifier and we were done or so with all.
Yeah, old code. BST0 identified with FOSID. I know it's a commercial tool. I used what I had.
A long list of copyright owners, a long list of contributors, informations, quite scars there.
Or we ended up with code that has multiple licenses. Really nice. Also identified by the scanning tools.
Unknown license. I saw these license for the first time. I don't know how many people are
aware with it but I couldn't identify it from the text. I needed help.
And also the tools can be misleading as you can see here. Quite nice help from the Xiaomi guys
because my tool gave a false positive. I was unsure. They identified it the code as BST0.
My tool identified it as GPL. So we documented everything. If somebody has anything to say later
that the license was not properly checked, we have the answer from two conflicting tools. And
yeah, I mean help. The community is based on help. We help each other to make things work.
Also there are SPDX identifiers that we cannot find. And initially I was looking for something called
public domain. Public domain is handled differently in different jurisdictions. So there is no
identifier. We defined our own not-expublic domain and I plan to submit it to the SPDX list.
So that every time when an S bomb is handled by somebody they can see that it is defined
and properly recognized and propagated in the S bomb. And then we had all the information that we
needed. We had SPDX headers, identifiers. And we started defining what we want to do. We wanted
to make it fully automatic. We wanted to reuse our build system which is make build a make based
and collecting information. What information? Our build system looks mostly like this and it
would make sense. So basically we have the not-eximage. We have the files. Then we get the sources
and the headers and the headers are reused and used by many. I try to simplify the whole thing
because it's quite massive. So the build system will give us debt files for each library. As you
can see, those are the ones that I've been using for the demo. And then for each library you have the
C files that we'll go in the library and the C files get the headers for each one of them
including the system ones. So all the dependencies are aggregated in a big file and then clearing
the path so that it can be reused. We populate the file with the proper files and paths.
Yeah, this one I already jumped over. SPDX to the rescue. You get a really nice documentation
on what fields you actually need and what fields you have to have, what fields are nice to have,
what is the format for them. So if you have any SPDX doubts, just go and read the manual. It's
wonderfully done. Also, they provide the examples. So you can just take a look at their examples
and then you figure out what would work for you and what not. So having also this extra information
we were able to finally have our objectives and define what we need. We decided to go with SPDX
to point three. We decided to go with JSON format because it's easy to parse and easy to transfer
to any other format. There are multiple converters over there. You can also convert it to cyclone
the exit. That is what you need. We decided to collect file hashes, licenses and relationships
between files for both sources and build artifacts. So that is how our header looks. I'm not
100% that this is all that we need, but this is what we have in this moment. So it's a simple
snippet from what we did. I generated the header on 24th. Then for source files we also collect
file name, file type, the ID, show one some licensees, also the license from file and license
concluded. If the file has no source, the concluded license is no assert. If the file has multiple
licensees, the concluded license will be either Apache or if you have a GPL, it will be GPL.
Okay. Same thing for headers. We use our own headers and we also use system headers. Everything
is documented with the shots from each of the files. Some of them have no license information
you to obvious reasons. And we thought that things are done, but they are not. As you would
have dependencies on your package manager, we have dependencies on source code. So we are getting
a build time, different get clones basically from other projects. And in our case, we are using
there are many more roughly 50 projects. So in our folder, we only have the rules to build,
but we do not have the sources. And the problem is that those projects either do not have
SPDX identifiers or we cannot trust them. So the logical thing to do for us as a community
is to help them do a license check, help them get SPDX identifiers on all our projects which
are dependencies and contribute upstream because they may need the helping hand. They may be
a one-man project. The alternate fix which I do not suggest anyone to do is to have patches
near the building rules for each file and add the licenses locally. It is ugly and it will not
help the community. So yeah. And my final slide before some Q&A, I think that we still have a few minutes.
This journey was almost three years. For me, it started with a lot of information. It was
overhelming information. People were mentioning SPDX, but without any reference to an embedded
operating system. SPDX are great, but they need some kind of definition for somebody that is new.
You need an S-bomb for packages, an S-bomb for cloud, an S-bomb for your project.
Open chain and SPDX are wonderful communities. If you have any doubt on anything, just go
there, read, ask. People will help. Looking at our dependencies, SPDX identifiers may be missing.
I bet that is the case for all of you here and all of you online. Maybe it's good to just
talk with the maintainers of those projects to make them aware that you need SPDX headers.
It may be good to try to help them. Maybe they do not have the resources for doing this work.
Also coming from both a company and an open source background, I can say join the open source
community. If you are interested in a specific area, in this case, open chain, SPDX, join those
communities. They will help you get better and you can help them understand what the problem is.
Thank you.
Questions for all of you who was kind enough to leave time?
Yeah, great hard. You spend a lot of time to help source SPDX. Really, good but you do.
But actually, did you request, really request for the source SPDX?
We as a community. Yeah, so the question was, if there was a request for source SPDX.
No, we as a community started discussing this because we are at the bottom of the supply chain.
So if we don't provide a build SPDX, the company building the software cannot do it.
It has to be implemented in the build system.
They will get a full source SPDX, they can do that from the scanning tools, but that is not what
their product has. It's, yeah, you have a subset of all the sources. Thank you for the question.
Yes.
The question was, how do we deal with external?
Have a test version of some library in there that you want to see?
The question was regarding projects that are not your direct dependencies.
They may be tools or test projects that will end up in your S-bomb, but they are not used.
The answer is, for this project, we don't have them.
We only have what we actually use and what we actually build.
We don't get them in our source.
But this again is our case. In other cases, probably there are other answers.
Sorry, I'm sorry. I don't know how to handle it for Java.
There is one last question, I think, or maybe two.
Yes, the source, the question was if there is a difference between source and build S-bomb.
The source S-bomb will be delivered at the packaging time for each release,
and it contains all the information for all sources in the project.
While the build S-bomb, let's say that you have a Raspberry Pi picot,
will contain only the files that end up in the final image on your Raspberry Pi picot.
With the applications and everything that you selected in the menu.
We have time for, I think, one last question. Yes.
In the next generation?
I have, yeah, the question was, how many projects we contribute to the S-bomb information?
In this moment, zero, we are just fixing our own S-bomb.
But the aim is to help our dependencies and then see how we can help.
So, thank you very much.
Thank you.