So, the interesting thing as an introduction is I happen to be one of the co-founder of SPDX.
Steve is the creator of Cyclone DX, which are two of the most permanent S-bomb standard.
So, it's great that we can go on stage together.
But basically, you don't need a S-bomb, that's what we want to talk about today.
So, that's our agenda.
I'm Philippe O'Modern, I'm the maintainer of a series of open source projects called
about code.
I'm also a co-founder of clearly defined co-founder of SPDX.
I've got a co- contributor to Cyclone DX, and also behind a small thing we're going to
talk about today called Burl.
That's much easier than switching back and forth.
Is it working now?
Okay.
I'm Steve Springet, hello.
Good afternoon.
I'm on the O'Wass Board of Directors.
I am the leader of, as Philippe mentioned, Cyclone DX, as well as dependency track, and
I'm also chair of ECMA TC54, which, among other things, is stand-alizing packed package
you are on?
It's yours.
I see, we're in the beginning, in the beginning, we had SPDX 1.0.
It was great, because first of all, we had licensed compliance as a thing.
A couple of years later, I actually had the need to track software and hardware inventories,
and be able to do that in a system, it was called dependency track, version 1.
I had an intern actually, right at four, and it was horrible piece of software, but not
because of the intern's fault, because of my fault, for sure, but it was a horrible piece
of software.
For the first time, it allowed me to track the hardware and the software inventories,
and using CPE's, it allowed me to identify vulnerabilities in that inventory.
And I have a red line here.
And that red line is reminiscent of the CPE health that we were all kind of living in, right?
Fuzzy matching health.
It was not good.
It wasn't until, let's see, OSS index came out the next year, and OSS index was a small
little project from a company called Vorescurity at the time.
They were later acquired by some of the type.
But OSS index had the ability to at least query by MD5-HASH or SHA1-HASH.
That was certainly an improvement, but it required at least that you actually produced
your inventory in some kind of a build process.
It really wasn't until package URL really started to become a thing in 2017, that finally
we actually had a much more precise mechanism of identifying a specific library and that
version of that library.
Around the same time, CycloneDex1.0 was coming out, same time the package URL was, and
we quickly realized the value of using package URL for basic vulnerability management.
So version 1.0 of Cyclone absolutely had support for Pearl, and for the first time with
dependency track version 3, which wasn't the crappy piece of software, we were actually able
to use an S-bomb and do basic vulnerability management for the very first time.
S-pdx2.2 was released a couple of years later, and also included support for CPE as
well as Pearls.
So the basic use case for Pearls and S-bomb's in general was vulnerability management.
For the first time, it was a human readable, but machine-processable software identifier, right?
And those are the key important ingredients.
If you think about a hash or a checksum, that's essentially the coordinates, like GPS,
the exact location of where your barbecue grill is in your backyard.
A Pearl is much like your address, right?
You give your street address out, you give some snail mailbox, and that's essentially
what Pearl is, right?
A little bit more granular.
The portability of the components, the inventory of components, is kind of essential
for the vulnerability management use case, as well as prominence of those components.
But those are really the only key ingredients.
The interesting part about S-bomb as a thing is it wasn't until 2020 when we started really
talking about regulation, that the graph really starts to show an upwards trend.
Now, we're just looking at the cyclone DX tool center, because that's what I have data
on.
But the same trend exists for S-PDX.
It's no different.
What we see is that with regulation, this dotted line represents the executive order
14028 in the United States, but CRA, everything else is on the right side of this chart.
With regulation, we see an explosion of available tools that support S-bombs.
But really, Pearl is what it made it all happen.
Pearl is what allowed us to go from CPE's, which allowed some degree of automation, to
Pearl, which allowed us to do hyper-automation.
S-bombs describe the software composition, but Pearls make those descriptions machine
readable and actionable.
And actually, that's not only Steve saying there was a study published, I think, around the
soft S-bomb for healthcare, where the effort, I couldn't find the URL anymore, but
said essentially an S-bomb with a Pearl is not something that's actionable.
So, Pearl, who has not heard about Pearl?
Raise your hand.
Okay, that's okay.
You can exist.
This presentation is not for you.
But so, it's a very stupid dumb dumb, small string that you can use to point to a package.
And you just look at the package manifest, you can find what the Pearl is.
The great thing about it is that unique naming is something that's delegated to package
a system.
And PM may learn and likes.
So, zero friction from what you see as a software developer to what's the name that
you can use across a system.
It's not an McMaster standard since December 6, anybody from McMahe here?
Oh, Steve, at least.
Many of you have been participating in this standardization effort, so thank you very much.
It's on the way to become an ISO standard, which is very humbling for a very tiny string like
that.
It's already actually included in S-bomb Vex, up and Vex, sorry, but also in ISO standard,
which is kind of weird where the standard was not completed and it was already part of ISO
standard.
Yeah, no, that's cool, which is a good thing I've seen from the standard perspective is
making sure you the standard is adopted before it becomes a real standard.
So, Pearl, enable actionable S-bomb and S-C-A, wizard it for vulnerabilities.
The point is you can look up and enrich information.
You can share Vex, I see there's a guide that creates a standard call up and Vex, which is
all based on package URLs, so it's also the case for S-C-A and S-C-A video.
The whole point is that you scan code, you get a Pearl, you can look up in your wrongs database.
There's a lot of information available in different tools here.
The point is that you can use it across the board and if you were to drop anything about
S-bombs and just focus on Pearl and this Pearls would be correct, that would be a massive
set forward towards a better supply chain.
So, the goal besides to get everyone to adopt Pearls is allowing us to share better inventories.
Obviously cyclone and S-P-D-D-F supported, but quick note, we've supported
I work for a company called ServiceNow, we've actually had support for Pearl in our inventory
of all the things that we have, both internally and externally, since about 2019.
So we're tracking upwards of 100,000 components internally and Pearl is our identifier for everything.
So hopefully we can disclose better vulnerabilities, which don't require us to search
with, like we used to do in the past with S-P-E-S, S-V-E since October 29th, as merged support
for package URL in the S-B-S-Q-M-O.
Open V-X-C-S-F, OS-V, all support package URL and we mention also OS-S-N-X, which has been
kicked by Pearl for a long period of time.
It's adopted industry-wise, I won't go into the details.
The slides will be available, upload it on the talk afterwards.
The thing is that committee adoption is great, but we need better and standardized Pearl.
OK.
Unfortunately, S-B-M quality and clarity is a problem.
We probably, many of you may know about it, but it's going to be a growing issue where
different tools produce different outcomes on the exact same input.
It's going to create a lot of friction because people just discuss about, oh, your S-B-M is not
right, my tool produce better S-B-M than yours.
We will need to find a way to lower the temperature on all these discussions.
There's a project led by Marcel over there, raise your hand,
go digital the means that producing S-B-M, benchmarks, another one from
Gagolix, Atari, from Nokia, called S-B-Q-E.org.
The point is working on ensuring that our tools produce
correctness, but I'm essentially correct, Pearl is going to be super important.
We need to validate Pearl's, but your initiative is going on there.
We've built tools to help you do that.
And Bell benchmark, I just talk about it, you have all the links.
Eventually, with these tools, there's no excuse, not to produce correct
Pearls in your tools, or in the tools of your vendors, or in the tools of your
supply chain partners, which ideally should never produce drunk pearls.
You should give them access to these open tools and reject
invalidase bomb with invalid pearls as drunk.
As Philippe was mentioning, Pearl is now a T-C-54 standard.
It's on its way to becoming an ISO standard.
T-C-54 is a group focusing specifically on software and system transparency.
If there are any specifications that are community-based,
that you believe would be worthy of an international standard,
that might fit this realm of software and system transparency.
Please reach out to me.
Actors have been a really great organization to work with.
They really, what we did real briefly is I dissected, essentially,
I decompose T-C-39, which is JavaScript, or JavaScript, right?
And how in the world can an entire programming language
produce an international standard every single year?
And I decompose exactly what they did, and we reproduced it.
It's now the model for all future T-Cs that are community-based with an ECMA.
So, if we, as a community, if we want to start developing standards,
that have a path to ISO and elsewhere,
ECMA might be a really good place for you.
So reach out to me if that's, that's an interest.
Yeah, so we're trying to bring better pearls.
Lots of initiatives in the ecosystem.
One, I'd like to point out is a series of beach cleaning operations,
boring, a term that was coined by MunaWar from a benrefactory last year.
And basically, it's rather than to fix things, the downstream is work with a
ecosystem, to bring clarity, clarity, specific cleaning skills,
for next packages, rust, and mevan.
Let me move forward.
Another thing is clear defined, which is a project at the OSI,
which has 55 millions of packages can, not always really available,
because there's a tiny APIs that we're working on two things.
First, ensuring there's a pearl API for that,
because every service user is a pretty defined as build pearl adapters,
but they're in fact an ensure it can define pretty,
predates the existence of pearl, by the way.
And we want to make sure that this data,
kit by pearl, is way deavailable to everyone.
In the end, pearls and verse need you.
There's really something that I want to highlight,
especially in relation to the producer,
when I was not allowed to speak more.
Bineries and CC++ is a place where pearl is as a dark spot.
We rely on the fact that you have any ecosystem.
If you're not incorporated in the ecosystem,
for small projects like, say, the Linux kernel,
open SSL, things that's really power,
most of the way today, there's no pearl, or they can be an ugly generic pearl.
We are working with these communities,
especially there's a project in the ISO C++ community,
called CPS, that Ariane, you know about.
OK, we can discuss about it.
But there's efforts there for C-Make to find ways
to get better informations in Bineries and basically how you collect
information from C-Make builds in terms of configuration.
There's also NAMASAN in the back.
NAMASAN, please raise your hand, higher.
NAMASAN is a project called S3, E-S-S-T-R-A.
And S3 is a set of plugins for GCC and L-V-M
that can collect all the dependencies in your build,
and eventually inject that in your L.
So you have literally an S-Bomb in your health
that you can keep a drop.
And that's pretty much it.
We've received lots of support.
Some of you are busy in the European Union here.
Raise your hand.
Do you pay taxes?
Raise your hand?
Thank you for your help.
And for your support to make this happen.
So you pay for that.
You can use it now.
Thank you for your help.
Do we have time for a question?
Please.
One.
No, no, no.
Okay, no questions.