So, as you could have imagined that's going to be a security talk, right?
So, my name is Marta, and I do a lot of security stuff around the bed at, and this is Samantha.
Hi, everyone.
And we are going to talk about the extensions we are working on on the Werneribit Management for the Yachter Project.
So, okay, the clicker doesn't work, there we go.
So, the Yachter Project has a tool called CVE Check.
Who of you has already used that?
Yep, about half of the room it looks, and side up.
So, it's a tool to check for non-verneribitis in a Yachter Project build.
And it has some interesting features, like it's pretty fast, because in a four-bit you are adding like two or three minutes to the time.
It uses the metadata from the recipes you already have in the Yachter Project.
And it has some specific options that allow you to do an override of certain results for either a specific vulnerability or a specific package, for example.
And it supports the fact that you are patching a CV in a package.
So, the fact that you have a patch, it is reflected inside the report.
The tool has a few limitations still.
So, it is using package versions as they declared only.
So, it doesn't look if that package actually has this vulnerability.
Then, if someone copies code, library or parts of a code inside the different package, this composition isn't handled.
And for the same reasons, some of the package managers do not work neither with that.
So, if you want to learn more about the CV check, I'm doing a lot of talks about that.
I think that the one from 23 was a pretty much complete.
And just after for them, 2024, there was something called NVD crisis.
It started in February.
The NVD database that we use for the report of pending vulnerabilities, they just stopped adding new entries.
The CV program was still working, but NVD wasn't filling up with new data.
It was a little bit visible before, but we still do not know what exactly happened.
They restarted work, but they still have big backlog.
But that wasn't yet.
They had also big API issues in December.
At that time, people were reporting and me too.
Don't load lasting for like 24 hours when you restarted it multiple times.
It was very complicated.
And we are in 2025.
The NVD database is handled by a US governmental organization.
As you may have heard, they have cut budget.
Right?
And we do not have official information, but from just looking what NVD is doing right now,
you can see that NVD is not doing much.
In January, they have added information to less than 10% of the entries.
And we can assume that it's going to continue this way.
This work that we have started that has a few ideas behind.
The first idea was the risk of the pending NVD.
And we were in a good situation that CV database itself started adding machine readable package format in 2024.
Not enough entries, but still it is now possible.
Another point is that with the recent regulations and all the geopolitics,
we have a real risk to see national or continent of NVD databases that you would be obliged to use.
Right?
Then, we have also the rise of Asmond Generation.
So, can we reuse the work done by S1?
People too, for vulnerabilities.
And there is a very big practical problem.
You have your product.
You have done the CV analysis when you were releasing it.
And then you want to redo it.
For example, five years later.
Do you want to keep the exact build five years ago,
or well not very practical, and probably it's going to be lost for some reason?
And for the security check, we just need some of the information not everything.
So, really, there's no need to keep that build directory.
So, there are a few abbreviations in the whole story.
So, the CV command vulnerability and remuneration.
That's the database of vulnerabilities those days.
As well as software build materials.
Data format containing list of packages,
reservation, dependencies, licensing, and well.
You can add a lot of stuff.
They are basically two variants, SPDX, second eggs.
In the Octo project, there is SPDX.
And then, finally, something less common.
The Vx vulnerability exchange.
This is kind of annotations for vulnerabilities.
In a Vx report, you can say, what, how does it affect your product?
For example, you can say that your product is vulnerable to this one.
But you can also say, the vulnerability is present, but I am not vulnerable.
Because in the setting, in the configuration options,
I use it will never be possible to exploit.
Or, I compiled out the vulnerability code, it's just not there.
They are still, as you read the multiple formats,
the two most popular CSF and OpenVx.
So, on the technical side, our idea was to run the check externally
from a Octo build, grab the data from the build,
and then run the check, and it could be five years, 10 years, 20 years later.
We wanted to have a possibility to plug in different databases.
If we need to add all the elements in the data flow.
And we wanted to support the metadata that is available right now in the Octo project,
or the work that has been done to fix the CPEs to do overrides
for certain vulnerabilities and so on and so on.
So, Samantha is going to work through the architecture part.
Thank you.
So, can you hear me well?
Yeah, sorry, okay, thanks.
So, on the technical side of this project, what we initially had in mind
while designing this external checker was to add first extract
and gather packages information of a district,
especially packages names and version, which is information
available by reading the SPDX summary file.
You can generate by.
Okay.
So, you can get this information from the SPDX summary file.
You can generate by inheriting the Create SPDX BB class.
So, using this packages list, we could then request either NVD database
or CV roll database package per package to get every related CVs.
Then combining both texts of information, you can then generate a fixed report.
It can either be individual files, each representing one vulnerability
or a summary of both.
In addition, we wanted to add a task that can update the SPDX files
to just add the link to a VX file.
So, it could ease a bit parsing and navigation through all those files.
So, this is quite a straightforward approach to generate a VX report.
So, let's jump right into the issue and limitation we've came across.
So, first thing we've noticed at that the SPDX generation is designed
to generate SPDX reports on built images.
So, you cannot run a partial build to get those information.
It is a little bit time consuming and it is definitely something you should keep in mind
when you want to generate either SPDX or VX report.
So, now on two bigger issues, we had many parsing issues on CVs,
especially using the ROCV database.
So, as you can see this is just an example, but we had quite a few instances
of CVs like this one.
So, every critical information is written out in the description text.
And nowhere else.
It is also the case for the version description which was described as well
which announced in order to describe more of the ranges that were affected.
It was long sentences in written in various ways.
So, it was quite difficult to find a way to pass automatically all of this.
And then we entered the last category of limitation with KM across which is the metadata.
So, within the VX standard there is only four available statuses.
You can flag a CV.
So, it can be either affected, not affected, fixed or under investigation.
Which does not reflect in that situation's centuries wrong
and we are waiting on the update or this vulnerability is disputed and so on.
That's one limitation.
And the last one is that we had unexpected results when using O2.
So, at first the results we had the CV results we had when using O2
differed a bit from the CV check results we can get from the CV check baby class.
So, some CVs were flagged as affected in one case and not affected in the other.
So, we found that we were missing some critical information that we can get by the metadata.
So, metadata collected by the CV check.
And so, our error was due to the fact that in some specific cases packages were flagged as affected
whereas, in reality, the issue was the issue is not applicable in the context of a youtube project build.
So, you probably guessed the improvement we've made to our architecture.
We added the metadata of the CV check as an input of O2.
And this way it was fixed the discrepancy we've just talked about.
And it also fixed the not too detailed, vex status situation.
Meaning that vex does support only for kind of CV status.
But the standard supports additional annotations such as the status notes and justification.
So, that's where we drifted away a bit from the open vex standard by adding your own custom status note and justification.
We got from the CV check metadata.
So, for example, you can have a CV flagged as affected.
The status note stating extreme one fix and the justification such as this is from an abandoned project and so on.
And as for the CV parsing issue, fortunately we have a good news.
There is a new format that had Blossom which is called ADP entry.
It is easy to parse and it is progressively implemented into the raw CV database.
And I will let my title continue.
To rush to the rest of the presentation.
So, the status today.
We have the vex Bb because of the metadata information indexed in the format.
That is available in the other project today.
The tooling is currently hosted separately.
And we are working on the overhead format so that then we can reintegrate it in the.
In the vector project.
Short instruction how if you want to try it.
Basically, in your local conf you need to add in her it vex.
Entrem of CV check if you have it.
You bid as usual.
You download the databases.
So, we have a separate script to download NVD and you have the overheads of CV.
Then the tool.
There are few options to give.
So, the input file that you get from the vector build.
They output directory when you want to have the result files.
We need to separate the directory directory.
And you point to the database type and the database location that you want to use.
And then it goes and generates file files.
Then we have also post processing scripts that you can use to.
To show up the results in a.
You can also generate it to CSV.
If you want to.
That is a simple input from core image.
Minimal pretty up to date or not many.
CV is present.
Our future plans is to bring that.
To link to the official repo integrate with the octobio.
As usual, not testing documentation.
It really will come and we have a lot of possibilities for new features.
For multiple databases, the database is like OSV.
I guess that you cannot hear.
And working on how we can integrate.
Overall, that is plus specific product.
This is some research work that we want to do in the future.
Probably you won't have time for questions, right?
No.
So, we can talk outside.
Thank you.