So, this session is a panel discussion by four or three people, and the basic idea

that we're going to be discussing is the whole idea of these bombs, right? Their usefulness, caveats of using them, and all these wonderful things. The rest of the day, everybody was talking about these bombs as something 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 these bombs, right? So we have, for the moment, three panelists, and the format will be that they will be

doing a very short introduction of, I don't know, the problem statement if you want, right? And then we'll, after these three short introductions, we'll go into more discussions, and we obviously would value audience participation.

So first up. Okay, afternoon.

My name's Anthony Harrison. I used to work for a very large system integrator, so the work on functional safety was very close at heart. Certainly things like the Siemens team as well, very similar to the sort of things I used to be involved in for many years. I retired a few months ago, but before I left, I was trying to introduce S-bombs

into my organisation, and it was following very much on from the log for J, 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've 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, 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 are things 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, you may even be positive, etc. 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 I'm asking this morning was, when the opto guys were saying they're generating an SBDX S-bomb, 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 it 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 it 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 to Kate on an open

source project I'm involved in, we generate an S-bomb 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're going to design, so we're picking up on the design S-bomb that Nico was talking about from 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 excellence 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 into the engineering life cycle. So I think all of it is supporting risk, so ultimately this is all about risk

management, and hopefully S-bomb and all these are helping you make the effective decisions. Now I'll shut up now, just to try and shape things for discussion.

Okay thanks, my name's Paul Moverice, I'm a solutions engineer for a company called Ankor, 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 S-bomb, 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

talked to them, but they've been given marching orders, so you know 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 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 this 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. So 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. And what that minimum amount of useful information is might be different depending on the use case. So 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 still a long way to go, I think.

Usefulness. 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. So 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, you know, am I at risk for some kind of compliance issue there? Those kind of safety issues, whether you, you know, I don't want to use that term after seeing the operational safety discussion. The other thing, provenance, you know, where is this coming from?

If you know what's in that software, having that assurance of where it comes from and what's it in there together is a much more powerful. And 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. And that can also help you prove some of the other things that you've seen or we've been talking about, right? A lot of this is difficult, though, you know, we've seen a lot of things about opaque artifacts and things, you know, the difficulty of actually

scanning at build time, which may produce a higher quality S-bomb, but at a lot of costs, right, performance and other things. So that kind of leads us into the caveats. I mean, 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. You know, we'll try to move towards that, right? We're on a journey up the mountain, whatever you want to say. We're probably, like if you're climbing Mount Everest, we probably haven't even gotten to base camp yet, right? So there's a long way to go. But the other thing, like in that realm, like 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. And the last thing on caveats, things like Log4Shell, I think, gave,

it pushed S-bombs into a lot of people's awareness because it was, S-bombs were a very effective way of finding where Log4Shell was affecting software. It may have given kind of a false sense of security just because Log4J in particular like sticks out like a sore thumb. It's

very easy to find. Things like the OpenSSL vulnerability just a couple of months ago, I think, may have been a reality check there. There are a lot of cases where you might have something like OpenSSL in software that you're consuming without even knowing it, right? It's a lot easier to hide. So just kind of a reality check, bring some people

back to Earth a little bit. And 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, right? Storing them, being able to search them, purge the ones you don't need anymore. That's been a topic a couple of times like we don't want to keep

more information than we really need, right? So 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. So I think that covers it for now. I'll go ahead and I think I'm up over time anyway. Thank you.

Like you, I've attended more panels than I've been on, and I don't like a panel that is a series of talks. And I did hear Alexo say that I needed to make a very brief introduction. So 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. I've been, my primary job has been related to copyleft license compliance since 1997. And so 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 SBOMBS is a case where that needs to be said, at least to a certain extent. The most useful application of SBOMBS 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 copyleft license, your usefulness of SBOMBS 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 looked 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 copyleft 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. SBOMBS 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 into SBOMBS is primarily to enable the continued production of proprietary software. Being at FOSDEM 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 SBOMBS.

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. Broadly, 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, slash 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, there's this 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? Since things have become electronic, I generally just search the, turn the PDF to text in grep anymore. I don't use table of contents. Really? Okay. Okay, okay. So we have a source file.

I used to write C. It used to be full of ifdefs. 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 around 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? Just to keep the argument going. I'd love to. And so in the world I'm imagining, which does not exist, I agree with you. This is why you 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 Affero GPL,

you would be required every time you build a binary to make sure you had a reproducible build that could produce that binary. So when you found a 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

checksum to the binary in your repository of binaries and source code, and voila, there's source code release that you made at the time you built it years ago. Simple enough. Yeah, I'm gonna 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, you know, 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 a little bit. 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. My view is be the change you want to be in the world. That's why I support you, instead of investing in us. Yeah, 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 there are different types of S-bombs, right? And there are S-bombs that apply to the source, and there are 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 all 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 it to have, right? Sorry, you want it? No? No? We can? Alright.

Ok, 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're talking about in a grip part, right? Yeah. Thomas? Can you give me a licensing?

It's funny enough, how Org started had nothing to do with our license at all. We basically wanted, the CPO wanted to have a method, what open source, what software are we using in general? What are open source, what proprietary, so we as a whole organization can see, even if all

open source was completely other AGL, what are we doing and where can we go more efficient and where should we invest in the development should be done? And by doing all S-bombs and having all the stuff, we actually saw what we were using, and then we actually directed the new 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 just organizing. So again, this is often forgotten that S-bombs can be a great way to basically make your building software more efficient. And that alone for that I will build S-bombs, even if my code is completely open source. Alright, so

repeating for the mic, sorry, the comment was that S-bombs while we're 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

parts of the company, sorry. 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 you. Big organizations have a very difficult to share

things. And so if you had S-bombs of your build and then started having a way of identifying common building blocks, I 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 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.

Ok 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 work in the defense 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 an 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 recognize 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 S-W 360 right

identifying the components that are reused over and over again kind of goes right in with that right saying ok 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 you know from a management perspective when we go to devote resources whether

it's additional head count whatever it is right we know that's a project that we you know 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 get repository or whatever but it would be very no you really

yeah it would be very difficult to look at you you'd have to time things and yeah it would be hard. To be clear I agree completely many of the tools we saw today and generally speaking S-BOMBS 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 S-BOMBS 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 S-BOMBS if the amount of funding and effort going into S-BOMBS 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 S-BOMBS are useful I agree completely they are

are they more useful than things we could be doing elsewhere with those resources

this is I use software because I like it and because I like other people using it this is what I'm going to do and having a good overview about the type of components that you use is also a well a good way to tell

other people what kind of open source components I am using I'm sorry but I I agree for everything and tell everybody if you want to know something I want to provide

good information for all the people who would like to use S-BOMBS okay so the point here was that even when producing open source license software you find S-BOMBS useful for

telling people what your software uses or to for documenting your software essentially okay please

we do have this information already here completely

set up in the system and says okay this is we know so we can approve this without this information it's always the same time we need to go to discussions we need to see if the company is losing money and time okay how do I summarize that

S-BOMBS are also useful for getting legal approval for using software or something like that yeah thank you, sorry and this is probably going to be an open question now to the audience of those who are generating S-BOMBS now

open source project that I'm involved in is Python based and it supports 3.7 to 3.11 we generate an S-BOMBS every week in both Cyclone DX and SPDX for each version of Python and each version of Python generates a different S-BOMBS

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 I'm not using it but 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 right okay brilliant, glad you picked that up so therefore are we capturing that information in the standards consistently yes I'm not

in the standard is one thing actually collecting it and storing it in the actual S-BOMBS that you are producing just to repeat that the standard allows for that but doesn't guarantee that when you produce the S-BOMBS 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 the 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 yet

is the level of education by the tooling developers regarding this topic is so I've been producing S-BOMBS for more than seven years I've spoken to more lawyers and package managers than I care about

everybody thinks that package managers and data is easy it is not right yeah so to summarize that point he's been producing S-BOMBS for seven years right and it's not just a matter of querying a package manager and being done right 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-BOMBS 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 you know 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 please do not reinvent the wheel if you need time and effort

this is the best point not Friday teaching developers is okay but it's not the right path developers are creatures of habit and they will not follow you even when the deadlines are very near I mean 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 it's probably very difficult for you it's not the only reason but one of the reasons it's 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 on the GPL compliant side I guess you'll handle the binary side because you have all your S-BOMBS

funding to fund it that way okay, yeah, sorry I'm trying to understand your point I understand that you 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 and using 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? Completely yours I think that's a question for me and I'll summarize it so the question was like, 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 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 we can be able to blacklist GPL stuff well the reason they want to blacklist copyleft stuff is they want to make proprietary software now it's a question of values the commenter 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-copylefted 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 copyleft license they had a Python function that I found in their source code that says oh if it's a copyleft license this Python function should return this string is-danger

so the concept that even those writing S-BOMBS tools believe that copyleft is a dangerous thing is kind of giving you a sense of the values that are circulating around the S-BOMBS 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

the answer is no

and I don't want to get too much into it but I'm going to talk about it later because I don't want to take too much of the time unless I know what's there

I'm just in the store room 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 we how do we what you're proposing to solve that problem so the you want to okay I think it's just random that's okay so the question is that

we want to do functional safety with open source 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 Therac 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 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 it 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

so Kate just told us the problem solved so we don't have to do anything more it's great use Yocto and the problem solved it sounds like

Ok, so the comment was that build tools no, build platforms like Yocto 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

yes, so the question is

whether or not the S-bomb is intended to capture in addition to the code and the dependencies is it also capturing the build environment, etc. 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 S-bombs, right? so there are S-bombs specifically for code repositories right? there are S-bombs specifically that are generated at build time right? so yes maybe there can be an S-bomb for the exact combination of conditions or there can be a more generalized S-bomb

right? and there's use cases for both of those how much, you know are you able to get all of these? maybe, right? again, it depends on what you're consuming from other people, right? if you're consuming a Docker image right? it may be too late to you know, you may be able to reproduce it

in a, you know, 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 yeah 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 list 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 of information but with a very restricted audience

as I think from the 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 because let's say what do people think about that? because I'm seeing some organizations saying I don't want

to publish my architecture essentially it's an architecture because that potentially is making it 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

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, 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

you're saying for like just internal management audits of resource planning something like that right who was working on this project yeah so all of that that information can be

captured in an S-bomb as well I agree with that 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 I certainly have 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 okay so staying with a list of ingredients and food labels analogy whenever we see a list of ingredients it's usually you know

couple of things not couple okay let's say a dozen things and then may also contain other things and it's also oh we can look at the chocolates and you know various other additives or whatever stuff like that right so even in this case we do not get a

complete and you know 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 yeah these are two pieces of chocolate other brands are available

other brands are available so okay one says there's 42 it's all in what language it's in German probably so one says 42% one says 44% but at the end product is chocolate are you able to tell that difference a 2% difference because

there's a set of okay probably bad taste maybe if you're really good but okay is your software the same because that's the difference between that 2% might be different compile option to take as an analogy okay 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 is talking about tools of materials exist

in many cases but we do not care at all what's the content so those 2% difference it has come to me in my square 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 are capable of creating an S-bomb and that they produce a chip of the product and in many cases fine for me go ahead I don't care what's in there

okay so 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 but knowing that the ingredients are available and I don't know I don't know if this is a perfect analogy the ingredients list comes up all the time there's more to it than that knowing that someone has the ability to audit that information means that I don't necessarily have to be the one that does it

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 that activity on the margin is extremely important 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 just knowing that is good I want to follow up to what you said

and ask you if your choices work because 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 it depends on what we mean by the recipe right, I mean is it just the list of what to combine in the proportion every little tiny step I mean some of it, there are

elements of that that could be related to food safety I didn't refrigerate it or whatever and yeah I give you the recipe for a salami salami sandwich right, you want to have an economic whole way river back to the actual pork is that for drastic

I'm a vegetarian so I yeah yeah but I mean it's an interesting thing you know 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 effect which might be GPL license or something

maybe an adverse reaction just to take it along there seems to be quite a good analogy here in terms of just receiving it you have to actually look at it otherwise the consequences of it you know basically you suffer those consequences

you also want to do the graph so I don't know how big companies handle the Lockerjay or the what I'm going to assume is that fairly small company

with not huge budget not a lot of you know if they had s-bombs at the time the big if just looked at them but I'm pretty sure that big companies in high budget also did the graph in the system because they couldn't afford assuming that all the s-bombs were right so what I'm saying is that

the conflicts we've been discussing 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 s-bombs are wrong I also encourage you to use the root source code and load the source code to your users to summarize that point he's saying that

if you have an s-bomb in a zero-day response situation let's say you can find Lockerjay very quickly but you're still going to want to go back and comb through everything to be extra certain right yeah well you obviously

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 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 actually the whole thing

the whole food part, because in Brazil I used to see, I saw a little documentary about a network of supermarkets in Holland that actually produces all the juice and using, okay, blockchain is not a matter part, but from the origin in Brazil, the way they pick up the fruit to traceability until using blockchain for each part, then they

shift everything until you reach the supermarket and they can show the documents with all the traces and the steps and everything. Basically, they have found a way to find a vulnerability in the middle of the process if some food has gotten 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, so that is kind of an intersection of signing images or signing software

with the SBOM showing what's in that software, right? Yeah, yeah, yeah. To really stretch the analogy, yeah, but I think that's, yeah, you need both of those, right? Ultimately, you probably want both of those. There is an open working group on the OpenSSF, 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 the bill 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, you know, to have all the ingredients and the provenance 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. Billing 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 a SBOM or are we all talking about producing it?

Nobody cares.

Your analytics approach places the destination of the software, which consumers are going to require. And that can help you filter because risk is very contextual.

And we're producing and consuming SBOMs from a risk perspective, whether it's legal, license compliance, and security. And security risks, for example, a lot of these cases are turned into economic. And, you know, based on these cameras, we can find a lot of sources, and they can find hundreds of CD's that are really finding a lot of things.

But a lot of it's not very useful, not actionable for developers, especially when it's stuff that goes and you 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.

So, you know, we just discussed some opportunities at the end of every Friday about having sort of better data sources and more automated scale to respond to threats and things like that. You know, we're blessed with some very nice proprietary databases that are...

Can you summarize all that? I'll have to summarize all that. Yeah, well, okay.

I actually want to go back to Zach's comment, because I have a question now, because Zach was pointing out with someone earlier that having the SBOM and the source code is really the ideal situation. And everybody's been saying SBOMs will help us with bugs and identify vulnerabilities, which possibly is true.

So if you have a log for J or any of these situations where you've identified in your SBOM, 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 SBOM? 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 SBOMs 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. That has happened. We've seen people build SBOMs, and yeah, that's essentially the case, where you can get an assessment and say this is vulnerable to whatever. Removing the binary is an option. There are maybe other mitigations that could be put in place,

but it is an awareness thing. That's kind of the main thing of SBOMs in general, is a shortcut to omniscient awareness of mastery over the contents of this thing. I think we're probably drifting a bit into slightly wider things. An SBOM 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 in an OT environment. You need to look at that, look at the context.

Maybe SBOMs need to capture more of a context. 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 SBOM that may help you make those decisions.

Do we need to change SBOMs if we look into a co-pilot? Do we then have a tendency with a 13% likelihood or something and need to add that to the SBOM?

I don't know. I don't have any comments on co-pilot. Okay, 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 SBOMs? I would probably say let's widen that a little bit more to basically explainable software. Can you explain what your software is doing? 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 SBOM 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 co-generation, which we all have, if you have compilers, because that's automatic co-generation, and we ultimately trust them.

So how do we put those different measures together and collate that and recognize 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 particular decision?

And I don't know whether you're going anywhere near that with your safety. So I think, yes, explainable software is possibly a completely new topic. That's why you don't want to discuss that. In another capacity, I've written multiple blog posts about the GitHub copilot situation,

including an 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 copilot. 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 co-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 I think maybe we can all work together on, to be angry about machine learning systems and machine learning researchers not caring about reproducibility as an issue. So the comment was that in SPDX version 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 a reproducible manner?

Not that it's not done now, but if you can record everything again, and have recipes for everything, do you think that AI fundamentally cannot be done? No, not at all. 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.

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.

Question. Philippe, I'm with you.

Okay. And therefore, they're treated the exact same way processed and handled. I think it's a very correct way to process that.

They may be correct or incorrect, but there are no more correct or incorrect than the Narcan database, the IPI setup file, or S. I wanted to just kind of add to what he's saying, but I'll summarize it.

So he's saying that he was surprised by the number of people, I think it was just one person that said they were actually consuming S-bombs today, 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 reverse 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 Felipe, 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 copyleft 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.

Okay, I agree that's unacceptable, but 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 maliciousness, yeah, it absolutely could be maliciousness. Delay, stone wall, right, yeah, yeah, yeah, yeah.

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. For the record, I think no one here assumes that these bombs are replaced.

We have to finish up pretty soon. Yeah, that's great.

Okay, so I think what you're saying is, you're orange, I think? Yeah, so you are producing and consuming internally generated S-bombs. So what I'll ask the question is, and what have you discovered? Right, 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? We can confirm that the license missing, we find plenty of weird licenses and some surprises all the time. Some surprising licenses, and no, we're losing control.

Not much of a control for both kind 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 to use, or they have a need for commercial license. Okay. Oh, yeah. Okay, well that's good, I think. I have the published source code of patches and things.

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 months, years, as we mature. And I think actually, I think S-bombs, if people start producing S-bombs, you're going to reveal a lot more than you, 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 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 are they also basically providing their compliance against the, a list of compliance against licenses, because if people start providing that as a starting point, that's going to help your risk assessment when it takes off 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 you,

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, 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? 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 going to send you a demo board. 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 want to tell anybody I signed that agreement because they'll never sell me a board again. And so this optimism that we're going to get vendors to give us S-bombs,

where vendors are getting people to sign those kinds of agreements, the idea that you're going to 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 easy.

You don't have any embedded products. I mean the chipset, if the drivers are off-screen, this makes it far easier, but it's not easy. Well, thank you for doing that.

So we're out of time. Many thanks to the wonderful panel and all the audience. Thank you, Alexios, for organizing. Yeah, sure. So we have one last session,

which is an open Q&A on everything as bombed for whoever is interested and still alive.