[00:00.000 --> 00:11.240]  All right, so good morning, good morning, welcome, bonjour, good morning, yeah, I can
[00:11.240 --> 00:15.200]  speak too many languages.
[00:15.200 --> 00:19.880]  For the people that know who I am, my name is Thomas Niemburger, I'm the head of the
[00:19.880 --> 00:25.440]  open source program officer at IPAM, I'm involved in several, well you can call it open source
[00:25.440 --> 00:32.440]  governance S-bomb related projects, including I run the security profile over the defects
[00:32.440 --> 00:39.160]  team, so if people have questions about security information in SPX3, I'm happy to answer those
[00:39.160 --> 00:42.080]  as well.
[00:42.080 --> 00:46.280]  I decided to just not make pretty slides, but to just open a browser, so to be more
[00:46.280 --> 00:49.720]  like a demo, and to make it a little bit more interactive, since I'm the first talker, I
[00:49.720 --> 00:57.400]  have to keep you all awake, and I'm usually a very high energy person.
[00:57.400 --> 01:03.720]  Apparently last night I was compared to Opalix, and I fell into a fat of open source juice,
[01:03.720 --> 01:06.240]  and therefore I'm all hyped up on open source stuff.
[01:06.240 --> 01:14.720]  So yeah, so I normally can talk very fast, so I will try to be a little bit slower.
[01:14.720 --> 01:21.720]  So I'm here a little bit to talk about Oort, Oort is a project, or Oort is a review toolkit,
[01:21.720 --> 01:33.400]  the screen, better, perfect, like first talk.
[01:33.400 --> 01:40.840]  So it should work, hopefully my internet is all working, so yeah, if you are on GitHub
[01:40.840 --> 01:47.680]  you can find Oort here, the full name is OSS review toolkit, or open source software review
[01:47.680 --> 01:54.720]  toolkit, it's a very complex name, it's actually for those people that are German.
[01:54.720 --> 01:59.640]  Oort in German means place, and I used to work for a location company, and all of our
[01:59.640 --> 02:04.840]  open source project had a location pun in them, so we were really trying to figure out
[02:04.840 --> 02:12.040]  all of the names, and how can we make a location name, and this is where we lined it on.
[02:12.040 --> 02:17.520]  So I'm actually going to do somewhat a live demo, but my internet is not working 100%,
[02:17.520 --> 02:22.040]  so we're just going to do it like this, where I just have luckily pages open, and I'll show
[02:22.040 --> 02:23.040]  you through.
[02:23.040 --> 02:28.240]  So if you want to get started with Oort, the easiest way is actually to use the GitHub
[02:28.240 --> 02:35.160]  action, and you can just literally, as the code shows here, you just add a few lines,
[02:35.160 --> 02:36.640]  and basically it's very standard.
[02:36.640 --> 02:42.000]  For people that are familiar with GitHub actions, in the middle there's a checkout.
[02:42.000 --> 02:47.280]  The line on top is a little bit different, and then you run Oort itself.
[02:47.280 --> 02:56.440]  This line is a little bit different, and it has to do with how Oort generates S-bombs.
[02:56.440 --> 03:01.920]  So for to create good S-bombs, you can make S-bombs that basically only operate on kind
[03:01.920 --> 03:06.800]  of like the declared license, the basic package data, but if you want to have a proper, what
[03:06.800 --> 03:07.800]  do you want to do?
[03:07.800 --> 03:10.960]  I originally have worked in the automotive industry, we want to know everything down
[03:10.960 --> 03:13.160]  to source level.
[03:13.160 --> 03:14.160]  And why is that?
[03:14.160 --> 03:19.200]  It's actually very simple, in the automotive business, basically products on the market,
[03:19.200 --> 03:26.320]  the minimum lifespan is 15 years, and it can go up to 25 years or longer.
[03:26.320 --> 03:30.560]  There's a vehicle on the road, it's minimum 10 years on the road, plus European legislation,
[03:30.560 --> 03:33.160]  contract law is another five years, 15 years.
[03:33.160 --> 03:40.120]  So all the solutions that we built for S-bombs, my successor, my successor, my successor, still
[03:40.120 --> 03:41.120]  needs to be able.
[03:41.120 --> 03:46.440]  So this is why we started building the way how Oort is designed, that we were like, hmm,
[03:46.440 --> 03:52.520]  we need a format that we can take the scan results that we have, and all of that have,
[03:52.520 --> 04:00.200]  we can just do, store them long term in a public format, that even if the tooling that
[04:00.200 --> 04:04.320]  we write doesn't exist anymore in 10 years, it's an international standard, so they can
[04:04.320 --> 04:10.240]  just write a new parser, read in this, and then of course I stumbled upon, and then I
[04:10.240 --> 04:15.560]  happened to make Kate's at Fostam in the bus.
[04:15.560 --> 04:20.360]  And so we got talking, and I was like, hey, that's interesting, this S-bomb thing, so
[04:20.360 --> 04:27.400]  this is like years ago, like what, 2015-ish, I think, 16-ish, a long, long time ago.
[04:27.400 --> 04:34.480]  So then I was like, hang on, I can solve two of my problems, I can basically have an output
[04:34.480 --> 04:39.800]  format that is recognized, so I have a long-term archive format, and I also have a format that
[04:39.800 --> 04:43.520]  I need it to exchange, so there are two forms of, why is that?
[04:43.520 --> 04:46.600]  In automotive, there is a long supply chain.
[04:46.600 --> 04:51.880]  So what we have commonly, we call this hamburgers, where you get something from a supplier, you
[04:51.880 --> 04:58.240]  do your thing, then it goes to another supplier, and then my company will be again in there.
[04:58.240 --> 05:01.600]  So we were just looking at what is the solution that we can, in the supply chain, basically
[05:01.600 --> 05:09.680]  exchange information, it still is, unfortunately, automotive, so still a lot of paper-based
[05:09.680 --> 05:11.680]  processes, and we were like, no, no, we need to go digital.
[05:11.680 --> 05:15.360]  So what you now see, luckily, is that some of the large German ones, which again, I'm
[05:15.360 --> 05:18.360]  based in Berlin, Germany, they are already switching to, basically, say, S-bombs, and
[05:18.360 --> 05:23.160]  then, no, no, no, yeah, you can still do paper, but we actually prefer you to give us an S-bomb,
[05:23.160 --> 05:28.200]  because then they can ingest it much more easier, and so yeah, we basically do SPDX,
[05:28.200 --> 05:34.000]  and actually we also support starting this for exchange, and also for archiving.
[05:34.000 --> 05:38.520]  So yeah, now, my talk was about how do you generate it, so it's actually very simple.
[05:38.520 --> 05:43.000]  So I took here the MimeTime projects, which is kind of our default project, it's a small
[05:43.000 --> 05:47.680]  node project, and if I want to do an S-bomb for it, it's actually very simple for people
[05:47.680 --> 05:52.800]  that are familiar with GitHub Actions, you can just run the action, and there's as simple
[05:52.800 --> 05:59.520]  as it is, and you can also do this in GitLab, I don't know for people familiar with GitLab,
[05:59.520 --> 06:04.760]  but basically it's all the same, you just run a GitLab pipeline, it says org scan,
[06:04.760 --> 06:10.760]  and you basically get a nice log, you click on the browse button there, and you get basically
[06:10.760 --> 06:15.920]  nice results, and it's kind of, we generate all of this.
[06:15.920 --> 06:25.920]  So we actually go further on S-bombs, because just generating an S-bomb is not good enough,
[06:25.920 --> 06:36.440]  so that the file is generated, that's nice, but you actually want a quality S-bomb, and
[06:36.440 --> 06:42.960]  it's actually quite challenging to produce a good S-bomb.
[06:42.960 --> 06:49.440]  Why do you think, people don't know, show me your hands, what do you think, or just
[06:49.440 --> 06:55.320]  speak up loud, what do you think is the problem with generating an S-bomb?
[06:55.320 --> 06:56.320]  Input data.
[06:56.320 --> 06:57.320]  Input data.
[06:57.320 --> 06:58.320]  What input data?
[06:58.320 --> 06:59.320]  You don't know.
[06:59.320 --> 07:03.960]  We don't know the input data.
[07:03.960 --> 07:13.040]  So when we do an analysis of your software projects, I'm also originally an engineer,
[07:13.040 --> 07:19.160]  I still do coding, we're happy when things built.
[07:19.160 --> 07:23.360]  So all the build tools are basically optimized to build code.
[07:23.360 --> 07:30.160]  To keep, actually, track what actually went into your code, yeah, that is kind of an additional
[07:30.160 --> 07:33.880]  feature, it's not a requirement that the build tool does that.
[07:33.880 --> 07:39.760]  So to figure out what actually goes into your software project, I bet whatever tool
[07:39.760 --> 07:47.080]  is your poison, whether it's a Maven or Gradle or MPM, I'm pretty certain your tool can produce
[07:47.080 --> 07:51.960]  a list of the packages that are included.
[07:51.960 --> 07:58.520]  I hate to tell you that, but most of the time that list is incomplete.
[07:58.520 --> 08:05.400]  For instance, if I look at MPM, MPM has six methods to give you a list of what is included.
[08:05.400 --> 08:08.560]  All of them are incorrect.
[08:08.560 --> 08:10.240]  And it's not to blame anything on MPM.
[08:10.240 --> 08:15.600]  No, no, when I build things, MPM is a very, JavaScript is a very rapidly developing ecosystem,
[08:15.600 --> 08:17.560]  so they build functions really, really rapidly.
[08:17.560 --> 08:18.560]  It's amazing.
[08:18.560 --> 08:21.080]  I work in MPM and know it a lot.
[08:21.080 --> 08:25.080]  So they add a feature for a particular use case.
[08:25.080 --> 08:29.520]  And looking at Aspom, it's simply not a use case that will support it.
[08:29.520 --> 08:30.680]  So they have different views.
[08:30.680 --> 08:33.080]  There's one quick view that just shows you quickly the dependencies.
[08:33.080 --> 08:37.520]  There's another view that shows you basically, hey, this was coming somewhere, but if you
[08:37.520 --> 08:43.880]  look, for instance, at a complete Aspom, you probably have seen, if you're a Node developer,
[08:43.880 --> 08:47.240]  that there are Node packages that you see C++ below.
[08:47.240 --> 08:52.800]  So Node is just used as a wrapper for some other C C C++ program, for instance, to compile
[08:52.800 --> 08:56.160]  your glyphs, your fonts.
[08:56.160 --> 08:59.720]  What you will look in when you generate an Aspom, it will might see the wrapper, but
[08:59.720 --> 09:03.960]  it will not see the C++ thing below it and what's in the compiled thing there, because
[09:03.960 --> 09:09.920]  the MPM tarball just complains the compiled C++ code for every platform.
[09:09.920 --> 09:12.800]  So you won't find this out.
[09:12.800 --> 09:18.320]  So the way how we went about this is, okay, what we do, we need to resolve everything
[09:18.320 --> 09:19.960]  back to source code.
[09:19.960 --> 09:23.840]  And that's actually really, really complicated, because if you want to look at Maven, that
[09:23.840 --> 09:27.840]  whole ecosystem is basically the gift developer compiled code, not the source code.
[09:27.840 --> 09:33.880]  Yeah, you can find a metadata, you can kind of figure out what went into this Java project,
[09:33.880 --> 09:36.520]  but actually here's a fun fact.
[09:36.520 --> 09:40.560]  Most of the time, the package metadata from this Maven project is actually incorrect.
[09:40.560 --> 09:44.720]  For an example, not the bash for instance on Amazon, but if you go for instance, if
[09:44.720 --> 09:49.560]  you know the Amazon Java SDK, and you look at the metadata, it points to the right code
[09:49.560 --> 09:50.560]  repository.
[09:50.560 --> 09:52.520]  Great Amazon, great work.
[09:52.520 --> 09:58.000]  But Maven doesn't have a solution to tell you when you have that code repository, which
[09:58.000 --> 10:01.440]  folder in that code repository actually contains the source code for the package.
[10:01.440 --> 10:07.560]  And if you know the AWS SDK for Java, it's one code repository, but close to 500 packages.
[10:07.560 --> 10:11.880]  So I have here a jar from the Java SDK, where is the source code for that jar?
[10:11.880 --> 10:17.720]  Oh yeah, it's in this code repository with another 400 plus of his friends.
[10:17.720 --> 10:21.480]  And for me to know the exact licensing or security vulnerabilities, I need to know exactly
[10:21.480 --> 10:22.480]  which source code.
[10:22.480 --> 10:24.560]  So then you need to do all kinds of tricks.
[10:24.560 --> 10:27.880]  So this is where we built our tooling to basically figure this out.
[10:27.880 --> 10:30.520]  I just want to give you a slight one of the output formats.
[10:30.520 --> 10:36.640]  So this is where we basically created a simple single file, we call this the web app, it's
[10:36.640 --> 10:38.480]  a single file, it's not a server.
[10:38.480 --> 10:41.120]  So when we started building this, we're like, no, no, we want to be compatible with as many
[10:41.120 --> 10:42.920]  different systems and many stuff.
[10:42.920 --> 10:48.000]  And we want to have a Docker container that you can just run in your CISD pipeline and
[10:48.000 --> 10:54.680]  it produces this plain files because every developer knows how to handle single files.
[10:54.680 --> 10:58.120]  You can take this file and you can just send it to your lawyer and your lawyer can open
[10:58.120 --> 11:00.280]  the file and they can also view it.
[11:00.280 --> 11:02.520]  We were all optimized for CISD pipeline.
[11:02.520 --> 11:07.920]  The second thing that we were looking at it is when we look at things, we want to be
[11:07.920 --> 11:08.920]  one meter of violation.
[11:08.920 --> 11:13.920]  So here you have a package in top, you see a license package that's copy left and source.
[11:13.920 --> 11:19.560]  So you can write policy rules on or very powerful policy rules, whatever you want to do.
[11:19.560 --> 11:22.560]  But when you draw a policy violation, and this was another complaint that we had a lot
[11:22.560 --> 11:29.000]  of tools, when you write in your open source policy, like I don't allow this license, you
[11:29.000 --> 11:31.920]  should tell your users how they can fix it themselves.
[11:31.920 --> 11:32.920]  Why?
[11:32.920 --> 11:39.720]  Well, in my company, I have 55,000 software engineers.
[11:39.720 --> 11:47.120]  If all of them, if they don't know it, contact my team, yeah, I'll be very busy.
[11:47.120 --> 11:51.760]  So the way how we set things up is like, no, no, no, we want things to be open source.
[11:51.760 --> 11:56.880]  We want to be based on open standards, SPDX, like on the X, so all S-BOM standards.
[11:56.880 --> 12:00.680]  We want to be able to write a policy where we can write whatever we want in our actual
[12:00.680 --> 12:02.640]  legal policy, actually translated.
[12:02.640 --> 12:04.480]  So ORD has something called policy as code.
[12:04.480 --> 12:08.640]  You can really take whatever your policy is, and you can encode that.
[12:08.640 --> 12:13.000]  And so we want to really be able to do, and we want everything to be plain file, so it's
[12:13.000 --> 12:16.520]  easy to integrate with whatever CI system.
[12:16.520 --> 12:17.520]  Why is that?
[12:17.520 --> 12:20.040]  Well, I run an OSPO, an open source program office.
[12:20.040 --> 12:21.040]  Are people familiar?
[12:21.040 --> 12:24.560]  Hands up, who's familiar with the term open source program office?
[12:24.560 --> 12:25.560]  Some people.
[12:25.560 --> 12:29.320]  So an open source program office is the industry term for, like, your knowledge center with
[12:29.320 --> 12:31.400]  an organization regarding the open source.
[12:31.400 --> 12:35.120]  So I run an OSPO, but that basically means that all open source questions, everything
[12:35.120 --> 12:41.200]  comes to my team, and we try to help our engineers by contributing back with compliance
[12:41.200 --> 12:43.560]  questions or help with community topics.
[12:43.560 --> 12:50.720]  We really like there to basically help our organization become better at open source.
[12:50.720 --> 12:53.800]  So that means I get lots and lots of questions regarding open source.
[12:53.800 --> 12:59.160]  I want something that really skills because I have thousands of engineers.
[12:59.160 --> 13:04.400]  Regarding this, how to fix me text, and having a very powerful policy, I can exactly decide,
[13:04.400 --> 13:08.240]  OK, these are the things that we really want to fix, and these are the things we don't
[13:08.240 --> 13:10.240]  want to fix, and we want to provide exactly the guidance.
[13:10.240 --> 13:15.240]  So the funny thing you might see is here, this is actually all YAML file and Git based.
[13:15.240 --> 13:21.280]  So we use actually the same developer workflow with pool request to basically fix up our
[13:21.280 --> 13:22.280]  licensing.
[13:22.280 --> 13:23.280]  Why do we do this?
[13:23.280 --> 13:25.960]  Actually, because that's what the developers are already known for.
[13:25.960 --> 13:28.160]  The developers already know how to do all of this stuff.
[13:28.160 --> 13:30.560]  So we enable the developers to fix the things themselves.
[13:30.560 --> 13:37.120]  The other thing is we can now use inner source to fix license compliance problems and security
[13:37.120 --> 13:39.160]  problems together.
[13:39.160 --> 13:40.160]  Why do we want to do this?
[13:40.160 --> 13:44.800]  Well, the more things we can actually fix issues, instead of what a lot of tools do,
[13:44.800 --> 13:49.480]  what they call notify more, they throw you an issue up, and then you have to fix it.
[13:49.480 --> 13:55.440]  It's better basically if we work together to actually fix all of these issues than if
[13:55.440 --> 13:59.320]  we do the inner source, this was actually the first time we did this, it was very, hang
[13:59.320 --> 14:00.320]  on.
[14:00.320 --> 14:04.280]  So other teams are going to fix my license compliance and security teams?
[14:04.280 --> 14:07.000]  Yes, because in our organization, guess what?
[14:07.000 --> 14:11.080]  A lot of the same open source is shared between a lot of different teams.
[14:11.080 --> 14:15.680]  So instead of having every team do all of this compliance and security work by themselves,
[14:15.680 --> 14:18.720]  for the things that are shared, we do collectively.
[14:18.720 --> 14:24.040]  And the nice thing is, you can do this in your organization, but we also not only open
[14:24.040 --> 14:27.280]  source the tooling, we also open source the data and the policies from the org side.
[14:27.280 --> 14:29.160]  So you can also do this with the whole community.
[14:29.160 --> 14:32.920]  So we're working and we had a workshop on Friday to discuss how can we do this even
[14:32.920 --> 14:40.320]  further, how can we collectively work to create better S-bombs.
[14:40.320 --> 14:45.080]  That's pretty much the way in a little sneak peek, lots of code, beautiful code, right,
[14:45.080 --> 14:46.080]  in the morning.
[14:46.080 --> 14:49.760]  This is the other thing that I'm working on already, this is what it is.
[14:49.760 --> 14:51.520]  It's the security profile.
[14:51.520 --> 14:56.120]  So the latest things that we're now working on is like, okay, we want to combine, update
[14:56.120 --> 15:00.120]  everything and include vulnerabilities as well.
[15:00.120 --> 15:04.040]  And then you come into a lot of other challenges to create an S-bomb.
[15:04.040 --> 15:09.680]  So technically, actually, to be clear, security info should ideally not be in your S-bomb.
[15:09.680 --> 15:15.120]  It should be as a standalone artifact in S-bomb format, but standalone.
[15:15.120 --> 15:18.200]  So because your S-bomb should be fixed for your software release and your security information
[15:18.200 --> 15:19.640]  is probably updated.
[15:19.640 --> 15:24.880]  But then, actually, we ran into a lot of changes, challenges with including security information.
[15:24.880 --> 15:25.880]  Because guess what?
[15:25.880 --> 15:32.960]  A lot of security information is either locked up in the provided database, and actually it's
[15:32.960 --> 15:38.240]  a lot of times not really accurate.
[15:38.240 --> 15:41.120]  And that's what we figured out when we were starting to move into security data.
[15:41.120 --> 15:44.440]  A lot of the data, when you actually look at the data, and you look, and I've been working
[15:44.440 --> 15:48.480]  with Philippe from XB, and looking at his data, you'll figure out that the ranges of
[15:48.480 --> 15:51.920]  software for a lot of CVEs are actually incorrect.
[15:51.920 --> 15:56.080]  And we were like, no, no, we want to build open source tooling that reduces the burden
[15:56.080 --> 15:59.200]  on our software developers, like need accurate data.
[15:59.200 --> 16:03.600]  So it's actually funny now that we started creation mechanisms, we called us to fix up
[16:03.600 --> 16:04.600]  license data.
[16:04.600 --> 16:08.400]  And now we have to build creation mechanisms for security data as well, so we can actually
[16:08.400 --> 16:12.680]  fix up the security data so that at the end we can produce high quality S-bomb.
[16:12.680 --> 16:16.720]  So we know exactly like these packages were in there under these licenses.
[16:16.720 --> 16:21.040]  And at the time of release, they were, we know this security vulnerabilities.
[16:21.040 --> 16:24.080]  And now the next thing is, how many people are familiar with VEX?
[16:24.080 --> 16:25.080]  Few.
[16:25.080 --> 16:29.880]  VEX is an upcoming standard, this basically, if you have a security vulnerability, you
[16:29.880 --> 16:34.120]  can basically say like, oh yeah, I know this security vulnerability was found by a scanner,
[16:34.120 --> 16:35.120]  it's reported.
[16:35.120 --> 16:41.160]  But I compiled this package with these parameters, so this vulnerability is actually not applicable
[16:41.160 --> 16:42.160]  to my software.
[16:42.160 --> 16:46.280]  So it's a way to, in a machine readable way, to say like, yes, the scanner will pick up
[16:46.280 --> 16:51.480]  a security vulnerability for OpenSL, but the way how I use OpenSL, I don't use the particular
[16:51.480 --> 16:54.280]  code where the security vulnerability was found for.
[16:54.280 --> 16:57.600]  So that's the next challenge where we're working on like, how can we do that in an automated
[16:57.600 --> 16:58.600]  way?
[16:58.600 --> 16:59.600]  And that's it.
[16:59.600 --> 17:00.600]  I think, let's go to questions.
[17:00.600 --> 17:01.600]  Do people have any questions?
[17:01.600 --> 17:02.600]  You might want to speak up to the microphone.
[17:02.600 --> 17:18.640]  So basically, most of the time when you compile stuff, you do like tree shaking, and so you
[17:18.640 --> 17:23.640]  import the library, but you don't import all the functions inside the library.
[17:23.640 --> 17:30.640]  So if a vulnerability is found in the library, but not one in the function you import, is
[17:30.640 --> 17:34.440]  there like some kind of way to detect that?
[17:34.440 --> 17:38.900]  So the question is like, is there a way to detect if you compile software whether something
[17:38.900 --> 17:40.400]  is included or not?
[17:40.400 --> 17:41.400]  No.
[17:41.400 --> 17:42.400]  Corrected?
[17:42.400 --> 17:43.400]  Not really.
[17:43.400 --> 17:48.960]  You want to?
[17:48.960 --> 17:54.840]  So I think the question was, if there is a component, but you're not using the whole component,
[17:54.840 --> 17:59.200]  you're using just a part of it, and there is a vulnerability, but the vulnerability is
[17:59.200 --> 18:01.440]  for something that you do not use.
[18:01.440 --> 18:05.920]  For example, a library that function that is never called in your code, is there a way
[18:05.920 --> 18:06.920]  to detect that?
[18:06.920 --> 18:07.920]  That's great.
[18:07.920 --> 18:08.920]  Honest answer?
[18:08.920 --> 18:09.920]  No.
[18:09.920 --> 18:10.920]  I don't know about that.
[18:10.920 --> 18:11.920]  I disagree.
[18:11.920 --> 18:16.720]  And there's a difference, okay.
[18:16.720 --> 18:23.080]  So you can do it, but when I look at things at scale, so you can do it for individual
[18:23.080 --> 18:24.080]  cases.
[18:24.080 --> 18:27.200]  You can do this, where you know to compile and stuff.
[18:27.200 --> 18:31.440]  But where I'm looking at is like, if you have a large organization like, we use tens of
[18:31.440 --> 18:33.560]  different compilers with tens of things.
[18:33.560 --> 18:35.440]  It doesn't scale.
[18:35.440 --> 18:40.920]  So the way how we did it around it, we in ORT have a mechanism where you can basically
[18:40.920 --> 18:46.120]  indicate either via SPDX what you're using, or you can add a creation afterwards where
[18:46.120 --> 18:51.000]  you say like, yes, I'm using this package, but I'm only using this folder.
[18:51.000 --> 18:58.000]  And then ORT will automatically subtract the things that are not applicable.
[18:58.000 --> 18:59.000]  One more question?
[18:59.000 --> 19:00.000]  Quick one?
[19:00.000 --> 19:02.000]  Let's figure if you want to come up.
[19:02.000 --> 19:03.000]  Yeah.
[19:03.000 --> 19:04.000]  Do the setup already.
[19:04.000 --> 19:05.000]  And we'll...
[19:05.000 --> 19:06.000]  The S-BOMB pipes.
[19:06.000 --> 19:11.000]  We were talking about design, source, build, where does ORT applies?
[19:11.000 --> 19:14.000]  I think there's a lot of these there.
[19:14.000 --> 19:17.600]  It's basically, we're focusing on the source S-BOMB.
[19:17.600 --> 19:18.600]  So we really...
[19:18.600 --> 19:19.600]  You're on the build.
[19:19.600 --> 19:21.600]  Build, source?
[19:21.600 --> 19:22.600]  You're built.
[19:22.600 --> 19:23.600]  Built?
[19:23.600 --> 19:24.600]  You're built.
[19:24.600 --> 19:25.600]  Yeah?
[19:25.600 --> 19:26.600]  Yeah, you're built.
[19:26.600 --> 19:27.600]  Built?
[19:27.600 --> 19:29.600]  We actually have all source source things in there as well.
[19:29.600 --> 19:30.600]  But it's...
[19:30.600 --> 19:31.600]  You can have source and build.
[19:31.600 --> 19:33.600]  The S-BOMB type is one type.
[19:33.600 --> 19:34.600]  But mostly we do build.
[19:34.600 --> 19:38.600]  So basically, we look at your source code, we pull it out, basically say like in this
[19:38.600 --> 19:43.600]  source code, the idea of why we started there is because everything starts at source code.
[19:43.600 --> 19:45.600]  The next speaker.
[19:45.600 --> 19:46.600]  Right.
[19:46.600 --> 19:57.600]  Background.