All right, welcome.
Finally enough, I think it was exactly here in 2018 that it was standing in this exact
samurai checked it.
Talking about some single package URL of parallel, actually introducing it a bit to the
world.
So the dev room schedule is a bit behind.
So with a show of hand, who has not heard about package URL or
parallel.
Okay, so we still go through the presentation.
We still go through the presentation.
Otherwise, I would have just passed and yield it to the next speaker.
So I'm the lead designer of a project called About Code and
Scan Code.
I'm also your lead commenter of a few S-bomb-related standards like
SPDX or I'm also co-contributed to secure the X because standards, you know,
we'll like them, we want more of them.
So we can pick and choose.
And everything I do is free an open source software,
and that's an open standards.
So if we go back in 2017, the problem I had was simple.
We're building this tool called Scan Code, which scans for package origin,
license, and a bit of dependencies.
Actually, the maintenance somewhere in the room.
Raise your hand.
And we had this problem, which is users were saying,
what do you do about security?
And we said, we do nothing.
What do you do about security?
We do nothing.
And a certain time it says, okay, let's try to do something.
And we were trying to look up in something which was called the OSVDB.
Other known also as the open source vulnerability database,
which was absolutely not open source, by the way.
It's fiercely proprietary.
It became something called risk-based security.
It was a really open washing.
And another one called the National Volunteer Database in the US.
And this was a very painful process.
We were just cracking our head, trying to find if this package we had scan
was actually the bare of non-secret issue.
It was really painful.
We did craft this small standard.
Well, it wasn't standard at the beginning.
It was just a way for us to literally have an identity failure.
So we could look up in the room to the database.
And since existing volume to the database is the new,
how to look up that I don't failure, we created one.
Because why not?
You know, more power.
It's not really a volume to the database.
It's more an aggregated database of existing non-secret issues.
Keep by-pro.
And the problem here, simple, is you think about OpenSSL,
or something like five utils.
You have one in Ruby gems, one in NPM, one in PIPI,
OpenSSL is speculated by multiple distrusts,
sometimes it's vendor, in crates, in Python wheels.
So each of these are subtly similar and subtly different.
And you need to be able to talk about then if shunty to figure out
is this package used?
Is this package vulnerable?
It's going to fix.
So that was the title slides back then.
We ended up setting up more of a Braille,
like Logo for now, rather than a cat's,
but it was a very tiny cat.
On the side, it was a challenge, if I recall,
to find who actually had taken this picture.
And what was the license?
So we have this problem.
You know, looking up from scan to package.
And we needed a way to do that.
And others were having the same problem.
Folks, for instance, at Sonataip,
with the OSS index, had the problem.
Initially, it was an ID that came from a company called JetFrog,
which does something called the Artifactory.
They had a project with Google Graphias.
And they had something which looked very much like a package URL,
that wasn't fast forward today.
We extracted the spec.
It's hard work to make sure you modularize any bit of your project to reuse.
But it's useful.
Sometimes it is.
We also went through the excruciating process of making it eventually real standard.
Because the seat of the pen spec written by somebody that knows nothing about it,
is a pain for everyone to implement.
And should out to the folks who make more,
I can hear you in the room.
Hey, that's been really awesome as part of a technical committee called TCC54.
You may not know about ECMA, but you know about JavaScript.
Sorry for you.
But there's something called TCC39 at ECMA,
which has been standardizing the JavaScript language.
And TCC54 is about the same,
but for cyclone DX,
and software supply chain transparency,
and really to the PR, including PR.
So, it's a standard.
Now, and that was painful.
But it became a standard on,
I think, you know better.
December fix.
Okay.
Interestingly enough, it was already back then,
already part of an ISO standard,
which is the OECCSCF20.
It was already part of SPDX and cyclone DX.
And it became merge into the CV schema.
As an alternative to what's called CPI,
back in on the 29th of October 2025.
And it's interesting because I had a bit of back and forth
with the MITRE people from CV says,
when is it becoming a standard?
Because it's a bit annoying for us if we merge it into CV,
but it's not yet a standard.
So, there's another standard coming up,
which is very relevant to package management,
not only for vulnerability, but also for dependency resolution,
which is how to have the command syntax to say,
this is a functional dependency set of version that I depend on,
or this is the set of vulnerable versions.
And that's it.
It's everywhere.
I think it helps makes,
as bomb and software conversion that is actionable.
I like to say that if you throw away all the as bombs,
all the alphabet soup,
and you just provide the list of pearls of what's in your product software app,
and share that with others.
That will be a massive step forward in transparency,
and actually making what we call the software supply chain,
eventually something that resembles a chain.
That's what I have to say.
It's used everywhere.
Again, ways of cycling the X's off.
We have a lot of initiative to work on better pearls.
I'll make sure I attack the slides to the first damage
and the cloud.
We need your help.
One duck spot that I want to talk about,
and actually this guy in blue there that I'd pointing my finger to,
may exactly block post on that topic, a couple days ago,
which is the small set of cc plus plus packages.
And that's going to be my last word.
That poor internet today.
Small things like openness,
a cell,
There's a dark spot, because they're unincorporated.
There's no proof of them, and they want to be able to report actionable vulnerabilities.
We have the vessel, which is the CV schema.
We have enough shelf standard.
We now are trying to think whether we can do kind of community days, mini registry to provide
just the name, people can rely on to reference to the kernel of an SSL unlike.
I had a long discussion yesterday, with a guy that's meant to have Linux stable.
That's some of you may know called Greg Koratman, who's kind of the top dog in the space.
Anyone else?
He wants a girl so he can, he's the number two producers of CV in the world today.
Just behind word fans.
He wants a girl so he can attach that to every of his CV.
So please join help us make that a better place.
That's it.
I'm behind on time, so if you want to take questions, I'll be outside.
Okay, so go for questions.
Who hates Pearl?
I'm making the questions.
I need more haters.
I don't have enough.
Good, one, two, three.
Perfect.
Okay.
Good.
So we work a lot with the pearls in their spots and in my opinion, it's the right approach to do it.
But the problem really is that many of the officers' tools, even if there is a Pearl in the
Espoam, they don't care and they just evaluate some other things like the name or the version.
But that you get completely different results across the tools.
Yes.
So it's a big question.
Yeah, so the repeating the question, different tools return different package
URL for the same input.
No, no, if you have an Espoam with a package URL, ask them the tools, the sketch, not
there.
The generators, but the CV is going to ask them whatever which evaluates the Espoam,
they don't look at the Pearl, but they use other fields from the Espoam and evaluates
that.
The symbolites.
Yeah, so the problem is simple is that there are only a few volunteer database today,
which are fully available to the by Pearl.
The OSV is doing a great job.
You have OSS index from Sonataip.
We have one called Van Gogh Code.
There was a meeting earlier this week for an initiative among many folks that do volunteer database
and deal with volunteer management to try to find a way.
How can we better exchange that out?
If we have somebody in the kernel that manage CVs, that stops putting Pearls in all their
CVs, eventually we'll get information upstream at the root.
That will make it more efficient.
But there's another related problem which is tools in Van Gogh's package URL.
Because I was not making the spec strict enough and clear enough, it's in point.
So there's suicide.
The in Van package URL or the maker package URL.
I was with last year or year, maybe a year or a half ago, working with large company,
which had basically about every single tool in the market in different teams.
More important to them is this, it's nice.
We should use up and source and the project we did was to scan,
have each of the product team in this commercial company, scan a bunch of very standard
based container image.
With their own commercial tool, share the SBOM, so we would compare the stuff.
We saw it would be a two weeks job that was easy PC, get a cyclone DX, literally almost
did them, and it was a total freaking mess.
I mean, we really had our eyes crying in valid schema, don't even talk about just even
very jazzy on in some case, which didn't even pass.
In one case, which I always use as an interesting, really problematic case,
base universal image from Red Hat, which is all our pins.
It is one of the commercial tools that detected a debutant package.
It was not fundamentally entirely wrong because it was the correct base version for that
package, but it was not the correct patch, and last I looked, Red Hat doesn't package
the debutant package, yes, maybe they should.
You could, many of us could do this kind of Frankenstein image, but Red Hat doesn't do
it.
One, you're trying to fix the vulnerable package that's a debutant package in Red Hat.
You're going to scratch your head and waste a lot of energy trying to find the right solution.
You could install a PTGET on the Red Hat image too.
The mask, RPM, is not really vulnerable in another issue.
Thank you.