 Welcome to the SPDX OSS EU mini summit. My name is Rose Judge. I am the chair of the SPDX steering committee. I work in the security group and I run the implementers call and participate in the tech call. So we have a great presentation for you. We're gonna start with a general SPDX 3.0 update. So I'm sure you've heard lots of this mysterious SPDX. We're gonna get into some of the details of what that means. We're gonna do a walkthrough of the profiles that are new in SPDX 3.0. Nicole and Kate are gonna give us a presentation on the safety profile, which is upcoming in 3.1. Some of the applications, the use cases around that. Kate's also gonna give us an overview of the hardware profile, which is upcoming in 3.1. Gary's gonna give us an overview of the services profile, which is also upcoming. And then Shane is gonna give us a walkthrough of the open chain security standard that is new. We're gonna take a 15 minute break after that. We're gonna walk through the new SPDX website preview. Then we're gonna turn it back to Gary for, or to Max, excuse me, for the SPDX tools update and then Gary for the SPDX Java tools of validation. So we're gonna try to keep everybody on schedule. So if you could hold your questions for the end, just jot them down and we're gonna have a discussion at the end where you'll have a chance to ask questions before we get into our discussion. So let's start with an SPDX 3.0 update. So before we talk about 3.0 and all that's new there, I wanted to briefly touch on how we got here. So SPDX has been around 10 plus years as a community. We've learned a lot about SBOM requirements and architecture and have continually evolved to incorporate all that we learn along the way. SPDX started, as many of you, I'm sure, are aware focused on license compliance, but we've grown to meet the needs of the changing industry. So we have a strong community, we listen to that community, we collaborate with that community to evolve and meet the use cases that they asked for. And this started as early as 2015 when there was desire to communicate security information in SBOMs and then we've continued all the way up until 3.0 with this new concept of profiles for additional use case support. So the other milestone I wanted to point out was in 2021, SPDX became an official ISO standard. So internationally recognized, that was for the 2.2 release and we have plans to pursue that again with 3.0 once we've kind of ironed out all the kinks and have given folks a chance to put this new specification to the test. Okay, so as I've mentioned, we've seen the needs of the industry evolve even since 2.1 we've had community members working on adding security features, but we have heard from users that they wanted more. So with 3.0 comes the addition of profiles. And these profiles are supporting emerging use cases as SBOM adoption has increased. So supporting security and safety critical application, compliance requirements, AI and ML, as I'm sure many of you aware is a huge space right now. There's a need for an increase in transparency around that which the AI and dataset profiles are trying to address and then software build provenance which covers things like reproducible builds. Of course when you add use cases, you add complexity. So in 3.0, we've tried to address this with profiles which are hoping to simplify some of the complexity in adding these additional use cases. We've removed some of the confusing fields and names. We've reorganized the model to enable general use bomb cases with minimum overhead so that you only carry the information that you need and that is relevant to you. Welcome to Zoom. Enter your meeting ID followed by town. Okay, finally, we've increased the flexibility of SPX in a few key areas. So you can communicate information at a much more granular level without having to package it all as envelope data which is designed for much more online access. It also makes it easier to communicate single elements which elements that are only of interest to you. This is made possible by some of the changes that we've made to support optional inclusion of elements for certain use cases and then we've enhanced the relationship structure to be both more expressive and easier to understand. Okay, so that's some of the motivation behind the changes but what is actually new? The biggest change is this concept of profiles which I will get into in more depth but just general structural changes to make sharing software metadata easier. Structurally in 3.0 we've also updated the way we reference external documents, how we model relationships and then as with any large update we've removed, renamed and added several classes and properties. Okay, so one of the big structural changes in 3.0 is external document references. In 2.3 if you wanted to reference an element or reference a document not in an SPDX document you would use an external document ref and that points outside of the document. In 3.0 we've moved this into an element collection so it can support external references easier and we have two classes of external references so imports, this is information where I got it from, the package, the checksum of the SPDX document, basically enough information to know where it came from and how I can verify that external reference and then the namespace map which is information about shorthand references within the document itself which makes it readable and easily referenceable. So you can still reference external information but because of the structural change tooling will need to adjust. So relationship, the relationship structure has also changed so in 2.3 relationships were a property of the element. So if I delivered a piece of software in 2.3 all the relationships were packaged within that element. The difficulty to this approach is that elements are immutable. So if I wanted to change a relationship within an element I can't just make that tiny little relationship change and call it the same element. I have to create an entire new element even if the relationship is the only thing that changed. So in 3.0 we move relationships to be its own element instead of a property of the element. So you can now create new SPDX document and point from one element to another via an updated relationship. So this is really critical for things like security or the build profile where relationships may be changing more frequently especially in things like VEX where you're changing status instead of having to constantly redo the element you just add a new relationship to update that status. So it's important for scalability. There's a good handful of other miscellaneous structural changes. I'm gonna touch on a few of them just for the sake of time but if you have questions just hold them till the end. So in 2.3 we had a string field for the creator and this was just a string that you could parse however you wanted. It was a tool personal organization. In 3.0 this becomes much more structured so we've separated out identities that have a naming authority versus those that don't. It's this agent class and you can use this agent class to indicate creation information with created by and created using properties. The supplier property has also been replaced by supplied by property of type agent. Let's see file type. It has been replaced by two fields. So fields that enumerate the content which is a media type string and then the software purpose for the actual purpose of the file. And then package file name has been replaced by the relationships from a package element to a file element. Checksums have been expanded a bit for easier verification so all elements now have an optional verified using property which supports multiple hash algorithms. The package checksum property for 2.3 has been replaced with content identifier property. Package URL is now a top level property for elements which should make lots of folks happy. This will be easier to find in 2.3 it was an external reference. Annotation and relationships are now independent elements so I touched on relationships how those have changed. Annotations are the same way and then snippets have been simplified which may not affect too many people because they're not used a ton. But, okay, removed renamed added properties. Definitely not gonna cover all of these but files analyzed is gone. This was a major point of confusion for folks at each doc fest people would come to us and say I have no idea how to use this property. So it's no longer needed with profiles same thing with license info in files. It's redundant with the declared license property. Package name or yeah package name and file name are now it's now just a name property of an element which we don't need to specify package and file name there because it's a property of either a package element or a file element. Extracted license info is now custom license and we added a whole bunch of classes and properties to support the new use cases which I won't touch on since we're gonna cover that in the next slide. So big picture, these changes should provide more flexibility and better support for scalability and the goal is that SPDX becomes a more simple implementation with less overhead, less metadata, less excuse me, like no assertion and none metadata that you wouldn't otherwise fill in because you can just choose which profiles you're gonna implement. So I've been talking about this mysterious profile concept and so as I've mentioned, SPDX with covering additional use cases comes complexity. Profiles are supposed to balance some of that complexity with simplicity. So profiles allow producers and consumers to focus on what's important to them and also allows them to use SPDX in a more predictable manner. So if you're only interested in security use cases, you don't have to carry all the license information that you normally would in 2.3. So when we say profile, it's kind of a nuanced term. There's three different aspects to it, conformance, namespace and then the actual working groups. So profile conformance is kind of like a declaration of what profile you intend to implement. So there's a profile conformance property that describes what the creator of the element collection intends to conform to. The profile namespace helps us organize information so basically knowing things like vulnerability information is gonna be in the security profile. And then the profile working group, which is how we are organized as a unit. So there's working groups under each profile. They meet weekly or bi-weekly and they discuss and determine the spec for that profile. There are one, two, three, six, seven profiles currently available for 3.0 with more on the horizon, which we'll hear about soon. But security is security information, vulnerability details, the build profile, which covers provenance and reproducible builds. AI and data are separate. So data is information about AI data sets and then AI is about AI models, so ethical security and model data, stuff like that. And then the licensing profile, which is gonna be congruent with the more traditional licensed compliance use cases that SPDX has offered. Software, which is gonna contain information specific to software. And then core, which is used across all the profiles. So we're gonna dive into profiles. Each profile's gonna get 10 minutes. I'm gonna really quick touch on core and software. Core is always assumed. All profiles will implement a core profile. This basically just contains information used across all the profiles. Core is kind of where an element stems from. An element is the fundamental class and requires a unique ID so that it can be referenced across different systems, serializations, implementations. So no matter what profile you implement, you'll have elements, you'll have this core profile. And then the software profile is also, will commonly be implemented. It's most applicable for that typical S-bomb application that you hear of. It describes one or more pieces of software and contains metadata specific to that software. So things like packages, files, snippets, what you're probably most used to seeing from 2.3. The software profile also has this S-bomb type, which comes from Sysa and an industry working group who got together, they published a document about S-bomb types in April of 2023. And basically an S-bomb type just describes the most likely type of S-bomb from the producer perspective so that consumers can draw conclusions about the types of data inside that S-bomb. Okay, so beyond 3.0, we have some other profiles on the horizon. We're gonna hear about them all today, so I'm not gonna get into them, but software is a service to help model services, which SAS is becoming increasingly popular revenue model. So how do we model that? How is that different from regular software? And we have a safety profile, which Nicole and Kate are going to tell us about soon, and then hardware, which just started meeting and Kate's gonna discuss on that too. So now I'm gonna turn it over to Thomas and Jeff is joining us virtually. They're gonna tell us about the security profile.