Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
A deep dive into the SBOM format SPDX
Play On
16 JAN • 2025
50 mins
Share:
In this episode, I spoke with Kate Stewart from the Linux Foundation and Gary O’Neall, a long-time SPDX contributor, about the evolution of SPDX and its role in software transparency. We discussed how SPDX started as a tool for tracking open-source license compliance and grew to address broader needs in security and vulnerability management.
Kate and Gary walked through the technical challenges teams face when generating accurate SBOMs, including handling circular dependencies and dealing with uncertainty in software components. They shared practical examples from their work with various organizations and explained how these challenges influenced the development of SPDX tools and specifications.
We explored current efforts to integrate SBOM generation into build systems, looking at specific examples from the Zephyr and Yocto projects. The discussion covered ongoing work to implement build-time SBOM generation for the Linux kernel, highlighting both the technical approach and its practical benefits for development teams.
The conversation then turned to the growing regulatory requirements around SBOMs, particularly in safety-critical systems. Kate and Gary explained how SPDX 3.0 is being developed to handle these requirements while supporting modern CI/CD pipelines. They described the technical considerations behind maintaining compatibility with existing tools while adding features for new use cases.
SPDX remains an open, community-driven project that continues to evolve with industry needs. Whether you’re dealing with compliance, security vulnerabilities, or supply chain transparency, this episode provides concrete insights into how SPDX can help address these challenges in your software development workflow.
Related episodes:
- Unveiling SBOMs: Insights from Allan Friedman of CISA - A deep dive into SBOM policy and implementation with ‘the father of SBOMs’
- SBOMs, CycloneDX, and Software Security with Steve Springett - Exploring CycloneDX with its creator and lead architect
Transcript
Show/Hide Transcript
Welcome back to another episode of Nerding out with Victor.
Today we're doing another SBOM episode and we got to cover spdx.
So with me today I have Kate Stewart and Gary O'Neill.
Welcome, both of you.
Thank you.
Thanks for having us.
Pleasure to have you on the show, Gary.
We've been corresponding quite a lot over the last few months.
We are on some working groups together.
And so let's maybe before we dive into the conversations, maybe we start with doing a round of introduction.
Gary, maybe, if you want to start.
Sure, sure.
So I've been working with SBOMs since way before it was popular, over 10 years.
I got into this business when my company was acquired by Microsoft and I went through due diligence and learned the importance of knowing what's in your software.
And so I've been doing.
I run a small consulting business that does analysis for a lot of acquisitions.
And I've been working with the software product data exchange almost from the very beginning.
And I'm kind of known a little bit as the tools guy.
So I've written a lot of tools to do spdx.
Thank you, Gary.
Kate?
Yeah, and I've been with the system package data Exchange now actually we rebranded our name recently just to catch the fact that we're more than just software at this point now.
Pretty much since 2009 when I was having to ship BSPS as part of being at a semiconductor manufacturer and we had to basically adhere to what was the actual terms and actually know what was in them and have a way we could share it with people.
And so that was sort of the starting point.
And Gary was joining very shortly thereafter and making it real and helping us all try to get keep this grounded in things that people can actually implement and move it forward from that.
Amazing.
Thanks, Kate.
So I guess Gary, you kind of almost answered my first question.
And my first question was going to be what was your first introduction to SBOMs really?
Because obviously both you guys have been around for quite some time and maybe Gary, start with you.
You mentioned that it's coming out of M and A, right?
Which is something that I've heard before and yeah, walk me through that process back then and how that looked and how that the landscape I've changed ever since.
Really?
Oh, yeah, it's changed quite a bit.
I mean, when we first got started, the, you know, I really had to evangelize to people why you would want to like track what's in your software.
And you know, and you know, it started more from the license Licensing side and compliance.
And I think it was only two years into SPDX where we started to, you know, kind of shape it more for security use cases.
But, you know, in either case, the problem statement's the same is, you know, I got some software, some, but from somebody.
Whether you're acquiring it as a company or acquiring it to use in your own enterprise, you kind of want to know what's inside the software.
And you know, 10 to 15 years ago, it was like a total evangelism.
It's like, no, you really want to know what's in there.
It's like, I don't know, it's kind of expensive.
And then, and then when you finally get to something like an M and a transaction and all of a sudden it's an emergency and that's when I get called in.
So.
And now it's changed quite a bit, especially with the NTIA and the government regulations.
Now everybody, it's no longer evangelizing.
It's more a question of now how do It?
Which is, which is great to see, right?
Yeah, Absolutely.
And Kate, it sounds like you started on the semiconductor side of things, which is slightly different, but I see a big wave from that as well.
So maybe shed some lights on how your view has changed or that view has changed, but.
Yes.
Well, for us to sell the silicon, we actually had to provide enablement, which meant like a Linux kernel and compilers and tool chains and bootloaders and things like that.
And the easiest path for us to do that was open source.
And so we got your basic bootloader, your kernel, and then a variety of user space packages and you put them into a BSP or board support package.
For us to ship that board support package, we needed to actually understand what was the licenses of all these open source components and make sure we complied to the terms of them.
The challenge was that I was doing this exercise in a semiconductor factory.
Colleagues at Monte Vista were doing the same exercise, colleagues at Wind river were doing the same exercise.
We had no way of sharing it.
And so we sort of tried to figure out how can we share this metadata about the packages we're looking at.
And so we basically got together and started talking and started figuring out what properties we want to share.
And that was the start of forming up the SPDX spec.
And then we, you know, and then we got use case after use case after use case.
That has taken us down some interesting directions.
And so once we, you know, once were able to start sharing things, I guess I think the 1.2 release, it was good, but then all of a sudden was sort of like, well, how do we start dealing with all these abstractions that are in the industry?
Like what a group of things, you know, we call in SPDX a group of anything, a package, effectively.
Now this gets overloaded with package managers and all the packaging technology.
But realistically for us, a group of things, like a tarball is that.
And having things as part of a file or a group of files has been a very powerful abstraction for us to use and leverage.
And so we've been sort of working that use cases into the next rev, which was the 2.0.
And 2.0 was kind of what we ended up refining and taking to ISO as a standard.
And we also put the security stuff in there.
Actually, at that time that was.
There was a lot of the security stuff started showing up with references.
So you could link packages or components or car balls for that matter, to vulnerabilities or CPEs and so forth.
So we started those use cases being represented at that point and linking things forward.
And like I say, we took it to ISO and it's been out there for.
Since, I guess what, we took this stuff there.
It's about four or five years now, I guess, and we've been continuing to refine it.
And more and more I've gotten really interested in how we deal with things for critical infrastructure and how we actually start looking at safety.
And so this is one of the areas that I care about a lot and I'm focusing on.
Gary's focusing on some other areas too, like services.
That's one of my favorite areas.
Yeah.
So it started from the semiconductor world, and I think we're almost seeing a big full circle there, I guess.
I mean, I've had some of the guys from coreboot on the show, for instance, before, and like, open source firmware is definitely in vogue at the moment, and it goes hand in hand with SBoM.
So it's kind of fun to see how that becomes a full circle.
And now we're treating them all like the same and describing them using an S bomb.
Yeah, yeah, absolutely.
I don't know if you've encountered Zephyr before.
Yes, yes.
Well, basically we've got it set up there that all you're pretty much doing is turning a config option and you're getting 3s boms out automatically.
So you've got all this information sitting there.
And this is kind of, I think, where we need to take the industry is so that this isn't a fire drill, it just comes into the whole processes automatically.
Yeah, absolutely.
I mean we've.
So one of the tiger team at cisa, I'm co leading on the reference implementation of sbom.
We had the Zephyr team representing there as well.
And it's particular when you go in lower level where you start to incorporate building SBOMs in like makefiles or not.
The tool chain is so very different than it is for either a microservice written in Python or JavaScript.
Like the tooling are so polar opposite.
Right.
In terms of like how you interface with them.
But it seems like there's a lot more maturity coming in there.
And SE is definitely.
And YOCTO as well, to be fair, is doing a good job when it comes to that.
This is.
I mean, so this is super interesting and let's.
You kind of talked about this, but already K.
But like the history of SPDX really doesn't derives from license compliance.
Right.
That's kind of the angle you started the project which.
Because I would imagine like.
Well, you kind of mentioned already security was not really part of the initial scope.
Right.
So it really started with license focus.
Is that.
Is that a correct assessment?
It's a start with transparency as to what you're there now.
We were recording the licensing so we could understand.
But transparency, I think was the root cause.
It was root here, which is understand what you really got and how you can basically, you know, track dependencies and track interactions with things.
You know, another way of looking at it.
Yeah, you know, I think it is.
You could argue that it started with licensing, but.
But I think the more important dimension is it really started with compliance.
We had like a set of rules, you know, legal rules.
You had, you know, you didn't have just engineers looking at stuff.
You had other parties that want to make sure things comply.
And you have compliance and security as well.
You have a lot of compliance and security.
Security, especially if you're a financial institution.
So that was a big part of our initial focus is how do we provide information that enables proper compliance?
You know, you know, starting with the licensing, but very shortly after that, in fact were.
I remember the meeting we had, Kate.
We were over at University of Nebraska at Omaha talking to one of the professors and pulled in their security, you know, their security professors.
We had a big discussion like, look, all these, all this data is this.
It's the same data.
You just want to know what is in there and if you want to comply with your security Policy, you need almost exactly the same information, you know, that you need for license compliance.
So it really was a very short distance from starting with the licensing to discussing security.
And when I sort of started discussing this stuff with the NTA working groups as they were starting off, you know, it was sort of like the security people were going, oh, we don't like licensing.
We're going like, well, actually you kind of need to know the same properties here.
Guys, this is not anything new here.
Use what's already there and built from it.
Don't try to create your own.
The hard part is knowing the dependencies, right?
Once you, once you got the dependency pre figured out whether you use it to correlate with a vulnerability database or use it to correlate with, you know, licensing information, data source, you know, that's a lot easier than just figuring out what the dependencies are.
So very leverageable data.
Well, that is one of the biggest problem, isn't it?
When.
Well, I wouldn't say the biggest, but one of the big problem is transient dependency and tracking that throughout the tool chain.
But that's where it gets very messy.
And I'm sure both of you have spent a lot of time trying to try to unravel this, right?
Yeah.
I mean, when.
I'll just give one example on that affects the standard is you would like to believe that you could represent dependencies as a tree.
And in 90% of the time that's true.
You know, and then it's like, oh shoot, there's, you know, there's actually circular dependencies.
It's generally considered a bad practice to have many of these, but guess what?
It happens.
Oh shoot.
So not only is it not a tree, it's not even a directed graph.
It's a cyclic graph.
You can have cycles in it.
It's like, oh man, that really messes up the tooling.
But your spec has to support it.
It's not that the spec is complicated in supporting graphs is that the world is complicated and we have to deal with that world and we have to be able to represent it in our standards.
So, you know, so that's some of the learnings.
It's like, oh gosh, I wish it was just a treat.
Oh my gosh, I do too.
Like I say, it all started off with just simple packages, okay.
And then packages into systems and it was sort of like.
And the world is even getting more complicated at this point in time with things that are dependent data, right?
Let's not forget data here because I don't know about you, but if you've got a self driving car, there's a lot of data sets that are being pulled into training up your car the same way there's a lot of code that's being pulled in to build up your application.
So understanding that data set and having the transparency on the data sets that are being used is part of the reason we've been heading more and more towards the system side.
Yeah.
On the AI data side, they're pretty big financial incentives not to reveal those data sets as we've seen pretty big pushbacks on disclosing the trading data.
Yeah, no, there may be incentives, but you need to know what you've got internally even if you're not exposing it externally.
And real estate.
I meant more that they know.
Oh, I meant more that they very much know what's in it.
It's just if they disclose it, they will be in trouble.
That certainly happens.
But being able to sort of know and be able to query things in a structured fashion is one of the pieces that we're trying to work towards making sure we can have happening at this point and taking.
Yeah, graphs.
Yeah, absolutely.
And one of the things, I mean, not only graphs, but graphs of graphs almost.
Right.
Because it's one of the things we cover a lot in the CISA working group with Gary's part of is how do you represent an entire system?
To your point, Kate, you might have a microservice which in turn has three to five different SBOMs, but then you want to represent that and that's part of a bigger system.
So you have these hierarchies of SBOMs and that's where it gets really complicated.
So this is what we did.
This is the whole reason SPX3 exists.
Okay.
Right.
We have a common underlying element that has any type of data hooked onto it.
So initially I think in like the NTIA stuff there was a whole concept of the crop circles.
I don't know if people are remembering some of those discussions where there's data associated with security, there's data associated with software, there's data associated with data, but there's metadata in with all these things.
And what we've got in SPDX right now is the ability to create databases with a common schema and so you can actually link all of these things together and reference, so you can reference from a build SBOM to the source sboms and know that you are, you know, you're coherent and things haven't been mucked up on you.
And then this data, you can then query and understand how things change over time, which puts you in a lovely place where if you're working with the CI flow and things are changing automatically, so all you're doing is adding a new element and changing some linkage.
But you're doing this in a database, in a structured fashion.
So at any point in time you say, oh, what was the SBoM on this date?
Oh, what was the SBoM on this Date?
And what was the SBoM of this subset?
You know, you can basically export these out of databases now.
And that's kind of what we need to do.
Scale rather than patch, patch, clunk, clunk.
Sorry.
That's my view on it.
Yeah, no, speak.
Speak to me more about that because that's interesting, right?
Because I mean, the way I've seen sboms traditionally is that what traditional, as long as I've been exposed to it is a snapshot in time, right?
Is it's a truth for that CI CD run, right?
And the next run, it's likely change, right?
Yeah.
So the thing is, what were finding about five years ago is every company were working with was creating their own databases, okay?
So all these large organizations had their own databases, and they were moving SPDX into the databases in a structured fashion.
So we started talking.
The tool tool group was basically very focused on this.
This was coming out of omg and we also were seeing evidence from ourselves, from the people were working with, that they were putting things into databases.
The challenge became, okay, how do we basically structure our data underneath the covers here so that we can be in databases very seamlessly.
If someone has to put out an S BOM that is your point in time, they can query it, but then they can also know, okay, how has it changed since then?
And how is the things going that way?
And so having that internal database and having that graph, a knowledge graph effectively of all your elements connected together becomes very powerful when we have to go to scale.
Scaling is a big one.
And if I could just take that a little step further with a couple of examples, because I'll give you a little insight into how our meetings run sometimes.
I'm always a big champion of compatibility with the prior versions, so people have to argue with me to get some changes in.
And a lot of the changes were made so that these systems can scale.
And just to be clear, SPDX is an interchange standard.
It's what data you send out of this database.
I don't think we want to be in the business of telling people how to design their internal systems.
That would be a little harder to adopt.
However, if the Exchange database is structured in a certain way, you can implement much more scalable systems internally.
So one of the examples I'll just point to was our representative from Microsoft, you know, which owns GitHub, wanted to have a very scalable system where every single commit that goes in can give you a live fresh update of your SBoM.
You think about the scale, you know, you talk about scale, you're not going to like read, rescan, regenerate, you know, redo all this really heavy lifting every time somebody does a commit.
You need to have things done at a very small atomic level and make things, you know, really accessible.
So a lot of the restructuring we've done about how things like how relationships work within the systems, that what we meant as like, we mint elements and you cannot change that element.
So we've moved things out of the element so you didn't have to create a new one every time there's a commit for all the different properties.
So we did a lot of engineering around that to make the SPDX system a lot more scalable.
And of course, I always try to balance it out with keeping it compatible and keeping it simple, you know, for maybe the people that don't want to build these giant systems.
So there's a little tension there and I think we did an okay job at that.
Let me.
So let me rephrase that, or to make sure I got it right.
So, like, you guys consider SPDX 3 more a database schema than a format.
Is that a fair recap of this?
I wouldn't, I would not say that.
There may be people in the community that would.
I mean, it is a schema.
I mean, it's a, it's very specifically, it's a shackle owl schema that we generate a JSON schema from and use it for JSON LD serializations and such.
So, I mean, it really is a schema, but it really is intended to be a schema for data you send from system A to system B, and people are using that same schema to implement internal systems as well.
But I personally would not say that's the design of it.
Now I will again say that there are people in our community that would say, yes, this is a prescription for how you should implement your system, but I personally would not say that it really is.
Let's create a Standard that people can exchange data system data around.
Yeah, I don't.
Kate, what do you think?
You might have a different opinion.
Like I say, I think that's.
We're threading a line here and so it's not as black and white as Victor would like because we are basically it's there for people to implement internally.
We aren't dictating what's in your database per se because you may have other properties, you may have other things you want to keep.
Sure.
And you know, and some of that other stuff you're keeping becomes fodder for the next rev of spdx, quite frankly.
But it, we are an interchange and we are.
But you want to interchange with modern systems, you don't want to interchange with things that are thrown out.
And so CI is part of it now.
Data data training data sets, validating data sets, testing data sets.
And then quite frankly, as we go towards critical infrastructure and all the regulatory side around that we've got to deal with, the safety profiles and the standards around safety are going to be key for, you know, making sure that we actually have the precision that, you know, we can know people stay safe.
And so that's, you know, these areas where we're expanding SPDX to make sure that we are handling it properly.
But these are things that are going to keep on emerging and you know, the world isn't getting simpler, let's put it that way.
It's getting a lot more complex.
Quite right.
And as far as safety, I would imagine that things like attestation would fall within scope of that as well to make sure you trust actual data and.
Or is that completely out of scope or.
Well, there's ways of doing attestation.
You're more likely to attest to an SBOM document or something like that.
Say that we've got mechanisms built in and we've had mechanisms built in pretty much since the two actually was it the 1.2 days where you're basically taking hashes on.
On artifacts to make sure that you have one to one and things haven't shifted out from under you.
So there's mechanisms there and then the attestation is someone saying yes, I've tried to check this effectively.
So people have generally put in attestations around the SBOM data as opposed to inside the SBOM data because that's what we've been finding.
On the other hand, there's ways of doing it.
People want to put them in, they can, there's ways it can happen but yeah, for that, yeah, like I said, we've put things in for it.
But realistically, most people try to do it here I am providing this SBOM document to the government for this thing at this point in time, and I'm attesting that this is accurate.
Right, right.
That's.
That's kind of where it happens.
And so it's happening around it in my mind mostly, but that's my perspective.
That's fair enough.
Then.
We always have the problem of unknowns, which is a big problem in the SBOM world.
Right.
Because we, just because you have an SBoM, we generate an SBOM from whatever piece of software, it doesn't mean that it's actually complete.
So the definition of complete is a bit of a, I think, hot potato in the SBOM world.
Right.
How do you guys think about this in general and like, where we're going with that?
Well, this whole issue of known unknowns came up in the NTI work.
And we made sure our 2.2 version of SPDX, which is when we took ISO, actually had an explicit way of signaling a known unknown.
And so known unknowns are a concept we are quite conscious of.
And whether or not there's full completeness on the information or not, you can signal.
And you could do that in 2.2, 2.3, as well as noun 3.0.
I would say we actually had it from the very beginning of 1.0, because when there's a lot of properties where we had two special values, none and no assertion.
So none means I know this does not exist.
I know there was never, you know, a statement around this, or I know there was no license associated with this.
That's a none.
No assertion means I don't know.
I know I don't know.
Therefore it's a no assertion.
So no assertion has been in there.
So we've carried that forward into 3.0, although in 3.0 we actually added a lot more flexibility in how you can state it.
So the relationship class actually has a, a new field that gives you a little bit more clarity on how much you know.
You don't know.
If I can complicate it a little with that.
Yeah, I guess the problem is also like you don't know if there's a dependency in there that you haven't tracked.
Right.
That do.
You can't specify that whatsoever.
That by definition you can't.
We can.
We have a way, and this is the two step I was talking about is you can say, hey, Is everything complete or not?
And you can put a no assertion on the completeness, which means I don't know if it's not complete or not.
So you can signal that you have some potential.
It may all be fine, maybe it complete, but you can't be authoritative at this point in time.
So you can be explicit about that.
Fair enough, Fair enough.
The next thing I wanted to have a chat about was something that Gary and I have been trading quite a few conversations around, which is licensing audit, which I, I know Gary has spent a lot of his life, spending his life, a lot of his life trying to figure out in terms of auditing S bonds.
But that is a bigger and bigger problem that I've seen, at least in my firsthand experience, like both in the case of a duplication, but also like incorrect licensing.
So maybe like how do you guys see the state of that currently and what's being done to I guess improve quality of license compliance and coherence, I guess is a good way of phrasing that.
Do you want me to start?
You want to start?
Because I got so many ideas on this.
Let me go ahead and start that.
Just so there's like two different areas.
Some of this is a little bit of a hot button with me, but with some of the SBOM tools out there, they, they'll generate just knowingly things that don't even parse as far as, you know, valid license expressions.
So there's definitely some work that needs to be done, you know, in the tooling side.
Just simple things, you know, does this license expression actually parse?
Is it valid?
And if it's not.
So but let maybe start there.
Like what's what?
Let's zoom in on that first because people who have watched this may not be aware of the whole license side of compliance.
Yeah, so within spdx, you know, and this by the way is these license expressions are actually used in a lot of other standards, many other standards as it turns out.
And it's basically like a Boolean expression of licenses.
So you would say like, oh, I found a license, an open source license gpl and oh, I found an open source license mit.
So both of those apply.
So I would create an expression MIT and gpl.
And if I just find a blob of text that doesn't correlate with any known licenses, we have a way of doing what we call a license ref.
So it's basically you create this thing that has the text and then you can refer to that in other parts of the SPDX document.
So these things are pretty well defined, they've been around, I don't know Kate, what about 10 years?
The thing to understand, to help simplify, improve the problem, one of the big contributions SPDX has made to the ecosystem as a whole is the license list where we've standardized a common set of licenses and have a group of lawyers that review them to come up with an idea to say whether it's unique or not and have standard templates so that you can do matching and so forth and then quite frankly getting it so that we've gotten open source projects to adopt this.
So rather than a random wall of text that it takes some sort of artificial intelligence inferencing machine to figure out which license it really is.
You have a one line that you parse and then you can say yeah, it's this license.
And the developers like that, they don't want to have to cut things around, they want to be able to just put the licensing in.
And so this whole initiative to just put that in started with u boot out there and then various other projects have adopted it since then, including the Linux kernel and Zephyr and so forth.
And we spent about five or six years ago, we did full pass going through and looking at Zephyr, looking at all the licenses in the kernel and cleaning them up and removing blocks of text.
Yeah, if I could just interject, I mean just when you mentioned the license list, I just want to say that we're actually expanding that same concept to other areas.
We actually have a hash algorithm group that started up that's doing the same curated list so that we could have identifiers and a group of experts.
I'm not one of the experts, but we have people that are expert in cryptography working on this group to basically associate certain known properties with the strength of the algorithm.
So be able to create and curate that as well.
So I think that's going to be just as valuable as that evolves.
And I just wanted to also mention back on the licensing, I just wanted to mention the, just as the story of NPM because I think this is a great story.
I've been doing as you know, I've been doing these license audits for a long time.
I used to hate to see NPM projects have a total nightmare of license, you know, because people could put in their files, you know that the metadata files, whatever random string they wanted and call it a license.
So sometimes you wouldn't find anything, sometimes you would find Things like this license is, you know, something I, it just, you just find all kinds of random stuff.
I'm trying to remember the guy's name.
I should give him a shout out if I could remember his name.
I'll mention it, but one of the maintainers in that group, in the NPM group says, hey, let's use license expressions.
This is pretty well thought out.
We got the license list and they went through and they put in tools, they verified it.
Now I just love it when I see an NPM project.
It's still a little bit of a nightmare in the dependencies.
It's kind of hard, you know, the way they do dependencies.
I wish it was a little cleaner, but as far as the licenses goes, it's great because you cannot upload a project without it having a valid license expression.
So it makes the downstream life.
And that I think is what the key is to the solution to the licensing is that the package managers, you know, the upstream projects and the package managers fully implement the standard.
So those of us downstream, when we look at these, it's much easier to parse rather than having to deal with these random strings that we see.
I mean it's funny because almost as you merge yourself in this world, almost all roads lead to package managers.
Because that's like, they are the canonical truth, more or less.
Yes, Kate, I'm going to disagree from the embedded side.
Just saying.
Fair enough.
It's all about the compiler.
Come on.
Right, Fair enough.
In higher level languages, I guess all roads lead to package managers.
Although you do see a push towards package managers on lower level averages as well.
Like Conan for C for instance.
So it is making its way down to lower level as well.
Maybe not to super low level of embedded code, but at least to compile that level.
At least.
But that's.
So the SPDX licensing database has kind of merged as the canonical source of truth for licensing these days.
You do have some friction with OSI model.
Do you guys care to comment on the discrepancies between the two?
It's not a discrepancy.
We do have data management issues.
We actually work pretty closely with the OSI group.
Yeah, it's actually a pretty good relationship.
One of the things we've done on our license list is we've added an OSI column to our database where we can say whether it's OSI approved or not.
I've worked with the technical folks at OSI to see if we could Automate that and make that a little bit more reliable.
Because what happens is, and I won't point fingers, but let's just say somebody changes the text of a license that you think should be the same and all of a sudden you got different text and it's like that doesn't really match anymore.
So the data gets out of sync and those are problems we're trying to work through.
I mean, there's another group too, which is the folks behind gpl.
Fsf.
Yes.
Free Soft foundation.
Yeah.
They also are pretty passionate about their licenses and they have their license list as well.
And you know, we work with them as well.
Yeah, we had to make specific changes to keep them happy actually in the license at one point in time, which made the colonel people unhappy.
So, you know, you just can't.
The other thing too that's been happening is, you know, this cleanup has been happening pretty much across the ecosystem and to the extent that like the Red Hat team has been slowly and surely cleaning up all of their packages and licensing, which makes it easier for a huge range of downstreams as well.
Yeah.
And so these sorts of, you know, initiatives of making it easier to just pull the data out and be accurate, you know, long, slow process.
But it makes things better in the long run too.
Absolutely.
And that's kind of what I meant by package manager because that expands beyond just languages, but also DEB and rpm.
So the operating system vendors, they have a unique position where they can actually give you a truth that is otherwise hard to do.
But it is nice to see that this is sweeping the industry.
I know PYPI is undergoing a similar audit right now that NPM did a few years ago.
Right.
So now there's focus there to clean that up as well, to make sure.
So yeah, it's hard when the data is dirty.
It's hard to generate a good sbop.
So I kind of want to turn my focus a bit over to your day job, I guess, Kate, now at the Linux Foundation.
So you guys are in a unique position as well in terms of like governors of a lot of software, all open source software.
What's the kind of view on projects that are under the Linux Foundation?
I'm thinking under CNCF and I'm thinking under other umbrella organs or so under organization, under the explanation in terms of like mandating S BOMs and quality of S BOMs as well.
Is there any conversation happening internally with.
With regards to that as.
As we speak?
Well, the projects I work for and work closely with are on the embedded side So I can't speak too much beyond that.
But I do know that the LF is very much committed to having accurate SBOMs available for the projects.
And to that extent Gary and Jeff have been working on a project to basically scan everything and make it visible and have it published.
And we've been actually, we've been publishing out for various projects.
The Source has BOM audits for about five years now.
Actually there was an LF scanning repo in GitHub that where this stuff was getting published and there's continuing work to continue to improve that.
So the LF is trying to help the projects as much as possible adopt best practices.
Gary, do you want to say anything more about what you and Jeff have been working on?
Yeah, so Jeff.
Jeff and I actually have worked together for many years.
We did audits together before he joined the Linux Foundation.
So I'm not an employee of Linux foundation myself, but I do provide support to a project and support to jap, you know, who does these scans.
So if I remember, so don't quote me on this, I'm probably off, but I think there's like about a couple Hundred or like 250 different Linux foundation projects that we kind of focus on and provide extra services for.
And one of those services is to do scanning and these are source sboms.
So we actually scan and look for actual license text and it's somewhat labor intensive to sift through the false positives and that.
We've been doing that for years.
I've been working with Jeff and we're just starting to roll out a more complete SBOMs.
And basically what we're doing is in addition to the source files, we're doing all of the dependencies that are represented in the metadata packages.
In fact, I'm using the pretty much the same tool chain that the CISA reference implementation is using.
We happen to pick the same tools almost pretty much independently, which is kind of interesting.
So, and we have some of our own tooling that we wrote this thing called Scaffold, but we'll be rolling that out for these 250 projects.
But the one thing I just want to mention though, this is a service that the Linux foundation will be providing, but it is not as good as what you could do if you did what the embedded team has been doing for years, which is producing the SBOM at build time.
Because we are doing a scan, we're actually looking at the metadata file, but you may have a metadata file that says something like get the latest version of this dependency.
Obviously we're not going to know exactly what version was pulled down when this particular executable was built.
But if you do a build sbom, you know, you'll know that.
So I, whenever I talk about this, I always, you know, I've certainly, I'd encourage people to use what we're producing out of these scans.
I think it's very usable.
I think it's as good or better than many of the SBOMs that I've seen, but it's not as good as what the teams could build themselves.
So kind of do what the Octo and Zephyr teams have been doing, which is, you know, generate these s boms at build time to get the most accurate results.
But if you don't have that, you know, we'll be producing these additional ones.
And these are all public, they're in a public repo, so anybody that uses the open source can pull them down.
Okay, interesting.
And I, I believe, was it the YOCTO or was it Zephyr project that modified the compiler to basically do it at.
Com in the compiler?
I think it was Zephyr product that actually modified to actually use the output from gcc if I'm not mist and then generate s pause based on that.
I think you're thinking more towards Yocto.
Zephyr is using CMake and it's putting instrumentation in CMake to basically pull out the debug information.
Realistically, YOCTO is also pulling out the debug information out of the build flow.
And that's where the source of truth is in terms of what you're actually getting with your image and work is I'm going to make something like this available for the Linux kernel too.
So that will be nice when that finally emerges.
That was going to be my next question, actually.
Like, I've heard rumors about this for a while, that the SBOM for the kernel is coming.
I guess you are kind of involved indirectly or directly with that, Kate.
I imagine, yeah.
Basically the same person who did it for Zephyr has turned his hand to looking at the kernel problem and so is working with Greg and some of the others in the kernel to make sure we can get something a little bit better.
So hopefully we'll be having something we feel comfortable with and making it visible with some noises, I guess, once it's there, because that'll be useful.
Do we have any timeline for that?
There's beta versions sitting around now.
It's just a question of making sure that something that we're all comfortable with.
I See, how many hours in the day and how many trips are you taking is kind of the challenge here for us all.
I think.
Fair enough.
I mean, I think that when that hits, that will be a big massive shift for the industry.
I think from my vantage point, like the having S bonds for the kernel, having proper S bombs for all the Linux distros, that's when we will really have a big shift in the, in like the adoption.
I think I'll point out right now you can get an SBOM for the kernel if you use yocto.
Just saying.
Fair enough, that's a fair point.
Okay, but yeah, pulling it in from the builds and things like that.
But yeah, no, you can generate out a build S BOM with YOCTO for the kernel and you've been able to do that for a couple years now.
It's just a matter of if you're not working within yocto, you want to have it, then you need to look for different mechanisms.
So that's what we're trying to get.
Yeah, absolutely.
Yeah.
No, I think it's end of the day it's the person who consumes the SBOM that will, sorry, that builds the kernel that needs to generate the SBoM and that kind of falls on then to the distribution, the distros essentially.
Right.
And they I guess use different tooling.
So there might be a cascading there.
But yeah, I don't know how custom the kernels are these days from the distribution they're probably pretty far from pretty heavily patched from the upstream kernel by now I would imagine.
So there might be some lag there involved as well.
No, this has been super interesting in terms of the competitive, sorry the compliance landscape as you go forward into.
I'm thinking both about CRA that's hitting Europe, which obviously can drive a big part, but also in terms of like compliance for.
I know NIST2, which was announced earlier last year, kind of stops just shy of mandating S bombs.
But you can interpret, I think it's PCI DSS 4.0 which kind of mandates S bombs.
So I'm curious about how you guys are seeing the driving force for S bombs.
Beyond the executive order which kind of spearheaded this in many ways.
I'm seeing it from the regulatory side and functional safety, we need that transparency.
And if you know, you want to know what's running on the nuclear power, someone needs to know, even if you don't from a public side or on a personal level, you need to know like you know you want the FDA to have actually reviewed all that's going into a medical device, especially with something that's implanted in your body.
Okay, yes, oh yes, absolutely.
These are things that we need that transparency when we start to have safety as an element here.
And you know, because open source changes so rapidly because there are security fixes showing up all the time.
The other thing you really want to do is you want to know, do I actually really need to fix this or not?
And so being able to have a higher precision and being able to get rid of the whole class of false positives at the component level is also an area I think we'll be heading.
So you believe the legal is the driving force here for change?
Really?
No.
Well, I'd say safety is a driving force for change, regulatory is a driving force for change rather than legal compliance.
But it's compliance, yes, compliance, yes to compliance with licensing.
Okay, fair enough.
Gary, what's your.
Yeah, I agree with safety.
I think safety is going to be a big driver.
You know, especially, you know, when you pull in AI self driving cars, all the data sets being used, there's a lot of regulatory compliance that's being thought about that I think is coming down the road.
The other thing I'll just mention, another dimension to this is the international dimension.
We're seeing lots of regulations come from different countries, they're similar, but not exactly the same.
One little, you know, kind of technical story on this is we have this tool called the, that was formerly known as the NTIA compliance checker that takes an SPDX file and tells you whether you comply with the minimum.
Ntia.
Well, we had to add a whole new command structure because you want to see does it meet the German standards, does it meet the Japanese standards?
You know, so does it meet the CRA minimums?
You know, so, you know, we're having to evolve our tooling to deal with these multiple regulations which have a common core, but they're just a little different.
Well, CRA is going to open a whole different kind of worm because, yes, the first draft is still there from the eu, but then you have the regional implementations of stra, right?
So that's gonna probably add a lot of very, a lot of arguments to your command line tooling.
And then India has its own take on things and China has its own take on things, as does, you know, Japan and Germany and so forth.
So we're seeing a lot of variants and everyone has specific things they care about.
But the regulatory side is definitely a factor here, no question.
Yeah, I mean for me the reason why I'm excited about SBOMs in general is.
I mean it's funny to be excited by the JSON element because it's really not that sexy.
But it's what enables and what it spans.
All these regulatory frameworks like the world I anticipate is that all the next wave of regulations be SOC2, be NIST, be ISO all these frameworks, they will mandate S BOMs in next order version after that I'm fairly confident with.
CRA just kind of opened this and started making it part of the public debate and now it's just, it's going to be part of all these framework.
That's at least that's the way I see this path going forward.
Yeah, I think one of the interesting data sides of it is the geography.
You know, how do you know what geography software originated in?
You know, in the services profile that I'm working on geography is very important because you know there's certain regulatory issues as far as, you know whether your data is actually stored on a server, you know where that service actually is.
So including this geography information is interesting but export regulations that also requires it.
Now the self driving cars, there's regulations about what software where that software for that self driving car could originate.
It's just going to be just a real challenge.
I don't think the challenge is representing the data.
I think the job for SPDX is pretty easy because the country codes and everything is pretty well standardized.
But how are you going to determine these things is the interesting thing, especially for open source projects.
So some nice, interesting problems to work on.
Absolutely.
I mean if the code lives in GitHub, you have the committer of that core code but you have no way of knowing geographically where this person is and what if it's constellation of people?
Then you have even less way of expressing that.
Right?
Yeah.
And what if somebody, you know, that's a US citizen moves to this other geography?
There's all kinds of really interesting edge cases to think about.
You know, in terms of what is it, what does this really mean as far as determining the origin of this alcohol or data?
Yeah, absolutely.
This has been super interesting.
I really appreciate both of you taking time of your busy days and I am looking forward to seeing SPX3 getting wider adoption across tooling because I know as Gary is acutely aware there is a problem with tooling keeping up with the latest version.
So I'm looking forward to seeing that adoption creepy up with all the tools and Any closing notes from either of you before we wrap up for today?
Let me just.
I'll just make one quick comment.
I'll turn it over to Kate, but I just want to mention SPDX is an open community.
We're welcoming of all contributors, whether it's tooling, improving the spec.
Just go to spdx.dev and you'll find out how you can participate.
But join us, you know, if you see an issue with our standard, do you think there's something off, you know, come in.
We're easy to work with and very happy to have more contributors to the spec.
So I just wanted to mention that for the group and it's great talking to you, Victor, and as always, Kate, and thanks for having us.
Yeah, it's been really good.
Victor, I'd also basically bring up that if you're interested in working on tools and helping to us to move some tools forward to SPDX3, we definitely would welcome all help to here.
We don't have, you know, we don't have large corporate organizations really pushing for things behind us, so it makes it a little bit more interesting to make the enablement happen.
And so this is our second transition.
We did a transition between 1.2 and 2.0, but there was a lot fewer tools out there at the time.
And so now we're ecosystems out there at the time.
So now we're basically going through this transition.
But I think what's there is a good base for us to evolve and hopefully the next set of transitions will not be as interesting because we will be adding more things for a while.
So I think we're on three for a little bit.
Yes, or Gary and I will be retired by then before the transition happens.
Well, we'll see.
Perfect.
Again, thank you so much for coming on the show and have a good day.
Cheers.
Thank you.
Found an error or typo? File PR against this file or the transcript.