 Hi, this is Anubhathian. Today we have with us once again, Keri Stewart, senior director of strategic programs at Linux Foundation. So let's start with SPDX. Tell us what's new going on in there in that specification. Well, the SPDX specification just a month ago released out to Tutu. And what we've been doing with that is adding in a lot more features that people have been wanting for their use cases, more relationships. And then we've been working with the Japanese automotive people who've been wanting to have a light version. So there's lots of really new technology sitting in the SPDX 2.2 spec. And I think we're at a stage right now where it's good enough that, and there's enough people using it, we want to probably take it to ISO. So we've been reformatting the document and we'll be starting to submit it into ISO so it can become an international specification. And that's happening. Can you talk a bit about if there is anything additional that was added to the 2.2 specification? Also, I would like to talk about some of the use cases since you mentioned the automaker. But before that, I just want to talk about anything new in the specification itself. So in the 2.2 specification, we've got a lot more relationships. People wanted to be able to handle some of the use cases that have come up from containers now. And so they wanted to be able to start to be able to express that and specify it. We've also been working with the NTIA. Basically, they have a software build materials or SBOM working groups. And SPDX is one of the formats that's been adopted and their framing group has wanted to see certain features so that we can specify known unknowns. So that's been added into the specification as well. And then there are how you can actually capture notices since that's something that people want to use. The license has called for it and we didn't have a clean way of doing it. And so some of our tool vendors basically asked for this. Not their vendors, I guess they're partners. There are open source projects that wanted to be able to capture this stuff. And so we need to give them a way to help. We're very much focused right now on making sure that SPDX can be useful in tools and that we can get the automation happening in the whole ecosystem. Be it when you build a binary to ship to someone or to test, you might have your SBOM. When you've downloaded something from the internet, you want to have your SBOM. When you ship it out to your customer, you want to be able to be very explicit and clear about what's there because you need to have that level of detail so you can track any vulnerabilities. Cause right now about, I guess 19, I think there was a stats from earlier in the year from one of the surveys and I can dig it up for you if you'd like, but I think 99% of all the code that was scanned by synopsis last year had open source in it and of which it was 70% of the whole build materials was open source. Open source is everywhere. And what we need to do is be able to work with it and be able to adhere to the licenses and transparency on the licenses is important as is being able to actually know what you have so you can remediate vulnerabilities. You mentioned a couple of things there. One was you mentioned tooling. So I'm kind of curious what sort of tooling is there that is already there whether it's open source or open source based commercial solution that worked with the SPDX documents? Actually, I've got a document that basically lists all of these tools that we've been able to find and more popping up as the day goes by. Well, you've got common tools like some of the Linux foundation projects are certainly working with it like Phosology for instance, is able to both consume and generate SPDX. So if you've got an SPDX document and you want to pull it in and cross-check it against your sources to make sure it's matching. No one's tampered with it. The Phosology tool can let you do that pretty easily. And codes out there that can generate Phosology. Free Software Foundation Europe has a lint tool in their reuse project that will basically generate an SPDX document if you're using the IDs. There's, I guess, there's actually a whole bunch more. So like I say, I've got a document a list of about 30 to 40. And obviously the SPDX tools are there. We've got a free online validator. So if someone gives you an SPDX document you can paste it into this validator and I'll tell you if it's a valid SPDX document or not. And we're looking to it. I'm finding also some tools that are emerging, one of which is decoder ring which we'll be bringing into the act umbrella soon which is looking at transforming between SPDX and SWID tags which is another format that's commonly in use. And so we have tooling emerging and making sure that what we've got with SPDX is usable for by tool developers and that we've got libraries right now for SPDX to help them in Java, Python and Go. So hopefully we'll see more tools come in and they'll be generating SPDX documents and people will be able to share the stuff and make it automatic, which is what we need. Another good tool, I can't forget this one, is Tern. And actually Tern, and so what Tern does is it's another tool that basically will sit there and it will decompose a container and it will let you know a whole, the build materials inside that container. So you can do that. And another one that's emerging, that we'll hopefully see more soon is something called OSS review toolkit that goes into your build flow. And so it goes in when you're actually, you work with it in your system and then as you're doing builds you're generating your S-bombs and you're having accurate information recorded, right, as you go. Like I say, all of this sort of thing should be in the background. It should not be a manual time intensive effort. When we started this project 10 years ago, it was and we wanted to get it automated. And I think we're finally getting to the stage where it's gonna be, there's enough tooling out there and there's enough of an ecosystem building that will get this automation to happen. This is why getting it to ISO and getting the specification to ISO means it'll make it easier for people in procurement to specify that they want to see the input as an SPDX document to complement the product that they're being given so that they can ingest it, manage it and so forth. But by it being able to say it's an ISO standard it makes things a lot easier in the procurement departments. Open chain recognized that we needed to do this and so they went through and open chain is actually the first specification we're taking through to ISO. But for SPDX, we're taking it through as well because once they say you need to follow the process you also need some for a format. And so it's very logical to make it easy for people to work with this information. And as you work with different players different or the ecosystem what are some of the pressing needs like automation, improve automation is one of those what are some of the other pressing needs that you think that the community has to work on? So some of the other pressing needs that we need to be working on is more playbooks, more instructions showing people how they can do things. We figured out, okay here's how we can model it here's how you can represent all these cases. This is all sort of known in certain people's heads but we have not done a good job of expressing to people so that it's approachable for them and they can do it. One of the things that's kind of exciting right now is the NTIA is having a that's working group on these software build materials it's come in from the security side but there's various proof of concepts that are going on with it one of which is healthcare proof of concept and so there's a group of about five to six device manufacturers, medical device manufacturers that are generating S-bombs and SPDX and then they are handing them into hospitals to go and be able to make sure they can ingest them in and this level of bringing people up to this level where they feel like they can do these things it's been really eye-opening to me how much we need to improve our hand-holding and improve the infrastructure to make it approachable and this obviously motivates more people to be getting involved from the vendors and the commercial side as well as the open source but it wouldn't have happened I think to a large extent for SPDX without this open source and without the projects that have adopted it already. Now just from the educational awareness point of view like if there's an open source project how can they easily create S-bomb documents that uses the SPDX specification with their releases and keep it synced? That's exactly what we love to see we love to see the open source upstream projects basically generate SPDX documents as they're going forward so the first step is to use the SPDX license identifiers and make sure you've got a clean license you understand what the licensing should be in each file and ideally you can document with the tags but then there's three or four tools out there that actually scan them and will generate an SPDX document for you. If you're working at the command line the reuse lint tool that I was mentioning from Free Software Foundation Europe will work very fast and quickly with what you've got and they'll also help you make sure you've got all your files tagged properly. If you've got a little bit you know you haven't done all the tagging exercises you want to work for you what you've got a scan code works at the command line and we'll give you that information as well and then if you want to start working in a larger system and you want to store results and looking things over time and have some state behind it all so like you know it'd be different versions of things over time Facology will remember you know from one version to another and will help you create these offer bill materials. Can you talk about you know some of the new use cases that you're seeing now which maybe you did not expect earlier which also shows how the whole community is actually growing. Oh yeah well when we started the project 10 years ago we didn't understand containers they weren't even on the mind set of people and there's a lot of information sitting in containers. We've had some really good talks over the last couple of years that illustrate the problems there was a report that was put out from the Linux Foundation by Armin Hemel that goes into the details of what's going on in containers and some of the concerns. So being able to get on top of automating what's going on with concern inside a container and what you're shipping and knowing you're not shipping more than you need to figuring out how we can improve these sorts of things is certainly an area that was not initially thought about. We've also seen a tremendous interest in what's going on in IoT space and so that you need to really understand what's going on in your devices when they're being deployed in the field and to know whether or not you know effectively is vulnerability going to break it or can you recover things like that. There's, we've seen tremendous in the last 10 years we've seen tremendous spectrum of things we just didn't anticipate. And the nice thing about SPVX is you've got a use case that we're not able to represent if we can't tell you how to do it just open an issue and we'll start trying to figure it out and start to figure if we need add fields in for you or things like that. Kate, thank you so much for taking your time out and talking to me today about these projects.