So, this session is panel discussion by four or three people and the basic idea that we're
going to be discussing is the whole idea of S-bombs, right? The usefulness, cover of using
them and all these wonderful things. Though the rest of the day everybody was talking
about S-bombs as like something, you know, that has to be there and we all know what
information has to be there. But maybe this is not so obvious to anyone and the whole
idea is to discuss the idea of S-bombs, right? So, we have for the moment three panelists
and the format will be that they will be doing a very short, short introduction of, I don't
know, the problem statement if you want, right? And then we'll, after these three short interactions,
we'll go into more discussions and we obviously will value audience participation. So, first
of all, thank you for your time. Okay, afternoon. My name's Anthony Harrison. I used to work
for a very large system integrator. So, the work on safe functional safety was very close
at heart. Certainly, they got things like the Siemens team as well, very similar to
the sort of things I used to involve in for many years. I retired a few weeks, a few months
ago. But before I left, I was trying to introduce S-bombs into my organization and it was following
very much on from the log4j need, where was the components, which systems were affected,
which customers needed to be informed, and where was our liability, very much from a
risk perspective. So, since I retired, I've been writing Python tools. So, if you want
to talk about me, about some of the Python tools I've been doing, because it's been
quite interesting, have a chat with me afterwards. But to sort of set the scene, I think we've
got four types of users. And it picks up on what Adolfo was saying, Adolfo, yes, about
who's a supplier? Is a supplier a developer? Is it, I've put the word supplier in there,
but basically someone who packages things together, it might be an embedded solution,
it might be a red hat, it might be someone else. And then you've got your integrators,
which is like your Siemens, people who are selling solutions to an end user who's going
to use it. And I believe that if you are a producer of S-bombs, you also should be a
consumer of S-bombs, first and foremost, because there should be value to you in what you are
producing, and you need to know where your vulnerabilities are, whether you're compliant
with your licenses as we've had lots of discussion about, but also where the things are changing,
particularly do you know those changes, are those changing happening under your control
or not? And this comes into the ecosystems, things happening outside, your maven, repositories,
et cetera. So the first thing is, I think everybody who's a consumer, everyone who's
a generator should also be consuming. So if you've seen some of the questions of asking
this morning was when the opto guys were saying they're generating an S-bdx, S-bombs, are
they actually using it? I think the answer is most definitely yes, you should be. And
then what are the sort of things you should be using them for? We've heard a lot about
vulnerability management on the basis, but that's heavily dependent on the quality of
your S-bombs. Have you got your components uniquely identified in a way that they can
be found consistently? Secondly, looking at license management, again, are we consistent?
But thirdly, looking at the change management, are versions of packages changing, are licenses
changing, and I was telling you to Kate, on an open source project that I'm involved
in, we generate an S-bombs every week, and we do a build, and we are seeing components
changing versions, and the metadata is changing with those versions. Sometimes it's getting
worse. So why have we lost the name of the supplier or the developer? And fourthly, I
think you should be using it for solution integrity. Have you built what you said you
were going to design? So we're picking up on the design S-bombs that Nico was talking
about from the safety. I think that would be really good to actually use the S-bombs
as part of the solution integrity. Have you built what you said you were going to build?
We saw a lot of that things with the Chexons from the Yocto guys. Have we got end of life
components? Are we planning for removing those end of life components, obsolete components,
and are we seeing the impact of those changes on the solution comes back onto the engineering
life cycle? So I think all of it is supporting risk. So ultimately this is all about risk
management, and hopefully S-bombs and all these are helping you make effective decisions.
Now I'll shut up now. Just to try and shape things for discussion.
Okay, thanks. My name's Paul Noveres. I'm a solutions engineer for a company called
Bancor. We produce a couple of open source projects that A, can produce S-bombs for,
in some cases, do vulnerability checks against them so you can look up SIFT and gripe. I'm
not going to talk specifically about any particular projects here. So just to hit on the topic
of the panel, I'm going to just jump into a couple of things. Oh, well, what I do there,
I'm out in the field. So I am a solutions architect. I'm working directly with the end
users a lot of the times. So most of my contact is with people who are on the beginning of
the learning curve. They may not even know what an S-bomb is the first time I talk to
them, but they've been given marching orders. So it spans a pretty wide range. So as far
as content, the biggest thing for me is that the S-bomb, and this seems to be somewhat
of a controversial statement sometimes, but the S-bomb needs to be seen as a objective
document that only has factual information in it and does not have judgments in it.
Those things are important, but should be separated out a lot of the times. A lot of
people probably haven't been in here all day, but there have been often on comments about
should we include CVEs in an S-bomb. My opinion is probably not because those are going to
change more than the software that the S-bomb describes. Obviously, if you rebuild the piece
of software, then you would want to build a new S-bomb, but the S-bomb should be static
as long as the software it's describing is static. In the case of a Docker image, we
know when that changes because the image digest would change. We could trigger a new build,
but we shouldn't necessarily be rebuilding those S-bombs continually if there's nothing
new there. Now, that ignores things like maybe our scanner has gotten better and can detect
more things. Obviously, that might be an exception to that kind of rule. The other thing, just
as far as content goes, the first thing we mentioned today, the specs, whether it's
SPDX, Cyclone DX, are extremely loose. You can have a valid S-bomb that doesn't actually
have enough information to be useful for your particular use case. What that minimum amount
of useful information is might be different depending on the use case. There's just something
to keep in mind. The other thing that's kind of come up again and again today, the quality
of the S-bomb is going to be really dependent on the tooling. There's no way to do these
things without automation at scale. It's just too difficult to keep up with. The tooling
is improving, but it's still a long way to go, I think.
The main thing here for me is the S-bomb is useful because it's going to make all the
other aspects of supply chain security better. One, what's in the software? That's the S-bomb.
It's kind of foundational to all the other aspects. Two would be things like, is the
software safe to use? Does it have vulnerabilities? What are those vulnerabilities? What is my
license? Am I at risk for some kind of compliance issue there? Those kind of safety issues,
whether you, I don't want to use that term after seeing the operational safety discussion.
The other thing, provenance, where is this coming from? If you know what's in that software,
having that assurance of where it comes from and what's in there together is much more
powerful. Then things like reproducibility. It's really esoteric, very difficult to actually
achieve in practice, but if you have an S-bomb, a high quality S-bomb, it can be effectively
a recipe towards that. That can also help you prove some of the other things that you've
seen or we've been talking about. A lot of this is difficult though. We've seen a lot
of things about opaque artifacts and things, the difficulty of actually scanning at build
time, which may produce a higher quality S-bomb, but at a lot of cost, performance and other
things. That kind of leads us into the caveats. The main thing here is to keep in mind that
our imagined state of how we want things to be and the actual reality are basically not
the same at all. We'll try to move towards that. We're on a journey up the mountain,
whatever you want to say. If you're climbing Mount Everest, we probably haven't even gotten
to base camp yet. There's a long way to go, but the other thing, in that realm, just declaring
we have a policy to produce or store or evaluate S-bombs doesn't actually solve the problems
you're trying to solve. There's a lot more work that has to be done.
The last thing on caveats, things like log for shell, I think, pushed S-bombs into a
lot of people's awareness because S-bombs were a very effective way of finding where
log for shell was affecting software. It may have given a false sense of security just
because log for J in particular sticks out like a sore thumb. It's very easy to find.
This is like the open SSL vulnerability just a couple of months ago. I think it may have
been a reality check there. There are a lot of cases where you might have something like
open SSL in software that you're consuming without even knowing it. It's a lot easier
to hide. Just kind of a reality check, bring some people back to Earth a little bit.
Then the last thing is just in addition to producing S-bombs, one caveat is you have
to think about managing them after you produce them, storing them, being able to search them,
purge the ones you don't need anymore. That's been a topic a couple of times. We don't want
to keep more information than we really need. How do we know when it's safe or reasonable
to get rid of some of this data? Much less how are we going to search through it when
we need to find it? I think that covers it for now. I'll go ahead and pick them up over
time anyway. Thank you.
Like you, I've attended more panels than I've been on. I don't like a panel that is a series
of talks. I did hear Alexa say that I needed to make a very brief introduction. Mine will
be, I promise I'm timing here, I'll be under two and a half minutes. My favorite childhood,
I'm Bradley Kuhn. I work for an organization, a charity called the Software Freedom Conservancy.
My primary job has been related to copy left license compliance since 1997. I've seen
a lot with regard to that issue, which does interact quite frequently with the issue that
you are here to discuss today of software bills and materials. My favorite childhood
story, by the way, is the story of the emperor has no clothes, and I found throughout my
career in open source and free software that I'm often the only one willing to say that
our emperors have no clothes. I think S-bombs is a case where that needs to be said at least
to a certain extent. The most useful application at S-bombs is in cases where you are in an
organization that produces proprietary and open source software together in products.
If you are an organization that is 100% open source and free software and choose a copy
left license, your usefulness of S-bombs is extremely limited, almost to the point that
you may not even want to invest in getting involved in this kind of thing. Now I'm a
realist and realize that almost all of you probably work for organizations, including
the trade associations among you, that produce lots of proprietary software. As such, you're
going to have to worry about all these issues we've been hearing about today, many of the
tools today look very interesting to me to solve those kinds of problems. But I want
to leave you with one thought, if I can, that is imagine if there was no proprietary software
in your organization, that you didn't sell it, you didn't use it, and you didn't want
to make it. And instead, you chose to look at the requirements of the copy left licenses
like the GPL, which require you to produce the complete corresponding source code as
a reproducible build every time you produce a binary. And you have to make that available
to every customer you have. S-bombs are most often needed when you don't necessarily have
all the source code to hand, or don't know if it's going to be to hand when you get something
from another vendor. So my argument is that the level of effort that's being put in S-bombs
is primarily to enable the continued production of proprietary software. Being a FOSDM and
being a free software activist my whole career, that's generally not something that I'm that
excited about, which is why I'm not excited about S-bombs.
Okay, so we heard opening statements about uses, about general use and caveats of using
them and why they're not needed, or in an ideal world if they're not needed. Okay, let's
go back to that. Bradley, even if in an ideal world where an organization is producing free
and open source software and following license obligations, they provide all the source for
every release they're doing. Right. There might still be the use case that I want to find
out which of my releases, plus products or whatever you want to call them, contain a
vulnerable version of a library. Right.
So if you have a lot of source code, this is a great tool called grep. And what you
can do is you can search the entire source code and look if a version of something is
in there. If you have all the source code for everything, and you never separate the
source from the binary, why does grep not work? You tell me.
Because it's easier to search a table of contents than the complete book. Right. That's why
we have table of contents and indexes. Right.
Yeah. It's funny, since things have become electronic, I generally just turn the PDF
into text and grep anymore. I don't use table of contents. Really? Yeah. Okay. Okay. Okay.
So we have a source file. I used to write C. I used to be full of if defs. So how do
I, if I search the source code, I will find a line of code, but it's not telling me whether
that line of code was actually compiled into the binary, and now actually on my target
architecture, target hardware. So how do we get round that? So we've talked about having
sort of a trail of evidence from the source code to a binary so we can then sort of match
the two together. If we have different compile options, I would expect we'll get different
binaries, I hope. So therefore, how do we accommodate that?
I'd love to. And so in the world I'm imagining, which does not exist, I agree with you. This
is why you'll have to do this work, because the world that I've been working towards my
whole career doesn't exist. But if it did, and all software was under the Afaro GPL,
you would be required every time you build a binary to make sure you had a reproducible
build that can produce that binary. So when you found the vulnerability in that binary,
you would have stored the complete corresponding source release right next to all the binaries.
You take the binary that's sitting out in the field, you compare the checks on to the
binary in your repository of binaries and source code, and voila, there's your source code
release that you made at the time you built it years ago. Simple enough.
I'm going to just, I still, I mean, I get it, right? Yes, theoretically, we should be
able to reproduce everything 100%, but in practice, like, we don't do things like inspect
every jar of food that's coming off the assembly line. We only inspect some of them just for
scalability purposes. So the SBOM still has a value there in providing a shortcut so that
you don't have to do a bunch of work over and over and over again on demand every time.
It does. I mean, I get it though. You're right. In an ideal universe, that would be true when
we have unlimited time, unlimited compute resources to do all these reproducible builds.
In practice, though, even if there aren't constraints on time and compute resource, reproducible
builds are extremely limited in, you know, I mean, it takes no, no, no, no, no, but they
can, they can, they can approximate a lot of what you would get out of it. Not everything.
No, not everything, but you can approximate some things, right? So I don't, I mean, I
agree with you in principle that reproducible builds would prove a lot of things, everything,
right? That would, that would absolutely solve a lot of problems, but I don't know if everybody
is really willing to do, to live in that world.
Yeah.
My view is be the change you want to be in the world. That's why I support it. What
you feel is instead of investing in us, Tom? I think part of our disagreement here of different
views is the slide that Kate showed in the beginning, that we're not talking about an
S-bomb, though, they're different type of S-bombs, right? And they're S-bombs that apply
to the source and they're S-bombs showing what the build is or what the deploy thing
is and stuff like that, right? Now, to Bradley's point, once you have everything documented
and provided, people can recreate this information, right? So the great example that Bradley said
this is looking at the source, right? But if the obligations are, we don't only give
the source, but also the build instructions and all the scripts that the license obligations
require, right? So people can go and recreate it and then try to find out this information,
right? But so the information will be there, right? The question is how easy we want you
to have, right? Sorry, you want it? No?
What did you say? Questions?
Hmm? All right. Yeah, let's talk.
Maybe one moment. So I think I completely agree with you that it is better to take such
decisions on the sources. But what is missing to do this is that the current vulnerability
databases that we have only reference vulnerabilities in giving it names, naming components. So there
is the missing of a vulnerability is present in this file, in this function, with this
method signature and so forth. And so I do not know what you want to search for. So if
you only search for CPD blah, blah, blah, you will not be able to catch all instances
on the vulnerable code because maybe a project has been set, we named the code has been
responded and so forth. So that is, I think, lacking.
Okay, so the comment was that, for example, vulnerability information does not usually
refer to specific source files and lines on the source file, but it refers to product
names or library names or whatever. So in order to find something you have to have to
look for these, right, and not for the fine grain that we are talking about in a gripped
part, right. Yeah. Thomas.
So I know we talk a lot about security and licensing, but funny enough, how Ortt started
had nothing to do with out licensing history at all. We basically wanted, the CTO wanted
to figure out what are we doing and where can we go more efficient and where should we
invest in the language that we should be going. And by doing the whole as-bolts and having
the old stuff, we actually see what we are reducing and then we are directing these in
near organization like, okay, yeah, you guys are using Ruby, you guys are using Java.
Actually, we are all standardized in this. Actually, the company actually saved a lot
of money by this organization. So again, this is often forgotten that as-bolts can be a
great way to basically make your building software more efficient. And that alone for
that, I will build as-bolts even if my code is completely over sourced.
All right. So, repeating for the mic, sorry. The comment was that S-bombs, while we are
talking about uses in compliance and security, can also be used in a lot of other ways and
can be very useful in such a way. For example, having a software catalog of components being
used by different, you know, parts of the company. Sorry, Anton.
So, I totally agree, Thomas. I think certainly the large organizations, I think we probably
got that discussion a bit with Siemens this morning. No criticism of it. Big organizations
have a very difficult to share things. And so, if you had S-bombs of your build and then
having a way of identifying common building blocks, I won't hesitate to say the word
products, or different instances of the same product, then yes, there must be some business
opportunities to, A, save money, or B, be more efficient. So, and I don't know whether
anyone is starting to see that or starting to, I don't know whether you started seeing
that, Thomas, with your, in your own industry.
So, just look here. I now work on how to open Pinos to see how we can build an S-bombs
for them. All of their code is fully open. If you had an S-bombs, they can also see
like, oh, where are people contributing? Because we have resolved everything back to
sources. And we can actually figure out, like, okay, these are where people are contributing.
These are people using these libraries. So, we can actually do three Pinos projects
in a group. We have here people, here people. We need more job guys. Here and here are
already people who are using this particular library. So, these people in this Pinos project
can probably help those products in that Pinos project solve things. And so, it doesn't
matter the size of the machine, it's really about building software efficiently.
Yeah. Okay. So, I think what Thomas is saying is, even if things are fully open, then it's
going to help as well. I would also agree that whether proprietary software still exists.
I used to be working in the defence sector. That's never going to go open source. It uses
open source, but it's not going to use fully open source for obvious reasons. But we've
got to keep those separate. And actually, businesses need to see those separate anyway. And S-bombs
is potentially a good way of sharing them and also handling some of the things like export
control that I think one of the projects said this morning was actually handling export control
things, which is also an interesting thing that obviously some of the licenses, the
open source licenses don't have that constraint, but businesses do. And we have to recognise
that. No, I just was going to add just to that. I think that's the other thing we saw
earlier this morning with the SW 360. Identifying the components that are reused over and over
again kind of goes right in with that. Saying, okay, this component, it might only have two
people working on it, but it is used in 19 different products that our company produces.
That may, from a management perspective, when we go to devote resources, whether it's additional
headcount, whatever it is, we know that's a project that is key to everything else we're
doing, right? So, yeah, I think that does help. Again, it's something you probably could reverse
engineer by looking at, you know, who's pulling from a Git repository or whatever, but it
would be very, no, you really, yeah, it would be very difficult to look at. You'd have to
time things and, yeah, it would be hard.
And to be clear, I agree completely. Many of the tools we saw today, and generally speaking,
SBOMs are a wonderful tool to aid in the production of proprietary software and mixed proprietary
open-source software. And I think all of you who are in that business, you should probably be
working and doing more with SBOMs because you're going to need it. I agree. But I just am not
in that business. I don't want a world with proprietary software. I want a world with free
software. And in the free software world, the better place to, you have to pick where resources
go. The better place to focus resources is in reproducible builds, not SBOMs. If the amount
of funding and effort going into SBOM technology right now was going into reproducible builds
technology, I think we would get better gains. So it's a question of where limited resources are
being deployed, more than it is whether or not SBOMs are useful. I agree completely. They are.
Are they more useful than things we could be doing elsewhere with those resources?
Yeah, come on.
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.
I would like to have SBOMs and my open-source projects to make it more easy for other people to
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
framework of open-source licensing?
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.
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.
Okay? Please.
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
and say, okay, this is, you know, we know.
So, it's looking at approval of the company.
It's, without those information,
it's always the same time.
We just can't, we need to go to the discussions,
we need to see if the company
that is losing money and time.
Okay. How do I summarize that?
As booms are also useful for getting legal approval for
using software or something like that.
Yeah. Thank you very much.
Sorry. And this is probably going to be
an open question out to the,
to the audience of those who are generating S-bombs now.
Open source project time involved in is
Python-based and it supports 3.7 to 3.11.
We generate an S-bomb every week in both
Cyclone DX and SPDX for each version of Python and
each version of Python generates
a different S-bomb because you've
got different dependencies that are version-specific.
So, I have, depending on the version of Python,
I may have, I think there's about 25 direct dependencies,
but then when you get the implicit ones,
it gets another about another 30.
Some of them have got 50 odd dependencies,
some have got 60.
So, I agree with your comment about publicizing it,
but are you, are people picking up the right version?
So, they are aware of what your software is using
because your software use will change.
Oh, yes.
Yeah. Okay.
So, right.
Okay. Brilliant.
Glad you picked that up.
So, therefore, how much,
so are we capturing that information in the standards?
Yes.
Consistently?
Yes.
I'm not.
In the standard is one thing,
actually collecting it and storing it
in the actual S-bomb that you're producing.
Right. I'll just repeat that.
Right. Yeah.
The standard allows for that,
but doesn't guarantee that when you produce the S-bomb that
that information will get A collected or B recorded.
Which is, yeah, a huge problem with usually,
it's a tooling problem usually.
And we've seen tooling improve a lot,
but again, it's a journey from where we would like to be ideally,
right, to from where we are now is,
just takes time and effort, obviously.
But that's the number one problem I see in the field is
that the tooling is not producing either complete results
or consistent with other tools.
Right. I mean, we saw a ton of examples of that,
where tools are producing different results.
Yeah.
May I ask that?
Do you know why there's a wide, especially with open source
sites, is the level of education
that is applied to new developers regarding this topic
is a wide variety.
So I've been producing S-bombs and other stuff
for more than seven years.
I spoke to more lawyers and package managers
developing than I care about.
Everybody thinks that package managers get a data that is easy.
It is not.
Right. Yeah.
So to summarize that point, he's been producing S-bombs
for years, seven years.
Right.
And it's not just a matter of querying a package manager
and being done, right?
There's, I mean, we see that all the time.
I work in containerized software mostly.
So a lot of the S-bombs I see produced
are actually produced after the build,
because somebody pulls a base image.
There's no S-bomb for that base image to consume today.
Hopefully, in the future, there will be.
But those things that are in those base images,
a lot of times, are opaque.
It may be open source software, but it's a Rust binary that
doesn't have audit information compiled in.
And there have been improvements in that.
Go puts audit information into the binaries.
Rust can do it, but doesn't do it by default yet.
So there's still, yes, a ton of that.
And so the rest of his point was the developer education.
It's one thing to be aware of S-bombs as a concept.
It's another thing to be aware of the limitations, what
has to be accounted for when you're building them,
when you're producing software in general.
There's just a lot of plates spinning all at the same time.
And maybe to add to that, we have a little talk
on Friday about us.
Please do not reinvent the wheel if you need S-bombs to.
Ask the community, have all the opportunities
to drive out of there, so building them all
and wasting a lot of time and effort.
It's just too useful.
And another thing that you have to find the workshop on Friday,
teaching developers is OK, but it's not the right path.
Because developers are creatures of habits.
And they will not follow you or not listen to you,
even when the deadlines are very near.
I mean, so the last comment was that developers,
it's difficult to get developers to change their behavior
and they don't listen, which I find too in my work, which
is primarily copy left license compliance.
To your point, I wanted to add, one of the reasons
is probably very difficult for you.
It's not the only reason, but one of the reasons
is difficult to build S-bombs for containers
is because nearly all containers in the world
are violating the GPL.
And so you don't have the source code to even go
and start building your S-bombs off the source code.
You're stuck with binaries that are GPL violating.
But there is absolutely no funding available
to handle that problem in the container world
and the GPL compliant side.
So I guess you'll head on the binary side,
because you have all your S-bombs funding to fund it that way.
OK, yeah, sorry.
I'm trying to understand your point.
I understand that it would imply that if all software was
open, we wouldn't have any need to S-bombs,
besides perhaps the things that they mentioned.
Even though every talk today was stuff
that wouldn't matter if all software was open.
But I'm trying to understand what your point is.
Are you implying that instead of actually being here
at both them, pushing open source software
so that all software, at some day, being open source,
are you implying that we're wasting time producing stuff
that actually supports the current standard?
But it's completely yours.
Yeah, that's a question for me, and I'll summarize it.
So the question was, in this imaginary world
that I proposed where all software is open source
and free software, is what I'm saying
that the effort being put into S-bombs
is actually enabling the production
of proprietary software.
And I think the answer is yes.
I think S-bombs are a system to make it easier
to ingest open source software and bring it
into proprietary software.
And I came to as many of the talks
as I could today when I didn't have other obligations.
And many of the talks today were talking
about ingestion of open source for that purpose.
When you hear people talking about, oh, we
can be able to blacklist GPL stuff.
Well, the reason they want to blacklist copy left stuff
is they want to make proprietary software.
Now, it's a question of values.
The commentator over there that I think never got summarized
was pointing out that in his values,
he feels he really wants to see his software put
into proprietary software and to encourage it and make it easy.
I don't, obviously, agree with those values.
If you agree with those values, I agree completely.
S-bombs are a great solution to be
able to encourage the adoption of non-copy-lefted software.
This is a very stark issue.
I want to give an example.
There was a talk earlier you can go on the internet
and figure out which one it was.
But their system, when it decided,
when putting licenses in buckets,
when it saw that it was a copy left license,
they had a Python function that I found in their source
grid that says, oh, if it's a copy left or it's a license,
this Python function should return the string is-danger.
So the concept that even those writing S-bomb tools
believe that copy left is a dangerous thing
is kind of giving you a sense of the values that
are circulating around the S-bomb community, which
is unfortunate, because I think the GPL is a wonderful license,
not a dangerous one.
But I realize others in the room disagree.
My question was, we cannot see the other side of the coin.
So wouldn't that, I mean, I'm not trying
to reconcile free software and commercial software by any means,
but wouldn't that extra transparency
brought by the S-bomb community also help for your use case?
Can I then define when that piece of software is being used?
The answer is no.
And I don't want to get too much into it,
but I'll talk about it later, because I
don't want to take too much of the time.
All right.
Kate, sorry.
I want open source database and safety critical applications.
Open source has bugs.
How can I track the bugs and fix them
so it doesn't kill people unless I know what's there?
But just in the source code, all through,
I'm not going to be able to find and fix.
It's at scale.
We need to abstract to go to scale.
How do we change?
How do you propose it to solve that problem?
So the code, you want to start at the right time?
OK.
I think you just run the mic to Kate.
Yeah.
That's OK.
So the question is that we want to do functional safety
with open source, right?
And in order to do it on scale, we
have to abstract things outside on a higher level
than simple source code and talk, for example, in packages
and have, again, the table of contents of things
rather than the actual source files.
So I want to respond.
Off the mic, it was said there's a concern
that software is going to kill people with the implication
that without us bombs, we won't be
able to prevent the killing of people with software.
Which I agree, there is software that has killed people.
I was very taken of the Therak-25 case, which,
if you're in computer science, you probably studied,
which was a proprietary software system that murdered
a number of people due to a software bug.
So I agree completely that we have a long, long history
of software bugs injuring people.
My argument is that the best thing to have
when you have a binary, that you worry has a bug
and has a vulnerability, the best thing to have
is to have a completely reproducible build
for that binary.
Such that you can go and make that binary again tens of years
later, hundreds of years later, and see, again,
have all the scripts used to control compilation,
installation, at your fingertips for every binary produced
in the world.
I agree with you that it takes a lot of resources to do that.
I would like to get to that world where that's the case,
where every person who relies on a piece of binary software
has the immediate access to the complete corresponding source
code.
There are some tools in that case
that I think should exist that don't.
I don't see anybody in this community working on them.
For example, our mind was working years ago
on this very interesting tool that was doing orchestration
through build processes, where it was tracking
exact hashes of source code that was going into a binary.
Those kinds of things are very excellent tools
that we do need and should be created,
and they would be a great enabler to the types of things
that I'm talking about.
But I don't see S-bombs bringing us that, at least not
at the moment.
I just want to say that the S-p-d-x-s-bombs are
bringing things in the past.
And we've had this exact of a while today.
What's with the things that are not prepared, the tool that
does it?
Yachto is doing it, and Deppro is doing it.
Hashes of the sources, and what's going to be intermediate,
and how this is going in the follow-up.
OK, so Kate just told us the problem's solved.
So we don't have to do anything more.
That's great.
You use Yachto and the problem's solved, it sounds like.
OK, so the comment was that build tools, no,
build platforms like Yachto and Zephyr already record all
hashes of sources going into binaries for their platforms.
Great.
Any other questions?
Come on, people, don't be shy.
Yeah?
Yeah, I have a cool question.
So for the textbooks, is the idea, and this might be a very
basic question, is the idea that we produce an textbook that
represents the task factor or, I don't know,
or as large whatever combination of tasks?
And that includes both.
Build dependencies, transitive tasks,
common dependencies, task dependencies.
Or is the idea that you use multiple of these as a factor
and for us, we'll have you.
So that you can then operate the idea.
I have a problem with vulnerability.
I realize it's an issue in a particular thinking
where it's, let's say, if it's an open as a cell vulnerability,
my build tool, I probably don't have as much.
But if it's in the document, I'm going to have much more.
You want that?
Yeah.
You summarize it.
Yeah, I'll summarize it.
Good.
Yeah, so the question is whether or not
the SBOM is intended to capture, in addition
to the code and the dependencies,
is it also capturing the build environment, et cetera,
things like that, right?
And the answer there is maybe.
And that's kind of one of the reasons,
like I don't know if you were here all day,
but one of the first things that we covered
was different types of SBOMs.
So there are SBOMs specifically for code repositories.
There are SBOMs specifically that are generated at build time.
So yes, maybe there can be an SBOM
for the exact combination of conditions,
or there can be a more generalized SBOM.
And there's use cases for both of those.
How much are you able to get all of these?
Maybe.
Again, it depends on what you're consuming from other people.
If you're consuming a Docker image,
it may be too late to, you may be
able to reproduce it in a, well, let's not get into that.
I'll say one thing more about reproducible builds.
Even in the universe where we have all the data,
actually reproducing a build is extremely difficult,
and maybe even impossible in some cases, right?
Because there's just too many variables.
So I am not one to shy away from saying,
we should have an ideal and work towards it, right?
I mean, absolutely.
But the level of effort to achieve one goal
is not necessarily the same amount of effort
to achieve another goal.
So.
Yeah, I guess one of my questions was,
let's say I have something I think that generates as well.
I'm supposed to run multiple times throughout the pipeline,
as opposed to throughout the blocks.
Yeah.
It depends.
Yeah.
The answer is it depends.
It depends.
The answer is always it depends.
But I'm just looking at the highest one is the design one.
Now, one of the things I've heard a lot of people,
and we've talked about lists of ingredients several times
today, people nervous about putting what's in their product
because potentially people are saying, well,
if you tell me I'm using package x, y, and z,
then a competitor can also put x, y, and z together.
So are people concerned about that?
Because that's one of the things that people are saying
is delaying the adoption and the publication of that.
Or is it saying that certain S-bombs
can have that level information, but with a very restricted
audience, as I think from maybe the later down ones, which
are probably more public because they potentially
have different business needs?
That's out for that.
I'm not saying I've got a view, but let's say what do people
think about that?
Because people, I'm seeing some of the organizations
saying, I don't want to publish my architecture,
since it's an architecture, because that potentially
is making a community potentially vulnerable.
My business model being vulnerable.
And go back to the market I used to work in,
my architecture was protected under certain business needs.
And I couldn't share that.
I still can't share it.
I just want to add one thing there.
And Siemens had their talk earlier today
about having different S-bombs for different use cases.
And one of them was specifically around that.
We have a specific S-bomb for regulatory consumption
that only includes the information
that the regulator needs.
And I don't know if that's a, I actually
wanted to talk to you guys about that.
Is that produced from the other S-bombs?
We'll get into that later.
But they have the other S-bombs they only
use for internal purposes.
So even in the case of software that is not
going to be distributed at all, there's still
a very strong use case for S-bombs.
That software that stays inside of Siemens maybe
doesn't even go into a product and is only
used for, let's say, internal accounting, I don't know,
whatever.
Right, right.
So there's still a use case there
where there's not a concern about necessarily
poisoning the software or whatever, right?
So yeah, I just wanted to tie back to that,
because I wanted to A, remind myself to talk to you about it.
But I thought it tied into what he was asking too.
There's a true reality of being in big organizations,
is because at some point someone will ask it, where,
or when, or why.
This is always about the project that you're working.
And sometimes there's someone that
is going to a completely different area,
a completely different country.
But for some how, it's using the project
to do their discussions.
And then what happens is that there's
a lot of people who have meant itself
trying to find information.
If that's a thing that already happens on S-bombs,
since there, you have all the information
of the project details.
And then this question could be totally sorted out.
You're saying for just internal management audits
of resource planning, something like that, right?
Who was working on this project?
Yeah, yeah.
So all of that, yeah, that information
can be captured in an S-bomb as well, right?
Yeah, I agree with that.
Yeah, I wanted to go back to you brought up
this list of ingredients question again,
which I think is a really interesting analogy
to this whole situation.
Certainly I've eaten processed foods in my life,
and I don't cook everything from scratch.
So having a list of ingredients is certainly much better
than not having one if those are your only two choices,
if you're given that false dichotomy.
However, I'm much more interested in getting recipes,
full recipes, with all the instructions
that I am getting lists of ingredients for something.
And similarly true, I've used proprietary software in my life.
I avoid it because I don't just want a list of ingredients.
I want the whole recipe.
OK, so staying with a list of ingredients and food labels,
analogy, whenever we see a list of ingredients,
it's usually a couple of things.
Not a couple, OK, let's say a dozen things.
And then may also contain other things.
And it's also, yeah, we can look at the chocolates, right?
And various other additives or whatever, stuff like that.
So even in this case, we do not get a complete and exhaustive
list of everything or not an accurate one.
Are we trying too much, right?
Trying to go to the S-bomb and find everything there.
So just looking at this, these are two pieces of chocolate.
Other brands are available.
Other brands are, yeah.
So OK, one says this 42, it's all in German, probably.
So one says 42%, one says 44%.
But the end product is chocolate.
Are you able to tell that difference of 2% difference?
Because there's a set of, well, OK,
probably by taste, maybe, if you're really good.
But OK, is your software the same?
Because the difference between that 2%
might be different compile option,
to take as an analogy.
OK, so the question is, if in our food we are so lax,
why do we try to do it in our software so exact
and we're spending all this money that Bradley's
talking about?
Yeah.
I have an opinion on this.
So I'm in a big company that consumes a lot of software
products.
So and we'll be care that builds of materials
exist in many cases.
But we do not care at all what is the content.
So those 2% difference, I agree.
Well, when people come to me and ask,
well, can we get that product from an open source point
of view, I ask, well, do they have an S-bomb?
And if they have an S-bomb, it's a sign
that they care about.
An S-bomb is important.
That they have to be capable of creating S-bomb.
And that they produce the product.
And in many cases, fine for me, go ahead.
I don't care what's in there.
OK, so you want to?
Yeah, I'll summarize that.
Yeah, so the comment was that he doesn't care
that what is in the software necessarily,
but he does care that there is an S-bomb, essentially.
And I agree with that.
As a consumer, a lot of times I don't.
I'm not going to read the ingredients, right?
But knowing that the ingredients are available, right?
And I don't know if this is a perfect analogy.
The ingredients list comes up all the time, right?
There's more to it than that.
But knowing that someone has the ability
to audit that information means that I don't necessarily have
to be the one that does it, right?
Just like when you go shopping, you
can benefit from other people bargaining,
even though you're not bargaining yourself,
just because that does drive prices
down in the general case, right?
The ability, that activity on the margin
is extremely important, right?
So yes, I care a lot that even if I'm
not doing the inspecting of the food
to make sure it's not spoiled or whatever,
that someone is, right?
Just knowing that is good.
Oh, I got a question.
Well, do you know how food inspections have to be done?
All right.
OK, so I want to follow up to what you just said and ask you.
If your choices work, you're saying
you're not going to look at it, which
means probably when the recipe is not available,
you're not going to go try to cook the version of yourself
to see if the recipe actually works.
You're going to be relying on the fact that, hey,
there's a recipe out there, and they
say that's the recipe for this, and probably somebody
looked at it.
So here's a question for you.
If you had a choice between just getting the ingredients list
and actually getting the recipe, which would you
rather have out there, assuming you're not
going to really look at either of them?
OK, well, it depends on what we mean by the recipe, right?
I mean, is it just the list of what
to combine in the proportion?
That's every little tiny stuff.
I mean, some of it, there are elements of that
that could be related to food safety, right?
I didn't refrigerate it or whatever.
And yeah, I'd.
If I give you the recipe for a salami sandwich, right?
Do you want to have a salmon all the way
with the back back to the actual pork?
I'm a vegetarian, so I don't know what to do with it.
Yeah.
But I mean, it's an interesting thing is, you know.
Where are the?
Wait.
Sorry.
OK, it's just an interesting thing is people
have allergies for food, and taking this scenario
along is quite things.
So, you know, product may contain nuts.
People are allergic to certain types of nuts.
So if you received an S-bomb, do you and, you know,
would you validate that that S-bomb is suitable for you
to use and not having an adverse infection on you,
which might be GPL, license or something,
maybe an adverse reaction?
Just to take it along.
Where's the, there seems to be quite a good analogy here
in terms of just receiving it.
You have to actually look at it,
on the wife, the consequences of it, you know, basically,
you suffer those consequences.
OK.
So, just a sympathetic story, I understand the argument
of this bomb is basically a synthesis of information
that if you have all the source code of your dependency,
you could extract essentially from there.
And I understand that in the use case of security,
it's much easier to just look for a version
and a component name in a database of bombs
than graphing to the source code in different forms of resources.
But if the stakes are high enough, in some cases,
you also want to do the graphing.
So I don't know how big companies handle the log-for-j
or the, or the...
How do you see the reality?
What I'm going to assume is that fairly small company
with not huge budget and not a lot of, you know,
computing resources, if they add bombs at the time,
it's a big if, just look them up.
But I'm pretty sure that big companies and high budgets
of computing resources also did the crap in the source code
because they couldn't afford assuming
that all these bombs were right.
So what I'm saying is that with the conflicts
we've been discussing, if you are, you know,
it's better if you also get all the source code
of all your components so that you have a plan B
in case your bombs are wrong.
I also encourage you to use the rooted source code
and load the source code to your users,
but that's the kind of problem.
Yeah, no, to summarize that point,
he's saying that if you have an S-bomb
in a zero-day response situation, let's say, right,
you can find log-for-j very quickly,
but you're still going to want to go back
and comb through everything to be extra certain, right?
Yeah, yeah, well, you obviously, yeah, yes,
I agree completely, you want that option.
I think part of the reason that that's necessary today
is that disconnect between what the scanners
are capable of detecting and recording,
how hard it is to have a truly bit-for-bit
reproducible build, right?
If we get to that universe where the builds
are reproducible, you don't have to do it all the time,
but if you know and you have a high confidence level
that these builds are reproducible,
you don't necessarily have to reproduce every one
of them all the time, right?
Actually, this whole thing's closed
with the whole food part.
So, because in Brazil, and I used to see,
I saw a little documentary about a network
of supermarkets in Orleans that actually produces
other juice and using, okay, blockchain is not
a matter part, but from the origin in Brazil,
the way they pick up the fruit to go in traceability
and do using blockchain for each part,
then the ship, the everything until you reach
the supermarket, and they can show the documents
with all the traces in the steps of everything.
Basically, they have found a way to find
a vulnerability in the middle process
if there's some food that's gotten or lost.
Yeah, that's a provenance issue, right?
Yeah, I can show this bottle of orange juice
came from this batch of oranges.
Those oranges came on this ship from this orchard
and were picked at this time.
Yeah, that is, so that is a kind of an intersection
of signing images or signing software
with the SBOM showing what's in that software, right?
Yeah, yeah, yeah, yeah, to really stretch the analogy.
Yeah, but that's, I think that's, yeah,
you need both of those, right?
Ultimately, you probably want both of those.
So, there is, for those interested in reproducible
builds or SBOM, there is a working group on the open SSF.
Probably faster.
There is an open working group on the open SSF.
A bunch of people are thinking on how you can get
a reproducible SBOM, and some of it deals with,
I mean, not necessarily capturing all of the ingredients
into the SBOM, but I think it's born,
I'm not really that involved, but from what I read,
they're trying to think if I take an SBOM
and try to reproduce a build from only the ingredients
listed in the SBOM, can I manage to do it?
And they're tying it to other trust issues.
But it's an interesting project, if anyone is interested.
I think we probably end.
I think to have all the ingredients and the providence
and things like that is going to provide a huge amount
of information to be managed.
And then how do you then manage it?
And how do you find it when you need to find it?
Because it's bad enough finding source code sometimes,
but then having to find other artifacts and relations,
that becomes quite hard.
So, I'll probably put it out of there.
For those of you who have got SBOMs and consuming them,
how are you managing them?
Because I believe that there's lots of things
we're talking about producing them,
but actually putting the relationship
and SBOMs must be related to other artifacts, I'm sure.
Bill of materials like hardware,
documentation that we talked about earlier about safety.
How are people managing those discrete artifacts together
as a unified, consistent solution?
Okay, a more general question.
Is anyone consuming at both,
or are we all talking about producing them?
Nobody cares.
Sorry, yeah.
Please.
Yeah, we produced and continued as well, for us all.
And we've produced a lot of things,
and we've produced a lot of different things.
But ultimately, we can't wait about the SBOMs
that represent the software that ends up being
a completely different one.
And so, the first thing we do is we help,
we use some of the tools in the state
that's actually in the X-ray,
and that's what we do.
We use them to find out if an artifact
has that many materials with the first part of the artifact
that we're representing.
And then we have our mechanisms tracking,
our releases, and then we use that same identifier.
And when we want to look at these SBOMs,
we're only really looking at,
and it's one of those things that has actually been released,
which starts with that.
And from that, if you have very solid deployment mechanisms,
you'll also have an understanding of where things are going.
So, your analytic exposure to places,
there's the estimation of the software,
which consumes a certain number of clients.
And that can help you filter,
because risk is fairly contextual.
And we're producing and consuming
that's from a risk perspective,
where it's legal, license compliant, and security.
And security risks, for example,
a lot of our use cases are turning completely to nine.
And the place of the shell is in the East Gambas.
We provide a lot of sources,
and they can find hundreds of CEs.
So, we're going to be finding a lot of things.
But a lot of it's not very useful, not actionable.
Or developers, especially when it's stuff we open,
don't need to worry about fixing.
So, it just gives us a really good data set to search,
and use in an operational sense.
But it requires humans.
We just sell some opportunities at the end of the day
about having sort of better data sources
with more automated-scale response to threats
and things like that.
We have less clips and very nice proprietary
on business-based faces that are moving
and only use for things like the CD, CD hatching,
and stuff like that.
And we're hoping to find a way to do that.
Can you summarize all that?
I'll have to summarize all that.
Yeah, well, okay.
They produce, yeah.
So, I actually want to go back to Zach's comment,
because I have a question now,
because Zach was pointing out,
with some of us earlier,
that having the S-bomb and the source code
is really the ideal situation.
And everybody's been saying S-bombs will help us
with bugs and identify vulnerabilities,
which possibly is true.
So, if you have a log4j or any of these situations
where you've identified in your S-bomb,
you have a version, you have that version,
and you have that package,
but, of course, you don't have the source code.
So, how does that help you solve the vulnerability
if you have the S-bomb?
It seems to me the only thing you can do
is take the binary out of deployment
if you don't have the source code.
So, I'm curious if I'm missing something
that the S-bombs do that allow you
to solve the vulnerability with no source code present.
Yeah, I'll take that.
That does happen sometimes where there's a project
that has been, there are binaries for an internal project,
let's say, and nobody knows where the code is, right?
That has happened.
We've seen people build S-bombs,
and yeah, that's essentially the case
where you can get an assessment
and say this is vulnerable to whatever.
That may, removing the binary is an option.
There are maybe other mitigations
that could be put in place,
but it is an awareness thing, right?
I mean, that's kind of the main thing
of S-bombs in general is a shortcut
to omniscient awareness of every mastery
over the contents of this thing, right?
I think we're probably drifting a bit
into slightly wider things.
And S-bomb is not your single point of decision making
for the things like vulnerability.
You need to look at how your product is being used,
has it been deployed, what's the environment,
who's using it?
If it's in a test environment,
that's probably a slightly different environment
to an operational deployment and an OT environment.
So you need to look at that,
you know, look at the context.
And maybe S-bombs need to capture more of a context.
And obviously, if you're creating a product,
defining what a product is,
it needs to also have that context around it,
which then gives you then maybe other protections,
physical protections as well,
that are not captured in the S-bomb,
that may help you make those decisions.
I have a totally different question about the usefulness
or what, do we need to change S-bombs
if we look into being a co-pilot and the one?
Do we then have a tendency
with a 13% rightly book or something
and need to add that to the S-bomb?
I don't know, well...
I'm not going to...
I don't have any comments on co-pilot.
OK, so the question there is,
with the likes of things like co-pilot
and I presume our little friend chat GPT,
what does that really make to the world of S-bombs?
And I would probably say...
let's widen that a little bit more
to basically explainable software.
Can you explain what your software is doing?
And I'm sure our safety people would be, you know,
one of the things when I've been involved in safety,
you've got to explain your architecture
and explain why your architecture is safe
and is fit for purpose.
So have you got explainable software?
And maybe an S-bomb will help that argument.
It won't be sufficient,
but it might help explain why your software...
why you think your software is suitable
because of your selection of your components,
you've got components of known pedigree, et cetera,
may help your argument.
But actually, things like, yes, automated code generation,
which we all have if you have compilers,
because that's automatic code generation,
and we ultimately trust them.
So how do we put those different measures together
and collate that and recognise that?
Because obviously, we've also got things like,
you know, AI, machine learning things, as well,
capturing the data, how good is the training data,
how good is the algorithm within that,
and can you understand why it made that pedigree a decision?
And I don't know whether you're going anywhere near that
with your safety.
But, yeah, so I think, yeah, explainable software
is possibly a completely new topic.
Where's the vibe? You don't want to discuss that?
Yeah, yeah.
In another capacity, I've written multiple blog posts
about the GitHub co-pilot situation,
including essay that won a prize of some sort.
So I encourage you to read those,
because that's sort of other issues about that,
because there's a lot of issues there.
I think one of the fundamental issues that you're pointing out
is more general, and it's not specific to co-pilot.
It's that machine learning, generally speaking,
as a discipline, if you can call it that,
is one of the most unreproducible processes
that we've ever invented in computer science.
And so the reason you can't get an S-bomb out the other side
of a code generation system that uses machine learning
is because you can't reproduce anything
in the machine learning process.
Once you train that model,
you don't really know why it's doing,
because at that point, it's just a table of floating point numbers.
And so that's something that we could,
I think maybe we could all work together on
to be angry about machine learning systems
and machine learning really.
About machine learning systems and machine learning researchers
not caring about reproducibility as an issue.
But the fact that...
Okay, yeah, good.
One of the things we're doing in the next round
of S-B-D-X-M-D-R-E-C-E,
is sending it through the handled data sets,
along with the computer parameters, as well as AIF.
And we've been working with AI researchers,
AIF groups, and so forth,
in order to be able to capture the key information
so we can at least start to summarize
what these factors into the index of the software.
So the comment was that in S-B-D-X-M-D-R-E-C-E on 3,
we're going to have AI and data profiles,
which tries to capture this information there.
Why do you think that AI cannot be done in irreproducible manner?
Now that's not done now, right?
But if you can record everything again,
have recipes for everything,
do you think that AI fundamentally cannot be done in a...
No, no, no.
I think the decisions have been made
for the history of machine learning,
going back basically 25 years,
that have led us to this point.
And there's a lot of...
We have to reverse engineer the entirety
of the machine learning research history
to get to reproducibility for machine learning, unfortunately,
because it wasn't taken seriously as an issue early on,
in part because of the amount of processing power required
to reproduce, right?
Because if you want to retrain something,
the amount of compute time you need to retrain
is not available to most people.
Okay.
Question.
Philippe, I'm going to give you a quick question.
I wanted to get back to the point that we consume lesbos,
and I was surprised because I know that one person
who doesn't consume lesbos
who has been in Japan for so long
has high-maintenance, we consume lesbos.
The way we treat lesbos is as a lossy proxy
or software data.
And therefore, they're treated the exact same way
you would have a package manifest in the process.
And I think it's a very correct way to process that.
There may be correct or incorrect,
but there are no correct or incorrect
than the Narcan package database,
the YPL set-up file, or S.
The comment was, sorry, oh.
Yeah, I wanted to just kind of add to what he's saying.
Yeah.
But I'll summarize it.
Yes, so he's saying that he was surprised
by the number of people, I think it was just one person that
said they're actually consuming lesbos today.
Yeah.
And that he is in the project he maintains.
I think that you're just ahead of the curve, probably.
Most people, their adoption today,
if you talk to people who are doing anything with S-bombs
today, their adoption curve looks like produce S-bomb,
then maybe consume S-bomb, and then maybe in the future,
I will incorporate the S-bombs that I'm consuming
into the product that I'm building or whatever, right?
Whereas in the future, let's say a year from now,
that may be a little bit reversed
where people start consuming S-bombs
before they create their own S-bombs.
But today, there's not enough people,
there are no suppliers producing S-bombs to be consumed, right?
That's a chicken and egg problem there.
I mean, that's what I'm seeing, at least.
So, Philippe, I should have raised my hand halfway
to that question, because I've consumed S-bombs two
to three times in my life in the cases
where under the copy left licenses, like the GPL,
we asked for the complete corresponding source code,
and in response to that request, they instead
produced an S-bomb, which is in fact not
the complete corresponding source code.
So I consumed it long enough to tell them this is not source
code, and they insisted, by the way,
that a major compliance industrial complex vendor
had told them that that's what they were
supposed to give us if we ever asked for the source code.
Yeah.
Good.
Yeah.
I just want to respond to that.
Just real quick.
But that's OK.
I agree that's unacceptable, but that's not an S-bomb.
That's not a problem with S-bombs inherently.
That's a problem with lawyers giving the wrong information
or people misunderstanding what the lawyer told them.
Or abating the licenses.
Or maliciousness.
Yeah, it absolutely could be maliciousness.
Delay, stone wall, right.
Yeah, yeah, yeah, yeah, yeah.
I was mean when you were talking about that.
No, no, no.
I just wanted to make a, yeah, yeah, yeah.
It just wasn't explicitly stated,
so I just wanted to kind of identify the issue.
That's OK.
Yeah, yeah.
For the record, I think no one here
assumes that S-bombs are replaced with S-bombs.
Yeah.
We have to finish up pretty soon.
Yeah.
I just want to comment on the losing of points.
I don't know if you need to go internally.
I'm going to consume it.
So there's a way of indicating the means of balancing
between the developers of trying to control this kind of thing.
It's great, so I'll repeat that.
OK, so I think what you're saying is, and you're orange,
I think.
Yeah, so you are producing and consuming
internally generated S-bombs.
So our last question is, I wonder if you discovered.
So as you are consuming, are you consuming the S-bombs?
What are you doing to help make decisions on your design?
Are you saying, oh, there's a license missing,
or, oh, I shouldn't be using that version.
In terms of license missing, we find plenty of weird license
and some surprises.
All the time, there's some surprising licenses
in the long run.
No, there's a resource, a virtual resource,
of both kinds of licenses.
And has that resulted in a change to your design,
or have you just?
Well, now and then we have to change libraries.
The users only have the need for commercial license.
OK.
Oh, yeah.
OK.
Well, that's good, I think.
I have the published source code, but actually,
it's not really talking.
So that's probably quite an interesting, you know,
licensing is probably quite an interesting use case
for people to understand.
And I think we've had quite a lot about licensing today,
which is really good.
I think there are plenty more.
I think we can, you know, I think that's what I think
there's plenty more to develop over the next month's years.
As we mature, and I think actually, I think if people
start producing S-bombs, you're going to reveal a lot more.
Then, you know, there's a lot of unknowns,
I believe, in software.
And I think are people starting to ask questions
of their suppliers, and you know,
I'm probably looking at the large organizations
that are in this room.
Have you put things on your contracts
that are now asking your people to provide S-bombs
with your delivery, as well as a delivery note,
and a release note?
Are people starting to do that and ask them, you know,
and probably to keep Bradley happy?
And also, are they also basically providing their compliance
against the list of compliance against licenses?
Because if people start providing that as a starting point,
that's going to help your risk assessment
when you take soft into a solution
and then start adding value to it.
That should be basically a real game changer
for businesses, as well.
Yeah, he's saying that he's unable to force any vendor
or supplier in general to supply an S-bomb,
which I think is a big problem in general, right?
I mean, A, your vendor may be 10,000 times bigger than,
well, not in your case, maybe not.
But for a lot of smaller operators, right,
they don't have the leverage over the vendor, right?
Or in the case of your consuming open source software,
like, they have no obligation to you at all, right?
They, I mean, we've seen, like, I totally agree,
like, open source maintainers are already put upon enough,
right?
There's nobody that should put a gun to their head
and say, you have to produce an S-bomb for me to consume.
That's where the tooling has to get better, right?
Companies like GitHub could even, you know,
advance this a lot by making it much easier
for project maintainers to have those produced
on a regular basis, right?
I, yeah, in my work in license compliance
and enforcement, the number of bad actors
in your vendor space is much higher
than you probably realize.
And it's often not the vendor being bigger than you.
It's actually these small vendors who are,
there's only a couple, there's kind of a cartel,
particularly I'm thinking of chipset, you know,
chipset for embedded devices vendors.
There is a major chipset that I'm sure there's probably
at least 30 devices in this room that use that chipset.
The vendor requires you to agree
before they will ship you even a demo board.
You promise I will never ask
for the complete corresponding source code under the GPL
and that's the only way I'm gonna send you a demo board.
That if you become my customer,
you're never allowed to ask me for the source code.
Now this is a GPL violation, but it's very hard to catch
because everybody who signs this agreement says,
I don't ever wanna tell anybody I signed that agreement
because they'll never sell me a board again.
And so this optimism that we're gonna get vendors
to give us S-bombs, where vendors are getting people
to sign those kinds of agreements.
The idea that you're gonna get them in an agreement
to agree to give you an S-bomb, I think is probably
a pipe dream in the current industrial environment
around embedded chipset vendors at least.
I don't know about other industries,
but in the embedded chipset vendors,
I think that's the case.
It's not that.
It's the wrong way, you don't have any embedded products.
I mean, we know popular companies that use their chipsets
if the driver's not off-streaming.
Right.
Yeah.
And this makes it easier for us.
It's not easy.
Yeah, yeah, yeah.
Well, thank you for doing that.
Yeah.
So we're out of time.
Many thanks to the wonderful panel and all the audience.
Thank you, all the audience.
Thank you.
Thank you, Alexios, for organizing.
Yeah, yeah.
Sure, don't wait.
Come on.
So we have one last session, which is an open Q&A
on everything S-bomb for whoever is interested
and is still alive and awake.