All right, so good morning, good morning, welcome, bonjour, good morning, yeah, I can
speak too many languages.
For the people that know who I am, my name is Thomas Niemburger, I'm the head of the
open source program officer at IPAM, I'm involved in several, well you can call it open source
governance S-bomb related projects, including I run the security profile over the defects
team, so if people have questions about security information in SPX3, I'm happy to answer those
as well.
I decided to just not make pretty slides, but to just open a browser, so to be more
like a demo, and to make it a little bit more interactive, since I'm the first talker, I
have to keep you all awake, and I'm usually a very high energy person.
Apparently last night I was compared to Opalix, and I fell into a fat of open source juice,
and therefore I'm all hyped up on open source stuff.
So yeah, so I normally can talk very fast, so I will try to be a little bit slower.
So I'm here a little bit to talk about Oort, Oort is a project, or Oort is a review toolkit,
the screen, better, perfect, like first talk.
So it should work, hopefully my internet is all working, so yeah, if you are on GitHub
you can find Oort here, the full name is OSS review toolkit, or open source software review
toolkit, it's a very complex name, it's actually for those people that are German.
Oort in German means place, and I used to work for a location company, and all of our
open source project had a location pun in them, so we were really trying to figure out
all of the names, and how can we make a location name, and this is where we lined it on.
So I'm actually going to do somewhat a live demo, but my internet is not working 100%,
so we're just going to do it like this, where I just have luckily pages open, and I'll show
you through.
So if you want to get started with Oort, the easiest way is actually to use the GitHub
action, and you can just literally, as the code shows here, you just add a few lines,
and basically it's very standard.
For people that are familiar with GitHub actions, in the middle there's a checkout.
The line on top is a little bit different, and then you run Oort itself.
This line is a little bit different, and it has to do with how Oort generates S-bombs.
So for to create good S-bombs, you can make S-bombs that basically only operate on kind
of like the declared license, the basic package data, but if you want to have a proper, what
do you want to do?
I originally have worked in the automotive industry, we want to know everything down
to source level.
And why is that?
It's actually very simple, in the automotive business, basically products on the market,
the minimum lifespan is 15 years, and it can go up to 25 years or longer.
There's a vehicle on the road, it's minimum 10 years on the road, plus European legislation,
contract law is another five years, 15 years.
So all the solutions that we built for S-bombs, my successor, my successor, my successor, still
needs to be able.
So this is why we started building the way how Oort is designed, that we were like, hmm,
we need a format that we can take the scan results that we have, and all of that have,
we can just do, store them long term in a public format, that even if the tooling that
we write doesn't exist anymore in 10 years, it's an international standard, so they can
just write a new parser, read in this, and then of course I stumbled upon, and then I
happened to make Kate's at Fostam in the bus.
And so we got talking, and I was like, hey, that's interesting, this S-bomb thing, so
this is like years ago, like what, 2015-ish, I think, 16-ish, a long, long time ago.
So then I was like, hang on, I can solve two of my problems, I can basically have an output
format that is recognized, so I have a long-term archive format, and I also have a format that
I need it to exchange, so there are two forms of, why is that?
In automotive, there is a long supply chain.
So what we have commonly, we call this hamburgers, where you get something from a supplier, you
do your thing, then it goes to another supplier, and then my company will be again in there.
So we were just looking at what is the solution that we can, in the supply chain, basically
exchange information, it still is, unfortunately, automotive, so still a lot of paper-based
processes, and we were like, no, no, we need to go digital.
So what you now see, luckily, is that some of the large German ones, which again, I'm
based in Berlin, Germany, they are already switching to, basically, say, S-bombs, and
then, no, no, no, yeah, you can still do paper, but we actually prefer you to give us an S-bomb,
because then they can ingest it much more easier, and so yeah, we basically do SPDX,
and actually we also support starting this for exchange, and also for archiving.
So yeah, now, my talk was about how do you generate it, so it's actually very simple.
So I took here the MimeTime projects, which is kind of our default project, it's a small
node project, and if I want to do an S-bomb for it, it's actually very simple for people
that are familiar with GitHub Actions, you can just run the action, and there's as simple
as it is, and you can also do this in GitLab, I don't know for people familiar with GitLab,
but basically it's all the same, you just run a GitLab pipeline, it says org scan,
and you basically get a nice log, you click on the browse button there, and you get basically
nice results, and it's kind of, we generate all of this.
So we actually go further on S-bombs, because just generating an S-bomb is not good enough,
so that the file is generated, that's nice, but you actually want a quality S-bomb, and
it's actually quite challenging to produce a good S-bomb.
Why do you think, people don't know, show me your hands, what do you think, or just
speak up loud, what do you think is the problem with generating an S-bomb?
Input data.
What input data?
You don't know.
We don't know the input data.
So when we do an analysis of your software projects, I'm also originally an engineer,
I still do coding, we're happy when things built.
So all the build tools are basically optimized to build code.
To keep, actually, track what actually went into your code, yeah, that is kind of an additional
feature, it's not a requirement that the build tool does that.
So to figure out what actually goes into your software project, I bet whatever tool
is your poison, whether it's a Maven or Gradle or MPM, I'm pretty certain your tool can produce
a list of the packages that are included.
I hate to tell you that, but most of the time that list is incomplete.
For instance, if I look at MPM, MPM has six methods to give you a list of what is included.
All of them are incorrect.
And it's not to blame anything on MPM.
No, no, when I build things, MPM is a very, JavaScript is a very rapidly developing ecosystem,
so they build functions really, really rapidly.
It's amazing.
I work in MPM and know it a lot.
So they add a feature for a particular use case.
And looking at Aspom, it's simply not a use case that will support it.
So they have different views.
There's one quick view that just shows you quickly the dependencies.
There's another view that shows you basically, hey, this was coming somewhere, but if you
look, for instance, at a complete Aspom, you probably have seen, if you're a Node developer,
that there are Node packages that you see C++ below.
So Node is just used as a wrapper for some other C C C++ program, for instance, to compile
your glyphs, your fonts.
What you will look in when you generate an Aspom, it will might see the wrapper, but
it will not see the C++ thing below it and what's in the compiled thing there, because
the MPM tarball just complains the compiled C++ code for every platform.
So you won't find this out.
So the way how we went about this is, okay, what we do, we need to resolve everything
back to source code.
And that's actually really, really complicated, because if you want to look at Maven, that
whole ecosystem is basically the gift developer compiled code, not the source code.
Yeah, you can find a metadata, you can kind of figure out what went into this Java project,
but actually here's a fun fact.
Most of the time, the package metadata from this Maven project is actually incorrect.
For an example, not the bash for instance on Amazon, but if you go for instance, if
you know the Amazon Java SDK, and you look at the metadata, it points to the right code
repository.
Great Amazon, great work.
But Maven doesn't have a solution to tell you when you have that code repository, which
folder in that code repository actually contains the source code for the package.
And if you know the AWS SDK for Java, it's one code repository, but close to 500 packages.
So I have here a jar from the Java SDK, where is the source code for that jar?
Oh yeah, it's in this code repository with another 400 plus of his friends.
And for me to know the exact licensing or security vulnerabilities, I need to know exactly
which source code.
So then you need to do all kinds of tricks.
So this is where we built our tooling to basically figure this out.
I just want to give you a slight one of the output formats.
So this is where we basically created a simple single file, we call this the web app, it's
a single file, it's not a server.
So when we started building this, we're like, no, no, we want to be compatible with as many
different systems and many stuff.
And we want to have a Docker container that you can just run in your CISD pipeline and
it produces this plain files because every developer knows how to handle single files.
You can take this file and you can just send it to your lawyer and your lawyer can open
the file and they can also view it.
We were all optimized for CISD pipeline.
The second thing that we were looking at it is when we look at things, we want to be
one meter of violation.
So here you have a package in top, you see a license package that's copy left and source.
So you can write policy rules on or very powerful policy rules, whatever you want to do.
But when you draw a policy violation, and this was another complaint that we had a lot
of tools, when you write in your open source policy, like I don't allow this license, you
should tell your users how they can fix it themselves.
Why?
Well, in my company, I have 55,000 software engineers.
If all of them, if they don't know it, contact my team, yeah, I'll be very busy.
So the way how we set things up is like, no, no, no, we want things to be open source.
We want to be based on open standards, SPDX, like on the X, so all S-BOM standards.
We want to be able to write a policy where we can write whatever we want in our actual
legal policy, actually translated.
So ORD has something called policy as code.
You can really take whatever your policy is, and you can encode that.
And so we want to really be able to do, and we want everything to be plain file, so it's
easy to integrate with whatever CI system.
Why is that?
Well, I run an OSPO, an open source program office.
Are people familiar?
Hands up, who's familiar with the term open source program office?
Some people.
So an open source program office is the industry term for, like, your knowledge center with
an organization regarding the open source.
So I run an OSPO, but that basically means that all open source questions, everything
comes to my team, and we try to help our engineers by contributing back with compliance
questions or help with community topics.
We really like there to basically help our organization become better at open source.
So that means I get lots and lots of questions regarding open source.
I want something that really skills because I have thousands of engineers.
Regarding this, how to fix me text, and having a very powerful policy, I can exactly decide,
OK, these are the things that we really want to fix, and these are the things we don't
want to fix, and we want to provide exactly the guidance.
So the funny thing you might see is here, this is actually all YAML file and Git based.
So we use actually the same developer workflow with pool request to basically fix up our
licensing.
Why do we do this?
Actually, because that's what the developers are already known for.
The developers already know how to do all of this stuff.
So we enable the developers to fix the things themselves.
The other thing is we can now use inner source to fix license compliance problems and security
problems together.
Why do we want to do this?
Well, the more things we can actually fix issues, instead of what a lot of tools do,
what they call notify more, they throw you an issue up, and then you have to fix it.
It's better basically if we work together to actually fix all of these issues than if
we do the inner source, this was actually the first time we did this, it was very, hang
on.
So other teams are going to fix my license compliance and security teams?
Yes, because in our organization, guess what?
A lot of the same open source is shared between a lot of different teams.
So instead of having every team do all of this compliance and security work by themselves,
for the things that are shared, we do collectively.
And the nice thing is, you can do this in your organization, but we also not only open
source the tooling, we also open source the data and the policies from the org side.
So you can also do this with the whole community.
So we're working and we had a workshop on Friday to discuss how can we do this even
further, how can we collectively work to create better S-bombs.
That's pretty much the way in a little sneak peek, lots of code, beautiful code, right,
in the morning.
This is the other thing that I'm working on already, this is what it is.
It's the security profile.
So the latest things that we're now working on is like, okay, we want to combine, update
everything and include vulnerabilities as well.
And then you come into a lot of other challenges to create an S-bomb.
So technically, actually, to be clear, security info should ideally not be in your S-bomb.
It should be as a standalone artifact in S-bomb format, but standalone.
So because your S-bomb should be fixed for your software release and your security information
is probably updated.
But then, actually, we ran into a lot of changes, challenges with including security information.
Because guess what?
A lot of security information is either locked up in the provided database, and actually it's
a lot of times not really accurate.
And that's what we figured out when we were starting to move into security data.
A lot of the data, when you actually look at the data, and you look, and I've been working
with Philippe from XB, and looking at his data, you'll figure out that the ranges of
software for a lot of CVEs are actually incorrect.
And we were like, no, no, we want to build open source tooling that reduces the burden
on our software developers, like need accurate data.
So it's actually funny now that we started creation mechanisms, we called us to fix up
license data.
And now we have to build creation mechanisms for security data as well, so we can actually
fix up the security data so that at the end we can produce high quality S-bomb.
So we know exactly like these packages were in there under these licenses.
And at the time of release, they were, we know this security vulnerabilities.
And now the next thing is, how many people are familiar with VEX?
Few.
VEX is an upcoming standard, this basically, if you have a security vulnerability, you
can basically say like, oh yeah, I know this security vulnerability was found by a scanner,
it's reported.
But I compiled this package with these parameters, so this vulnerability is actually not applicable
to my software.
So it's a way to, in a machine readable way, to say like, yes, the scanner will pick up
a security vulnerability for OpenSL, but the way how I use OpenSL, I don't use the particular
code where the security vulnerability was found for.
So that's the next challenge where we're working on like, how can we do that in an automated
way?
And that's it.
I think, let's go to questions.
Do people have any questions?
You might want to speak up to the microphone.
So basically, most of the time when you compile stuff, you do like tree shaking, and so you
import the library, but you don't import all the functions inside the library.
So if a vulnerability is found in the library, but not one in the function you import, is
there like some kind of way to detect that?
So the question is like, is there a way to detect if you compile software whether something
is included or not?
No.
Corrected?
Not really.
You want to?
So I think the question was, if there is a component, but you're not using the whole component,
you're using just a part of it, and there is a vulnerability, but the vulnerability is
for something that you do not use.
For example, a library that function that is never called in your code, is there a way
to detect that?
That's great.
Honest answer?
No.
I don't know about that.
I disagree.
And there's a difference, okay.
So you can do it, but when I look at things at scale, so you can do it for individual
cases.
You can do this, where you know to compile and stuff.
But where I'm looking at is like, if you have a large organization like, we use tens of
different compilers with tens of things.
It doesn't scale.
So the way how we did it around it, we in ORT have a mechanism where you can basically
indicate either via SPDX what you're using, or you can add a creation afterwards where
you say like, yes, I'm using this package, but I'm only using this folder.
And then ORT will automatically subtract the things that are not applicable.
One more question?
Quick one?
Let's figure if you want to come up.
Yeah.
Do the setup already.
And we'll...
The S-BOMB pipes.
We were talking about design, source, build, where does ORT applies?
I think there's a lot of these there.
It's basically, we're focusing on the source S-BOMB.
So we really...
You're on the build.
Build, source?
You're built.
Built?
You're built.
Yeah?
Yeah, you're built.
Built?
We actually have all source source things in there as well.
But it's...
You can have source and build.
The S-BOMB type is one type.
But mostly we do build.
So basically, we look at your source code, we pull it out, basically say like in this
source code, the idea of why we started there is because everything starts at source code.
The next speaker.
Right.
Background.