[00:00.000 --> 00:24.600]  So, this session is panel discussion by four or three people and the basic idea that we're
[00:24.600 --> 00:30.440]  going to be discussing is the whole idea of S-bombs, right? The usefulness, cover of using
[00:30.440 --> 00:38.040]  them and all these wonderful things. Though the rest of the day everybody was talking
[00:38.040 --> 00:44.520]  about S-bombs as like something, you know, that has to be there and we all know what
[00:44.520 --> 00:50.800]  information has to be there. But maybe this is not so obvious to anyone and the whole
[00:50.800 --> 00:58.120]  idea is to discuss the idea of S-bombs, right? So, we have for the moment three panelists
[00:58.120 --> 01:08.360]  and the format will be that they will be doing a very short, short introduction of, I don't
[01:08.360 --> 01:15.480]  know, the problem statement if you want, right? And then we'll, after these three short interactions,
[01:15.480 --> 01:23.320]  we'll go into more discussions and we obviously will value audience participation. So, first
[01:23.320 --> 01:44.680]  of all, thank you for your time. Okay, afternoon. My name's Anthony Harrison. I used to work
[01:44.680 --> 01:49.200]  for a very large system integrator. So, the work on safe functional safety was very close
[01:49.200 --> 01:53.800]  at heart. Certainly, they got things like the Siemens team as well, very similar to
[01:53.800 --> 02:00.880]  the sort of things I used to involve in for many years. I retired a few weeks, a few months
[02:00.880 --> 02:07.560]  ago. But before I left, I was trying to introduce S-bombs into my organization and it was following
[02:07.560 --> 02:14.560]  very much on from the log4j need, where was the components, which systems were affected,
[02:14.560 --> 02:19.760]  which customers needed to be informed, and where was our liability, very much from a
[02:19.760 --> 02:26.640]  risk perspective. So, since I retired, I've been writing Python tools. So, if you want
[02:26.640 --> 02:29.280]  to talk about me, about some of the Python tools I've been doing, because it's been
[02:29.280 --> 02:37.760]  quite interesting, have a chat with me afterwards. But to sort of set the scene, I think we've
[02:37.760 --> 02:46.640]  got four types of users. And it picks up on what Adolfo was saying, Adolfo, yes, about
[02:46.640 --> 02:54.440]  who's a supplier? Is a supplier a developer? Is it, I've put the word supplier in there,
[02:54.440 --> 02:58.760]  but basically someone who packages things together, it might be an embedded solution,
[02:58.760 --> 03:05.440]  it might be a red hat, it might be someone else. And then you've got your integrators,
[03:05.440 --> 03:10.400]  which is like your Siemens, people who are selling solutions to an end user who's going
[03:10.400 --> 03:17.240]  to use it. And I believe that if you are a producer of S-bombs, you also should be a
[03:17.240 --> 03:23.440]  consumer of S-bombs, first and foremost, because there should be value to you in what you are
[03:23.440 --> 03:29.040]  producing, and you need to know where your vulnerabilities are, whether you're compliant
[03:29.040 --> 03:34.960]  with your licenses as we've had lots of discussion about, but also where the things are changing,
[03:34.960 --> 03:40.800]  particularly do you know those changes, are those changing happening under your control
[03:40.800 --> 03:46.400]  or not? And this comes into the ecosystems, things happening outside, your maven, repositories,
[03:46.400 --> 03:52.280]  et cetera. So the first thing is, I think everybody who's a consumer, everyone who's
[03:52.280 --> 03:56.800]  a generator should also be consuming. So if you've seen some of the questions of asking
[03:56.800 --> 04:02.680]  this morning was when the opto guys were saying they're generating an S-bdx, S-bombs, are
[04:02.680 --> 04:07.960]  they actually using it? I think the answer is most definitely yes, you should be. And
[04:07.960 --> 04:11.960]  then what are the sort of things you should be using them for? We've heard a lot about
[04:11.960 --> 04:17.480]  vulnerability management on the basis, but that's heavily dependent on the quality of
[04:17.480 --> 04:22.640]  your S-bombs. Have you got your components uniquely identified in a way that they can
[04:22.640 --> 04:31.680]  be found consistently? Secondly, looking at license management, again, are we consistent?
[04:31.680 --> 04:38.600]  But thirdly, looking at the change management, are versions of packages changing, are licenses
[04:38.600 --> 04:42.880]  changing, and I was telling you to Kate, on an open source project that I'm involved
[04:42.880 --> 04:47.680]  in, we generate an S-bombs every week, and we do a build, and we are seeing components
[04:47.680 --> 04:53.840]  changing versions, and the metadata is changing with those versions. Sometimes it's getting
[04:53.840 --> 05:00.520]  worse. So why have we lost the name of the supplier or the developer? And fourthly, I
[05:00.520 --> 05:04.720]  think you should be using it for solution integrity. Have you built what you said you
[05:04.720 --> 05:10.560]  were going to design? So we're picking up on the design S-bombs that Nico was talking
[05:10.560 --> 05:14.600]  about from the safety. I think that would be really good to actually use the S-bombs
[05:14.600 --> 05:18.160]  as part of the solution integrity. Have you built what you said you were going to build?
[05:18.160 --> 05:23.640]  We saw a lot of that things with the Chexons from the Yocto guys. Have we got end of life
[05:23.640 --> 05:30.400]  components? Are we planning for removing those end of life components, obsolete components,
[05:30.400 --> 05:36.160]  and are we seeing the impact of those changes on the solution comes back onto the engineering
[05:36.160 --> 05:43.800]  life cycle? So I think all of it is supporting risk. So ultimately this is all about risk
[05:43.800 --> 05:49.960]  management, and hopefully S-bombs and all these are helping you make effective decisions.
[05:49.960 --> 06:01.280]  Now I'll shut up now. Just to try and shape things for discussion.
[06:01.280 --> 06:16.760]  Okay, thanks. My name's Paul Noveres. I'm a solutions engineer for a company called
[06:16.760 --> 06:23.840]  Bancor. We produce a couple of open source projects that A, can produce S-bombs for,
[06:23.840 --> 06:29.240]  in some cases, do vulnerability checks against them so you can look up SIFT and gripe. I'm
[06:29.240 --> 06:35.520]  not going to talk specifically about any particular projects here. So just to hit on the topic
[06:35.520 --> 06:42.800]  of the panel, I'm going to just jump into a couple of things. Oh, well, what I do there,
[06:42.800 --> 06:48.320]  I'm out in the field. So I am a solutions architect. I'm working directly with the end
[06:48.320 --> 06:55.800]  users a lot of the times. So most of my contact is with people who are on the beginning of
[06:55.800 --> 07:00.560]  the learning curve. They may not even know what an S-bomb is the first time I talk to
[07:00.560 --> 07:11.000]  them, but they've been given marching orders. So it spans a pretty wide range. So as far
[07:11.000 --> 07:18.480]  as content, the biggest thing for me is that the S-bomb, and this seems to be somewhat
[07:18.480 --> 07:23.160]  of a controversial statement sometimes, but the S-bomb needs to be seen as a objective
[07:23.160 --> 07:30.600]  document that only has factual information in it and does not have judgments in it.
[07:30.600 --> 07:38.400]  Those things are important, but should be separated out a lot of the times. A lot of
[07:38.400 --> 07:42.800]  people probably haven't been in here all day, but there have been often on comments about
[07:42.800 --> 07:49.520]  should we include CVEs in an S-bomb. My opinion is probably not because those are going to
[07:49.520 --> 07:57.640]  change more than the software that the S-bomb describes. Obviously, if you rebuild the piece
[07:57.640 --> 08:03.280]  of software, then you would want to build a new S-bomb, but the S-bomb should be static
[08:03.280 --> 08:09.000]  as long as the software it's describing is static. In the case of a Docker image, we
[08:09.000 --> 08:15.760]  know when that changes because the image digest would change. We could trigger a new build,
[08:15.760 --> 08:20.240]  but we shouldn't necessarily be rebuilding those S-bombs continually if there's nothing
[08:20.240 --> 08:25.400]  new there. Now, that ignores things like maybe our scanner has gotten better and can detect
[08:25.400 --> 08:31.920]  more things. Obviously, that might be an exception to that kind of rule. The other thing, just
[08:31.920 --> 08:38.800]  as far as content goes, the first thing we mentioned today, the specs, whether it's
[08:38.800 --> 08:45.160]  SPDX, Cyclone DX, are extremely loose. You can have a valid S-bomb that doesn't actually
[08:45.160 --> 08:50.800]  have enough information to be useful for your particular use case. What that minimum amount
[08:50.800 --> 08:55.920]  of useful information is might be different depending on the use case. There's just something
[08:55.920 --> 09:02.280]  to keep in mind. The other thing that's kind of come up again and again today, the quality
[09:02.280 --> 09:06.520]  of the S-bomb is going to be really dependent on the tooling. There's no way to do these
[09:06.520 --> 09:12.840]  things without automation at scale. It's just too difficult to keep up with. The tooling
[09:12.840 --> 09:20.720]  is improving, but it's still a long way to go, I think.
[09:20.720 --> 09:27.840]  The main thing here for me is the S-bomb is useful because it's going to make all the
[09:27.840 --> 09:35.840]  other aspects of supply chain security better. One, what's in the software? That's the S-bomb.
[09:35.840 --> 09:40.240]  It's kind of foundational to all the other aspects. Two would be things like, is the
[09:40.240 --> 09:46.440]  software safe to use? Does it have vulnerabilities? What are those vulnerabilities? What is my
[09:46.440 --> 09:53.320]  license? Am I at risk for some kind of compliance issue there? Those kind of safety issues,
[09:53.320 --> 09:59.920]  whether you, I don't want to use that term after seeing the operational safety discussion.
[09:59.920 --> 10:06.880]  The other thing, provenance, where is this coming from? If you know what's in that software,
[10:06.880 --> 10:11.280]  having that assurance of where it comes from and what's in there together is much more
[10:11.280 --> 10:18.560]  powerful. Then things like reproducibility. It's really esoteric, very difficult to actually
[10:18.560 --> 10:25.520]  achieve in practice, but if you have an S-bomb, a high quality S-bomb, it can be effectively
[10:25.520 --> 10:30.400]  a recipe towards that. That can also help you prove some of the other things that you've
[10:30.400 --> 10:37.960]  seen or we've been talking about. A lot of this is difficult though. We've seen a lot
[10:37.960 --> 10:43.200]  of things about opaque artifacts and things, the difficulty of actually scanning at build
[10:43.200 --> 10:49.760]  time, which may produce a higher quality S-bomb, but at a lot of cost, performance and other
[10:49.760 --> 10:58.760]  things. That kind of leads us into the caveats. The main thing here is to keep in mind that
[10:58.760 --> 11:05.360]  our imagined state of how we want things to be and the actual reality are basically not
[11:05.360 --> 11:10.120]  the same at all. We'll try to move towards that. We're on a journey up the mountain,
[11:10.120 --> 11:14.800]  whatever you want to say. If you're climbing Mount Everest, we probably haven't even gotten
[11:14.800 --> 11:21.680]  to base camp yet. There's a long way to go, but the other thing, in that realm, just declaring
[11:21.680 --> 11:30.800]  we have a policy to produce or store or evaluate S-bombs doesn't actually solve the problems
[11:30.800 --> 11:33.920]  you're trying to solve. There's a lot more work that has to be done.
[11:33.920 --> 11:42.920]  The last thing on caveats, things like log for shell, I think, pushed S-bombs into a
[11:42.920 --> 11:50.480]  lot of people's awareness because S-bombs were a very effective way of finding where
[11:50.480 --> 11:57.640]  log for shell was affecting software. It may have given a false sense of security just
[11:57.640 --> 12:02.760]  because log for J in particular sticks out like a sore thumb. It's very easy to find.
[12:02.760 --> 12:07.280]  This is like the open SSL vulnerability just a couple of months ago. I think it may have
[12:07.280 --> 12:12.200]  been a reality check there. There are a lot of cases where you might have something like
[12:12.200 --> 12:19.040]  open SSL in software that you're consuming without even knowing it. It's a lot easier
[12:19.040 --> 12:25.720]  to hide. Just kind of a reality check, bring some people back to Earth a little bit.
[12:25.720 --> 12:30.240]  Then the last thing is just in addition to producing S-bombs, one caveat is you have
[12:30.240 --> 12:36.200]  to think about managing them after you produce them, storing them, being able to search them,
[12:36.200 --> 12:41.440]  purge the ones you don't need anymore. That's been a topic a couple of times. We don't want
[12:41.440 --> 12:48.560]  to keep more information than we really need. How do we know when it's safe or reasonable
[12:48.560 --> 12:53.840]  to get rid of some of this data? Much less how are we going to search through it when
[12:53.840 --> 13:00.360]  we need to find it? I think that covers it for now. I'll go ahead and pick them up over
[13:00.360 --> 13:03.080]  time anyway. Thank you.
[13:03.080 --> 13:14.520]  Like you, I've attended more panels than I've been on. I don't like a panel that is a series
[13:14.520 --> 13:19.800]  of talks. I did hear Alexa say that I needed to make a very brief introduction. Mine will
[13:19.800 --> 13:25.160]  be, I promise I'm timing here, I'll be under two and a half minutes. My favorite childhood,
[13:25.160 --> 13:32.560]  I'm Bradley Kuhn. I work for an organization, a charity called the Software Freedom Conservancy.
[13:32.560 --> 13:39.600]  My primary job has been related to copy left license compliance since 1997. I've seen
[13:39.600 --> 13:46.840]  a lot with regard to that issue, which does interact quite frequently with the issue that
[13:46.840 --> 13:51.800]  you are here to discuss today of software bills and materials. My favorite childhood
[13:51.800 --> 13:57.000]  story, by the way, is the story of the emperor has no clothes, and I found throughout my
[13:57.000 --> 14:02.200]  career in open source and free software that I'm often the only one willing to say that
[14:02.200 --> 14:07.440]  our emperors have no clothes. I think S-bombs is a case where that needs to be said at least
[14:07.440 --> 14:16.680]  to a certain extent. The most useful application at S-bombs is in cases where you are in an
[14:16.680 --> 14:23.800]  organization that produces proprietary and open source software together in products.
[14:23.800 --> 14:28.600]  If you are an organization that is 100% open source and free software and choose a copy
[14:28.600 --> 14:34.520]  left license, your usefulness of S-bombs is extremely limited, almost to the point that
[14:34.520 --> 14:38.840]  you may not even want to invest in getting involved in this kind of thing. Now I'm a
[14:38.840 --> 14:42.440]  realist and realize that almost all of you probably work for organizations, including
[14:42.440 --> 14:47.920]  the trade associations among you, that produce lots of proprietary software. As such, you're
[14:47.920 --> 14:50.840]  going to have to worry about all these issues we've been hearing about today, many of the
[14:50.840 --> 14:55.480]  tools today look very interesting to me to solve those kinds of problems. But I want
[14:55.480 --> 15:02.240]  to leave you with one thought, if I can, that is imagine if there was no proprietary software
[15:02.240 --> 15:06.720]  in your organization, that you didn't sell it, you didn't use it, and you didn't want
[15:06.720 --> 15:14.080]  to make it. And instead, you chose to look at the requirements of the copy left licenses
[15:14.080 --> 15:20.240]  like the GPL, which require you to produce the complete corresponding source code as
[15:20.240 --> 15:24.760]  a reproducible build every time you produce a binary. And you have to make that available
[15:24.760 --> 15:32.000]  to every customer you have. S-bombs are most often needed when you don't necessarily have
[15:32.000 --> 15:37.780]  all the source code to hand, or don't know if it's going to be to hand when you get something
[15:37.780 --> 15:43.120]  from another vendor. So my argument is that the level of effort that's being put in S-bombs
[15:43.120 --> 15:49.760]  is primarily to enable the continued production of proprietary software. Being a FOSDM and
[15:49.760 --> 15:54.280]  being a free software activist my whole career, that's generally not something that I'm that
[15:54.280 --> 16:02.640]  excited about, which is why I'm not excited about S-bombs.
[16:02.640 --> 16:18.640]  Okay, so we heard opening statements about uses, about general use and caveats of using
[16:18.640 --> 16:26.760]  them and why they're not needed, or in an ideal world if they're not needed. Okay, let's
[16:26.760 --> 16:38.200]  go back to that. Bradley, even if in an ideal world where an organization is producing free
[16:38.200 --> 16:45.880]  and open source software and following license obligations, they provide all the source for
[16:45.880 --> 16:51.720]  every release they're doing. Right. There might still be the use case that I want to find
[16:51.720 --> 16:56.800]  out which of my releases, plus products or whatever you want to call them, contain a
[16:56.800 --> 17:03.560]  vulnerable version of a library. Right.
[17:03.560 --> 17:07.120]  So if you have a lot of source code, this is a great tool called grep. And what you
[17:07.120 --> 17:11.440]  can do is you can search the entire source code and look if a version of something is
[17:11.440 --> 17:16.840]  in there. If you have all the source code for everything, and you never separate the
[17:16.840 --> 17:20.840]  source from the binary, why does grep not work? You tell me.
[17:20.840 --> 17:24.800]  Because it's easier to search a table of contents than the complete book. Right. That's why
[17:24.800 --> 17:28.240]  we have table of contents and indexes. Right.
[17:28.240 --> 17:34.240]  Yeah. It's funny, since things have become electronic, I generally just turn the PDF
[17:34.240 --> 17:40.560]  into text and grep anymore. I don't use table of contents. Really? Yeah. Okay. Okay. Okay.
[17:40.560 --> 17:47.880]  So we have a source file. I used to write C. I used to be full of if defs. So how do
[17:47.880 --> 17:53.240]  I, if I search the source code, I will find a line of code, but it's not telling me whether
[17:53.240 --> 17:58.480]  that line of code was actually compiled into the binary, and now actually on my target
[17:58.480 --> 18:07.520]  architecture, target hardware. So how do we get round that? So we've talked about having
[18:07.520 --> 18:15.160]  sort of a trail of evidence from the source code to a binary so we can then sort of match
[18:15.160 --> 18:20.440]  the two together. If we have different compile options, I would expect we'll get different
[18:20.440 --> 18:26.560]  binaries, I hope. So therefore, how do we accommodate that?
[18:26.560 --> 18:33.840]  I'd love to. And so in the world I'm imagining, which does not exist, I agree with you. This
[18:33.840 --> 18:36.960]  is why you'll have to do this work, because the world that I've been working towards my
[18:36.960 --> 18:42.480]  whole career doesn't exist. But if it did, and all software was under the Afaro GPL,
[18:42.480 --> 18:46.480]  you would be required every time you build a binary to make sure you had a reproducible
[18:46.480 --> 18:51.720]  build that can produce that binary. So when you found the vulnerability in that binary,
[18:51.720 --> 18:56.840]  you would have stored the complete corresponding source release right next to all the binaries.
[18:56.840 --> 19:00.520]  You take the binary that's sitting out in the field, you compare the checks on to the
[19:00.520 --> 19:04.240]  binary in your repository of binaries and source code, and voila, there's your source code
[19:04.240 --> 19:07.840]  release that you made at the time you built it years ago. Simple enough.
[19:07.840 --> 19:14.680]  I'm going to just, I still, I mean, I get it, right? Yes, theoretically, we should be
[19:14.680 --> 19:22.840]  able to reproduce everything 100%, but in practice, like, we don't do things like inspect
[19:22.840 --> 19:29.960]  every jar of food that's coming off the assembly line. We only inspect some of them just for
[19:29.960 --> 19:38.480]  scalability purposes. So the SBOM still has a value there in providing a shortcut so that
[19:38.480 --> 19:44.400]  you don't have to do a bunch of work over and over and over again on demand every time.
[19:44.400 --> 19:52.720]  It does. I mean, I get it though. You're right. In an ideal universe, that would be true when
[19:52.720 --> 19:58.960]  we have unlimited time, unlimited compute resources to do all these reproducible builds.
[19:58.960 --> 20:06.320]  In practice, though, even if there aren't constraints on time and compute resource, reproducible
[20:06.320 --> 20:16.520]  builds are extremely limited in, you know, I mean, it takes no, no, no, no, no, but they
[20:16.520 --> 20:23.320]  can, they can, they can approximate a lot of what you would get out of it. Not everything.
[20:23.320 --> 20:32.320]  No, not everything, but you can approximate some things, right? So I don't, I mean, I
[20:32.320 --> 20:39.320]  agree with you in principle that reproducible builds would prove a lot of things, everything,
[20:39.320 --> 20:43.200]  right? That would, that would absolutely solve a lot of problems, but I don't know if everybody
[20:43.200 --> 20:47.200]  is really willing to do, to live in that world.
[20:47.200 --> 20:48.200]  Yeah.
[20:48.200 --> 20:53.200]  My view is be the change you want to be in the world. That's why I support it. What
[20:53.200 --> 21:03.000]  you feel is instead of investing in us, Tom? I think part of our disagreement here of different
[21:03.000 --> 21:08.840]  views is the slide that Kate showed in the beginning, that we're not talking about an
[21:08.840 --> 21:15.440]  S-bomb, though, they're different type of S-bombs, right? And they're S-bombs that apply
[21:15.440 --> 21:24.320]  to the source and they're S-bombs showing what the build is or what the deploy thing
[21:24.320 --> 21:30.360]  is and stuff like that, right? Now, to Bradley's point, once you have everything documented
[21:30.360 --> 21:40.600]  and provided, people can recreate this information, right? So the great example that Bradley said
[21:40.600 --> 21:46.720]  this is looking at the source, right? But if the obligations are, we don't only give
[21:46.720 --> 21:53.240]  the source, but also the build instructions and all the scripts that the license obligations
[21:53.240 --> 22:01.280]  require, right? So people can go and recreate it and then try to find out this information,
[22:01.280 --> 22:07.840]  right? But so the information will be there, right? The question is how easy we want you
[22:07.840 --> 22:14.840]  to have, right? Sorry, you want it? No?
[22:14.840 --> 22:16.840]  What did you say? Questions?
[22:16.840 --> 22:18.840]  Hmm? All right. Yeah, let's talk.
[22:18.840 --> 22:23.840]  Maybe one moment. So I think I completely agree with you that it is better to take such
[22:23.840 --> 22:31.840]  decisions on the sources. But what is missing to do this is that the current vulnerability
[22:31.840 --> 22:38.840]  databases that we have only reference vulnerabilities in giving it names, naming components. So there
[22:38.840 --> 22:44.840]  is the missing of a vulnerability is present in this file, in this function, with this
[22:44.840 --> 22:50.840]  method signature and so forth. And so I do not know what you want to search for. So if
[22:50.840 --> 22:56.840]  you only search for CPD blah, blah, blah, you will not be able to catch all instances
[22:56.840 --> 23:01.840]  on the vulnerable code because maybe a project has been set, we named the code has been
[23:01.840 --> 23:05.840]  responded and so forth. So that is, I think, lacking.
[23:05.840 --> 23:12.840]  Okay, so the comment was that, for example, vulnerability information does not usually
[23:12.840 --> 23:19.840]  refer to specific source files and lines on the source file, but it refers to product
[23:19.840 --> 23:24.840]  names or library names or whatever. So in order to find something you have to have to
[23:24.840 --> 23:31.840]  look for these, right, and not for the fine grain that we are talking about in a gripped
[23:31.840 --> 23:37.840]  part, right. Yeah. Thomas.
[23:37.840 --> 23:55.840]  So I know we talk a lot about security and licensing, but funny enough, how Ortt started
[23:55.840 --> 24:02.840]  had nothing to do with out licensing history at all. We basically wanted, the CTO wanted
[24:02.840 --> 24:07.840]  to figure out what are we doing and where can we go more efficient and where should we
[24:07.840 --> 24:12.840]  invest in the language that we should be going. And by doing the whole as-bolts and having
[24:12.840 --> 24:17.840]  the old stuff, we actually see what we are reducing and then we are directing these in
[24:17.840 --> 24:22.840]  near organization like, okay, yeah, you guys are using Ruby, you guys are using Java.
[24:22.840 --> 24:27.840]  Actually, we are all standardized in this. Actually, the company actually saved a lot
[24:27.840 --> 24:31.840]  of money by this organization. So again, this is often forgotten that as-bolts can be a
[24:31.840 --> 24:37.840]  great way to basically make your building software more efficient. And that alone for
[24:37.840 --> 24:40.840]  that, I will build as-bolts even if my code is completely over sourced.
[24:40.840 --> 24:46.840]  All right. So, repeating for the mic, sorry. The comment was that S-bombs, while we are
[24:46.840 --> 24:52.840]  talking about uses in compliance and security, can also be used in a lot of other ways and
[24:52.840 --> 24:58.840]  can be very useful in such a way. For example, having a software catalog of components being
[24:58.840 --> 25:03.840]  used by different, you know, parts of the company. Sorry, Anton.
[25:03.840 --> 25:14.840]  So, I totally agree, Thomas. I think certainly the large organizations, I think we probably
[25:14.840 --> 25:19.840]  got that discussion a bit with Siemens this morning. No criticism of it. Big organizations
[25:19.840 --> 25:26.840]  have a very difficult to share things. And so, if you had S-bombs of your build and then
[25:26.840 --> 25:32.840]  having a way of identifying common building blocks, I won't hesitate to say the word
[25:32.840 --> 25:39.840]  products, or different instances of the same product, then yes, there must be some business
[25:39.840 --> 25:45.840]  opportunities to, A, save money, or B, be more efficient. So, and I don't know whether
[25:45.840 --> 25:49.840]  anyone is starting to see that or starting to, I don't know whether you started seeing
[25:49.840 --> 25:52.840]  that, Thomas, with your, in your own industry.
[25:52.840 --> 25:57.840]  So, just look here. I now work on how to open Pinos to see how we can build an S-bombs
[25:57.840 --> 26:02.840]  for them. All of their code is fully open. If you had an S-bombs, they can also see
[26:02.840 --> 26:05.840]  like, oh, where are people contributing? Because we have resolved everything back to
[26:05.840 --> 26:10.840]  sources. And we can actually figure out, like, okay, these are where people are contributing.
[26:10.840 --> 26:14.840]  These are people using these libraries. So, we can actually do three Pinos projects
[26:14.840 --> 26:20.840]  in a group. We have here people, here people. We need more job guys. Here and here are
[26:20.840 --> 26:25.840]  already people who are using this particular library. So, these people in this Pinos project
[26:25.840 --> 26:30.840]  can probably help those products in that Pinos project solve things. And so, it doesn't
[26:30.840 --> 26:34.840]  matter the size of the machine, it's really about building software efficiently.
[26:34.840 --> 26:42.840]  Yeah. Okay. So, I think what Thomas is saying is, even if things are fully open, then it's
[26:42.840 --> 26:52.840]  going to help as well. I would also agree that whether proprietary software still exists.
[26:52.840 --> 26:57.840]  I used to be working in the defence sector. That's never going to go open source. It uses
[26:57.840 --> 27:03.840]  open source, but it's not going to use fully open source for obvious reasons. But we've
[27:03.840 --> 27:09.840]  got to keep those separate. And actually, businesses need to see those separate anyway. And S-bombs
[27:09.840 --> 27:13.840]  is potentially a good way of sharing them and also handling some of the things like export
[27:13.840 --> 27:18.840]  control that I think one of the projects said this morning was actually handling export control
[27:18.840 --> 27:24.840]  things, which is also an interesting thing that obviously some of the licenses, the
[27:24.840 --> 27:29.840]  open source licenses don't have that constraint, but businesses do. And we have to recognise
[27:29.840 --> 27:38.840]  that. No, I just was going to add just to that. I think that's the other thing we saw
[27:38.840 --> 27:43.840]  earlier this morning with the SW 360. Identifying the components that are reused over and over
[27:43.840 --> 27:48.840]  again kind of goes right in with that. Saying, okay, this component, it might only have two
[27:48.840 --> 27:54.840]  people working on it, but it is used in 19 different products that our company produces.
[27:54.840 --> 28:01.840]  That may, from a management perspective, when we go to devote resources, whether it's additional
[28:01.840 --> 28:07.840]  headcount, whatever it is, we know that's a project that is key to everything else we're
[28:07.840 --> 28:13.840]  doing, right? So, yeah, I think that does help. Again, it's something you probably could reverse
[28:13.840 --> 28:19.840]  engineer by looking at, you know, who's pulling from a Git repository or whatever, but it
[28:19.840 --> 28:23.840]  would be very, no, you really, yeah, it would be very difficult to look at. You'd have to
[28:23.840 --> 28:28.840]  time things and, yeah, it would be hard.
[28:28.840 --> 28:32.840]  And to be clear, I agree completely. Many of the tools we saw today, and generally speaking,
[28:32.840 --> 28:38.840]  SBOMs are a wonderful tool to aid in the production of proprietary software and mixed proprietary
[28:38.840 --> 28:43.840]  open-source software. And I think all of you who are in that business, you should probably be
[28:43.840 --> 28:48.840]  working and doing more with SBOMs because you're going to need it. I agree. But I just am not
[28:48.840 --> 28:52.840]  in that business. I don't want a world with proprietary software. I want a world with free
[28:52.840 --> 28:59.840]  software. And in the free software world, the better place to, you have to pick where resources
[28:59.840 --> 29:04.840]  go. The better place to focus resources is in reproducible builds, not SBOMs. If the amount
[29:04.840 --> 29:10.840]  of funding and effort going into SBOM technology right now was going into reproducible builds
[29:10.840 --> 29:16.840]  technology, I think we would get better gains. So it's a question of where limited resources are
[29:16.840 --> 29:20.840]  being deployed, more than it is whether or not SBOMs are useful. I agree completely. They are.
[29:20.840 --> 29:25.840]  Are they more useful than things we could be doing elsewhere with those resources?
[29:25.840 --> 29:29.840]  Yeah, come on.
[29:29.840 --> 29:55.840]  Again, many of us may work for commercial companies, but on the other side, we are maintained as a open-source project. So we do open-source. And I personally, I do not care about GDL licenses so much.
[29:55.840 --> 30:01.840]  I would like to have SBOMs and my open-source projects to make it more easy for other people to
[30:01.840 --> 30:25.840]  consume them. This is I do the software because I like it and because I like other people using it. This is what I do. And having a good overview about the topic and the point that you use is also a good way to help other people. What kind of open-source control design do you use under the
[30:25.840 --> 30:31.840]  framework of open-source licensing?
[30:31.840 --> 30:49.840]  I'm sorry, but I just read up the idea that I need a source code for everything and tell everybody that you want to know something and then you need to throw it towards the source code. I want to provide good information for other people who would like to use my open-source.
[30:49.840 --> 31:08.840]  So the point here was that even when producing open-source license software, you find SBOM useful for telling people what your software uses or for documenting your software, essentially.
[31:08.840 --> 31:20.840]  Okay? Please.
[31:20.840 --> 31:42.840]  I'm mostly almost no lawyer in my back because they know exactly what is coming there. They know where it's coming from and we have the data and usually the lawyer says okay, it's passing by this one and this one you know we don't need to care about this thing. So we do have this information already here, completely set up in the system and says
[31:42.840 --> 31:45.280]  and say, okay, this is, you know, we know.
[31:45.280 --> 31:48.560]  So, it's looking at approval of the company.
[31:48.560 --> 31:50.580]  It's, without those information,
[31:50.580 --> 31:51.560]  it's always the same time.
[31:51.560 --> 31:53.760]  We just can't, we need to go to the discussions,
[31:53.760 --> 31:54.880]  we need to see if the company
[31:54.880 --> 31:57.320]  that is losing money and time.
[31:57.320 --> 32:00.920]  Okay. How do I summarize that?
[32:00.920 --> 32:03.600]  As booms are also useful for getting legal approval for
[32:03.600 --> 32:06.040]  using software or something like that.
[32:06.040 --> 32:09.120]  Yeah. Thank you very much.
[32:09.120 --> 32:14.880]  Sorry. And this is probably going to be
[32:14.880 --> 32:16.160]  an open question out to the,
[32:16.160 --> 32:19.240]  to the audience of those who are generating S-bombs now.
[32:19.240 --> 32:23.640]  Open source project time involved in is
[32:23.640 --> 32:28.840]  Python-based and it supports 3.7 to 3.11.
[32:28.840 --> 32:33.880]  We generate an S-bomb every week in both
[32:33.880 --> 32:38.760]  Cyclone DX and SPDX for each version of Python and
[32:38.760 --> 32:40.360]  each version of Python generates
[32:40.360 --> 32:42.760]  a different S-bomb because you've
[32:42.760 --> 32:47.040]  got different dependencies that are version-specific.
[32:47.040 --> 32:50.880]  So, I have, depending on the version of Python,
[32:50.880 --> 32:54.800]  I may have, I think there's about 25 direct dependencies,
[32:54.800 --> 32:56.160]  but then when you get the implicit ones,
[32:56.160 --> 32:57.720]  it gets another about another 30.
[32:57.720 --> 32:59.600]  Some of them have got 50 odd dependencies,
[32:59.600 --> 33:01.120]  some have got 60.
[33:01.120 --> 33:05.880]  So, I agree with your comment about publicizing it,
[33:05.880 --> 33:09.160]  but are you, are people picking up the right version?
[33:09.160 --> 33:12.720]  So, they are aware of what your software is using
[33:12.720 --> 33:15.440]  because your software use will change.
[33:15.440 --> 33:21.280]  Oh, yes.
[33:21.280 --> 33:22.280]  Yeah. Okay.
[33:22.280 --> 33:26.440]  So, right.
[33:26.440 --> 33:28.720]  Okay. Brilliant.
[33:28.720 --> 33:30.080]  Glad you picked that up.
[33:30.080 --> 33:31.960]  So, therefore, how much,
[33:31.960 --> 33:36.560]  so are we capturing that information in the standards?
[33:36.560 --> 33:37.480]  Yes.
[33:37.480 --> 33:38.480]  Consistently?
[33:38.480 --> 33:39.600]  Yes.
[33:39.600 --> 33:40.920]  I'm not.
[33:40.920 --> 33:45.120]  In the standard is one thing,
[33:45.120 --> 33:47.720]  actually collecting it and storing it
[33:47.720 --> 33:49.640]  in the actual S-bomb that you're producing.
[33:49.640 --> 33:51.120]  Right. I'll just repeat that.
[33:51.120 --> 33:52.040]  Right. Yeah.
[33:52.040 --> 33:54.280]  The standard allows for that,
[33:54.280 --> 33:57.360]  but doesn't guarantee that when you produce the S-bomb that
[33:57.360 --> 34:01.360]  that information will get A collected or B recorded.
[34:01.360 --> 34:05.120]  Which is, yeah, a huge problem with usually,
[34:05.120 --> 34:07.480]  it's a tooling problem usually.
[34:07.480 --> 34:12.280]  And we've seen tooling improve a lot,
[34:12.280 --> 34:18.440]  but again, it's a journey from where we would like to be ideally,
[34:18.440 --> 34:21.520]  right, to from where we are now is,
[34:21.520 --> 34:24.080]  just takes time and effort, obviously.
[34:24.080 --> 34:27.480]  But that's the number one problem I see in the field is
[34:27.480 --> 34:33.320]  that the tooling is not producing either complete results
[34:33.320 --> 34:36.240]  or consistent with other tools.
[34:36.240 --> 34:38.920]  Right. I mean, we saw a ton of examples of that,
[34:38.920 --> 34:40.800]  where tools are producing different results.
[34:40.800 --> 34:41.720]  Yeah.
[34:41.720 --> 34:43.280]  May I ask that?
[34:43.280 --> 34:45.280]  Do you know why there's a wide, especially with open source
[34:45.280 --> 34:48.280]  sites, is the level of education
[34:48.280 --> 34:51.680]  that is applied to new developers regarding this topic
[34:51.680 --> 34:52.760]  is a wide variety.
[34:52.760 --> 34:55.160]  So I've been producing S-bombs and other stuff
[34:55.160 --> 34:56.600]  for more than seven years.
[34:56.600 --> 34:59.160]  I spoke to more lawyers and package managers
[34:59.160 --> 35:01.160]  developing than I care about.
[35:01.160 --> 35:05.120]  Everybody thinks that package managers get a data that is easy.
[35:05.120 --> 35:06.600]  It is not.
[35:06.600 --> 35:07.200]  Right. Yeah.
[35:07.200 --> 35:11.800]  So to summarize that point, he's been producing S-bombs
[35:11.800 --> 35:14.360]  for years, seven years.
[35:14.360 --> 35:14.840]  Right.
[35:14.840 --> 35:17.920]  And it's not just a matter of querying a package manager
[35:17.920 --> 35:20.040]  and being done, right?
[35:20.040 --> 35:22.760]  There's, I mean, we see that all the time.
[35:22.760 --> 35:25.120]  I work in containerized software mostly.
[35:25.120 --> 35:28.120]  So a lot of the S-bombs I see produced
[35:28.120 --> 35:29.760]  are actually produced after the build,
[35:29.760 --> 35:32.840]  because somebody pulls a base image.
[35:32.840 --> 35:37.040]  There's no S-bomb for that base image to consume today.
[35:37.040 --> 35:39.400]  Hopefully, in the future, there will be.
[35:39.400 --> 35:43.280]  But those things that are in those base images,
[35:43.280 --> 35:44.840]  a lot of times, are opaque.
[35:44.840 --> 35:48.800]  It may be open source software, but it's a Rust binary that
[35:48.800 --> 35:51.880]  doesn't have audit information compiled in.
[35:51.880 --> 35:56.800]  And there have been improvements in that.
[35:56.800 --> 35:59.960]  Go puts audit information into the binaries.
[35:59.960 --> 36:03.360]  Rust can do it, but doesn't do it by default yet.
[36:03.360 --> 36:06.200]  So there's still, yes, a ton of that.
[36:06.200 --> 36:10.800]  And so the rest of his point was the developer education.
[36:10.800 --> 36:13.320]  It's one thing to be aware of S-bombs as a concept.
[36:13.320 --> 36:15.880]  It's another thing to be aware of the limitations, what
[36:15.880 --> 36:18.480]  has to be accounted for when you're building them,
[36:18.480 --> 36:21.680]  when you're producing software in general.
[36:21.680 --> 36:25.360]  There's just a lot of plates spinning all at the same time.
[36:25.360 --> 36:27.440]  And maybe to add to that, we have a little talk
[36:27.440 --> 36:28.880]  on Friday about us.
[36:28.880 --> 36:34.200]  Please do not reinvent the wheel if you need S-bombs to.
[36:34.200 --> 36:36.720]  Ask the community, have all the opportunities
[36:36.720 --> 36:40.120]  to drive out of there, so building them all
[36:40.120 --> 36:42.400]  and wasting a lot of time and effort.
[36:42.400 --> 36:43.400]  It's just too useful.
[36:43.400 --> 36:48.440]  And another thing that you have to find the workshop on Friday,
[36:48.440 --> 36:51.600]  teaching developers is OK, but it's not the right path.
[36:51.600 --> 36:53.840]  Because developers are creatures of habits.
[36:53.840 --> 36:56.400]  And they will not follow you or not listen to you,
[36:56.400 --> 36:59.040]  even when the deadlines are very near.
[36:59.040 --> 37:02.160]  I mean, so the last comment was that developers,
[37:02.160 --> 37:04.400]  it's difficult to get developers to change their behavior
[37:04.400 --> 37:07.680]  and they don't listen, which I find too in my work, which
[37:07.680 --> 37:09.920]  is primarily copy left license compliance.
[37:09.920 --> 37:12.840]  To your point, I wanted to add, one of the reasons
[37:12.840 --> 37:14.400]  is probably very difficult for you.
[37:14.400 --> 37:16.240]  It's not the only reason, but one of the reasons
[37:16.240 --> 37:18.840]  is difficult to build S-bombs for containers
[37:18.840 --> 37:22.320]  is because nearly all containers in the world
[37:22.320 --> 37:24.960]  are violating the GPL.
[37:24.960 --> 37:27.760]  And so you don't have the source code to even go
[37:27.760 --> 37:29.920]  and start building your S-bombs off the source code.
[37:29.920 --> 37:32.720]  You're stuck with binaries that are GPL violating.
[37:32.720 --> 37:34.720]  But there is absolutely no funding available
[37:34.720 --> 37:36.360]  to handle that problem in the container world
[37:36.360 --> 37:37.600]  and the GPL compliant side.
[37:37.600 --> 37:39.720]  So I guess you'll head on the binary side,
[37:39.720 --> 37:42.320]  because you have all your S-bombs funding to fund it that way.
[37:45.840 --> 37:47.800]  OK, yeah, sorry.
[37:47.800 --> 37:50.200]  I'm trying to understand your point.
[37:50.200 --> 37:53.760]  I understand that it would imply that if all software was
[37:53.760 --> 37:57.240]  open, we wouldn't have any need to S-bombs,
[37:57.240 --> 38:00.280]  besides perhaps the things that they mentioned.
[38:00.280 --> 38:02.520]  Even though every talk today was stuff
[38:02.520 --> 38:05.400]  that wouldn't matter if all software was open.
[38:05.400 --> 38:07.920]  But I'm trying to understand what your point is.
[38:07.920 --> 38:11.960]  Are you implying that instead of actually being here
[38:11.960 --> 38:14.640]  at both them, pushing open source software
[38:14.640 --> 38:18.760]  so that all software, at some day, being open source,
[38:18.760 --> 38:21.960]  are you implying that we're wasting time producing stuff
[38:21.960 --> 38:24.520]  that actually supports the current standard?
[38:24.520 --> 38:25.800]  But it's completely yours.
[38:25.800 --> 38:28.480]  Yeah, that's a question for me, and I'll summarize it.
[38:28.480 --> 38:30.720]  So the question was, in this imaginary world
[38:30.720 --> 38:33.240]  that I proposed where all software is open source
[38:33.240 --> 38:35.440]  and free software, is what I'm saying
[38:35.440 --> 38:38.120]  that the effort being put into S-bombs
[38:38.120 --> 38:40.200]  is actually enabling the production
[38:40.200 --> 38:41.320]  of proprietary software.
[38:41.320 --> 38:43.200]  And I think the answer is yes.
[38:43.200 --> 38:47.520]  I think S-bombs are a system to make it easier
[38:47.520 --> 38:50.720]  to ingest open source software and bring it
[38:50.720 --> 38:52.000]  into proprietary software.
[38:52.000 --> 38:54.080]  And I came to as many of the talks
[38:54.080 --> 38:57.040]  as I could today when I didn't have other obligations.
[38:57.040 --> 38:58.880]  And many of the talks today were talking
[38:58.880 --> 39:01.800]  about ingestion of open source for that purpose.
[39:01.800 --> 39:04.640]  When you hear people talking about, oh, we
[39:04.640 --> 39:07.360]  can be able to blacklist GPL stuff.
[39:07.360 --> 39:09.880]  Well, the reason they want to blacklist copy left stuff
[39:09.880 --> 39:11.920]  is they want to make proprietary software.
[39:11.920 --> 39:13.360]  Now, it's a question of values.
[39:13.360 --> 39:15.360]  The commentator over there that I think never got summarized
[39:15.360 --> 39:17.400]  was pointing out that in his values,
[39:17.400 --> 39:20.160]  he feels he really wants to see his software put
[39:20.160 --> 39:23.560]  into proprietary software and to encourage it and make it easy.
[39:23.560 --> 39:26.280]  I don't, obviously, agree with those values.
[39:26.280 --> 39:28.760]  If you agree with those values, I agree completely.
[39:28.760 --> 39:31.400]  S-bombs are a great solution to be
[39:31.400 --> 39:36.080]  able to encourage the adoption of non-copy-lefted software.
[39:36.080 --> 39:37.520]  This is a very stark issue.
[39:37.520 --> 39:38.720]  I want to give an example.
[39:38.720 --> 39:40.400]  There was a talk earlier you can go on the internet
[39:40.400 --> 39:42.160]  and figure out which one it was.
[39:42.160 --> 39:45.680]  But their system, when it decided,
[39:45.680 --> 39:48.280]  when putting licenses in buckets,
[39:48.280 --> 39:51.480]  when it saw that it was a copy left license,
[39:51.480 --> 39:54.120]  they had a Python function that I found in their source
[39:54.120 --> 39:56.960]  grid that says, oh, if it's a copy left or it's a license,
[39:56.960 --> 40:02.320]  this Python function should return the string is-danger.
[40:02.320 --> 40:05.280]  So the concept that even those writing S-bomb tools
[40:05.280 --> 40:08.440]  believe that copy left is a dangerous thing
[40:08.440 --> 40:10.600]  is kind of giving you a sense of the values that
[40:10.600 --> 40:12.680]  are circulating around the S-bomb community, which
[40:12.680 --> 40:15.760]  is unfortunate, because I think the GPL is a wonderful license,
[40:15.760 --> 40:17.120]  not a dangerous one.
[40:17.120 --> 40:19.080]  But I realize others in the room disagree.
[40:21.800 --> 40:25.440]  My question was, we cannot see the other side of the coin.
[40:25.440 --> 40:29.360]  So wouldn't that, I mean, I'm not trying
[40:29.360 --> 40:32.680]  to reconcile free software and commercial software by any means,
[40:32.680 --> 40:35.080]  but wouldn't that extra transparency
[40:35.080 --> 40:40.280]  brought by the S-bomb community also help for your use case?
[40:40.280 --> 40:44.840]  Can I then define when that piece of software is being used?
[40:44.840 --> 40:46.160]  The answer is no.
[40:46.160 --> 40:47.760]  And I don't want to get too much into it,
[40:47.760 --> 40:48.960]  but I'll talk about it later, because I
[40:48.960 --> 40:50.480]  don't want to take too much of the time.
[40:50.480 --> 40:51.960]  All right.
[40:51.960 --> 40:55.320]  Kate, sorry.
[40:55.320 --> 41:01.600]  I want open source database and safety critical applications.
[41:01.600 --> 41:03.760]  Open source has bugs.
[41:03.760 --> 41:08.680]  How can I track the bugs and fix them
[41:08.680 --> 41:12.680]  so it doesn't kill people unless I know what's there?
[41:12.680 --> 41:15.600]  But just in the source code, all through,
[41:15.600 --> 41:17.920]  I'm not going to be able to find and fix.
[41:17.920 --> 41:19.480]  It's at scale.
[41:19.480 --> 41:22.400]  We need to abstract to go to scale.
[41:22.400 --> 41:24.120]  How do we change?
[41:24.120 --> 41:28.800]  How do you propose it to solve that problem?
[41:28.800 --> 41:31.120]  So the code, you want to start at the right time?
[41:31.120 --> 41:33.120]  OK.
[41:33.120 --> 41:34.720]  I think you just run the mic to Kate.
[41:34.720 --> 41:36.400]  Yeah.
[41:36.400 --> 41:37.040]  That's OK.
[41:37.040 --> 41:42.920]  So the question is that we want to do functional safety
[41:42.920 --> 41:44.600]  with open source, right?
[41:44.600 --> 41:47.040]  And in order to do it on scale, we
[41:47.040 --> 41:51.320]  have to abstract things outside on a higher level
[41:51.320 --> 41:55.160]  than simple source code and talk, for example, in packages
[41:55.160 --> 41:59.000]  and have, again, the table of contents of things
[41:59.000 --> 42:03.600]  rather than the actual source files.
[42:03.600 --> 42:05.720]  So I want to respond.
[42:05.720 --> 42:07.640]  Off the mic, it was said there's a concern
[42:07.640 --> 42:09.840]  that software is going to kill people with the implication
[42:09.840 --> 42:12.520]  that without us bombs, we won't be
[42:12.520 --> 42:15.600]  able to prevent the killing of people with software.
[42:15.600 --> 42:18.000]  Which I agree, there is software that has killed people.
[42:18.000 --> 42:20.880]  I was very taken of the Therak-25 case, which,
[42:20.880 --> 42:23.200]  if you're in computer science, you probably studied,
[42:23.200 --> 42:25.840]  which was a proprietary software system that murdered
[42:25.840 --> 42:28.280]  a number of people due to a software bug.
[42:28.280 --> 42:31.560]  So I agree completely that we have a long, long history
[42:31.560 --> 42:34.400]  of software bugs injuring people.
[42:34.400 --> 42:39.720]  My argument is that the best thing to have
[42:39.720 --> 42:42.000]  when you have a binary, that you worry has a bug
[42:42.000 --> 42:44.520]  and has a vulnerability, the best thing to have
[42:44.520 --> 42:46.640]  is to have a completely reproducible build
[42:46.640 --> 42:48.240]  for that binary.
[42:48.240 --> 42:53.000]  Such that you can go and make that binary again tens of years
[42:53.000 --> 42:55.680]  later, hundreds of years later, and see, again,
[42:55.680 --> 42:58.320]  have all the scripts used to control compilation,
[42:58.320 --> 43:01.480]  installation, at your fingertips for every binary produced
[43:01.480 --> 43:02.120]  in the world.
[43:02.120 --> 43:04.640]  I agree with you that it takes a lot of resources to do that.
[43:04.640 --> 43:06.640]  I would like to get to that world where that's the case,
[43:06.640 --> 43:10.320]  where every person who relies on a piece of binary software
[43:10.320 --> 43:12.960]  has the immediate access to the complete corresponding source
[43:12.960 --> 43:13.680]  code.
[43:13.680 --> 43:15.280]  There are some tools in that case
[43:15.280 --> 43:17.360]  that I think should exist that don't.
[43:17.360 --> 43:19.720]  I don't see anybody in this community working on them.
[43:19.720 --> 43:21.680]  For example, our mind was working years ago
[43:21.680 --> 43:27.120]  on this very interesting tool that was doing orchestration
[43:27.120 --> 43:30.480]  through build processes, where it was tracking
[43:30.480 --> 43:35.440]  exact hashes of source code that was going into a binary.
[43:35.440 --> 43:37.960]  Those kinds of things are very excellent tools
[43:37.960 --> 43:39.600]  that we do need and should be created,
[43:39.600 --> 43:43.520]  and they would be a great enabler to the types of things
[43:43.520 --> 43:44.400]  that I'm talking about.
[43:44.400 --> 43:47.720]  But I don't see S-bombs bringing us that, at least not
[43:47.720 --> 43:49.320]  at the moment.
[43:49.320 --> 43:55.040]  I just want to say that the S-p-d-x-s-bombs are
[43:55.040 --> 43:56.040]  bringing things in the past.
[43:56.040 --> 44:01.040]  And we've had this exact of a while today.
[44:01.040 --> 44:03.240]  What's with the things that are not prepared, the tool that
[44:03.240 --> 44:03.740]  does it?
[44:03.740 --> 44:08.040]  Yachto is doing it, and Deppro is doing it.
[44:08.040 --> 44:11.040]  Hashes of the sources, and what's going to be intermediate,
[44:11.040 --> 44:12.640]  and how this is going in the follow-up.
[44:12.640 --> 44:14.800]  OK, so Kate just told us the problem's solved.
[44:14.800 --> 44:16.920]  So we don't have to do anything more.
[44:16.920 --> 44:17.400]  That's great.
[44:17.400 --> 44:20.240]  You use Yachto and the problem's solved, it sounds like.
[44:20.240 --> 44:25.440]  OK, so the comment was that build tools, no,
[44:25.440 --> 44:32.400]  build platforms like Yachto and Zephyr already record all
[44:32.400 --> 44:37.760]  hashes of sources going into binaries for their platforms.
[44:37.760 --> 44:39.720]  Great.
[44:39.720 --> 44:41.120]  Any other questions?
[44:41.120 --> 44:42.320]  Come on, people, don't be shy.
[44:42.320 --> 44:43.320]  Yeah?
[44:43.320 --> 44:44.440]  Yeah, I have a cool question.
[44:44.440 --> 44:48.280]  So for the textbooks, is the idea, and this might be a very
[44:48.280 --> 44:52.160]  basic question, is the idea that we produce an textbook that
[44:52.160 --> 44:56.800]  represents the task factor or, I don't know,
[44:56.800 --> 45:00.160]  or as large whatever combination of tasks?
[45:00.160 --> 45:02.640]  And that includes both.
[45:02.640 --> 45:05.080]  Build dependencies, transitive tasks,
[45:05.080 --> 45:07.440]  common dependencies, task dependencies.
[45:07.440 --> 45:12.400]  Or is the idea that you use multiple of these as a factor
[45:12.400 --> 45:14.880]  and for us, we'll have you.
[45:14.880 --> 45:17.480]  So that you can then operate the idea.
[45:17.480 --> 45:19.960]  I have a problem with vulnerability.
[45:19.960 --> 45:22.880]  I realize it's an issue in a particular thinking
[45:22.880 --> 45:26.480]  where it's, let's say, if it's an open as a cell vulnerability,
[45:26.480 --> 45:29.440]  my build tool, I probably don't have as much.
[45:29.440 --> 45:34.640]  But if it's in the document, I'm going to have much more.
[45:34.640 --> 45:35.120]  You want that?
[45:35.120 --> 45:35.600]  Yeah.
[45:35.600 --> 45:36.840]  You summarize it.
[45:36.840 --> 45:37.880]  Yeah, I'll summarize it.
[45:37.880 --> 45:38.520]  Good.
[45:38.520 --> 45:40.840]  Yeah, so the question is whether or not
[45:40.840 --> 45:45.800]  the SBOM is intended to capture, in addition
[45:45.800 --> 45:48.000]  to the code and the dependencies,
[45:48.000 --> 45:51.720]  is it also capturing the build environment, et cetera,
[45:51.720 --> 45:53.240]  things like that, right?
[45:53.240 --> 45:55.520]  And the answer there is maybe.
[45:55.520 --> 45:58.600]  And that's kind of one of the reasons,
[45:58.600 --> 46:00.080]  like I don't know if you were here all day,
[46:00.080 --> 46:01.840]  but one of the first things that we covered
[46:01.840 --> 46:03.520]  was different types of SBOMs.
[46:03.520 --> 46:08.480]  So there are SBOMs specifically for code repositories.
[46:08.480 --> 46:12.960]  There are SBOMs specifically that are generated at build time.
[46:12.960 --> 46:16.480]  So yes, maybe there can be an SBOM
[46:16.480 --> 46:20.000]  for the exact combination of conditions,
[46:20.000 --> 46:22.680]  or there can be a more generalized SBOM.
[46:22.680 --> 46:25.920]  And there's use cases for both of those.
[46:25.920 --> 46:30.480]  How much are you able to get all of these?
[46:30.480 --> 46:31.840]  Maybe.
[46:31.840 --> 46:35.520]  Again, it depends on what you're consuming from other people.
[46:35.520 --> 46:38.280]  If you're consuming a Docker image,
[46:38.280 --> 46:41.040]  it may be too late to, you may be
[46:41.040 --> 46:44.280]  able to reproduce it in a, well, let's not get into that.
[46:44.280 --> 46:47.440]  I'll say one thing more about reproducible builds.
[46:47.440 --> 46:52.280]  Even in the universe where we have all the data,
[46:52.280 --> 46:54.960]  actually reproducing a build is extremely difficult,
[46:54.960 --> 46:57.200]  and maybe even impossible in some cases, right?
[46:57.200 --> 46:59.600]  Because there's just too many variables.
[46:59.600 --> 47:04.320]  So I am not one to shy away from saying,
[47:04.320 --> 47:06.760]  we should have an ideal and work towards it, right?
[47:06.760 --> 47:08.360]  I mean, absolutely.
[47:08.360 --> 47:11.880]  But the level of effort to achieve one goal
[47:11.880 --> 47:13.760]  is not necessarily the same amount of effort
[47:13.760 --> 47:15.440]  to achieve another goal.
[47:15.440 --> 47:17.440]  So.
[47:17.440 --> 47:21.240]  Yeah, I guess one of my questions was,
[47:21.240 --> 47:24.480]  let's say I have something I think that generates as well.
[47:24.480 --> 47:28.080]  I'm supposed to run multiple times throughout the pipeline,
[47:28.080 --> 47:29.840]  as opposed to throughout the blocks.
[47:29.840 --> 47:30.340]  Yeah.
[47:30.340 --> 47:30.840]  Yeah.
[47:30.840 --> 47:31.340]  Yeah.
[47:31.340 --> 47:32.320]  It depends.
[47:32.320 --> 47:32.820]  Yeah.
[47:32.820 --> 47:33.880]  The answer is it depends.
[47:33.880 --> 47:35.000]  It depends.
[47:35.000 --> 47:36.640]  The answer is always it depends.
[47:36.640 --> 47:41.840]  But I'm just looking at the highest one is the design one.
[47:41.840 --> 47:44.440]  Now, one of the things I've heard a lot of people,
[47:44.440 --> 47:47.640]  and we've talked about lists of ingredients several times
[47:47.640 --> 47:52.920]  today, people nervous about putting what's in their product
[47:52.920 --> 47:57.440]  because potentially people are saying, well,
[47:57.440 --> 48:00.280]  if you tell me I'm using package x, y, and z,
[48:00.280 --> 48:05.440]  then a competitor can also put x, y, and z together.
[48:05.440 --> 48:07.760]  So are people concerned about that?
[48:07.760 --> 48:09.840]  Because that's one of the things that people are saying
[48:09.840 --> 48:13.800]  is delaying the adoption and the publication of that.
[48:13.800 --> 48:16.680]  Or is it saying that certain S-bombs
[48:16.680 --> 48:19.600]  can have that level information, but with a very restricted
[48:19.600 --> 48:24.760]  audience, as I think from maybe the later down ones, which
[48:24.760 --> 48:26.920]  are probably more public because they potentially
[48:26.920 --> 48:28.760]  have different business needs?
[48:32.440 --> 48:33.840]  That's out for that.
[48:33.840 --> 48:36.600]  I'm not saying I've got a view, but let's say what do people
[48:36.600 --> 48:37.600]  think about that?
[48:37.600 --> 48:40.880]  Because people, I'm seeing some of the organizations
[48:40.880 --> 48:43.960]  saying, I don't want to publish my architecture,
[48:43.960 --> 48:46.560]  since it's an architecture, because that potentially
[48:46.560 --> 48:50.000]  is making a community potentially vulnerable.
[48:50.000 --> 48:52.200]  My business model being vulnerable.
[48:52.200 --> 48:55.720]  And go back to the market I used to work in,
[48:55.720 --> 49:00.360]  my architecture was protected under certain business needs.
[49:00.360 --> 49:01.920]  And I couldn't share that.
[49:01.920 --> 49:03.800]  I still can't share it.
[49:03.800 --> 49:05.400]  I just want to add one thing there.
[49:05.400 --> 49:07.720]  And Siemens had their talk earlier today
[49:07.720 --> 49:10.680]  about having different S-bombs for different use cases.
[49:10.680 --> 49:13.080]  And one of them was specifically around that.
[49:13.080 --> 49:18.120]  We have a specific S-bomb for regulatory consumption
[49:18.120 --> 49:19.760]  that only includes the information
[49:19.760 --> 49:21.400]  that the regulator needs.
[49:21.400 --> 49:23.160]  And I don't know if that's a, I actually
[49:23.160 --> 49:25.040]  wanted to talk to you guys about that.
[49:25.040 --> 49:27.080]  Is that produced from the other S-bombs?
[49:27.080 --> 49:28.360]  We'll get into that later.
[49:28.360 --> 49:32.680]  But they have the other S-bombs they only
[49:32.680 --> 49:34.240]  use for internal purposes.
[49:34.240 --> 49:37.360]  So even in the case of software that is not
[49:37.360 --> 49:39.560]  going to be distributed at all, there's still
[49:39.560 --> 49:43.520]  a very strong use case for S-bombs.
[49:43.520 --> 49:46.560]  That software that stays inside of Siemens maybe
[49:46.560 --> 49:49.000]  doesn't even go into a product and is only
[49:49.000 --> 49:52.720]  used for, let's say, internal accounting, I don't know,
[49:52.720 --> 49:54.640]  whatever.
[49:54.640 --> 49:55.320]  Right, right.
[49:55.320 --> 49:57.320]  So there's still a use case there
[49:57.320 --> 50:00.560]  where there's not a concern about necessarily
[50:00.560 --> 50:04.160]  poisoning the software or whatever, right?
[50:06.560 --> 50:09.080]  So yeah, I just wanted to tie back to that,
[50:09.080 --> 50:11.880]  because I wanted to A, remind myself to talk to you about it.
[50:11.880 --> 50:14.400]  But I thought it tied into what he was asking too.
[50:14.400 --> 50:17.240]  There's a true reality of being in big organizations,
[50:17.240 --> 50:20.480]  is because at some point someone will ask it, where,
[50:20.480 --> 50:23.000]  or when, or why.
[50:23.000 --> 50:25.440]  This is always about the project that you're working.
[50:25.440 --> 50:27.400]  And sometimes there's someone that
[50:27.400 --> 50:29.440]  is going to a completely different area,
[50:29.440 --> 50:30.960]  a completely different country.
[50:30.960 --> 50:33.040]  But for some how, it's using the project
[50:33.040 --> 50:34.720]  to do their discussions.
[50:34.720 --> 50:36.560]  And then what happens is that there's
[50:36.560 --> 50:38.560]  a lot of people who have meant itself
[50:38.560 --> 50:40.440]  trying to find information.
[50:40.440 --> 50:43.040]  If that's a thing that already happens on S-bombs,
[50:43.040 --> 50:44.840]  since there, you have all the information
[50:44.840 --> 50:46.360]  of the project details.
[50:46.360 --> 50:48.800]  And then this question could be totally sorted out.
[50:48.800 --> 50:52.120]  You're saying for just internal management audits
[50:52.120 --> 50:55.880]  of resource planning, something like that, right?
[50:55.880 --> 50:58.080]  Who was working on this project?
[50:58.080 --> 50:59.160]  Yeah, yeah.
[50:59.160 --> 51:00.840]  So all of that, yeah, that information
[51:00.840 --> 51:03.720]  can be captured in an S-bomb as well, right?
[51:03.720 --> 51:05.160]  Yeah, I agree with that.
[51:05.160 --> 51:06.720]  Yeah, I wanted to go back to you brought up
[51:06.720 --> 51:09.040]  this list of ingredients question again,
[51:09.040 --> 51:10.960]  which I think is a really interesting analogy
[51:10.960 --> 51:13.080]  to this whole situation.
[51:13.080 --> 51:15.520]  Certainly I've eaten processed foods in my life,
[51:15.520 --> 51:18.360]  and I don't cook everything from scratch.
[51:18.360 --> 51:22.520]  So having a list of ingredients is certainly much better
[51:22.520 --> 51:25.200]  than not having one if those are your only two choices,
[51:25.200 --> 51:27.840]  if you're given that false dichotomy.
[51:27.840 --> 51:29.960]  However, I'm much more interested in getting recipes,
[51:29.960 --> 51:33.000]  full recipes, with all the instructions
[51:33.000 --> 51:36.440]  that I am getting lists of ingredients for something.
[51:36.440 --> 51:38.920]  And similarly true, I've used proprietary software in my life.
[51:38.920 --> 51:41.320]  I avoid it because I don't just want a list of ingredients.
[51:41.320 --> 51:42.400]  I want the whole recipe.
[51:46.080 --> 51:51.880]  OK, so staying with a list of ingredients and food labels,
[51:51.880 --> 51:57.600]  analogy, whenever we see a list of ingredients,
[51:57.600 --> 52:01.560]  it's usually a couple of things.
[52:01.560 --> 52:04.080]  Not a couple, OK, let's say a dozen things.
[52:04.080 --> 52:07.400]  And then may also contain other things.
[52:07.400 --> 52:12.040]  And it's also, yeah, we can look at the chocolates, right?
[52:12.040 --> 52:17.600]  And various other additives or whatever, stuff like that.
[52:17.600 --> 52:23.920]  So even in this case, we do not get a complete and exhaustive
[52:23.920 --> 52:28.800]  list of everything or not an accurate one.
[52:28.800 --> 52:30.800]  Are we trying too much, right?
[52:30.800 --> 52:35.160]  Trying to go to the S-bomb and find everything there.
[52:35.160 --> 52:39.120]  So just looking at this, these are two pieces of chocolate.
[52:39.120 --> 52:40.080]  Other brands are available.
[52:40.080 --> 52:42.440]  Other brands are, yeah.
[52:42.440 --> 52:48.800]  So OK, one says this 42, it's all in German, probably.
[52:48.800 --> 52:51.880]  So one says 42%, one says 44%.
[52:51.880 --> 52:53.640]  But the end product is chocolate.
[52:53.640 --> 52:56.040]  Are you able to tell that difference of 2% difference?
[52:59.960 --> 53:03.040]  Because there's a set of, well, OK,
[53:03.040 --> 53:05.720]  probably by taste, maybe, if you're really good.
[53:05.720 --> 53:07.920]  But OK, is your software the same?
[53:07.920 --> 53:10.120]  Because the difference between that 2%
[53:10.120 --> 53:12.400]  might be different compile option,
[53:12.400 --> 53:14.680]  to take as an analogy.
[53:14.680 --> 53:21.120]  OK, so the question is, if in our food we are so lax,
[53:21.120 --> 53:24.760]  why do we try to do it in our software so exact
[53:24.760 --> 53:27.400]  and we're spending all this money that Bradley's
[53:27.400 --> 53:28.600]  talking about?
[53:28.600 --> 53:30.080]  Yeah.
[53:30.080 --> 53:32.680]  I have an opinion on this.
[53:32.680 --> 53:37.000]  So I'm in a big company that consumes a lot of software
[53:37.000 --> 53:38.240]  products.
[53:38.240 --> 53:43.400]  So and we'll be care that builds of materials
[53:43.400 --> 53:46.000]  exist in many cases.
[53:46.000 --> 53:49.120]  But we do not care at all what is the content.
[53:49.120 --> 53:54.720]  So those 2% difference, I agree.
[53:54.720 --> 53:56.400]  Well, when people come to me and ask,
[53:56.400 --> 53:59.520]  well, can we get that product from an open source point
[53:59.520 --> 54:03.840]  of view, I ask, well, do they have an S-bomb?
[54:03.840 --> 54:05.680]  And if they have an S-bomb, it's a sign
[54:05.680 --> 54:07.360]  that they care about.
[54:07.360 --> 54:08.840]  An S-bomb is important.
[54:08.840 --> 54:13.240]  That they have to be capable of creating S-bomb.
[54:13.240 --> 54:16.200]  And that they produce the product.
[54:16.200 --> 54:19.800]  And in many cases, fine for me, go ahead.
[54:19.800 --> 54:22.560]  I don't care what's in there.
[54:22.560 --> 54:24.240]  OK, so you want to?
[54:24.240 --> 54:26.520]  Yeah, I'll summarize that.
[54:26.520 --> 54:29.640]  Yeah, so the comment was that he doesn't care
[54:29.640 --> 54:32.240]  that what is in the software necessarily,
[54:32.240 --> 54:35.200]  but he does care that there is an S-bomb, essentially.
[54:35.200 --> 54:37.400]  And I agree with that.
[54:37.400 --> 54:40.640]  As a consumer, a lot of times I don't.
[54:40.640 --> 54:42.800]  I'm not going to read the ingredients, right?
[54:42.800 --> 54:46.520]  But knowing that the ingredients are available, right?
[54:46.520 --> 54:48.880]  And I don't know if this is a perfect analogy.
[54:48.880 --> 54:51.280]  The ingredients list comes up all the time, right?
[54:51.280 --> 54:52.520]  There's more to it than that.
[54:52.520 --> 54:55.280]  But knowing that someone has the ability
[54:55.280 --> 55:00.160]  to audit that information means that I don't necessarily have
[55:00.160 --> 55:02.440]  to be the one that does it, right?
[55:02.440 --> 55:04.880]  Just like when you go shopping, you
[55:04.880 --> 55:07.720]  can benefit from other people bargaining,
[55:07.720 --> 55:09.400]  even though you're not bargaining yourself,
[55:09.400 --> 55:11.240]  just because that does drive prices
[55:11.240 --> 55:12.720]  down in the general case, right?
[55:12.720 --> 55:15.880]  The ability, that activity on the margin
[55:15.880 --> 55:18.760]  is extremely important, right?
[55:18.760 --> 55:22.400]  So yes, I care a lot that even if I'm
[55:22.400 --> 55:24.480]  not doing the inspecting of the food
[55:24.480 --> 55:26.520]  to make sure it's not spoiled or whatever,
[55:26.520 --> 55:27.880]  that someone is, right?
[55:27.880 --> 55:28.920]  Just knowing that is good.
[55:28.920 --> 55:31.920]  Oh, I got a question.
[55:31.920 --> 55:36.000]  Well, do you know how food inspections have to be done?
[55:36.000 --> 55:38.480]  All right.
[55:38.480 --> 55:42.560]  OK, so I want to follow up to what you just said and ask you.
[55:42.560 --> 55:44.000]  If your choices work, you're saying
[55:44.000 --> 55:45.200]  you're not going to look at it, which
[55:45.200 --> 55:47.080]  means probably when the recipe is not available,
[55:47.080 --> 55:49.320]  you're not going to go try to cook the version of yourself
[55:49.320 --> 55:50.680]  to see if the recipe actually works.
[55:50.680 --> 55:52.480]  You're going to be relying on the fact that, hey,
[55:52.480 --> 55:53.560]  there's a recipe out there, and they
[55:53.560 --> 55:55.320]  say that's the recipe for this, and probably somebody
[55:55.320 --> 55:56.120]  looked at it.
[55:56.120 --> 55:57.640]  So here's a question for you.
[55:57.640 --> 56:00.360]  If you had a choice between just getting the ingredients list
[56:00.360 --> 56:03.480]  and actually getting the recipe, which would you
[56:03.480 --> 56:05.160]  rather have out there, assuming you're not
[56:05.160 --> 56:07.840]  going to really look at either of them?
[56:07.840 --> 56:12.480]  OK, well, it depends on what we mean by the recipe, right?
[56:12.480 --> 56:14.360]  I mean, is it just the list of what
[56:14.360 --> 56:16.640]  to combine in the proportion?
[56:16.640 --> 56:19.200]  That's every little tiny stuff.
[56:19.200 --> 56:22.040]  I mean, some of it, there are elements of that
[56:22.040 --> 56:25.360]  that could be related to food safety, right?
[56:25.360 --> 56:28.920]  I didn't refrigerate it or whatever.
[56:28.920 --> 56:31.760]  And yeah, I'd.
[56:31.760 --> 56:35.240]  If I give you the recipe for a salami sandwich, right?
[56:35.240 --> 56:36.720]  Do you want to have a salmon all the way
[56:36.720 --> 56:39.440]  with the back back to the actual pork?
[56:39.440 --> 56:44.160]  I'm a vegetarian, so I don't know what to do with it.
[56:44.160 --> 56:46.640]  Yeah.
[56:46.640 --> 56:48.880]  But I mean, it's an interesting thing is, you know.
[56:48.880 --> 56:50.880]  Where are the?
[56:50.880 --> 56:52.880]  Wait.
[56:52.880 --> 56:53.560]  Sorry.
[56:53.560 --> 56:57.640]  OK, it's just an interesting thing is people
[56:57.640 --> 57:01.520]  have allergies for food, and taking this scenario
[57:01.520 --> 57:02.680]  along is quite things.
[57:02.680 --> 57:04.760]  So, you know, product may contain nuts.
[57:04.760 --> 57:07.280]  People are allergic to certain types of nuts.
[57:07.280 --> 57:11.680]  So if you received an S-bomb, do you and, you know,
[57:11.680 --> 57:14.960]  would you validate that that S-bomb is suitable for you
[57:14.960 --> 57:17.800]  to use and not having an adverse infection on you,
[57:17.800 --> 57:21.120]  which might be GPL, license or something,
[57:21.120 --> 57:24.360]  maybe an adverse reaction?
[57:24.360 --> 57:26.200]  Just to take it along.
[57:26.200 --> 57:29.240]  Where's the, there seems to be quite a good analogy here
[57:29.240 --> 57:31.040]  in terms of just receiving it.
[57:31.040 --> 57:33.680]  You have to actually look at it,
[57:33.680 --> 57:37.200]  on the wife, the consequences of it, you know, basically,
[57:37.200 --> 57:39.320]  you suffer those consequences.
[57:39.320 --> 57:42.080]  OK.
[57:42.080 --> 57:44.760]  So, just a sympathetic story, I understand the argument
[57:44.760 --> 57:47.960]  of this bomb is basically a synthesis of information
[57:47.960 --> 57:50.760]  that if you have all the source code of your dependency,
[57:50.760 --> 57:53.440]  you could extract essentially from there.
[57:53.440 --> 57:55.920]  And I understand that in the use case of security,
[57:55.920 --> 57:58.400]  it's much easier to just look for a version
[57:58.400 --> 58:01.440]  and a component name in a database of bombs
[58:01.440 --> 58:04.600]  than graphing to the source code in different forms of resources.
[58:04.600 --> 58:08.120]  But if the stakes are high enough, in some cases,
[58:08.120 --> 58:10.480]  you also want to do the graphing.
[58:10.480 --> 58:13.280]  So I don't know how big companies handle the log-for-j
[58:13.280 --> 58:15.240]  or the, or the...
[58:15.240 --> 58:17.000]  How do you see the reality?
[58:17.000 --> 58:20.360]  What I'm going to assume is that fairly small company
[58:20.360 --> 58:23.240]  with not huge budget and not a lot of, you know,
[58:23.240 --> 58:26.360]  computing resources, if they add bombs at the time,
[58:26.360 --> 58:28.680]  it's a big if, just look them up.
[58:28.680 --> 58:31.520]  But I'm pretty sure that big companies and high budgets
[58:31.520 --> 58:34.920]  of computing resources also did the crap in the source code
[58:34.920 --> 58:37.560]  because they couldn't afford assuming
[58:37.560 --> 58:39.480]  that all these bombs were right.
[58:39.480 --> 58:42.360]  So what I'm saying is that with the conflicts
[58:42.360 --> 58:45.280]  we've been discussing, if you are, you know,
[58:45.280 --> 58:47.360]  it's better if you also get all the source code
[58:47.360 --> 58:49.840]  of all your components so that you have a plan B
[58:49.840 --> 58:51.440]  in case your bombs are wrong.
[58:51.440 --> 58:53.440]  I also encourage you to use the rooted source code
[58:53.440 --> 58:54.920]  and load the source code to your users,
[58:54.920 --> 58:57.040]  but that's the kind of problem.
[58:57.040 --> 58:59.360]  Yeah, no, to summarize that point,
[58:59.360 --> 59:02.640]  he's saying that if you have an S-bomb
[59:02.640 --> 59:05.920]  in a zero-day response situation, let's say, right,
[59:05.920 --> 59:09.160]  you can find log-for-j very quickly,
[59:09.160 --> 59:12.600]  but you're still going to want to go back
[59:12.600 --> 59:17.600]  and comb through everything to be extra certain, right?
[59:18.720 --> 59:20.800]  Yeah, yeah, well, you obviously, yeah, yes,
[59:20.800 --> 59:22.800]  I agree completely, you want that option.
[59:22.800 --> 59:26.440]  I think part of the reason that that's necessary today
[59:26.440 --> 59:30.720]  is that disconnect between what the scanners
[59:30.720 --> 59:33.960]  are capable of detecting and recording,
[59:33.960 --> 59:37.360]  how hard it is to have a truly bit-for-bit
[59:37.360 --> 59:38.920]  reproducible build, right?
[59:38.920 --> 59:41.160]  If we get to that universe where the builds
[59:41.160 --> 59:46.160]  are reproducible, you don't have to do it all the time,
[59:46.360 --> 59:49.680]  but if you know and you have a high confidence level
[59:49.680 --> 59:52.280]  that these builds are reproducible,
[59:52.280 --> 59:54.640]  you don't necessarily have to reproduce every one
[59:54.640 --> 59:56.480]  of them all the time, right?
[59:56.480 --> 59:59.360]  Actually, this whole thing's closed
[59:59.360 --> 01:00:01.200]  with the whole food part.
[01:00:01.200 --> 01:00:03.400]  So, because in Brazil, and I used to see,
[01:00:03.400 --> 01:00:07.960]  I saw a little documentary about a network
[01:00:07.960 --> 01:00:11.160]  of supermarkets in Orleans that actually produces
[01:00:11.160 --> 01:00:13.640]  other juice and using, okay, blockchain is not
[01:00:13.640 --> 01:00:17.000]  a matter part, but from the origin in Brazil,
[01:00:17.000 --> 01:00:20.080]  the way they pick up the fruit to go in traceability
[01:00:20.080 --> 01:00:22.360]  and do using blockchain for each part,
[01:00:22.360 --> 01:00:24.800]  then the ship, the everything until you reach
[01:00:24.800 --> 01:00:27.600]  the supermarket, and they can show the documents
[01:00:27.600 --> 01:00:30.160]  with all the traces in the steps of everything.
[01:00:30.160 --> 01:00:33.160]  Basically, they have found a way to find
[01:00:33.160 --> 01:00:34.880]  a vulnerability in the middle process
[01:00:34.880 --> 01:00:37.680]  if there's some food that's gotten or lost.
[01:00:37.680 --> 01:00:40.360]  Yeah, that's a provenance issue, right?
[01:00:40.360 --> 01:00:43.440]  Yeah, I can show this bottle of orange juice
[01:00:43.440 --> 01:00:45.480]  came from this batch of oranges.
[01:00:45.480 --> 01:00:50.480]  Those oranges came on this ship from this orchard
[01:00:50.480 --> 01:00:52.680]  and were picked at this time.
[01:00:52.680 --> 01:00:57.240]  Yeah, that is, so that is a kind of an intersection
[01:00:57.240 --> 01:01:02.240]  of signing images or signing software
[01:01:02.240 --> 01:01:05.920]  with the SBOM showing what's in that software, right?
[01:01:05.920 --> 01:01:10.760]  Yeah, yeah, yeah, yeah, to really stretch the analogy.
[01:01:10.760 --> 01:01:13.040]  Yeah, but that's, I think that's, yeah,
[01:01:13.040 --> 01:01:14.360]  you need both of those, right?
[01:01:14.360 --> 01:01:17.120]  Ultimately, you probably want both of those.
[01:01:17.120 --> 01:01:21.720]  So, there is, for those interested in reproducible
[01:01:21.720 --> 01:01:26.720]  builds or SBOM, there is a working group on the open SSF.
[01:01:29.680 --> 01:01:31.240]  Probably faster.
[01:01:31.240 --> 01:01:35.800]  There is an open working group on the open SSF.
[01:01:35.800 --> 01:01:40.120]  A bunch of people are thinking on how you can get
[01:01:40.120 --> 01:01:44.400]  a reproducible SBOM, and some of it deals with,
[01:01:44.400 --> 01:01:47.960]  I mean, not necessarily capturing all of the ingredients
[01:01:47.960 --> 01:01:51.320]  into the SBOM, but I think it's born,
[01:01:51.320 --> 01:01:54.720]  I'm not really that involved, but from what I read,
[01:01:54.720 --> 01:01:57.440]  they're trying to think if I take an SBOM
[01:01:57.440 --> 01:01:59.760]  and try to reproduce a build from only the ingredients
[01:01:59.760 --> 01:02:02.240]  listed in the SBOM, can I manage to do it?
[01:02:02.240 --> 01:02:05.760]  And they're tying it to other trust issues.
[01:02:05.760 --> 01:02:08.880]  But it's an interesting project, if anyone is interested.
[01:02:11.120 --> 01:02:12.120]  I think we probably end.
[01:02:12.120 --> 01:02:13.440]  I think we probably end.
[01:02:13.440 --> 01:02:18.440]  I think to have all the ingredients and the providence
[01:02:20.520 --> 01:02:23.240]  and things like that is going to provide a huge amount
[01:02:23.240 --> 01:02:24.920]  of information to be managed.
[01:02:25.760 --> 01:02:27.640]  And then how do you then manage it?
[01:02:27.640 --> 01:02:30.400]  And how do you find it when you need to find it?
[01:02:30.400 --> 01:02:35.160]  Because it's bad enough finding source code sometimes,
[01:02:35.160 --> 01:02:39.600]  but then having to find other artifacts and relations,
[01:02:39.600 --> 01:02:41.720]  that becomes quite hard.
[01:02:41.720 --> 01:02:42.960]  So, I'll probably put it out of there.
[01:02:42.960 --> 01:02:45.600]  For those of you who have got SBOMs and consuming them,
[01:02:45.600 --> 01:02:46.920]  how are you managing them?
[01:02:48.920 --> 01:02:51.200]  Because I believe that there's lots of things
[01:02:51.200 --> 01:02:53.360]  we're talking about producing them,
[01:02:53.360 --> 01:02:55.520]  but actually putting the relationship
[01:02:55.520 --> 01:02:59.360]  and SBOMs must be related to other artifacts, I'm sure.
[01:02:59.360 --> 01:03:01.080]  Bill of materials like hardware,
[01:03:02.600 --> 01:03:06.000]  documentation that we talked about earlier about safety.
[01:03:06.000 --> 01:03:11.000]  How are people managing those discrete artifacts together
[01:03:11.000 --> 01:03:13.800]  as a unified, consistent solution?
[01:03:15.600 --> 01:03:17.280]  Okay, a more general question.
[01:03:17.280 --> 01:03:19.880]  Is anyone consuming at both,
[01:03:19.880 --> 01:03:22.880]  or are we all talking about producing them?
[01:03:22.880 --> 01:03:23.880]  Nobody cares.
[01:03:25.200 --> 01:03:26.040]  Sorry, yeah.
[01:03:27.040 --> 01:03:27.880]  Please.
[01:03:27.880 --> 01:03:31.880]  Yeah, we produced and continued as well, for us all.
[01:03:33.560 --> 01:03:35.880]  And we've produced a lot of things,
[01:03:35.880 --> 01:03:41.240]  and we've produced a lot of different things.
[01:03:41.240 --> 01:03:43.880]  But ultimately, we can't wait about the SBOMs
[01:03:43.880 --> 01:03:45.880]  that represent the software that ends up being
[01:03:45.880 --> 01:03:47.560]  a completely different one.
[01:03:47.560 --> 01:03:51.760]  And so, the first thing we do is we help,
[01:03:51.760 --> 01:03:53.000]  we use some of the tools in the state
[01:03:53.000 --> 01:03:53.960]  that's actually in the X-ray,
[01:03:53.960 --> 01:03:55.120]  and that's what we do.
[01:03:55.120 --> 01:03:57.920]  We use them to find out if an artifact
[01:03:57.920 --> 01:04:01.920]  has that many materials with the first part of the artifact
[01:04:01.920 --> 01:04:03.240]  that we're representing.
[01:04:03.240 --> 01:04:07.760]  And then we have our mechanisms tracking,
[01:04:07.760 --> 01:04:11.280]  our releases, and then we use that same identifier.
[01:04:11.280 --> 01:04:14.320]  And when we want to look at these SBOMs,
[01:04:14.320 --> 01:04:15.800]  we're only really looking at,
[01:04:15.800 --> 01:04:19.960]  and it's one of those things that has actually been released,
[01:04:19.960 --> 01:04:21.040]  which starts with that.
[01:04:21.040 --> 01:04:24.840]  And from that, if you have very solid deployment mechanisms,
[01:04:24.840 --> 01:04:26.960]  you'll also have an understanding of where things are going.
[01:04:26.960 --> 01:04:29.320]  So, your analytic exposure to places,
[01:04:29.320 --> 01:04:31.640]  there's the estimation of the software,
[01:04:31.640 --> 01:04:34.480]  which consumes a certain number of clients.
[01:04:34.480 --> 01:04:35.920]  And that can help you filter,
[01:04:35.920 --> 01:04:39.440]  because risk is fairly contextual.
[01:04:39.440 --> 01:04:43.320]  And we're producing and consuming
[01:04:43.320 --> 01:04:44.440]  that's from a risk perspective,
[01:04:44.440 --> 01:04:47.760]  where it's legal, license compliant, and security.
[01:04:47.760 --> 01:04:50.440]  And security risks, for example,
[01:04:50.440 --> 01:04:52.480]  a lot of our use cases are turning completely to nine.
[01:04:52.480 --> 01:04:56.320]  And the place of the shell is in the East Gambas.
[01:04:56.320 --> 01:04:58.840]  We provide a lot of sources,
[01:04:58.840 --> 01:05:00.520]  and they can find hundreds of CEs.
[01:05:00.520 --> 01:05:02.640]  So, we're going to be finding a lot of things.
[01:05:02.640 --> 01:05:05.760]  But a lot of it's not very useful, not actionable.
[01:05:05.760 --> 01:05:08.960]  Or developers, especially when it's stuff we open,
[01:05:08.960 --> 01:05:11.360]  don't need to worry about fixing.
[01:05:11.360 --> 01:05:14.280]  So, it just gives us a really good data set to search,
[01:05:14.280 --> 01:05:16.320]  and use in an operational sense.
[01:05:18.240 --> 01:05:19.760]  But it requires humans.
[01:05:22.680 --> 01:05:25.080]  We just sell some opportunities at the end of the day
[01:05:25.080 --> 01:05:28.200]  about having sort of better data sources
[01:05:28.200 --> 01:05:31.760]  with more automated-scale response to threats
[01:05:31.760 --> 01:05:33.840]  and things like that.
[01:05:33.840 --> 01:05:36.320]  We have less clips and very nice proprietary
[01:05:36.320 --> 01:05:41.320]  on business-based faces that are moving
[01:05:41.320 --> 01:05:45.800]  and only use for things like the CD, CD hatching,
[01:05:45.800 --> 01:05:46.640]  and stuff like that.
[01:05:46.640 --> 01:05:49.640]  And we're hoping to find a way to do that.
[01:05:54.480 --> 01:05:55.320]  Can you summarize all that?
[01:05:55.320 --> 01:05:56.360]  I'll have to summarize all that.
[01:05:56.360 --> 01:05:58.480]  Yeah, well, okay.
[01:05:58.480 --> 01:05:59.800]  They produce, yeah.
[01:05:59.800 --> 01:06:02.920]  So, I actually want to go back to Zach's comment,
[01:06:02.920 --> 01:06:04.760]  because I have a question now,
[01:06:04.760 --> 01:06:06.040]  because Zach was pointing out,
[01:06:06.040 --> 01:06:07.240]  with some of us earlier,
[01:06:07.240 --> 01:06:10.320]  that having the S-bomb and the source code
[01:06:10.320 --> 01:06:12.240]  is really the ideal situation.
[01:06:12.240 --> 01:06:15.760]  And everybody's been saying S-bombs will help us
[01:06:15.760 --> 01:06:18.560]  with bugs and identify vulnerabilities,
[01:06:18.560 --> 01:06:20.600]  which possibly is true.
[01:06:20.600 --> 01:06:24.400]  So, if you have a log4j or any of these situations
[01:06:24.400 --> 01:06:26.720]  where you've identified in your S-bomb,
[01:06:26.720 --> 01:06:29.400]  you have a version, you have that version,
[01:06:29.400 --> 01:06:31.360]  and you have that package,
[01:06:31.360 --> 01:06:33.320]  but, of course, you don't have the source code.
[01:06:33.320 --> 01:06:36.640]  So, how does that help you solve the vulnerability
[01:06:36.640 --> 01:06:37.880]  if you have the S-bomb?
[01:06:37.880 --> 01:06:39.120]  It seems to me the only thing you can do
[01:06:39.120 --> 01:06:40.920]  is take the binary out of deployment
[01:06:40.920 --> 01:06:42.280]  if you don't have the source code.
[01:06:42.280 --> 01:06:43.560]  So, I'm curious if I'm missing something
[01:06:43.560 --> 01:06:45.400]  that the S-bombs do that allow you
[01:06:45.400 --> 01:06:49.200]  to solve the vulnerability with no source code present.
[01:06:51.160 --> 01:06:52.480]  Yeah, I'll take that.
[01:06:52.480 --> 01:06:55.200]  That does happen sometimes where there's a project
[01:06:55.200 --> 01:07:00.200]  that has been, there are binaries for an internal project,
[01:07:00.360 --> 01:07:03.800]  let's say, and nobody knows where the code is, right?
[01:07:03.800 --> 01:07:04.720]  That has happened.
[01:07:04.720 --> 01:07:06.160]  We've seen people build S-bombs,
[01:07:06.160 --> 01:07:08.440]  and yeah, that's essentially the case
[01:07:08.440 --> 01:07:10.440]  where you can get an assessment
[01:07:10.440 --> 01:07:14.680]  and say this is vulnerable to whatever.
[01:07:14.680 --> 01:07:18.080]  That may, removing the binary is an option.
[01:07:18.080 --> 01:07:19.720]  There are maybe other mitigations
[01:07:19.720 --> 01:07:20.680]  that could be put in place,
[01:07:20.680 --> 01:07:22.040]  but it is an awareness thing, right?
[01:07:22.040 --> 01:07:24.080]  I mean, that's kind of the main thing
[01:07:24.080 --> 01:07:26.800]  of S-bombs in general is a shortcut
[01:07:26.800 --> 01:07:31.280]  to omniscient awareness of every mastery
[01:07:31.280 --> 01:07:33.680]  over the contents of this thing, right?
[01:07:36.160 --> 01:07:37.360]  I think we're probably drifting a bit
[01:07:37.360 --> 01:07:39.640]  into slightly wider things.
[01:07:39.640 --> 01:07:43.040]  And S-bomb is not your single point of decision making
[01:07:43.040 --> 01:07:44.600]  for the things like vulnerability.
[01:07:44.600 --> 01:07:47.240]  You need to look at how your product is being used,
[01:07:47.240 --> 01:07:50.280]  has it been deployed, what's the environment,
[01:07:50.280 --> 01:07:52.240]  who's using it?
[01:07:52.240 --> 01:07:53.720]  If it's in a test environment,
[01:07:53.720 --> 01:07:55.160]  that's probably a slightly different environment
[01:07:55.160 --> 01:07:57.680]  to an operational deployment and an OT environment.
[01:07:57.680 --> 01:07:58.840]  So you need to look at that,
[01:07:58.840 --> 01:08:00.160]  you know, look at the context.
[01:08:01.520 --> 01:08:05.000]  And maybe S-bombs need to capture more of a context.
[01:08:05.000 --> 01:08:07.800]  And obviously, if you're creating a product,
[01:08:07.800 --> 01:08:09.880]  defining what a product is,
[01:08:09.880 --> 01:08:12.360]  it needs to also have that context around it,
[01:08:12.360 --> 01:08:15.280]  which then gives you then maybe other protections,
[01:08:15.280 --> 01:08:16.760]  physical protections as well,
[01:08:16.760 --> 01:08:18.400]  that are not captured in the S-bomb,
[01:08:18.400 --> 01:08:20.480]  that may help you make those decisions.
[01:08:27.200 --> 01:08:31.960]  I have a totally different question about the usefulness
[01:08:31.960 --> 01:08:34.160]  or what, do we need to change S-bombs
[01:08:34.160 --> 01:08:36.760]  if we look into being a co-pilot and the one?
[01:08:39.760 --> 01:08:41.520]  Do we then have a tendency
[01:08:41.520 --> 01:08:44.240]  with a 13% rightly book or something
[01:08:44.240 --> 01:08:46.960]  and need to add that to the S-bomb?
[01:08:46.960 --> 01:08:48.640]  I don't know, well...
[01:08:48.640 --> 01:08:50.600]  I'm not going to...
[01:08:50.600 --> 01:08:53.400]  I don't have any comments on co-pilot.
[01:08:53.400 --> 01:08:58.280]  OK, so the question there is,
[01:08:58.280 --> 01:09:00.240]  with the likes of things like co-pilot
[01:09:00.240 --> 01:09:02.880]  and I presume our little friend chat GPT,
[01:09:02.880 --> 01:09:06.480]  what does that really make to the world of S-bombs?
[01:09:06.480 --> 01:09:08.080]  And I would probably say...
[01:09:09.560 --> 01:09:11.200]  let's widen that a little bit more
[01:09:11.200 --> 01:09:13.480]  to basically explainable software.
[01:09:13.480 --> 01:09:16.600]  Can you explain what your software is doing?
[01:09:16.600 --> 01:09:19.480]  And I'm sure our safety people would be, you know,
[01:09:19.480 --> 01:09:21.280]  one of the things when I've been involved in safety,
[01:09:21.280 --> 01:09:23.120]  you've got to explain your architecture
[01:09:23.120 --> 01:09:25.720]  and explain why your architecture is safe
[01:09:25.720 --> 01:09:27.320]  and is fit for purpose.
[01:09:27.320 --> 01:09:29.880]  So have you got explainable software?
[01:09:29.880 --> 01:09:33.400]  And maybe an S-bomb will help that argument.
[01:09:33.400 --> 01:09:34.720]  It won't be sufficient,
[01:09:34.720 --> 01:09:37.960]  but it might help explain why your software...
[01:09:37.960 --> 01:09:40.720]  why you think your software is suitable
[01:09:40.720 --> 01:09:43.560]  because of your selection of your components,
[01:09:43.560 --> 01:09:46.680]  you've got components of known pedigree, et cetera,
[01:09:46.680 --> 01:09:48.320]  may help your argument.
[01:09:48.320 --> 01:09:51.840]  But actually, things like, yes, automated code generation,
[01:09:51.840 --> 01:09:54.240]  which we all have if you have compilers,
[01:09:54.240 --> 01:09:56.280]  because that's automatic code generation,
[01:09:56.280 --> 01:09:59.040]  and we ultimately trust them.
[01:09:59.040 --> 01:10:03.800]  So how do we put those different measures together
[01:10:03.800 --> 01:10:06.440]  and collate that and recognise that?
[01:10:06.440 --> 01:10:08.600]  Because obviously, we've also got things like,
[01:10:08.600 --> 01:10:12.000]  you know, AI, machine learning things, as well,
[01:10:12.000 --> 01:10:14.600]  capturing the data, how good is the training data,
[01:10:14.600 --> 01:10:16.240]  how good is the algorithm within that,
[01:10:16.240 --> 01:10:19.400]  and can you understand why it made that pedigree a decision?
[01:10:19.400 --> 01:10:21.640]  And I don't know whether you're going anywhere near that
[01:10:21.640 --> 01:10:23.200]  with your safety.
[01:10:23.200 --> 01:10:25.720]  But, yeah, so I think, yeah, explainable software
[01:10:25.720 --> 01:10:28.400]  is possibly a completely new topic.
[01:10:31.320 --> 01:10:33.160]  Where's the vibe? You don't want to discuss that?
[01:10:33.160 --> 01:10:34.680]  Yeah, yeah.
[01:10:34.680 --> 01:10:38.280]  In another capacity, I've written multiple blog posts
[01:10:38.280 --> 01:10:41.400]  about the GitHub co-pilot situation,
[01:10:41.400 --> 01:10:44.800]  including essay that won a prize of some sort.
[01:10:44.800 --> 01:10:46.240]  So I encourage you to read those,
[01:10:46.240 --> 01:10:48.400]  because that's sort of other issues about that,
[01:10:48.400 --> 01:10:49.800]  because there's a lot of issues there.
[01:10:49.800 --> 01:10:52.560]  I think one of the fundamental issues that you're pointing out
[01:10:52.560 --> 01:10:55.360]  is more general, and it's not specific to co-pilot.
[01:10:55.360 --> 01:10:58.720]  It's that machine learning, generally speaking,
[01:10:58.720 --> 01:11:01.520]  as a discipline, if you can call it that,
[01:11:01.520 --> 01:11:04.760]  is one of the most unreproducible processes
[01:11:04.760 --> 01:11:06.960]  that we've ever invented in computer science.
[01:11:06.960 --> 01:11:09.480]  And so the reason you can't get an S-bomb out the other side
[01:11:09.480 --> 01:11:12.160]  of a code generation system that uses machine learning
[01:11:12.160 --> 01:11:13.840]  is because you can't reproduce anything
[01:11:13.840 --> 01:11:15.240]  in the machine learning process.
[01:11:15.240 --> 01:11:16.680]  Once you train that model,
[01:11:16.680 --> 01:11:18.480]  you don't really know why it's doing,
[01:11:18.480 --> 01:11:21.240]  because at that point, it's just a table of floating point numbers.
[01:11:21.240 --> 01:11:23.280]  And so that's something that we could,
[01:11:23.280 --> 01:11:24.920]  I think maybe we could all work together on
[01:11:24.920 --> 01:11:27.720]  to be angry about machine learning systems
[01:11:27.720 --> 01:11:29.240]  and machine learning really.
[01:11:29.240 --> 01:11:32.480]  About machine learning systems and machine learning researchers
[01:11:32.480 --> 01:11:35.720]  not caring about reproducibility as an issue.
[01:11:35.720 --> 01:11:38.200]  But the fact that...
[01:11:38.200 --> 01:11:39.680]  Okay, yeah, good.
[01:11:39.680 --> 01:11:41.560]  One of the things we're doing in the next round
[01:11:41.560 --> 01:11:43.880]  of S-B-D-X-M-D-R-E-C-E,
[01:11:43.880 --> 01:11:46.280]  is sending it through the handled data sets,
[01:11:46.280 --> 01:11:49.640]  along with the computer parameters, as well as AIF.
[01:11:49.640 --> 01:11:51.840]  And we've been working with AI researchers,
[01:11:51.840 --> 01:11:53.960]  AIF groups, and so forth,
[01:11:53.960 --> 01:11:56.120]  in order to be able to capture the key information
[01:11:56.120 --> 01:11:58.040]  so we can at least start to summarize
[01:11:58.040 --> 01:12:02.640]  what these factors into the index of the software.
[01:12:02.640 --> 01:12:08.760]  So the comment was that in S-B-D-X-M-D-R-E-C-E on 3,
[01:12:08.760 --> 01:12:12.560]  we're going to have AI and data profiles,
[01:12:12.560 --> 01:12:15.240]  which tries to capture this information there.
[01:12:15.240 --> 01:12:21.720]  Why do you think that AI cannot be done in irreproducible manner?
[01:12:21.720 --> 01:12:23.880]  Now that's not done now, right?
[01:12:23.880 --> 01:12:26.560]  But if you can record everything again,
[01:12:26.560 --> 01:12:28.840]  have recipes for everything,
[01:12:28.840 --> 01:12:32.120]  do you think that AI fundamentally cannot be done in a...
[01:12:32.120 --> 01:12:33.080]  No, no, no.
[01:12:33.080 --> 01:12:36.000]  I think the decisions have been made
[01:12:36.000 --> 01:12:37.680]  for the history of machine learning,
[01:12:37.680 --> 01:12:39.880]  going back basically 25 years,
[01:12:39.880 --> 01:12:41.360]  that have led us to this point.
[01:12:41.360 --> 01:12:42.480]  And there's a lot of...
[01:12:42.480 --> 01:12:44.080]  We have to reverse engineer the entirety
[01:12:44.080 --> 01:12:46.360]  of the machine learning research history
[01:12:46.360 --> 01:12:48.920]  to get to reproducibility for machine learning, unfortunately,
[01:12:48.920 --> 01:12:52.560]  because it wasn't taken seriously as an issue early on,
[01:12:52.560 --> 01:12:56.160]  in part because of the amount of processing power required
[01:12:56.160 --> 01:12:57.080]  to reproduce, right?
[01:12:57.080 --> 01:12:58.800]  Because if you want to retrain something,
[01:12:58.800 --> 01:13:01.960]  the amount of compute time you need to retrain
[01:13:01.960 --> 01:13:04.160]  is not available to most people.
[01:13:04.160 --> 01:13:06.800]  Okay.
[01:13:06.800 --> 01:13:07.800]  Question.
[01:13:07.800 --> 01:13:09.160]  Philippe, I'm going to give you a quick question.
[01:13:09.160 --> 01:13:11.160]  I wanted to get back to the point that we consume lesbos,
[01:13:11.160 --> 01:13:13.680]  and I was surprised because I know that one person
[01:13:13.680 --> 01:13:15.920]  who doesn't consume lesbos
[01:13:15.920 --> 01:13:18.760]  who has been in Japan for so long
[01:13:18.760 --> 01:13:22.120]  has high-maintenance, we consume lesbos.
[01:13:22.120 --> 01:13:26.400]  The way we treat lesbos is as a lossy proxy
[01:13:26.400 --> 01:13:29.120]  or software data.
[01:13:29.120 --> 01:13:32.960]  And therefore, they're treated the exact same way
[01:13:32.960 --> 01:13:37.120]  you would have a package manifest in the process.
[01:13:37.120 --> 01:13:42.400]  And I think it's a very correct way to process that.
[01:13:42.400 --> 01:13:43.760]  There may be correct or incorrect,
[01:13:43.760 --> 01:13:45.520]  but there are no correct or incorrect
[01:13:45.520 --> 01:13:48.400]  than the Narcan package database,
[01:13:48.400 --> 01:13:53.680]  the YPL set-up file, or S.
[01:13:53.680 --> 01:13:56.040]  The comment was, sorry, oh.
[01:13:56.040 --> 01:13:59.120]  Yeah, I wanted to just kind of add to what he's saying.
[01:13:59.120 --> 01:13:59.760]  Yeah.
[01:13:59.760 --> 01:14:00.520]  But I'll summarize it.
[01:14:00.520 --> 01:14:03.160]  Yes, so he's saying that he was surprised
[01:14:03.160 --> 01:14:05.800]  by the number of people, I think it was just one person that
[01:14:05.800 --> 01:14:08.440]  said they're actually consuming lesbos today.
[01:14:08.440 --> 01:14:09.840]  Yeah.
[01:14:09.840 --> 01:14:13.800]  And that he is in the project he maintains.
[01:14:13.800 --> 01:14:20.280]  I think that you're just ahead of the curve, probably.
[01:14:20.280 --> 01:14:22.320]  Most people, their adoption today,
[01:14:22.320 --> 01:14:25.360]  if you talk to people who are doing anything with S-bombs
[01:14:25.360 --> 01:14:29.440]  today, their adoption curve looks like produce S-bomb,
[01:14:29.440 --> 01:14:33.240]  then maybe consume S-bomb, and then maybe in the future,
[01:14:33.240 --> 01:14:36.440]  I will incorporate the S-bombs that I'm consuming
[01:14:36.440 --> 01:14:38.720]  into the product that I'm building or whatever, right?
[01:14:38.720 --> 01:14:41.760]  Whereas in the future, let's say a year from now,
[01:14:41.760 --> 01:14:43.080]  that may be a little bit reversed
[01:14:43.080 --> 01:14:44.720]  where people start consuming S-bombs
[01:14:44.720 --> 01:14:46.360]  before they create their own S-bombs.
[01:14:46.360 --> 01:14:49.040]  But today, there's not enough people,
[01:14:49.040 --> 01:14:54.680]  there are no suppliers producing S-bombs to be consumed, right?
[01:14:54.680 --> 01:14:57.360]  That's a chicken and egg problem there.
[01:14:57.360 --> 01:14:59.000]  I mean, that's what I'm seeing, at least.
[01:15:03.800 --> 01:15:06.120]  So, Philippe, I should have raised my hand halfway
[01:15:06.120 --> 01:15:08.800]  to that question, because I've consumed S-bombs two
[01:15:08.800 --> 01:15:11.240]  to three times in my life in the cases
[01:15:11.240 --> 01:15:14.360]  where under the copy left licenses, like the GPL,
[01:15:14.360 --> 01:15:16.920]  we asked for the complete corresponding source code,
[01:15:16.920 --> 01:15:19.000]  and in response to that request, they instead
[01:15:19.000 --> 01:15:21.040]  produced an S-bomb, which is in fact not
[01:15:21.040 --> 01:15:22.640]  the complete corresponding source code.
[01:15:22.640 --> 01:15:25.680]  So I consumed it long enough to tell them this is not source
[01:15:25.680 --> 01:15:28.000]  code, and they insisted, by the way,
[01:15:28.000 --> 01:15:30.520]  that a major compliance industrial complex vendor
[01:15:30.520 --> 01:15:32.520]  had told them that that's what they were
[01:15:32.520 --> 01:15:35.120]  supposed to give us if we ever asked for the source code.
[01:15:35.120 --> 01:15:36.120]  Yeah.
[01:15:36.120 --> 01:15:36.620]  Good.
[01:15:36.620 --> 01:15:37.120]  Yeah.
[01:15:37.120 --> 01:15:38.680]  I just want to respond to that.
[01:15:38.680 --> 01:15:40.160]  Just real quick.
[01:15:40.160 --> 01:15:41.480]  But that's OK.
[01:15:41.480 --> 01:15:45.520]  I agree that's unacceptable, but that's not an S-bomb.
[01:15:45.520 --> 01:15:47.400]  That's not a problem with S-bombs inherently.
[01:15:47.400 --> 01:15:51.400]  That's a problem with lawyers giving the wrong information
[01:15:51.400 --> 01:15:54.640]  or people misunderstanding what the lawyer told them.
[01:15:54.640 --> 01:15:55.560]  Or abating the licenses.
[01:15:55.560 --> 01:15:57.240]  Or maliciousness.
[01:15:57.240 --> 01:15:58.920]  Yeah, it absolutely could be maliciousness.
[01:15:58.920 --> 01:16:01.040]  Delay, stone wall, right.
[01:16:01.040 --> 01:16:02.040]  Yeah, yeah, yeah, yeah, yeah.
[01:16:02.040 --> 01:16:03.160]  I was mean when you were talking about that.
[01:16:03.160 --> 01:16:04.160]  No, no, no.
[01:16:04.160 --> 01:16:05.600]  I just wanted to make a, yeah, yeah, yeah.
[01:16:05.600 --> 01:16:07.280]  It just wasn't explicitly stated,
[01:16:07.280 --> 01:16:09.800]  so I just wanted to kind of identify the issue.
[01:16:09.800 --> 01:16:10.300]  That's OK.
[01:16:10.300 --> 01:16:11.600]  Yeah, yeah.
[01:16:11.600 --> 01:16:14.400]  For the record, I think no one here
[01:16:14.400 --> 01:16:16.480]  assumes that S-bombs are replaced with S-bombs.
[01:16:16.480 --> 01:16:16.980]  Yeah.
[01:16:20.520 --> 01:16:22.040]  We have to finish up pretty soon.
[01:16:22.040 --> 01:16:22.540]  Yeah.
[01:16:22.540 --> 01:16:25.040]  I just want to comment on the losing of points.
[01:16:25.040 --> 01:16:28.520]  I don't know if you need to go internally.
[01:16:28.520 --> 01:16:29.520]  I'm going to consume it.
[01:16:29.520 --> 01:16:33.680]  So there's a way of indicating the means of balancing
[01:16:33.680 --> 01:16:39.200]  between the developers of trying to control this kind of thing.
[01:16:39.200 --> 01:16:41.400]  It's great, so I'll repeat that.
[01:16:41.400 --> 01:16:43.920]  OK, so I think what you're saying is, and you're orange,
[01:16:43.920 --> 01:16:44.680]  I think.
[01:16:44.680 --> 01:16:48.240]  Yeah, so you are producing and consuming
[01:16:48.240 --> 01:16:51.800]  internally generated S-bombs.
[01:16:51.800 --> 01:16:57.080]  So our last question is, I wonder if you discovered.
[01:16:57.080 --> 01:17:00.440]  So as you are consuming, are you consuming the S-bombs?
[01:17:00.440 --> 01:17:04.840]  What are you doing to help make decisions on your design?
[01:17:04.840 --> 01:17:07.560]  Are you saying, oh, there's a license missing,
[01:17:07.560 --> 01:17:09.880]  or, oh, I shouldn't be using that version.
[01:17:09.880 --> 01:17:13.440]  In terms of license missing, we find plenty of weird license
[01:17:13.440 --> 01:17:14.920]  and some surprises.
[01:17:14.920 --> 01:17:18.200]  All the time, there's some surprising licenses
[01:17:18.200 --> 01:17:19.320]  in the long run.
[01:17:19.320 --> 01:17:21.400]  No, there's a resource, a virtual resource,
[01:17:21.400 --> 01:17:24.320]  of both kinds of licenses.
[01:17:24.320 --> 01:17:27.640]  And has that resulted in a change to your design,
[01:17:27.640 --> 01:17:28.600]  or have you just?
[01:17:28.600 --> 01:17:31.680]  Well, now and then we have to change libraries.
[01:17:31.680 --> 01:17:34.720]  The users only have the need for commercial license.
[01:17:34.720 --> 01:17:35.320]  OK.
[01:17:35.320 --> 01:17:37.320]  Oh, yeah.
[01:17:37.320 --> 01:17:37.820]  OK.
[01:17:37.820 --> 01:17:39.080]  Well, that's good, I think.
[01:17:39.080 --> 01:17:40.880]  I have the published source code, but actually,
[01:17:40.880 --> 01:17:42.720]  it's not really talking.
[01:17:42.720 --> 01:17:44.400]  So that's probably quite an interesting, you know,
[01:17:44.400 --> 01:17:49.640]  licensing is probably quite an interesting use case
[01:17:49.640 --> 01:17:51.480]  for people to understand.
[01:17:51.480 --> 01:17:53.960]  And I think we've had quite a lot about licensing today,
[01:17:53.960 --> 01:17:56.600]  which is really good.
[01:17:56.600 --> 01:17:58.200]  I think there are plenty more.
[01:17:58.200 --> 01:18:00.440]  I think we can, you know, I think that's what I think
[01:18:00.440 --> 01:18:04.880]  there's plenty more to develop over the next month's years.
[01:18:04.880 --> 01:18:10.000]  As we mature, and I think actually, I think if people
[01:18:10.000 --> 01:18:13.360]  start producing S-bombs, you're going to reveal a lot more.
[01:18:13.360 --> 01:18:15.680]  Then, you know, there's a lot of unknowns,
[01:18:15.680 --> 01:18:18.320]  I believe, in software.
[01:18:18.320 --> 01:18:21.800]  And I think are people starting to ask questions
[01:18:21.800 --> 01:18:23.200]  of their suppliers, and you know,
[01:18:23.200 --> 01:18:25.520]  I'm probably looking at the large organizations
[01:18:25.520 --> 01:18:26.520]  that are in this room.
[01:18:26.520 --> 01:18:28.240]  Have you put things on your contracts
[01:18:28.240 --> 01:18:31.520]  that are now asking your people to provide S-bombs
[01:18:31.520 --> 01:18:34.560]  with your delivery, as well as a delivery note,
[01:18:34.560 --> 01:18:36.400]  and a release note?
[01:18:36.400 --> 01:18:39.600]  Are people starting to do that and ask them, you know,
[01:18:39.600 --> 01:18:42.000]  and probably to keep Bradley happy?
[01:18:42.000 --> 01:18:44.520]  And also, are they also basically providing their compliance
[01:18:44.520 --> 01:18:47.680]  against the list of compliance against licenses?
[01:18:47.680 --> 01:18:51.000]  Because if people start providing that as a starting point,
[01:18:51.000 --> 01:18:53.120]  that's going to help your risk assessment
[01:18:53.120 --> 01:18:54.920]  when you take soft into a solution
[01:18:54.920 --> 01:18:57.000]  and then start adding value to it.
[01:18:57.000 --> 01:18:59.680]  That should be basically a real game changer
[01:18:59.680 --> 01:19:04.680]  for businesses, as well.
[01:19:29.800 --> 01:19:34.080]  Yeah, he's saying that he's unable to force any vendor
[01:19:34.080 --> 01:19:36.480]  or supplier in general to supply an S-bomb,
[01:19:36.480 --> 01:19:38.920]  which I think is a big problem in general, right?
[01:19:38.920 --> 01:19:42.840]  I mean, A, your vendor may be 10,000 times bigger than,
[01:19:42.840 --> 01:19:44.960]  well, not in your case, maybe not.
[01:19:44.960 --> 01:19:47.640]  But for a lot of smaller operators, right,
[01:19:47.640 --> 01:19:50.240]  they don't have the leverage over the vendor, right?
[01:19:50.240 --> 01:19:54.040]  Or in the case of your consuming open source software,
[01:19:54.040 --> 01:19:57.120]  like, they have no obligation to you at all, right?
[01:19:57.120 --> 01:20:01.200]  They, I mean, we've seen, like, I totally agree,
[01:20:01.200 --> 01:20:04.880]  like, open source maintainers are already put upon enough,
[01:20:04.880 --> 01:20:05.720]  right?
[01:20:05.720 --> 01:20:07.280]  There's nobody that should put a gun to their head
[01:20:07.280 --> 01:20:10.560]  and say, you have to produce an S-bomb for me to consume.
[01:20:10.560 --> 01:20:13.000]  That's where the tooling has to get better, right?
[01:20:14.160 --> 01:20:16.880]  Companies like GitHub could even, you know,
[01:20:16.880 --> 01:20:19.800]  advance this a lot by making it much easier
[01:20:19.800 --> 01:20:22.240]  for project maintainers to have those produced
[01:20:22.240 --> 01:20:23.760]  on a regular basis, right?
[01:20:23.760 --> 01:20:27.560]  I, yeah, in my work in license compliance
[01:20:27.560 --> 01:20:30.640]  and enforcement, the number of bad actors
[01:20:30.640 --> 01:20:32.680]  in your vendor space is much higher
[01:20:32.680 --> 01:20:34.240]  than you probably realize.
[01:20:34.240 --> 01:20:37.120]  And it's often not the vendor being bigger than you.
[01:20:37.120 --> 01:20:38.800]  It's actually these small vendors who are,
[01:20:38.800 --> 01:20:41.240]  there's only a couple, there's kind of a cartel,
[01:20:41.240 --> 01:20:42.680]  particularly I'm thinking of chipset, you know,
[01:20:42.680 --> 01:20:45.120]  chipset for embedded devices vendors.
[01:20:45.120 --> 01:20:48.400]  There is a major chipset that I'm sure there's probably
[01:20:48.400 --> 01:20:51.200]  at least 30 devices in this room that use that chipset.
[01:20:51.200 --> 01:20:54.240]  The vendor requires you to agree
[01:20:54.240 --> 01:20:57.200]  before they will ship you even a demo board.
[01:20:57.200 --> 01:20:59.520]  You promise I will never ask
[01:20:59.520 --> 01:21:02.080]  for the complete corresponding source code under the GPL
[01:21:02.080 --> 01:21:04.920]  and that's the only way I'm gonna send you a demo board.
[01:21:04.920 --> 01:21:06.320]  That if you become my customer,
[01:21:06.320 --> 01:21:07.920]  you're never allowed to ask me for the source code.
[01:21:07.920 --> 01:21:10.720]  Now this is a GPL violation, but it's very hard to catch
[01:21:10.720 --> 01:21:13.360]  because everybody who signs this agreement says,
[01:21:13.360 --> 01:21:15.920]  I don't ever wanna tell anybody I signed that agreement
[01:21:15.920 --> 01:21:19.280]  because they'll never sell me a board again.
[01:21:19.280 --> 01:21:22.840]  And so this optimism that we're gonna get vendors
[01:21:22.840 --> 01:21:24.960]  to give us S-bombs, where vendors are getting people
[01:21:24.960 --> 01:21:26.800]  to sign those kinds of agreements.
[01:21:26.800 --> 01:21:28.800]  The idea that you're gonna get them in an agreement
[01:21:28.800 --> 01:21:31.680]  to agree to give you an S-bomb, I think is probably
[01:21:31.680 --> 01:21:34.280]  a pipe dream in the current industrial environment
[01:21:34.280 --> 01:21:36.120]  around embedded chipset vendors at least.
[01:21:36.120 --> 01:21:37.160]  I don't know about other industries,
[01:21:37.160 --> 01:21:38.320]  but in the embedded chipset vendors,
[01:21:38.320 --> 01:21:39.360]  I think that's the case.
[01:21:39.360 --> 01:21:40.200]  It's not that.
[01:21:40.200 --> 01:21:44.200]  It's the wrong way, you don't have any embedded products.
[01:21:44.200 --> 01:21:49.200]  I mean, we know popular companies that use their chipsets
[01:21:50.480 --> 01:21:52.280]  if the driver's not off-streaming.
[01:21:52.280 --> 01:21:53.120]  Right.
[01:21:53.120 --> 01:21:53.960]  Yeah.
[01:21:53.960 --> 01:21:55.760]  And this makes it easier for us.
[01:21:55.760 --> 01:21:57.080]  It's not easy.
[01:21:57.080 --> 01:21:57.920]  Yeah, yeah, yeah.
[01:21:57.920 --> 01:21:59.360]  Well, thank you for doing that.
[01:21:59.360 --> 01:22:00.200]  Yeah.
[01:22:01.520 --> 01:22:05.160]  So we're out of time.
[01:22:05.160 --> 01:22:07.680]  Many thanks to the wonderful panel and all the audience.
[01:22:07.680 --> 01:22:09.680]  Thank you, all the audience.
[01:22:09.680 --> 01:22:12.520]  Thank you.
[01:22:12.520 --> 01:22:14.240]  Thank you, Alexios, for organizing.
[01:22:14.240 --> 01:22:15.080]  Yeah, yeah.
[01:22:15.080 --> 01:22:15.920]  Sure, don't wait.
[01:22:15.920 --> 01:22:16.760]  Come on.
[01:22:16.760 --> 01:22:17.600]  Come on.
[01:22:17.600 --> 01:22:18.920]  Come on.
[01:22:18.920 --> 01:22:22.320]  So we have one last session, which is an open Q&A
[01:22:22.320 --> 01:22:26.720]  on everything S-bomb for whoever is interested
[01:22:26.720 --> 01:22:45.720]  and is still alive and awake.