WEBVTT

00:00.000 --> 00:08.000
OK, let's get started.

00:08.000 --> 00:09.000
Hello, everyone.

00:09.000 --> 00:12.000
I'm Eric Bravet, and this is Martin Eddini,

00:12.000 --> 00:15.000
and we are working in a redhead.

00:15.000 --> 00:17.000
And we are working on something which is called

00:17.000 --> 00:18.000
complex.

00:18.000 --> 00:21.000
Have you ever heard about complex raise-hand?

00:21.000 --> 00:22.000
Perfect.

00:22.000 --> 00:24.000
Another one.

00:24.000 --> 00:25.000
Anyone?

00:25.000 --> 00:27.000
OK, I will tell you what it is.

00:27.000 --> 00:31.000
Complex is an open source, cloud native software

00:31.000 --> 00:34.000
factory, or a built-factor if you want, and is

00:34.000 --> 00:37.000
focused mainly on software subjects and security.

00:37.000 --> 00:41.000
What we are doing in redhead, we are building software

00:41.000 --> 00:45.000
in a complex, actually, a lot of software, for example,

00:45.000 --> 00:48.000
operators, maybe an artifact, home charts,

00:48.000 --> 00:52.000
RPM packages, but in this presentation,

00:52.000 --> 00:57.000
we will be mostly interested in a container images.

00:57.000 --> 01:02.000
Complex is really big, too big, to be handled by the single team,

01:02.000 --> 01:06.000
and our team is specialized for a bone domain.

01:06.000 --> 01:09.000
We are generating as bones, we are augmenting them,

01:09.000 --> 01:13.000
and we are also delivering those as bone solutions

01:13.000 --> 01:16.000
to the other teams that are committed to the security

01:16.000 --> 01:21.000
and compliance, for example, for a vulnerability management.

01:22.000 --> 01:26.000
In this presentation, we would like to show you that in redhead,

01:26.000 --> 01:29.000
we are not treating as bones as some kind of mandatory

01:29.000 --> 01:32.000
checklist, but we are trying to, let's say,

01:32.000 --> 01:35.000
unlock their potential, we are looking for a way

01:35.000 --> 01:38.000
how to make it better, how to make it more precise,

01:38.000 --> 01:42.000
and we would like to introduce a new concept,

01:42.000 --> 01:44.000
which is called contextual, as bone,

01:44.000 --> 01:48.000
and tell you what it brings for vulnerability management.

01:49.000 --> 01:52.000
So, let's start with a really simple,

01:52.000 --> 01:54.000
real-board, a world scenario.

01:54.000 --> 01:57.000
You handle a large build system as a complex,

01:57.000 --> 02:01.000
and you build a simple image as it is in a slide.

02:01.000 --> 02:03.000
You have a simple container file.

02:03.000 --> 02:05.000
So, basically, you build it, you probably

02:05.000 --> 02:08.000
deploy it to the production, you generate as bones

02:08.000 --> 02:11.000
for that, you may be forget about as bone,

02:11.000 --> 02:15.000
and three months later, vulnerability pops up

02:16.000 --> 02:18.000
in a HTTP BD package.

02:18.000 --> 02:20.000
And in your CI-CD pipeline,

02:20.000 --> 02:23.000
your image can turn red,

02:23.000 --> 02:26.000
and you get acknowledged that your image is affected,

02:26.000 --> 02:29.000
and so on, we know that, right?

02:29.000 --> 02:33.000
Question is, what's to do now?

02:33.000 --> 02:37.000
Do you update your HTTP BD package in your container file,

02:37.000 --> 02:41.000
or you will wait for a base image update?

02:41.000 --> 02:43.000
You don't know at this point.

02:43.000 --> 02:46.000
I mean, in this point, you know,

02:46.000 --> 02:48.000
you can see you are installing just an empire,

02:48.000 --> 02:51.000
and logically the HTTP BD package will be source

02:51.000 --> 02:53.000
probably from the base image, right?

02:53.000 --> 02:55.000
It's a really simple here.

02:55.000 --> 02:58.000
The real problem is in a large scale build system

02:58.000 --> 03:02.000
with a complex container files, multiple base images,

03:02.000 --> 03:04.000
hundreds of dependencies, basically,

03:04.000 --> 03:07.000
here is a real problem to get acknowledged

03:07.000 --> 03:10.000
like from where is the package came from.

03:10.000 --> 03:13.000
And most vulnerabilities cameras tell you

03:13.000 --> 03:15.000
this image is vulnerable,

03:15.000 --> 03:18.000
but they have a limited capability to answer

03:18.000 --> 03:23.000
question from where exactly the vulnerability came from.

03:23.000 --> 03:26.000
You might remember that you produced as bone

03:26.000 --> 03:30.000
after the time, and you would like to check it, right?

03:30.000 --> 03:33.000
Here are the bad news, most of the as bones

03:33.000 --> 03:37.000
or traditional analyzed as bones has the same problem.

03:37.000 --> 03:39.000
They provide flat list of packages,

03:39.000 --> 03:42.000
where it's everything attributed to a final image,

03:42.000 --> 03:47.000
but you cannot extract the information like from which base image

03:47.000 --> 03:49.000
where it was exactly in a supply chain,

03:49.000 --> 03:52.000
this package has been installed.

03:52.000 --> 03:54.000
And this is the problem from the perspective

03:54.000 --> 03:57.000
of the vulnerability management.

03:57.000 --> 04:00.000
So what is our solution?

04:00.000 --> 04:03.000
At Red Hat, we are solving it with the context,

04:03.000 --> 04:06.000
with so-called contextual, as bone pattern,

04:06.000 --> 04:09.000
the idea is really simple.

04:09.000 --> 04:12.000
We use SPD-X relationships to say from where

04:12.000 --> 04:15.000
which package exactly came from.

04:15.000 --> 04:19.000
SPD-X specification is really flexible.

04:19.000 --> 04:23.000
We can even create packages, other packages,

04:23.000 --> 04:26.000
that are basically represent our images

04:26.000 --> 04:28.000
that are part of the build process,

04:28.000 --> 04:31.000
our base images, our builder images,

04:31.000 --> 04:33.000
our intermediate images.

04:33.000 --> 04:36.000
And we can bound them with a relationship,

04:36.000 --> 04:39.000
and we are doing it by expressing,

04:39.000 --> 04:42.000
okay, this is my final image,

04:42.000 --> 04:47.000
and this is basically descendant of this base image.

04:47.000 --> 04:50.000
And we are also using contents relationship

04:50.000 --> 04:53.000
that are already present in a generated as bone,

04:53.000 --> 04:56.000
and we are modifying them to point those packages

04:56.000 --> 05:00.000
back to this original base images.

05:00.000 --> 05:02.000
And on the right side, now we know,

05:02.000 --> 05:04.000
now it's everything clear.

05:04.000 --> 05:07.000
HTTBD package has been installed in a Python 3.12,

05:07.000 --> 05:10.000
and Python 3.12 is an ancestor,

05:10.000 --> 05:16.000
or our image is a descendant of Python 3.12 base image.

05:16.000 --> 05:19.000
What is the actual application?

05:19.000 --> 05:22.000
We use this contextual as bone,

05:22.000 --> 05:24.000
in a vulnerability management,

05:24.000 --> 05:25.000
and thanks to contextual,

05:25.000 --> 05:27.000
as bone we will immediately see

05:27.000 --> 05:31.000
that vulnerability emerged from your base image.

05:31.000 --> 05:33.000
So with the contextual as bone,

05:33.000 --> 05:35.000
the remediation is straightforward.

05:35.000 --> 05:37.000
You will would like to probably coordinate

05:37.000 --> 05:42.000
with a redhead UBI team to get updated UBI Python 3.12 image,

05:42.000 --> 05:46.000
and then you will just rebuild your component

05:46.000 --> 05:48.000
to inherit the fix.

05:48.000 --> 05:51.000
It's very important, also in our build system,

05:51.000 --> 05:54.000
you can track all the images that are inheriting

05:54.000 --> 05:58.000
from this base image, and you will immediately rebuild them,

05:58.000 --> 06:01.000
because you know that they are affected, right?

06:01.000 --> 06:04.000
Because they are using the same base image.

06:04.000 --> 06:06.000
On the other hand, when you can see

06:06.000 --> 06:10.000
that vulnerability came from your installments,

06:10.000 --> 06:11.000
so we are saying basically,

06:11.000 --> 06:13.000
my component contains NumPy,

06:13.000 --> 06:16.000
you need to, you are in charge to fix it.

06:18.000 --> 06:20.000
Okay, how it works?

06:20.000 --> 06:22.000
This is most complex slide,

06:22.000 --> 06:25.000
with some kind of animation of that.

06:25.000 --> 06:27.000
Let's take a look step-by-step.

06:27.000 --> 06:28.000
Okay.

06:28.000 --> 06:30.000
In the three brackets,

06:30.000 --> 06:32.000
we have three different container files,

06:32.000 --> 06:36.000
and basically the lowest one is our component.

06:36.000 --> 06:40.000
The container file above is basically its base image.

06:40.000 --> 06:41.000
It's a Python 3.12.

06:41.000 --> 06:44.000
This is actually really simplified real world,

06:44.000 --> 06:46.000
a real world scenario,

06:46.000 --> 06:48.000
where it's installed, obviously,

06:48.000 --> 06:49.000
Python 3.12,

06:49.000 --> 06:52.000
and our affected HTTP package.

06:52.000 --> 06:56.000
And also, we are at the above,

06:56.000 --> 06:58.000
it's its base image,

06:58.000 --> 07:01.000
and this is source-to-image base image,

07:01.000 --> 07:04.000
and we are installing guides there.

07:04.000 --> 07:05.000
Okay.

07:05.000 --> 07:06.000
So first step is very simple.

07:06.000 --> 07:08.000
We all probably doing that.

07:08.000 --> 07:12.000
We generally play in traditional analyzed as bold.

07:12.000 --> 07:14.000
Okay.

07:14.000 --> 07:16.000
The second step is new.

07:16.000 --> 07:20.000
We either download or generate base image as bold,

07:20.000 --> 07:23.000
and this is like a little bit crucial part,

07:23.000 --> 07:26.000
why we are downloading the base image as bold first.

07:26.000 --> 07:29.000
And this is especially important in a systems,

07:29.000 --> 07:33.000
like a complex, where you are building not only your products,

07:33.000 --> 07:35.000
but also base images for these products,

07:35.000 --> 07:38.000
and base images for those base images, and so on.

07:38.000 --> 07:42.000
And you can end up with some prompt scratch image.

07:42.000 --> 07:44.000
So we are downloading this image,

07:44.000 --> 07:47.000
because this image can be already contextualized,

07:47.000 --> 07:52.000
and could potentially contain information about its ancestors.

07:52.000 --> 07:55.000
Luckily, this image,

07:55.000 --> 07:59.000
this as bold of the base image is already contextualized,

07:59.000 --> 08:01.000
so we can see that, okay.

08:01.000 --> 08:04.000
This image actually contains HTTP-D and Python,

08:04.000 --> 08:11.000
and it's base image source-to-image base contains git.

08:11.000 --> 08:12.000
Okay.

08:12.000 --> 08:15.000
Let's return back to our traditional,

08:15.000 --> 08:16.000
my component as bold,

08:16.000 --> 08:18.000
and let's start modifying it.

08:18.000 --> 08:21.000
So as I said, we can add various packages,

08:21.000 --> 08:25.000
so we are adding representations of our images

08:25.000 --> 08:29.000
that were part of our build process or previous build processes.

08:29.000 --> 08:32.000
So we are adding UBI Python 3.12.

08:32.000 --> 08:36.000
This information we can extract from our container file, actually,

08:36.000 --> 08:40.000
and the second base image in a chain is

08:40.000 --> 08:42.000
this UBI source-to-image base,

08:42.000 --> 08:45.000
and this information we are actually extracting

08:45.000 --> 08:48.000
from a base image as bone.

08:48.000 --> 08:52.000
And we are also bounding them with a descendant of relationships,

08:52.000 --> 08:57.000
so we are creating some hierarchical chain of these images.

08:57.000 --> 09:03.000
This is the most important part we are taking those two

09:03.000 --> 09:08.000
as bones for a base image, and our generated as bone,

09:08.000 --> 09:10.000
and we are matching the packages between them.

09:10.000 --> 09:12.000
And the rules are basically simple.

09:12.000 --> 09:16.000
Everything what is matched between those two documents

09:16.000 --> 09:18.000
is basically sourced from the base image,

09:18.000 --> 09:21.000
and everything what is left not matched

09:21.000 --> 09:25.000
is actually our own installments in our container file.

09:25.000 --> 09:29.000
And we can divide this in basically two categories,

09:29.000 --> 09:33.000
those matched packages, those packages that came from

09:33.000 --> 09:36.000
our UBI Python 3.12.

09:36.000 --> 09:40.000
So for these packages in our traditional component,

09:40.000 --> 09:43.000
as bone we just modified those relationships,

09:43.000 --> 09:48.000
and point those packages to this representation of UBI Python 3.12,

09:48.000 --> 09:53.000
and those packages that already have the relationship

09:53.000 --> 09:57.000
in the base image, we just inherit this relationship

09:57.000 --> 09:59.000
if it makes sense.

09:59.000 --> 10:03.000
Okay, and this is the basically final product,

10:03.000 --> 10:05.000
where is everything on the place.

10:05.000 --> 10:08.000
So we are saying that my component is a descendant

10:08.000 --> 10:12.000
of UBI Python 3.12, and this contains HDPD and Python

10:12.000 --> 10:15.000
and Python 3.12 with the descendant of source

10:15.000 --> 10:18.000
to image base, and this contains Git,

10:18.000 --> 10:21.000
and NumPy was installed in our container file.

10:21.000 --> 10:26.000
So this is that simple is just this between two documents.

10:26.000 --> 10:28.000
No, it is not.

10:28.000 --> 10:35.000
How we would match packages between two S-bones.

10:35.000 --> 10:39.000
Ideally we need some kind of unique identifier, right?

10:39.000 --> 10:41.000
Yes.

10:41.000 --> 10:45.000
But the problem is that SPDX specification doesn't

10:45.000 --> 10:49.000
enforce any, but we have some like hooks that we can catch,

10:49.000 --> 10:53.000
and those are three basically unique identifier.

10:53.000 --> 10:57.000
Perals, package URLs, under some circumstances

10:57.000 --> 11:02.000
can be used for matching those packages.

11:02.000 --> 11:05.000
The another option is package verification code,

11:05.000 --> 11:10.000
which is basically SPDX guaranteed unique identifier for package.

11:10.000 --> 11:14.000
And check sums could be also useful,

11:14.000 --> 11:18.000
because if you use the same algorithm for the

11:18.000 --> 11:21.000
code calculating for a base image as bone,

11:21.000 --> 11:26.000
and a child image as bone, there are basically comparable.

11:26.000 --> 11:30.000
But some packages like custom binaries and files

11:30.000 --> 11:33.000
have no unique identifier at all.

11:33.000 --> 11:37.000
This is the limitation of scanning your software.

11:37.000 --> 11:41.000
So we cannot reliably match these packages,

11:41.000 --> 11:44.000
and we are at the beginning with such packages.

11:44.000 --> 11:47.000
We know that they are present in our image,

11:47.000 --> 11:51.000
and we are unable to tell from where exactly came from.

11:51.000 --> 11:55.000
There is also like other point of view that contextual

11:55.000 --> 11:58.000
S-bones is actually exposing this gap,

11:58.000 --> 12:01.000
making those packages more visible,

12:01.000 --> 12:05.000
because you can mark them with some annotations.

12:05.000 --> 12:09.000
And also allows us to ask two very important questions.

12:09.000 --> 12:12.000
Can we improve the S-bones generation process

12:12.000 --> 12:15.000
to introduce some identifiers?

12:16.000 --> 12:19.000
It can be comparable across different documents,

12:19.000 --> 12:23.000
or it should be a little bit more careful about these packages

12:23.000 --> 12:25.000
in our trusted ecosystem.

12:25.000 --> 12:28.000
Okay, before discussing those questions,

12:28.000 --> 12:31.000
we have another result, one myotechnical project,

12:31.000 --> 12:35.000
and this is actually third source of content

12:35.000 --> 12:40.000
in our S-bones, and those are multi-stage builds,

12:40.000 --> 12:43.000
because this is something what is left in our

12:43.000 --> 12:47.000
component content, and it looks like it goes installed

12:47.000 --> 12:49.000
in our final layer, but it is not.

12:49.000 --> 12:53.000
It was actually built and taken from the

12:53.000 --> 12:55.000
other stages of multi-stage build.

12:55.000 --> 12:59.000
And right now I am calling my colleague Martin Eugenie

12:59.000 --> 13:02.000
because he knows most of about this.

13:02.000 --> 13:04.000
Yeah, thank you for the work.

13:04.000 --> 13:08.000
Please people in the back, if you cannot hear me, give me a sign.

13:08.000 --> 13:09.000
Okay.

13:10.000 --> 13:13.000
Okay, I'll find.

13:13.000 --> 13:18.000
So as I said, we have a solution that works for base images.

13:18.000 --> 13:21.000
If we have packages in a base image, we can identify

13:21.000 --> 13:24.000
where exactly they are coming from, so that's all good.

13:24.000 --> 13:28.000
But there are more, let's say complicated cases,

13:28.000 --> 13:32.000
for example multi-stage builds, where these base image

13:32.000 --> 13:34.000
contextualized S-bones are not enough.

13:34.000 --> 13:37.000
So if you take a look at a build like this,

13:37.000 --> 13:39.000
you know, we have a builder stage that

13:39.000 --> 13:42.000
inherits from goal and latest builds,

13:42.000 --> 13:45.000
some kind of go application.

13:45.000 --> 13:47.000
And then in the final stage,

13:47.000 --> 13:52.000
we copy this resulting build binary into the final stage.

13:52.000 --> 13:55.000
And as a curveball, we also copy another binary.

13:55.000 --> 13:57.000
That's completely different.

13:57.000 --> 14:00.000
So we copy a slash-bind slash curl,

14:00.000 --> 14:02.000
just as an example, to identify

14:02.000 --> 14:05.000
actually the weaknesses of base image contextualized

14:05.000 --> 14:06.000
S-bones.

14:06.000 --> 14:09.000
So why is this the problem?

14:09.000 --> 14:11.000
Why is this S-bomb not enough?

14:11.000 --> 14:16.000
So let's say we have a vulnerability that we come up with

14:16.000 --> 14:19.000
image scanning in our hello program.

14:19.000 --> 14:22.000
You know, it has some dependency on some library,

14:22.000 --> 14:26.000
library version 2.0.0.0, right?

14:26.000 --> 14:29.000
And we have a vulnerability in the

14:29.000 --> 14:31.000
slash-bind slash curl program.

14:31.000 --> 14:33.000
The problem is that the path through

14:33.000 --> 14:36.000
mediation for these vulnerabilities is quite different.

14:36.000 --> 14:38.000
In one case, we have to update our program,

14:38.000 --> 14:41.000
either fix a vulnerability or maybe a band

14:41.000 --> 14:42.000
dependency.

14:42.000 --> 14:45.000
But in the other case, it's not really our responsibility,

14:45.000 --> 14:47.000
although it is our responsibility.

14:47.000 --> 14:50.000
But it is not.

14:50.000 --> 14:53.000
We cannot easily fix a vulnerability in curl.

14:53.000 --> 14:55.000
What we have to do is actually wait for

14:55.000 --> 14:59.000
the maintainers of the goal and latest image to update

14:59.000 --> 15:02.000
it and then we can rebuild our image.

15:02.000 --> 15:05.000
So in the case of red hat, the goal and latest image

15:05.000 --> 15:08.000
would actually be managed by some other team.

15:08.000 --> 15:10.000
And so what needs to be noticed,

15:10.000 --> 15:12.000
notify the team and then rebuild our images,

15:12.000 --> 15:14.000
they are affected.

15:14.000 --> 15:16.000
And if we take a look at the base image contextualizes

15:16.000 --> 15:18.000
bomb, we can see that there is no way we can

15:18.000 --> 15:21.000
actually distinguish between these vulnerabilities.

15:21.000 --> 15:23.000
So what can we do?

15:27.000 --> 15:29.000
Because of the fact that in complex,

15:29.000 --> 15:31.000
we have access to the build process.

15:31.000 --> 15:33.000
We have access to some additional context that we can

15:33.000 --> 15:36.000
leverage to identify content and classify them

15:36.000 --> 15:38.000
between different images.

15:38.000 --> 15:41.000
So we also have access to the container file,

15:41.000 --> 15:44.000
which can be very useful because

15:44.000 --> 15:48.000
when copying content into your final stage of your image,

15:48.000 --> 15:50.000
you have to use the copy command.

15:50.000 --> 15:52.000
And what that gives you is the opportunity to

15:52.000 --> 15:55.000
see and list all the paths that you copy from

15:55.000 --> 15:57.000
into your final stage.

15:57.000 --> 15:59.000
So you can see that in the middle,

15:59.000 --> 16:01.000
square above.

16:01.000 --> 16:03.000
We have the goal and latest image,

16:03.000 --> 16:05.000
and we copy slash bin slash hello,

16:05.000 --> 16:07.000
and slash bin slash curl.

16:07.000 --> 16:09.000
Right, so we have that.

16:09.000 --> 16:11.000
But since we are in control of the build,

16:11.000 --> 16:14.000
we also have some other advantages,

16:14.000 --> 16:16.000
like build artifacts.

16:16.000 --> 16:18.000
So when we build an image,

16:18.000 --> 16:20.000
a lot of complicated stuff happens,

16:20.000 --> 16:22.000
but we also have some artifacts from the build,

16:22.000 --> 16:24.000
which we can leverage.

16:24.000 --> 16:25.000
So during the build,

16:25.000 --> 16:28.000
we of course pull the goal and latest image,

16:28.000 --> 16:31.000
and we have full access to its content content.

16:31.000 --> 16:35.000
But we also have a so-called intermediate image,

16:35.000 --> 16:38.000
which is probably not a very often used term,

16:38.000 --> 16:40.000
but in this context,

16:40.000 --> 16:44.000
it means a kind of image that is created

16:44.000 --> 16:49.000
when you run all the instructions in the builder stage.

16:49.000 --> 16:52.000
So if you take a look at the container file again,

16:52.000 --> 16:54.000
once we build our hello application,

16:54.000 --> 16:57.000
we create some kind of temporary partial image,

16:58.000 --> 17:02.000
that has all of the content already installed.

17:02.000 --> 17:05.000
And by combining these two sources of information,

17:05.000 --> 17:09.000
we can select selectively scan images,

17:09.000 --> 17:11.000
and only those past which interest us,

17:11.000 --> 17:14.000
and we can determine which content actually ends up

17:14.000 --> 17:16.000
in our final image.

17:16.000 --> 17:18.000
And so at the end of this process,

17:18.000 --> 17:20.000
that I simplify it quite a lot,

17:20.000 --> 17:22.000
but there's no time to go into it more.

17:22.000 --> 17:25.000
We have some kind of classification of packages,

17:25.000 --> 17:28.000
that were copied to the final image,

17:28.000 --> 17:30.000
and we know exactly where they came from.

17:30.000 --> 17:32.000
So we know that the hello program,

17:32.000 --> 17:33.000
and it's dependency lib,

17:33.000 --> 17:35.000
it's from the go-line latest builder image,

17:35.000 --> 17:37.000
or the builder base image,

17:37.000 --> 17:40.000
and we know that curl is from the intermediate image.

17:43.000 --> 17:46.000
Okay, what can we do with this information?

17:46.000 --> 17:50.000
If we take the base image contextualized as bombs,

17:50.000 --> 17:52.000
and again, utilize package matching,

17:52.000 --> 17:55.000
we can selectively classify which package

17:55.000 --> 17:58.000
originates from which builder image.

17:58.000 --> 18:01.000
So we know that by matching hello with hello,

18:01.000 --> 18:05.000
we get that this was built during our build process,

18:05.000 --> 18:07.000
so it is our responsibility to fix,

18:07.000 --> 18:12.000
and we know that CURL is from the go-line lightest builder image.

18:12.000 --> 18:15.000
So we have to do is notify the owners of that builder image,

18:15.000 --> 18:17.000
and rebuild our image.

18:17.000 --> 18:18.000
At the end of this,

18:18.000 --> 18:21.000
we get the fully contextualized bomb,

18:21.000 --> 18:26.000
which classifies the relationships between our images.

18:26.000 --> 18:29.000
So if we see the green, my component image,

18:29.000 --> 18:33.000
we see that it is a build tool of a go-line lightest,

18:33.000 --> 18:36.000
which specifies that go-line lightest is a builder image for this image,

18:36.000 --> 18:39.000
and also go-line lightest intermediate,

18:39.000 --> 18:41.000
it is the descendant of the go-line lightest,

18:41.000 --> 18:45.000
because it was originally that image,

18:45.000 --> 18:47.000
but we installed some content in it.

18:48.000 --> 18:54.000
And we have nicely classified packages between the different images in the build.

18:57.000 --> 18:59.000
So that's really all from our site.

18:59.000 --> 19:02.000
I hope that it was easily understood,

19:02.000 --> 19:04.000
but probably not.

19:06.000 --> 19:08.000
If you scan the QR code,

19:08.000 --> 19:10.000
you have access to some of our repositories,

19:10.000 --> 19:11.000
where we do the work,

19:11.000 --> 19:13.000
and also our emails, our contacts.

19:13.000 --> 19:15.000
If we have any questions,

19:15.000 --> 19:16.000
we'd love to hear them,

19:16.000 --> 19:18.000
and hopefully answer them.

19:18.000 --> 19:20.000
Good.

19:26.000 --> 19:27.000
Good.

19:27.000 --> 19:29.000
Thank you for keeping it very short,

19:29.000 --> 19:32.000
so we have more time for questions.

19:32.000 --> 19:33.000
You have the mics for you.

19:33.000 --> 19:35.000
What about tools,

19:35.000 --> 19:36.000
that allies,

19:36.000 --> 19:39.000
as long as we are full of descendant of relationships

19:39.000 --> 19:42.000
for building an entity for them,

19:42.000 --> 19:47.000
if you respond doesn't want to expose the dependencies,

19:47.000 --> 19:49.000
and what's?

19:49.000 --> 19:51.000
Those,

19:51.000 --> 19:52.000
as opposed to,

19:52.000 --> 19:53.000
is like,

19:53.000 --> 19:55.000
can you repeat the question?

19:55.000 --> 19:56.000
Yeah, I can repeat it.

19:56.000 --> 19:57.000
The question was,

19:57.000 --> 19:58.000
what are the other,

19:58.000 --> 20:00.000
if I understood it correctly,

20:00.000 --> 20:03.000
what are the other software types,

20:03.000 --> 20:04.000
right,

20:04.000 --> 20:05.000
except content images?

20:05.000 --> 20:07.000
If I analyze your conceptual,

20:08.000 --> 20:10.000
let's start with the other things.

20:10.000 --> 20:11.000
Okay.

20:11.000 --> 20:13.000
Set it up.

20:13.000 --> 20:14.000
Relationship,

20:14.000 --> 20:17.000
but that's not far away from building the entity.

20:17.000 --> 20:21.000
It doesn't see a lot of the analysis.

20:21.000 --> 20:25.000
How does that align with the fact,

20:25.000 --> 20:27.000
and what's to use this there?

20:27.000 --> 20:28.000
Yeah, this is a new concept,

20:28.000 --> 20:30.000
so the tooling for me is doing that.

20:30.000 --> 20:31.000
Yeah, sorry.

20:31.000 --> 20:32.000
Sorry about that.

20:32.000 --> 20:33.000
Yeah,

20:33.000 --> 20:36.000
the question was about tooling.

20:36.000 --> 20:40.000
What if the tooling doesn't understand the descendant of relationship, right?

20:40.000 --> 20:42.000
Yeah, this is a new kind of concept,

20:42.000 --> 20:45.000
so the tooling needs to be adapted for that.

20:45.000 --> 20:49.000
Okay, so we are working at delivering this solution in another redhead team,

20:49.000 --> 20:53.000
that they are need to adapt their tooling to understand this descendant of relationship.

20:53.000 --> 20:55.000
So it's a redhead job?

20:55.000 --> 20:56.000
Yeah, this is,

20:56.000 --> 20:57.000
yeah.

20:57.000 --> 20:58.000
The question was, if it is internal,

20:58.000 --> 21:00.000
but it could be used,

21:00.000 --> 21:01.000
and like,

21:01.000 --> 21:02.000
the concept is,

21:02.000 --> 21:03.000
we have basically,

21:03.000 --> 21:04.000
we have the tools, open source,

21:04.000 --> 21:05.000
and can be used,

21:05.000 --> 21:08.000
and that tooling might be adapted accordingly.

21:08.000 --> 21:10.000
Yeah, the approach is kind of experimental,

21:10.000 --> 21:13.000
so like there's no tooling that can actually take advantage of it,

21:13.000 --> 21:14.000
because the idea is new.

21:14.000 --> 21:15.000
Go ahead.

21:15.000 --> 21:18.000
When you're contextualizing it,

21:18.000 --> 21:21.000
this metadata stored in the A to itself,

21:21.000 --> 21:23.000
we'll see our information,

21:23.000 --> 21:25.000
so we're going to install system that now

21:25.000 --> 21:26.000
is always metadata.

21:26.000 --> 21:29.000
If you start programming.

21:29.000 --> 21:30.000
Okay.

21:30.000 --> 21:31.000
I'll repeat the question,

21:31.000 --> 21:32.000
but it's a clarify.

21:32.000 --> 21:34.000
About the data you mean,

21:34.000 --> 21:36.000
which part exactly do you mean the response of the images,

21:36.000 --> 21:37.000
or?

21:37.000 --> 21:40.000
You mentioned that you're contextualizing it,

21:40.000 --> 21:44.000
so you add things that you understood about this specific,

21:44.000 --> 21:46.000
the dependencies may be the versions

21:46.000 --> 21:49.000
or the relationships between the base and the environment.

21:49.000 --> 21:52.000
So if you kind of analyze this image,

21:52.000 --> 21:53.000
and you have to metadata.

21:53.000 --> 21:54.000
I was wondering,

21:54.000 --> 21:56.000
the metadata is one of our analysis,

21:56.000 --> 21:59.000
and then you have to understand how to report,

22:00.000 --> 22:03.000
or is it going to explain the image?

22:03.000 --> 22:04.000
Okay.

22:04.000 --> 22:05.000
To repeat the question,

22:05.000 --> 22:07.000
where is the metadata used for contextualization,

22:07.000 --> 22:08.000
actually coming from,

22:08.000 --> 22:10.000
is there internal system for that?

22:10.000 --> 22:12.000
So there is,

22:12.000 --> 22:14.000
there are the parent's s-bombs.

22:14.000 --> 22:17.000
Those are basically just analyzed s-bombs.

22:17.000 --> 22:19.000
We contextualize them if we can.

22:19.000 --> 22:20.000
If not,

22:20.000 --> 22:21.000
there are simply analyzes bombs,

22:21.000 --> 22:22.000
with the tool like sift.

22:22.000 --> 22:24.000
If we're talking about metadata,

22:24.000 --> 22:28.000
such as the actual container files and stuff like that,

22:28.000 --> 22:32.000
we have access to the build,

22:32.000 --> 22:36.000
so we can see all of the intermediate studies

22:36.000 --> 22:37.000
that get created there.

22:37.000 --> 22:39.000
So there's no special tooling.

22:39.000 --> 22:41.000
All of this is available when building an image.

22:41.000 --> 22:42.000
I'm not sure if that's enough,

22:42.000 --> 22:44.000
or maybe if you want to add something.

22:44.000 --> 22:45.000
No.

22:45.000 --> 22:46.000
You also want to.

22:46.000 --> 22:47.000
What?

22:49.000 --> 22:52.000
Where do you give this information about descendant total stuff?

22:52.000 --> 22:54.000
So is it inside the inventory?

22:54.000 --> 22:55.000
Yes.

22:55.000 --> 22:57.000
The question was,

22:57.000 --> 23:00.000
where we are keeping this information about descendant of,

23:00.000 --> 23:03.000
well actually in the contextual as well itself.

23:03.000 --> 23:06.000
So if you are building your base image,

23:06.000 --> 23:09.000
you will contextualize it.

23:09.000 --> 23:13.000
You will acknowledge about their parents in the chain.

23:13.000 --> 23:17.000
And while you are building your descendants,

23:17.000 --> 23:19.000
you are basically accumulating information

23:19.000 --> 23:21.000
downstream the chain.

23:21.000 --> 23:22.000
Does it make sense?

23:22.000 --> 23:23.000
Yes.

23:23.000 --> 23:25.000
But do you put these both inside of the chain?

23:25.000 --> 23:26.000
Yes.

23:26.000 --> 23:27.000
No way.

23:27.000 --> 23:29.000
We are actually storing it into places,

23:29.000 --> 23:32.000
in a class which is basically instance of TPA,

23:32.000 --> 23:34.000
which is open to our product,

23:34.000 --> 23:36.000
and we also storing them in a repository

23:36.000 --> 23:39.000
where we are storing all content images.

23:39.000 --> 23:40.000
Okay.

23:42.000 --> 23:43.000
Please go ahead.

23:43.000 --> 23:46.000
When you go to all the containers,

23:46.000 --> 23:48.000
you know, from the very base of it,

23:48.000 --> 23:50.000
you've been adding files to the application.

23:50.000 --> 23:52.000
Why are we just generating the next one,

23:52.000 --> 23:53.000
each of those states,

23:53.000 --> 23:55.000
and then looking at the delta change?

23:55.000 --> 23:57.000
Because that will find out which we compose

23:57.000 --> 23:59.000
come in at each state instead.

23:59.000 --> 24:00.000
You have,

24:00.000 --> 24:01.000
Exactly that.

24:01.000 --> 24:03.000
And then allow it to work with both sides of the edge,

24:03.000 --> 24:04.000
as well as actually the edge.

24:04.000 --> 24:05.000
Yes.

24:05.000 --> 24:07.000
So to repeat the question,

24:07.000 --> 24:08.000
why aren't we generating

24:08.000 --> 24:10.000
as bones from all the images in the chains?

24:10.000 --> 24:12.000
The answer is,

24:12.000 --> 24:13.000
we do exactly that.

24:13.000 --> 24:16.000
So this does not reflect well on the presentation,

24:16.000 --> 24:19.000
but basically the process that we use.

24:19.000 --> 24:21.000
Like every time we generate,

24:21.000 --> 24:22.000
we build an image,

24:22.000 --> 24:24.000
we generate an s-bone for it,

24:24.000 --> 24:27.000
and then once we generate an s-bone for the send-end of the image,

24:27.000 --> 24:29.000
we use the already generated s-bone,

24:29.000 --> 24:32.000
and then contextualize based of the whole s-bone,

24:32.000 --> 24:34.000
of the ancestors.

24:34.000 --> 24:35.000
Sorry.

24:37.000 --> 24:38.000
Yeah, pretty much.

24:42.000 --> 24:45.000
I mean, there's no real reason why.

24:45.000 --> 24:47.000
The question was,

24:47.000 --> 24:50.000
why we are not using cycle on the X as well.

24:50.000 --> 24:52.000
Yeah, we are not using that,

24:52.000 --> 24:56.000
because there is no like convenient relationship pattern there.

24:56.000 --> 24:57.000
So.

24:59.000 --> 25:00.000
Oh, yeah.

25:00.000 --> 25:01.000
Yes.

25:03.000 --> 25:05.000
As a simple tool user,

25:05.000 --> 25:06.000
using set-up,

25:06.000 --> 25:09.000
tri-bay for inspecting containers,

25:09.000 --> 25:13.000
I would say an optimal solution would be for me.

25:14.000 --> 25:16.000
This solution would be if those containers,

25:16.000 --> 25:17.000
containers,

25:17.000 --> 25:20.000
scan all the images in the world.

25:20.000 --> 25:24.000
I mean, would come with the content,

25:24.000 --> 25:25.000
I mean, with the information,

25:25.000 --> 25:29.000
do you assemble already in the s-bone,

25:29.000 --> 25:31.000
and having a s-bone,

25:31.000 --> 25:34.000
and with the text connected to it,

25:34.000 --> 25:35.000
so I couldn't,

25:35.000 --> 25:36.000
in the end,

25:36.000 --> 25:37.000
just really say okay,

25:37.000 --> 25:38.000
that's it.

25:38.000 --> 25:41.000
And even if you don't have access to that,

25:42.000 --> 25:43.000
I don't have access to that.

25:43.000 --> 25:44.000
So,

25:44.000 --> 25:45.000
that would not be good.

25:45.000 --> 25:46.000
Yeah.

25:46.000 --> 25:49.000
So it was a suggestion to generate s-bone

25:49.000 --> 25:52.000
for each image in this chain, right?

25:52.000 --> 25:54.000
Yeah, yeah, yeah.

25:54.000 --> 25:57.000
And what is the problem of this approach?

25:57.000 --> 25:58.000
I don't know.

25:58.000 --> 25:59.000
I don't know.

25:59.000 --> 26:00.000
Yeah, yeah.

26:00.000 --> 26:01.000
But yeah,

26:01.000 --> 26:03.000
but there is a one-one-like problem

26:03.000 --> 26:05.000
that you are so suggesting

26:05.000 --> 26:08.000
that you would take a look into this s-bone,

26:08.000 --> 26:09.000
which you,

26:09.000 --> 26:11.000
the up the chain, right?

26:11.000 --> 26:13.000
And you look where is the vulnerability.

26:13.000 --> 26:14.000
Yeah?

26:14.000 --> 26:16.000
This could be an approach.

26:16.000 --> 26:17.000
Definitely.

26:17.000 --> 26:19.000
It might be a simple way,

26:19.000 --> 26:21.000
but the problem is that

26:21.000 --> 26:23.000
the each s-bone you are taking a look

26:23.000 --> 26:26.000
is basically content of this particular image,

26:26.000 --> 26:28.000
for a particular base image.

26:28.000 --> 26:31.000
And while you are doing some installments

26:31.000 --> 26:32.000
downstream,

26:32.000 --> 26:33.000
you are changing this content.

26:33.000 --> 26:34.000
Why?

26:34.000 --> 26:36.000
Because you can delete the content.

26:36.000 --> 26:38.000
You are updating your packages.

26:38.000 --> 26:40.000
And at the package managers,

26:40.000 --> 26:42.000
I'm basically removing older packages.

26:42.000 --> 26:45.000
So this is not like the correct representation.

26:45.000 --> 26:48.000
Downstream, there is a contact show as well,

26:48.000 --> 26:49.000
which is like,

26:49.000 --> 26:50.000
absolutely,

26:50.000 --> 26:51.000
let's say,

26:51.000 --> 26:53.000
most precise representation

26:53.000 --> 26:56.000
of the content from all this chain.

26:56.000 --> 26:57.000
Okay?

26:57.000 --> 27:00.000
If you take a look to steps about,

27:00.000 --> 27:02.000
this is not like,

27:02.000 --> 27:03.000
or rather say,

27:03.000 --> 27:04.000
downstream,

27:04.000 --> 27:07.000
we are not super set of all the packages

27:07.000 --> 27:09.000
that are installed,

27:09.000 --> 27:10.000
M-O.

27:10.000 --> 27:11.000
Yes.

27:11.000 --> 27:12.000
Okay.

27:12.000 --> 27:13.000
That's what we see.

27:13.000 --> 27:14.000
Thank you.

27:14.000 --> 27:15.000
We have time.

27:15.000 --> 27:16.000
I think so.

27:16.000 --> 27:17.000
Yeah.

27:17.000 --> 27:18.000
I'll go ahead, please.

27:18.000 --> 27:19.000
Yes.

27:19.000 --> 27:21.000
I'll go ahead, please.

27:21.000 --> 27:22.000
Yes.

27:22.000 --> 27:25.000
We just use the action way to allow systems.

27:25.000 --> 27:28.000
Because I have to update and I can use this,

27:28.000 --> 27:29.000
for example,

27:29.000 --> 27:30.000
between five blocks,

27:30.000 --> 27:31.000
and use it for,

27:31.000 --> 27:33.000
we know that you designed the license.

27:35.000 --> 27:36.000
Okay.

27:36.000 --> 27:37.000
Okay.

27:37.000 --> 27:38.000
To repeat the question.

27:43.000 --> 27:45.000
Sorry, I'm deaf in the horse.

27:45.000 --> 27:46.000
Okay.

27:46.000 --> 27:47.000
It's a long question.

27:47.000 --> 27:48.000
So,

27:48.000 --> 27:49.000
okay, I'll touch some rice,

27:49.000 --> 27:50.000
hopefully it's correct.

27:50.000 --> 27:53.000
So, can we use this for different platforms?

27:53.000 --> 27:54.000
Okay.

27:54.000 --> 27:55.000
And,

27:55.000 --> 27:57.000
what do we actually do?

27:57.000 --> 28:00.000
If we scan the layers of images.

28:00.000 --> 28:01.000
Right?

28:01.000 --> 28:02.000
That was the question?

28:02.000 --> 28:05.000
You just need the action way to allow systems.

28:05.000 --> 28:06.000
Yeah.

28:06.000 --> 28:08.000
If we have access to each layer,

28:08.000 --> 28:11.000
to just the response or each layer.

28:11.000 --> 28:12.000
We have access to the layers.

28:12.000 --> 28:14.000
Since complex is a build system,

28:14.000 --> 28:17.000
we are using build data to build our images.

28:17.000 --> 28:20.000
We can basically inspect each layer

28:20.000 --> 28:23.000
and see what control region is there.

28:23.000 --> 28:26.000
And so, we can scan just that content in each layer of the image.

28:26.000 --> 28:29.000
And then we get, basically, the package is present in that layer.

28:29.000 --> 28:32.000
And this way, we can contextualize the response.

28:32.000 --> 28:35.000
I'm not sure that's cool enough.

28:35.000 --> 28:36.000
Okay.

28:36.000 --> 28:37.000
Thanks.

28:37.000 --> 28:38.000
Thank you.

28:38.000 --> 28:40.000
Thank you.