 But I think a lot of this goes back to earlier on, Kate was saying that we want to base this more on facts, and that's an opinion. And so part of software being developed is to go through multiple levels of transformations, whether it's running source code to binaries, taking binaries, packaging them into a container, into a virtual machine, and so on. There's a lot of processes that go on in the creation of software. And the more accurately we can represent these processes and document them, the more factual information we have to then evaluate the ecosystem and to kind of evaluate the claims that we have. So the build profile goes around a couple of use cases. The first is security. We know about vulnerabilities. Rose and Dorff will talk a little bit about that. But we are in an age where we also have supply chain compromises, build system gets compromised, a build tool, and start spitting out bad output. In those cases, we do also have to figure out, when something like that happens, how do we go about remediating it? I know we have folks from the reproducible builds here as well. And that's also part of ensuring a good build is, one is that we can understand the provenance of a build, but at the same time, if we are able to reproduce the build and multiple people can independently verify them against each other, then we get that guarantees as well. And so a lot of this is also kind of borrowing and lending from a lot of the supply chain and build provenance side of things. So we took a lot of inspiration from Salsa. We took a lot of inspiration for reproducible builds when we started creating this. Also, auditing the quality in particular of the build. So this goes in a case where initially, when we're giving an S-Bong, we say, here are the components of a particular piece of software. Now, I'm saying that this contains Carol's compression library, but then the question is, how do I know that this contains Carol's compression library? And in this case, if we had the build information propagated with provenance, we can say that, yeah, this is how I figured out the information and that kind of assurance and certainty of my claim then becomes stronger. And last but not least is in the area of safety, where we are dealing with human lives and critical infrastructure. We need to be able to reason about what goes into the software and having that level of granularity is very important. So I'm going to pass to Anisha to talk about a few examples. OK. So we have a couple of examples that we worked on. One of them is the hosted build paradigm. So for example, GitHub Actions. So if you were a software developer developing like a Python application, you may be able to use a GitHub Action to generate a wheel and publish it to PyPy. I'll see if I can use the clicker. So if you think about the case of GitHub Actions doing a build, the instance of that build is what the build element is made of and that is the primary class that we're using in the build profile. This information that's in the build element, you should be able to generate that from the build stage that you're using. So GitHub Actions already generates all of this information. And so when you are making a build profile, you should be able to encode all of this information. So this is things like the build ID, start time, end time, the parameters that went into your build, what configuration you use. So typically for GitHub Actions, you would have a dot GitHub and workflow for a build that happens on GitHub Action. So you can use that URL over there. You can figure out what commit that build was done on. And so you can encode that information in here. And then you can also point to any log files that you find. Now that's not enough for us to glean what exactly happened in the build, because things we want to know is what file was used to configure the build. And we want to know who configured the build. And all of those connections, we use the SPDX relationships. So we've added a bunch of SPDX relationships to the core model to encode those kind of relationships between the actors in the build, what the source code is that went into the build, and what parameters went into the build with the build tool. So you have a number of things in here that define, for example, all of the pink stuff are all packages that are representing the build tool that was used to invoke the build. The green one on the top is used to represent what the host was on which the build was invoked. So what VM you're using or what container you're using. You have the teal ones, and the orange one, which is the build configuration. So this is like any of the YAML files or setup.py that you would use to define what you're going to build. And then there are some purple things over there which is using the core's identity. And that is used to identify who or what triggered the build. So the second example we tried to use is something like a build system that you would host. You would either host or you would install on your own machine and invoke the build. So it's almost like the self-hosted environment or the on-prem environment that an organization may set up to do their builds. So in this case, you would still be using a build element. But there are also more introspection that you can do. So for example, the build that gets triggered by an event may spin up some parallel builds. And so we introduced the concept called a nested build. And so what you can do is if you wanted to introspect your build some more, you could define that, OK, if I do make, for example, that will trigger a compilation of source code or setup of build scripts or downloading of build scripts and each one of those can be a separate build stage. So in the nested example, you'll have each one of those build stages as build elements. And each of them will be able to encode the build element parameters. So this is the top level build that you would define. And there will be a nested build that happens that gets triggered after this. And you can have a relationship called build child of that points to the build that triggered of the secondary build. Yeah, I think one of the things that I think where we kept in mind when building this, a lot of the discussion was around how to implement this. And I think the idea is if you look at GitHub Actions, if you look at things like CircleCI, Tecton Build, and everything, it's like kind of different levels of granularity. And there's a little bit of mismatch between sometimes of what the build system can instrument and what is required. And so I think, as Nisha went through the examples of all of this, what we're showing is that you can actually incrementally build this. So as a build system, you can say, OK, I have this as a build. At some point, I can say, I have a few more nested builds, but I don't know any information about that. And so I can be like, no assertion. And as a build system is able to have better instrumentation, they can then start building up the capabilities. Yeah, and so this is why we encoded those additional information as relationships. Because there are situations where you can introspect some of the build, but you can't introspect all of it unless you do more investigation. And so once you get more information about what your build looks like, then you can add on to the existing S-bomb that you'd create. So this looks like the same thing, right? So this is just a final slide just to show what you've seen, but this is actually just the elements of the build model. So I think the main things to show off is just making a distinction. I know we've kind of picked this already into relationships just a few weeks out of date. But basically, defining inputs, outputs, we built around the model around who, when, where, where, why, type of questions of the build. And so if you're creating a build system, and this is like the intention of the build profile is mainly for builders or build tools, these are kind of things that you have to keep in mind, right? I think it's the questions of like, what goes into the inputs, outputs, the actors that are defined in that, and being able to then decompose this into nested builds. Yeah, I think Nisha, in her examples, gave a good overview on how that would be implemented. I think that's all we have for the build profile. Okay, thank you. Do you have an example of how that's represented in an SBOM? We don't have a serialized version of this yet. Actually, right now we're trying to figure out how to incorporate the relationships because that's where this profile shines because you want those relationships. So right now we have the relationships in the core model which we need to discuss how we can put some constraints around it, meaning like if you're using the build profile then you have to use these mandatory relationships. But as far as serialization goes, I don't, we don't have an example of it right now, but we're working on it. No, you hit that. I was more interested in the relationships and how those would be represented in an, even a sample existing as SBOM, which isn't an idea of what it looks like. So in SBDX 3.0, relationship is a core element. And so what you would do is just create an element that has the from part, which is represented by the IDs, the from part, the to part, and then the relationship type. And the relationship type is what all these are, the build input of, build child of. So once you, once you figure out, okay, that's what my build graph looks like, you can create an SBOM with the build profile in it. So I think just to illustrate a little bit, right? There's, I think this thing, if you didn't have the build profile, I think what it looked like is you had an input which is like the build, basically the build input file, and then you would have the package as output. So in your tradition, however you want to call it, but like in a build material today, that just describes the content, you would say like this package is using the generated, or this file generates this, right? And so what the build profile is, is kind of like an overlay upon those elements to show you're like, okay, this is how the source is made. Thank you. I have one question. These informations are barely useful for understanding when we build some packages, but recently these informations are getting more complex and complex. So from my understanding, SPDX and S-bombs are for securities and license compliance. So my question is, do you have any vision or idea how detailed information should be treated and created in the feeling in the S-bomb? So the thing about SPDX is, you represent what you need. If you need to go down to the level and the detailed level for something like a safety use case, you can, but you don't need to. You only can represent what you have available to you, but if you wanna go back and refine it further and put a lot more information about your builds, there's a way to do it. It's very scalable. That's the whole idea here. I think each profile has a mandatory field. So when we would like to use some certain profile, we needed to implement the mandatory field. In fact, that's a great, oh, I can talk through the microphone. That's a great lead in for what we're gonna talk about next, which is the migration from SPDX 2.3 to 3.0 and profiles and relationships both are topics for that. So. We've got a last question here. Oh, go ahead. Hi. I've read something about Omri board that seems to be, do a graph of everything that was done in the builder. Does it connect to this? Do you plan on? Yeah, so in, we currently have the ability, is this on? Yeah, it's on. We currently have the ability to encode like GitArts, which is what OmniBall uses as hashes. The idea is that, with that relationship within that, you will be able to kind of overlay this information to kind of describe, take that OmniBall back and then be able to translate it to like, this was how it was built. This is a composition of it. And through those relationships and those hashes to be able to kind of directly map the inputs out, was Mark earlier. And. So the beauty of OmniBall is that, all of the information comes out from the build system. A lot of the times when we are building a software, we don't actually know what the interactions are. Like, we don't really see anything that's statically compiled. We just guess based on the, okay, we gave this thing, these kind of C flags. So I'm going to guess that that's what happened, but we don't really know if it actually happens. So it's more like, yes, you can use this to encode whatever information you know, or you need to know, or whatever you need to encode. But with OmniBall, it becomes more accurate. Right. So my idea is you can like, encode the whole OmniBall report into a build profile. Yeah. Or parts of it, because we still have external references. So you can just encode the top part of it and point to an OmniBall graph.