This is the CRA, yes, we are full of excitement, I would say.
Of course.
All right, we're going to get continue.
Thanks very much for coming, and we're continuing with our program of our show, which is CRA in practice,
the next app is Martha Rabgiska.
We'll talk about the CRA compliance and embedded systems, a practical look from the Yachtau project models.
Please.
So how many embedded developers are there in this room?
Oh, damn it.
Okay, so how many embedded product users are there?
Yeah, so it means that this talk applies to all of you, basically.
So if you do not know me, my name is Martha, and I talk a lot about security,
when I do not talk about open source, basically.
And those recent months, I'm doing a lot of work on the CRA, including the standardization,
and including Ellie compliance for CRA.
And this talk is about my personal opinion.
There's no official statement of the Yachtau project and so on and so on.
Yeah, so.
But first, what is your project?
Yachtau project is really not, but not only distribution creation framework,
mostly from embedded, but you're not obliged to use it and embedded.
And the advantage is that it's very easy to be extended by hardware vendors,
and that's what they are doing.
And it's the fact that the standard of building the distribution,
with open source licenses in a foundation project, the standard.
It is out there everywhere in starting from automotive to home appliances.
And basically, you are very likely to own at least one Yachtau project device at home.
I'm just looking at this table and wondering how many of those things is.
It's hard to see from outside, right?
You need to look into some in this is when you open it.
So not going to do it right now.
All the Yachtau project sites, the Yachtau project itself, it is not a product itself.
It's under the CRA, and doesn't have a manufacturer.
So we could say that the Yachtau project site, we say, do not care that much,
not many obligations, skip to next topic.
But, uses of the Yachtau project, a project at typically manufacturers.
The full full full manufacturers on this series, with the whole full compliance.
And there are products that are using the Yachtau project that fall into the important
or critical category.
So, in addition to that, people who do work on the Yachtau project typically work
for those manufacturers.
So, when I do CRA talk for the Yachtau project, people usually have a full room, basically.
Now, a little bit of basics about the Yachtau project.
So, it's a distribution building and a basic term is a recipe.
It's an instruction to build one software package.
It puts the source code, puts how you are going to build it, how you are going to install it.
And we have recipes, basically, to build the whole world.
Recipes are grouped into something called layers.
So, layers is a logical group of recipes, so you can have a layer for specific hardware.
You may have layers for specific functionality.
Let's say, for example, metaphorically.
And now, for the embedded people, I am oversimplifying.
For reason, because otherwise, I wouldn't fit it on the screen.
So, a simple example of how people do use it in embedded.
So, you have some official open embedded end of the project layers.
You can configure them together to build the firmware you put on your device.
Nice.
But what happens in practice is that you, even though you want to add your own application,
you want to change a few things.
So, you create one layer where you add a new recipe for your application.
And, but that package that is in the standard layer, that's good,
but I need to enable one more option.
So, you do a modification.
There is a way to modify recipes that come from other layers in your own layer.
And then, it's not, it's getting, the path is getting longer.
So, getting more layers, because there are layers for your old product,
but you are using a chip from vendor X, that vendor is providing.
They only with their own fixes and add the, you end up with like 25 layers.
And like 10 of them are modifying, or if you are like 10 of them are modifying the device recipes.
And they are not just enabling some configuration options there, adding patches to the code.
We start seeing dragon heads showing up, right?
And so, how does it recipe look like?
That is this one that's a real monster, and for demonstration purposes,
it's a real recipe of the group, but look at that, so, but look at that, as you know,
if it were a product, it's, on the important list of the series, but it's an unprecedented project.
So, what we have here, we can notice that we have the download location, it's in the first thing in the SSURI.
We also have CV products, so we change them.
We notify what is the product name for vulnerability checking.
And you can see a nice list of those CVs, something, those are patches for all those CVs.
So, this is extreme example, but that's how recipes tend to end up after five years of maintenance.
So, so, what that, it was, that's the yukta project already do for the SURI compliance.
So, we have as one generation, and no matter how complex your layer configuration ends up,
you can generate this as one for that.
It's pretty much detailed build time, as one that can become gigantic if you're unable to manage it.
It is in the current main branch, it's the SPDX3, you can switch to SPDX2, which SPDX2 is the current,
as it does default, that's going to change in the next one.
You have also all provenance information.
As you have all download locations,
normally you have you are tracing all places you download your software from,
you know which patches have been applied, except for really crazy things that you can do,
because crazy things we can always do, you know what you have got.
We also now have non-vonabity checking, so that's also integrated working with any layers.
Set up with annotations that we have seen in the recipe,
and there are quite many security tools that are packaged.
There are the recipes and layers for those things.
Including security tools, even you can be the appliance with an interaction system if you wish.
On the process site, what do we have?
We have a long time support versions, support for security fixes,
and the process of accepting or not,
affix in the LTSries.
So that's good with the four years LTS,
not being enough for most embedded products,
which is already one thing under discussion,
but an open subject, then we have testing,
and pretty interesting testing because on multiple architectures,
and history shows that the testing is frequently showing issues in upstream,
that the project has a lot of experience
explained to many upstream maintainers that something broke on some.
Specific configuration,
with specific elliptic and specific specific,
so that they fix it.
We also have a vulnerability reporting and management processes,
so there's a security team,
and there are ways to manage security fixes by those tagging inside patches.
So here probably we are doing way better than people
by building their stuff from scratch.
Those two think is of course not perfect,
but it is working pretty good.
For some cases of aesthetics we see my talk tomorrow,
nine foot.
Now about the challenges.
So the first dragon,
the first dragon we have already seen here,
you have a recipe,
that has been modified, that is the upstream,
and then you have a vendor applying a patch to this code,
that they wrote.
And even a complicated case, they took a patch set
from one of the vendors,
and they applied that in addition.
The question is then,
how do you call that package A in this case?
Is it A or is it something else?
Taking to account that people are really creative,
and those few patches that may be worth of two releases.
So the current situation we have,
is that if a package has a lot of patches,
it is still called the same package.
Even if it doesn't even look any more like the same one.
And as a consequence,
you need to tag all the security annotations by hand.
What becomes a little bit complex,
if you are, I wonder you have 100 patches over the so-3.
Some people would say yes, upstream, that stuff.
Yes, I would say try to upstream that stuff.
The problem being frequently that people want to ship their device
and their upstreaming is down the discussion.
And it won't be in the ideas they want to have in the product.
So there will be upstream but two project versions later.
So that's one problem that there is.
And honestly, the only solution I see to that stuff is to do an analysis
of so-called trees and find out the number.
And do the complete graph analysis and find out what we actually have.
The second, the second subject,
secured by default configuration.
So the current policy is to minimize the changes from upstream.
What I run into frequently is that I added a configuration and it turns out that the upstream project
is actually unsafe by default.
So what do you do then?
Many cases, you just want to apply changes and to do that secure by default.
This is complicated to do at scale for hundreds of packages.
Then we have the fact that the October project is completely configurable.
So with the same tree, you may be building a default and you may be building an appliance.
So it's very hard to put to come with one set of standards.
And one configuration for people to agree on.
And then, historically, they are vendors shipping their own layers for the October project.
They own hardening changes.
That, of course, completely incompatible one another.
Change number three.
For many important and mandatory solutions under the series,
like their systems.
There's no default that is provided inside the app.
The project, because outside there are multiple solutions that exist.
So you have, as a vendor, you have multiple ways to integrate it.
Oh, and it's on the manufacturers played to correctly and securely integrate their important components.
And that makes writing a nice complete risk analysis really hard.
Without asking, well, this is the second volume of the risk analysis.
Then, in the embedded, we have vendors that are literally years behind upstream.
And yes, it's not one year.
It's like, and we have people who stack on vendors software that is years behind upstream.
As a consequence, there's no ideas whatsoever to give them security updates,
so they are backporting on not fixes.
And so if the project makes an important change for the security functionality,
it may turn out that it will ship on devices five years later, actually.
If I, yes, I'm really nice at that.
So it is slowly changing for, for this year, the vendors getting more and more close to upstream,
but for the embedded world December 27 is basically tomorrow,
because the devices are already being designed.
So to wrap up, in the embedded, it's really uneven.
I think that they're working well.
I like basically the as-mom metadata.
And it's really uneven from one vendor.
One chip vendor, another example.
And what requires work is that we have a years and years of fragmentation of security solutions,
so many vendors have their own stuff, and do not want to show it away.
Security default, it's a really complex problem to solve,
because actually it's requiring not security default.
And we have hardware diversity, a big example of that being secured,
that on the most popular and the platform was a per-cheap specific solution
until not long time ago.
But we are advancing on the positive side.
So, thank you.
I guess we do not have time for questions, right?
Actually, actually we do have time.
We do have time for one question.
Who's the great person ask one question?
And the next speaker, can you make yourself visible to us?
Thank you.
Please sit down for a second.
Thank you for that matter.
I'll try to be quick.
We manufacture OEM devices in the embedded space.
I'm understanding that our customers would be the manufacturer under the CRA,
and it's their responsibility for all of the software components that they receive within
Yopto and elsewhere.
And I'm trying to understand attestation.
How do they ensure that each of the components is safe and review those?
And when they're not, what do they do?
How do they remove those components?
Or what are the solutions that they will have to be compliant,
given that that's their responsibility?
So, the question, if I understood it correctly,
was how do those embedded vendors that are using Yopto project?
I showed that the components they use are secure.
Do you want the Honest answer?
The Honest answer is that they trust that they have been correctly integrating to the
Honest answer?
And, but as they, especially the bigger of them are getting scared by the
final part of the CRA, they are starting into looking how to analyze that
by of data.
But embedded people know already for a long time ago that they do not have
10 dependencies.
They have more like a thousand.
And analyzing thousand dependencies manually for secure configuration
that's not one evening task we can say.
That is true.
It's all complicated.
Thanks very much.
My hand from applause.