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.
SBOMs, CycloneDX, and Software Security with Steve Springett
Play On
20 OCT • 2024
1 hour 12 mins
Share:
In this episode of Nerding Out With Viktor, Steve Springett joins Viktor Petersson for a thought-provoking conversation on the future of software security and compliance. As they delve into the world of Cyclone DX, it becomes clear that standardization is key to unlocking true autonomy in software communication.
Steve, one of five core working group stewards overseeing Cyclone DX’s adoption within ECMA International, shares his expertise with Viktor. He explains how their community-driven approach ensures that TC 54 TG 1 remains aligned with industry needs. The discussion touches on the importance of sharing information across disparate systems, dependency tracking, and SBOMs (Software Bill of Materials), highlighting the potential for a single mainstream option if standards are adopted by big cloud vendors.
The conversation takes an interesting turn when Viktor asks about the concept of different types of SBOMs within CycloneDX. Steve explains that this approach allows for the creation of a single bill of materials by linking different components together. However, even in small deployments, this leads to multiple SBOMs, raising questions about best practices around production and consumption.
Steve emphasizes that CycloneDX represents a mix of existing SDLC (Software Development Life Cycle) and software asset management lifecycles, making it relatable to developers and IT professionals. He shares his vision for the future of software security and compliance, where organizations can communicate autonomously through standardized SBOMs.
Throughout their conversation, Viktor asks insightful questions, delving into topics such as the best practices around producing and consuming multiple SBOMs. Steve highlights that there’s no one-size-fits-all solution, but rather a need for flexibility in approaching software security and compliance.
As they geek out over the latest developments in SBOMs, it becomes clear that standardization is key to unlocking true autonomy in software communication. The conversation showcases Steve’s expertise as a pioneer in software security and compliance, providing listeners with practical knowledge and industry insights that can be applied to their own work.
Viktor asks Steve about his experience working on CycloneDX and how it compares to other SBOM standards like SPDX. Steve explains the differences between the two, highlighting Cyclone DX’s pragmatic and automatable design philosophy. He also discusses the challenges of dependency tracking and the importance of provenance in software supply chains.
As they discuss the future of SBOMs, Viktor asks if big cloud vendors would adopt a standard option, making it as common as unit testing is today. Steve emphasizes that CycloneDX can represent all kinds of things, hardware, software, containers, services, and more. He explains that while some organizations may choose to put everything into a single bill of materials, others may find it easier to separate them out and make everything linkable.
Steve shares his vision for the future of SBOMs, where organizations can communicate autonomously through standardized SBOMs. He emphasizes the importance of flexibility in approaching software security and compliance, highlighting that Cyclone DX represents a mix of existing SDLC and software asset management lifecycles.
Throughout their conversation, Viktor asks insightful questions, delving into topics such as best practices around producing and consuming multiple SBOMs. Steve highlights that there’s no one-size-fits-all solution, but rather a need for flexibility in approaching software security and compliance.
As they wrap up their discussion, Steve mentions Project Koala, which is using a similar approach to Cyclone DX. He encourages listeners to join the community work, highlighting that it’s free for anyone to participate. Viktor shares his enthusiasm for the project, emphasizing the potential for standardized SBOMs to transform the way we communicate software information.
Overall, this episode of Nerding Out With Viktor offers a thought-provoking conversation on the future of software security and compliance, showcasing Steve Springett’s expertise and vision for a more standardized approach. As listeners tune in, they’ll gain valuable insights into the importance of standardization in software communication, the challenges and opportunities surrounding multiple SBOMs, and the innovative approaches being taken by industry leaders like Steve Springett.
Key topics covered:
- Steve Springett’s journey into SBOM and Cyclone DX
- Differences between CycloneDX and SPDX
- The role of provenance in software supply chains
- The future of SBOMs and their importance in cybersecurity compliance
- Introduction to O-BOMs (Operational Bill of Materials) and how they expand the SBOM concept
If you’re working in software development, DevOps, or cybersecurity, this episode is packed with practical advice and forward-thinking insights on how SBOMs are reshaping the industry.
Transcript
Show/Hide Transcript
Before we dive into the show, I want to do a quick mention of a product that I've created called Spomify.
Spomify is an SBOM hub.
It integrates directly into your CI cd pipeline, so you can upload all your sboms straight into Spomify, and from there, you can share sboms with all your relevant stakeholders.
So check out [email protected].
and now onto the show.
Welcome back to another episode of Nerding out with Victor.
Today I have Steve Spriggit on the episode.
Welcome to the show, Steve.
Hey, Victor.
Thanks for having me.
Appreciate it.
Super excited to have you.
You're one of the most prominent figures in the Cyclone DX s bomb world.
So I'm really excited to kind of do almost like a follow up to my episode with Alan Friedman and kind of dive into more like applied s bombs, more so than s bombs in theory.
And we've our path run across such a few different things around the sbom world.
So we have a lot of grounds to cover.
So maybe a good starting point is you obviously have used Sbom for a long time in your day job, so maybe give a backstory like your day job and how you kind of started using SBOn for sbons for a thing.
Really?
Yeah.
Yeah.
No, thanks.
I don't know if prominent figure is.
I don't know how to take that.
That just means I have a target on my back at some point.
But no, I had a prior employer of mine.
We had some really basic requirements, right?
I had a requirement to track the inventory of things that were delivering to market.
And that thing that were most concerned about just because of the use cases that it was, you know, used in and who those customers were, was full stack.
Right?
It was a server appliance.
And so I had, you know, full stack requirements where I needed to track the.
All the individual hardware components.
Not going down to the, you know, resistor capacitor type level, but, you know, going down to maybe the mainboard type level, right.
What are the kind of cards that are in this system?
What is the firmware that's on this thing?
What is the operating system?
And the packages for that OS?
What is the application and the application libraries?
I had a need to track that entire thing, and what resulted in that was essentially the very first version of OAuth's dependency track.
It was horrible.
It was absolutely horrible.
But I hired an intern, and, you know, we kind of hashed it out because there was nothing on the market that really allowed me to do this.
Right.
You know, there wasn't even a file format that allowed me to do this, but I had this requirement, I couldn't say no.
So you had to invent something.
But that was around, sorry, this was around.
This is around 2012.
Okay, so this is twelve years ago, and I had been doing supply chain stuff before that, right.
I had gotten into physical supply chain starting in 2008.
I was working on, not on the specification itself, but one of the implementations, it was a specification called epedigree.
And epedigree was an EPC global standard that really tracked the inventory and the, how would you say all those raw materials eventually came to be pharmaceuticals, and where those pharmaceuticals were then delivered.
Right.
Who were the different parties in the supply chain?
What flowed to whom and in what form did that flow, right.
So it was capturing both the inventory as well as the time aspect of not quite time series.
But it was complicated enough, which is actually one of the reasons why that specification failed.
It was really complicated and I learned a tremendous amount from that experience because I basically learned what works and what doesn't when developing a spec.
Right.
The state of California and the state of Florida at the time were the only states that really did it, and it was too bloody expensive for them to keep doing it.
Right.
The, you know, the manufacturing industry in pharmaceuticals, they push back, and rightfully so, because it was way too costly for them to do it.
And anyway, so I had some experience doing some supply chain stuff.
So when I was asked to do this task back in 2012, you know, I kind of knew what I needed to do and what I needed to stay away from.
And so that was good.
That kind of gave me a good starting point.
But basically what I did in 2012 with that full stack inventory eventually became the data model for dependency track, which that very first version was horrible, but it did the job, right?
It did.
Okay.
I maybe had a dozen users.
Right?
That's it.
Right, right.
And, but that data model kind of still exists today, and it exists in the, you know, the completely rewritten, you know, widely used dependency track, but it also exists in the cycle and the specification.
Right.
There's, there's a lot of synergies between these things because, you know, while we needed a portable format, these things were ultimately designed to work together, right.
A solution, not a specific solution, but a solution was designed to very easily work with the specification.
And so that's kind of the story of how I got into this and why.
And the s bomb community is certainly not perfect.
I know, NTIA started their effort in 2018.
I had no idea s bomb was a thing.
I mean, to me, why would you limit yourself to just software?
That doesn't make any sense to me.
But I posted an article on medium, like a couple of years ago, and I basically equated that to, like, the physical supply chain folks.
I think I equated it to, like, maybe an automobile manufacturer.
Right.
Having a bomb specific for, you know, carbon fiber parts and another bomb specific for the aluminum parts and another.
That doesn't make any sense.
Right, right, yeah.
And at the time, predating the whole, I guess, s bomb tipping point that happened around the executive order being announced, where everybody jumped on it.
Prior to that, like the googles of the world, they already have something equivalent to this internally.
Like all the really sophisticated tech shops, they had these inventory systems in house, right.
That were completely developed in house and did not adhere to any standard whatsoever.
Like, what kind of, like, were there any inspiration from that you drew from?
Or like, did you kind of work in the silo, or how did you think about that back in those days?
No, no.
That's a great point.
A lot of these tech firms, even my own one today, I mean, we have all this data.
It just wasn't in a standardized format and still isn't, and it's never going to be, which is kind of the point.
Now we can, which means that we can kind of spit out whatever format that exists today or in the future without issue.
For me, for my employer, that also includes all the services.
When we spit out an S bomb, you get the software, but you also get all the hundreds of services that you can optionally enable as well.
And other vendors that other software manufacturers that have an inventory of either software services, in some cases, hardware that they deliver to market.
Right.
Producing these types of bills and materials is relatively elementary.
Right.
It's just a matter of conforming to the whatever specification, assuming that specification can actually capture what it is that you want to communicate.
Yeah.
So, yeah, so, Cyclone Washington, one of the things I learned early on from that epedigree experience is that the perfect standard will eventually be too complex, too costly to implement.
I'll give you an example.
There was about a dozen or so valid use cases.
I had my entire team spend, I don't know, six, eight months developing hundreds of negative test cases, things that you can do with a spec that should never happen in real life.
That tells me that the specification is just too complex.
One of the things that we wanted to do with Cyclone early on, and we carry this philosophy today, is that we are not trying to create the perfect object model, because that will obviously be too costly, etcetera.
What we wanted to do was create a good enough object model whereby it is a little bit prescriptive and by which it would be a little bit more difficult for adopters to shoot themselves in the foot.
There's really only one way to do something in Cyclone DX, whatever it is that you want to do.
There's usually only one, maybe two ways to do something, and that's by design, that we wanted to limit the flexibility in order to save the users a bunch of hurt down the road.
At the same time, we really wanted the specification to be highly automatable.
Now, anything could be automated.
Right.
I can automate stuff all day, however, and I'm sure we're going to get into this in a bit, because I know you've been working on some of this stuff with some of the CiSA stuff, but I've never ever considered s bomb creation as a one time thing.
I consider it a process.
And when you consider it a process, you need lots and lots of really small tools that focus on really small things.
Maybe you're building an S bomb and maybe you need to enhance it with some information.
Well, I don't need that one little tool that does the enrichment to understand the entirety of the specification.
I just needed to concentrate on that one little aspect and that's what it was.
Cyclone.
It's like the Unix philosophy, right?
Do one thing I do well.
Right?
Right.
It could be chained together, and I think that's.
I merged myself in Sbomwell for the last eight months or so now.
And I think that's one of the huge difference between.
I don't want to get into the format war, but between SPDX and Cyclone DX is more pragmatic and easier to understand.
You can probably do things in SPDX that could not do in cycling DX, for instance, and probably vice versa too.
But the bar to get into it, to your point, is a lot lower with Cyclo DX, and it's just a JSON file.
Sure, a recipe can also be adjacent file, but it's a much more programmatic object rather than a JSON file, if that makes sense.
Yep.
Yep, absolutely.
I've read the entirety of the SPDX specification multiple times.
I know it very well.
Now, I have not done the same with SPDX three, but we actually consider SPDX three to be a competing bomb format.
SPDX two is not really that keep in mind that even though people can use it for such things, the NTIA effort that kicked this whole thing off, they didn't start with let's find out existing bills and materials formats.
That's not what they did.
What they did was let's figure out do formats exist that can meet our use case.
And there were three of those formats.
Obviously the worst example of misuse would be s wid.
Completely not designed for this.
It is by name software identity.
Right.
So can you misuse s wid four s bom?
Sure.
And you really have to stretch yourself to do that.
Not even part of the debate anymore.
It's not.
But at the same time, if you actually, and I would encourage folks to actually read SPDX version two because that's the most widely used specification.
Read it, read it, read the specification.
Truly understand the words that are on the page because you might have a little bit different perspective when you do.
Yeah, I mean they are.
I think they're coming from two philosophical, different approaches to solving that problem.
Right.
And I think that's, well, we can get into formats later, but I mean, I think the format in long run will probably be an implementation detail, hopefully.
Exactly.
I think we're going to be talking about exchanging and stuff like that later on.
And I do believe I agree with you.
If we're still arguing about formats in five years, we failed as an industry.
My opinion.
Yeah, yeah, absolutely.
So in your day job going back to like early days of s bombs and bringing that you started with, I presume you started with a pain point around security, I believe.
I mean that's dependency track does do licensing audit as well, but it's coming from the strong side of security audits.
Right.
So that was the actual business need you were trying to solve for.
It's like give me my entire stack, show me the cv's I'm affected by.
I presume that was the advantage you came correct.
Yeah, well, we had two requirements, again, because of the customers that were selling into, we first and foremost had to have an inventory of everything that were delivering.
That was use case number one.
And then once you actually have that inventory.
Yes, security was that secondary use case because we also had additional requirements on informing those customers on any kind of vulnerabilities.
And then of course when we do, you know, that starts the whole stopwatch.
Right.
So there was some other use cases built on top of that.
But yeah, licensing really wasn't too much of a concern for those customers at that time.
But yeah, s bombs obviously can be used for licensing as well.
One of the interesting things that I feel that kind of gets overlooked with licensing is that while most of us talk about licensing from, like, open source perspective, one of the really interesting things is that once you get a lot of really ingrained adoption in some large organizations, suddenly they actually care.
Depending on where they're located in the world, it might vary, but they care a lot about commercial licensing.
And, you know, tracking the type of license it is, whether it's per seat, per server, you know, if it's an embedded type of license, if it's a service, if it's a subscription.
Right.
What actually happens to that software when that subscription or license expires?
Well, that's no longer a legal thing.
That's a security thing.
If you look at the CIA triad now, availability is impacted.
So we're having a lot of folks voice interest in the commercial licensing support.
So we delivered that, like, a couple of.
Couple of versions ago in Cyclone DX.
Yeah.
I've been toying with quite a bit of these metadata elements in, well, both in cycling DX and SPDX.
And it is a complicated matter.
Right.
And it's kind of like you're getting into not only security, but also discoverability and inventory tracking.
So it's kind of like it's.
And that's.
We'll get into the whole O bomb structure later on, but it's kind of like, where do you draw the line between S bomb and when is an S bomb no longer an S bomb?
Right.
Because all of a sudden, are you tracking your network infrastructure, your clusters, in an S bomb?
Like, is that really the right toll for job?
And I know there are elements there.
So maybe.
Maybe that's a good kind of transition into the whole concept of O bombs, which, first time I discovered that, I was like, yeah, that just makes sense.
Right.
S bomb is just, like the starting point towards something much greater.
So maybe start with, like, laying out the foundation for what.
What's.
What's O bombs?
And, like, how do s bombs fit into that bigger picture?
Yeah.
So the.
Your s bomb for any given piece of software is essentially, well, it should be immutable.
It should never change for a version of a piece of software, that inventory doesn't change.
Now, if you apply a patch, if you update it, well, that's a new piece of software.
It's a new s bomb.
But your s bomb for a given version should not change.
Now, when that s bom is ultimately.
When that software is ultimately deployed somewhere, whether it's like an on prem server.
Whether it's in your Kubernetes cluster doesn't matter, right.
It's deployed somewhere.
Well now you have to take into consideration what is the configuration of that thing.
What other kind of environmental attributes do I need to take into consideration for that inventory, for example, I'll give you an example in the Java world just because, you know, even though folks love to harp on Java for being entirely verbose, and I will note disagree with that, it still is widely used in enterprise.
But I'll give you an example in Java.
Say for example, I get a web application from a vendor, well I deploy that thing maybe out to a Tomcat container or whatever it is.
Well Tomcat wasn't actually delivered by the vendor, right.
That thing, that runtime component, Tomcat and the JVM, well that's part of my stack as well.
So when I need to know vulnerabilities, well you know, so that's the addition part of the vulnerabilities.
Now the interesting thing about Obom, depending on the ecosystem that you're working in Java, let's take log four shell as an example.
Well if that same piece of software had a vulnerable version of log four j, I honestly don't need the vendor to patch anything.
There's a way in Java to say, well, here's my extended class path, I want you to use this thing first.
I can literally deploy fixed versions of log four j out to my entire enterprise and not actually have the vendors actually modify their R's or the wires or their R's, their web archives.
So that additional version of log four j that might be safe, that is now also now part of my inventory.
So essentially you have more of a fluid type of specification for representing the obom.
This, this is not a static thing, right.
This is a living breathing document because it could change day to day, hour to hour based on, you know, organizational need.
And then you can then tie that into the whole sauce bombs, ML bombs.
There's like, there's a whole like this diagram on the cycling Dx website about like how they all link together essentially.
And you have these reference like Vex files is not a good example of that.
That's like, it's not really part of the S bomb, but it's kind of referenced in S bomb.
So like maybe like how does your worldview look like assuming that s bombs do take off and that becomes like, which I think at least I'm very bullish on, it's gonna be the standard for anybody who's like security oriented, needs to meet any compliance.
Right.
That's gonna be the world that we live in.
Five years.
So now that we have S bombs, that's one big piece of the puzzle.
How do you see the next stepping stone from that?
Assuming we do have that, how would that world look like for you?
Ten years out?
Yeah, I think that ten year out perspective, I think, in my opinion, s bomb will be basically just, oh, well, of course you need that.
It's kind of like unit testing, right?
Yeah, of course.
Technology testing.
Right.
So, I mean, it's.
It's.
It's a new thing to the software industry.
Relatively new.
I mean, our hardware counterparts have been, parts have been doing that for 50 years.
Right.
It's, you know, it was very common in the.
In the 1970s, for example.
Right.
Just knowing what you have right now, the hardware world has some interesting things that we don't necessarily have to deal with.
So a lot of their maturity is kind of built around their reality, which is very different than ours.
For example, if they're delivering a specific model of maybe a router, right?
I guess you would say router.
You're delivering an electronic device to market that has software, and you might have a hardware component in that particular device that.
That maybe that supplier is out of.
So you have an alternative supplier that you haven't changed the model number, but technically, this is a different inventory than the one next to it because you ran out and you had replacement.
This happens in hardware all the time.
And I understand why the hardware folks don't want software in their stuff, because they've.
They've got processes that have been fully vetted, fully baked for many decades, and they don't want us.
Oh, with our s bombs coming around and mucking it up, I don't blame them.
But at the same time, I think it's increasingly important that we understand that software and s bomb is just one part of the equation.
And manufacturers specifically, like IoT devices, they should deliver h bombs.
They should deliver s bombs to market.
I believe in ten years, having services information will be just.
Well, of course you would.
I get questions all the time.
Even for the open source stuff like dependency track, organizations might want to lock it down and they come out with a list.
Well, what does it need to connect to so I can have my firewall guys ensure that.
Well, here's my services bomb for that.
Here's my bomb that has just the services information.
It has all the URL, the endpoint URL's, it has all the data classifications that directional flow of data in there.
This is everything your firewall guys need.
I mean that's beautiful.
Imagine you can plug this into your Kubernetes cluster and it does automatically provisioning all your routing rules, for instance, automatically.
And say if this service tries to talk to something else.
Well I know there are ways to define this in the Kubernetes world, but having agnostic format for this that can be pluggable, that describes.
These are the ways I need to talk to, and at least in my experience in my other company where network requirements for an IoT device is like a very frequent talking point in enterprise, they're like, okay, tell me exactly which ports this device on.
These endpoints these devices need to talk to because we need to open up our firewalls for this.
And the current solution for that in the IoT world is like well here's a wiki page, we will update that at some point.
We will try not to, but the reality is that we might need to change that.
But there's no dynamic discovery process of that at all.
Right?
Right, exactly.
Yeah, it's very static.
So you know, in ten years time, you know, I kind of see software and services kind of being.
Well of course you would.
Right.
Just part of what we do in developing software.
But hopefully in ten years time.
Right now, right now we have kind of a, I would describe the industry as just very immature.
We're trying to drive model t's down the Nurburgring.
We have a long way to go.
And what I predict or where I envision the industry going to is not having a bunch of these tools that kind of produce and generate s bombs.
Right.
That's if we're still there in ten years.
I think again, we've failed as an industry.
Where I see this going is kind of like you mentioned cloud a lot.
So I'll give you a cloud example.
In cloud you have this concept of observability, which is essentially looking at the real time performance of all your microservices across your entire deployment, right.
And trying to pinpoint things that are either going wrong or could go wrong, right?
Yeah, I believe that in order for us to do this right, we're essentially going to need some kind of observability layer on top of our existing build infrastructure that automatically starts doing this stuff for us, not just the generation of the bills and materials, but in some cases accounting for the deficiencies in some of our infrastructure as well.
Now I'll give you an example of the deficiencies right now.
If you sell to the us federal government.
Right.
SSDF is a hard requirement.
You have to do it.
And part of SSDF is providence.
And I'm not talking about salsa providence.
That's something entirely different.
I'm talking about actual provenance.
So knowing where your chain of custody, where you got something from.
Now, many organizations have like on prem, like repository servers, whether it's something like artifactory or nexus repo or one of the many others.
Right.
Well, the use of those repos speeds things up.
It also hides where you actually got something in many cases, because those repos are usually out of the box, set up as the easy button.
Right.
They proxy maven central, they proxy NPM, J s, they proxy pypod.
Did you actually get those components from there?
I don't know.
So part of that observability layer would be to account for some of the DNS changes that might happen.
Because if you get something from one mirror versus another, sometimes that matters.
Not always, but sometimes it does.
It accounts for things like, you know, organizations with local repository servers.
Right.
And not being able to track where the province actually lies.
So I think as an industry, that's something we need to get to eventually.
But I haven't seen any tools come around or any, or even any papers that I can kind of look at that kind of discuss this kind of challenge and possible ways to solve it.
But isn't that in part solved with hashes in the s bomb, like in the NTIA minimum elements, for instance, which kind of like considered somewhat of the gold standard for like what you should look like in theory, but only in reality, because it's really hard to do in reality, as it turns out.
But I, one of the things they call for is hashing all the dependencies.
So you say, well, here's my SHA 256 for this python package.
If I have that, assuming there is no collision in the SHA 256 hash, which is, I don't think there are any known ones because I don't think anybody uses MD five anymore.
You can, regardless where you procure that, you can trust that it is the file that you anticipate or a package anticipate to get.
So the repository where you retrieve it from is somewhat irrelevant, but I'm not sure.
Oh, okay.
I'll give you some examples.
So this has actually happened, and I can't tell you where it happened, but I know that it has occurred and it probably still is occurring to this day.
So some nation states have a very long tail long strategy, right?
In terms of getting into organizations not really doing anything that would suggest that they were in their networks, whatever.
One thing that I know many government agencies are interested in is, of course they're interested in Providence.
But it is possible, for example, for a nation state adversary to compromise your build infrastructure in a way where instead of resolving dependencies from your local repository server, you're resolving it from one of theirs that they control.
Now, they can control that repository server that you're fetching all your artifacts from.
And when you eventually need to upgrade those, first of all, now they have.
Now that nation state adversary has a complete list of not only the stuff that you have in your s bomb, but all the stuff that you use for testing, unit testing, integration testing, all the other things that you rely on that is not in your s bomb.
So first and foremost, right.
But when you eventually need to upgrade your components, when you upgrade that component, now it becomes a challenge.
They've got you.
So knowing where you actually get an artifact from is highly important.
Interesting.
Okay, that's an interesting attack vector.
Yeah, I haven't thought of that.
Yeah, that's fair enough.
Yeah.
And going back to what you said before about knowing what you have, and we kind of getting into service discovery, which is, I know, it's like Wally Gartner's buzzword they used, like a few years ago, like everything was about service discovery, blah.
And I feel like this has a potential to become like the future of service discovery, right?
A standardized, like, if SaaS bombs become a thing that the industry kind of backs, and I guess Cod native foundation, all those guys back get behind and support, then it could become like the de facto service discovery mechanism that describes all your classes, all your services, including external services, right?
Yeah, absolutely.
That's an interesting prospect, right?
Because then you tie it together to your s pumps, and now you start to have this, like, really beautiful map of what actually goes into your deliverables, right?
Yeah.
I think as an industry, we, the s bombs, a lot of the NTIA, and now the CISA framing for s bombs is really about sharing files.
But when we start talking about O bombs and SAS bombs and all these very dynamic things, right, my SAS bomb could change 50 times a day because maybe that's how many times I deployed to production, right?
These are very dynamic things.
So a file based approach is not what you want.
You actually want more of an API for these types of things.
100%.
That was one of the earliest beefs I had when I started getting to the world of sboms, where people really treated s bombs like as static elements.
And they are static in the sense, like, they are static for that particular revision of whatever you're doing.
But it's like, if you're a modern company, you can Google deploy, what, 10,000 times a day?
You got to email that file 10,000 times to your customers.
It doesn't work.
Right.
It's just completely unrealistic.
Right, right.
So getting into the whole, like, collaboration part of sboms, like, that was one of the most obvious things that I figured out when I started actually doing sboms at squidling in the real world, it's like, cool.
But if my customer asked for an S bomb, like, how am I going to share it with them?
Like the S bomb sharing primer from scisha.
Like, they call this out, what, two years ago?
And it's like.
And that has been very much reflected in conversation I have with cisos around the world.
Like, people are like, well, yeah, my vendors sent me sboms.
I chucked them into sharepoint.
Cool.
Now what?
So I think that gives us a really good transition into Project Wala, or the transparency exchange API, which you and Ola has been working on for quite some time that I'm kind of newcomer to, but I really like the idea of the project.
So maybe give a kind of a big primer or a little bit of a primer on what's project Walla and how does it solve the whole discovery and sharing element?
Yeah.
So Project Koala, which is also called the transparency exchange API, by the way, interesting fact.
Chris Gates.
Christopher Gates, who's big in the sbom world from the medical device.
Yeah.
Perspective.
Right?
We have this group within Cyclone DX called the Industry Working Group.
We've got a bunch of different working groups, right?
We've got feature working groups, a core working group, but we have an industry working group, and they're the ones that sometimes we get some really lofty ideas, and they're the ones that's, like, no ranging back, you know, they provide a lot of guardrails for us in some way.
Right.
They also provide us some opportunities, like, what kinds of things are they seeing in the real world?
So they provide feedback to us a lot.
And it was Christopher Gates who actually coined the term Project Koala, like, a couple of years ago, and it just kind of stuck.
He didn't think I would actually go forward and, like, actually do it, but now.
Now it's just kind of there.
It's cute.
It's.
Well, for the people who actually don't know Koalas in person, it's cute.
But it's essentially this effort.
It started initially for a Cyclone DX.
I don't want to say Cyclone DX only, but it was certainly geared more towards Cyclone.
And it was really intended to focus on that last mile.
I have an S bomb now.
What?
Because logging into 10,000 support portals in different ways to get S bombs for different versions of different software, that's not scalable, right.
If I have to hire an army of interns to do that.
We failed as an industry 100%.
Yeah, absolutely.
We're trying to work on that whole last mile.
How do we publish, how do we search, how do we retrieve these s bombs in a standardized way?
It has over the last couple of years that idea, which has been kind of percolating in our GitHub repository, which has largely remained unused until more recently.
We've been primarily working in Google Docs, but we've expanded that scope and our approach to that over the years.
We are, we recognize that.
And this kind of goes, I guess, with the evolution of cyclone itself.
Right?
Cyclone was never a NS bomb format.
Never was, never will be.
It was a full stack bills of materials format, but is now kind of morphing into a format for, or a way to represent software and system transparency.
That's really what it is.
It's a transparency expression language.
If you look at the capabilities of Cyclone DX, there is probably, if I had to guess, 60% of its capabilities actually have nothing to do with bills and materials.
And a lot of the stuff that we're doing in the next version also have nothing to do with bills and materials.
It's really about transparency.
And we wanted the API to be able to support these artifacts that kind of represent transparency, whether they're s bombs or different types of attestations, like legal attestations, not like the in total kind, but all these different types of things that you might want to share out with customers in a.
In a standardized kind of way where you can search and you can publish and search and retrieve these things not just automatically, but autonomously.
Because if we want to scale, right, if I'm a company and I have 10,000 vendors that I do business with, plugging in even the URL's 10,000 times, that's also a failure.
So we needed it to be as autonomous as humanly possible.
The other aspect of this is, and I'll probably get a lot of flack from, you know, maybe the federal government, whatever, but when you actually talk to organizations, either the software producers that are delivering bills and materials or the organizations that want to retrieve this type of information.
What they actually want has nothing to do with bills and materials, and nor do they want them, nor do they want to share them.
What we see in the market when I talk to companies is that they want very specific types of questions answered.
And if you think about, you brought up Vex earlier.
Right?
Well, think about how Vex works.
And for the folks that are listening to this who have what's Vex?
I'm vexed.
I'm going to give Alan so much heat for that.
I love Alan, but, yeah, horrible name for a thing.
But think about what you have to do for Vex, right?
You have to consume an S bomb.
You have to process it, then you have to, and that's going to turn on a bunch of lights.
And then you have to process this other thing that nobody is giving you today, nobody even has called a vex, which then turns the lights off.
And all the customers from all the different software vendors basically have to do the exact same thing over and over again.
That's also a failure in my mind.
Right.
Because now you have to have really complex tools on the consumption end and you have to have this additional level of transparency provided by the vendors just to be able to make ANy sense out of it.
What organizations really want is to ask questions such as, hey, are you using a vulnerable version of log four j?
Great.
Since I know that you're vulnerable.
What kind of things do I need to do as a workaround, right.
Or where I should need an sbom or a vex to do that?
So we've built in this concept into koala called insights, which allows for this limited transparency option.
So if you want to, for example, provide a list of inventory, but maybe not the full inventory, or if you want to provide vulnerability information, but not all of it.
This is a way for organizations to do this limited transparency use case.
It makes asking and answering the questions much more useful, much more expedient.
You can automate this stuff all day and it ultimately makes the lawyers happy, which they, I mean, let's face it, they have a, many organizations have a problem with s bombs today.
And when it comes to Vex, here's my besides all the technical issues that we have with Vex today, including like, including even the, including some of the cost effects because nobody's really talking about the cost of that today.
You have some challenges in terms of now your development team, who's sitting close to that code, is now responsible for essentially doing the type of messaging out to customers that historically a p Cert team would do.
If I'm auditing my code base and I'm saying, oh, that's not exploitable because of this.
Yes.
Those types of statements from your development team now go out to your customers, which usually involve legal, usually involve PCERT.
And now you're introducing some process into these organizations that they've never had before, which is a challenge.
But I think that, yeah, there's even a bigger one there, which is by, I think, I've had a conversation with cisos and people industry around their sports that I think one of the biggest reasons why many organizations are reluctant to s bombs is because they can no longer plead ignorant to the fact that they have security vulnerabilities.
Right.
As long as you have no hard evidence for the fact that, you know, you have vulnerabilities in your codebase, you can like, oh, I didn't know that as a SISo, the second you have an s bomb for your entire organization.
Kind of hard to.
Right.
Absolutely.
Yeah, I think that's kind of the point.
You know, if I had to guess why s bombs became a thing, it was.
It's probably because of breach fatigue.
Right.
People were JuST tired of libraries being vulnerable, not being updated.
This was a way to kind of force the industry to kind of grow uP.
Yes.
Which, you know, it has some growing pains, but, you know, some of the most challenging things about s bomb actually have nothing to do with, like, even vulnerabilities.
It really comes down to what the lawyers want to do BecauSE I've seen some really interesting perspectives from legal teams at different organizations.
I bet because you're exposing yourself to love of legal risk.
Right.
The second you expose that.
Right, exactly.
So I want to go back to, like, protocol in general because I think that's really interesting because I stumbled across protocol after I had kind of built Spotify for the same kind of solution, really.
And it was just a good mAp.
Like, we've BaSicallY come up with the same, I guess, not everything, but kind of the same building blocks, called them different things.
And I'm like, I aspire to become compatible with Project Koala because I think it's great to have it open.
But one thing you mentioned that you consider probably quality.
The last mile.
I don't think it's the last mile.
I think it's the building block in the middle.
It's the middleman.
It's the distribution transportation layer that is then consumed by the last piece, which is the analysis part.
So that could be dependence track that can be guac or insert blank proprietary analysis tool.
Right.
And so I think that by standardizing a framework around that, it will make communication.
I think in the SaISA documents they call it transportation, I think is the la, the word they use for it.
But having a standardized framework for that is a key building block for being able to actually execute the greater vision without this manual work.
Right.
So I think that's fantastic.
Yeah, exactly.
So we've, you know, we're taking an approach that's very, very similar to how we, you know, develop cyclone.
So for cyclone, basically we have, we spin up feature working groups that work on major features of whatever it is that we're trying to build.
Right now we've got three and.
No, actually we've got four feature working groups for Cyclone DX 1.7.
And they basically are essentially task groups.
They work on this big piece of work and they disband and we work on something else.
And ultimately it's all community driven.
And that eventually gets approved by a core working group, which are essentially the stewards of the specification.
I'm one of five now.
And then that gets promoted up to TC 54 within ECMA International, we're taking the exact same approach with Project Koala.
All the community work is happening now.
It's free for anyone to join.
Maybe we can post a link to that in the show notes.
So free for open for folks to join that community work will then feed into the efforts going for a TC 54 TG one, which is task group one within ECMA International, which there's a path to standardization.
And that's exactly what we're going for.
Because when I attend these things, I'm kind of wearing my OWasp hat, but I'm also wearing a little bit of my employer's hat as well, because commercial enterprise y type stuff.
Lots of different ways that we can share this information and trying to figure out ways that we can get like all these disparate systems, dependency track s bomify, you know, all these different things.
To ultimately communicate autonomously in the future is kind of the end reason.
That's where we want to, that's where we want to be, right?
Absolutely.
Do you see a world where the big cloud vendors would just adopt the standard as part of their, like, is it the new s three, like for block story?
Like is how do you like now?
Because that would be like one big play, right, of actually having mainstream option there if it's an open standard.
now that's that's really cool.
Like one thing I think is interesting, kind of going with a way from the price quality, but going into something I just remember that you mentioned earlier is the whole thing of like separation of responsibilities in sboms.
And I'm probably considered kind of a purist in the sense of deciding sbons.
You see a lot of people doing an SBOM for an entire thing.
Here's my service, and it has one sbom.
But in the concept, in Cyclone DX, you have a concept of different types of sboms.
Like you have a container SBOM, you have an application SBom, and they can't be combined into one document.
So they are, even in a very small deployment, you end up with many S bombs.
Right.
Like how, what triggered that thought was what you're saying about the Java application.
Like you have one for a runtime, one for the actual application.
How do you see the best practice around that today?
Whatever is the simplest way to produce and consume those, should I be used?
Cyclone DX has this concept of life cycles, and it's built into the specification and lifecycles in Cyclone DX very closely represent both SDLC and software asset management lifecycles.
So these are things that either development shops or I enterprise it organizations use today, right?
We didn't invent a new kind of thing, so it mixes well with the vocabulary that developers and folks in ITAM and SAm already use.
And I view Cyclone DX.
Cyclone DX can represent all kinds of things, hardware, software, containers, services, it can represent it all.
And if you want to put all of that into a single bomb, fine.
There's plenty of organizations that do that.
If it's easier for you to separate it out and make everything linkable, fine.
You can do that as well.
On the consumption side, it makes things a little bit more challenging when you do that.
On the creation side, it's usually a little bit easier.
But if you take a few steps, if you take those additional steps, you can get an entire deployment represented in a single bills of materials.
It's not only difficult to do.
What you probably shouldn't do is represent all of your like SAS bomb type stuff or all of your services and your interdependencies of services along with the inventory of those services.
That's kind of, that's crossing the line in my view, not just from a idealistic perspective, but ultimately you're going to want to share this information.
And if I'm a cloud vendor, I am not going to give you the inventory of things that are in my microservices, it's not going to happen because that micro service that I have, maybe it gets stock quotes, maybe that's the service.
I've got ten different versions of that thing in production at any given time.
Which version would you like?
Because I have no idea what version you're going to hit.
That's the reality of cloud.
I'm never going to give you that, but I will give you the services that are outwardly exposed to the consumers.
These things you need to, I think, understand maybe, and draw the line on what you're going to share and what you're not going to share.
So that kind of is the same approach that I take to operational bills and materials as well.
Here's my software.
This doesn't change.
I'm going to share that with you.
Here's my operational stuff on the back end, and you're not getting it.
So on that note, secure by design is another one of these initiatives that driving transparency in the supply chain.
And they are called for radical transparency, I think is the terminology that use in their document.
And you can interpret that in many ways.
One interpretation is, well, it should be including everything, including my internals, not just the firmware that goes on my device.
I saw my customer, but also what's sitting on the back end and what supported that back and even is not publicly exposed.
Right.
So how do you see that?
Because I feel like there is a push in the industry to kind of like take it all the way and have like, well, tell me everything that sits in your cluster, essentially.
I think that's a horrible idea, in my opinion.
I'm all for transparency.
Right.
I work in a standards body.
I develop standards.
We're open all the time.
We record meetings all the time.
I'm a big fan of transparency, but not at the expense of helping my adversaries do whatever it is that they want to do.
And ultimately, if you're too transparent, you are basically giving them the.
You're giving your adversaries the keys to the car along with a map on how to get there.
No, I think lawyers and everyone else will just say no.
And if the industry pushes too far and too hard in that approach, I think it's going to backfire on us.
Right.
We're going to, you know, we're going to have be set back quite a bit in terms of our transparency efforts.
If that idealistic view, you know, keeps on, you know, if they keep on beating their drum because it's.
It's going to be a big setback.
For us, there's some things that we just don't want to be transparent about and.
Yeah, how do you, I mean, executive order is another one that, I mean, for those not familiar, essentially if you're selling software to the government, you need to provide an S bomb.
It's the TL doctor.
But that's also a bit ambiguous.
Right.
Like what if I'm selling a SaaS service to the government?
What's their spom there?
Is it, where do you draw the line there?
Because it's kind of the same argument, but I'm not sure if you've seen anything, debates around that in the industry, like where do people draw the line?
And like, and also, I guess on the other side, like where would the government be happy?
Withdraw the line?
I'm not sure if you have any insights on that.
There was, for a little while, there was a services s bomb working group, and I don't think we, I mean, you can read the papers from CISA, they talk a little bit about services.
They talk a little bit about, there was one group that focused on including services in a traditional s bomb, which, yes, of course you should.
And then there was another group that was talking about just services, just like cloud native type of things.
And it started getting really complex because we started discussing things like, well, this is only available in this region because this customer is, it gets really complex.
What does an Sbom look like from a pure cloud perspective?
And I encourage folks to read the paper, but essentially we don't really have a clear, definitive thing where you can point to some resource and say, I want that.
We don't have a minimum elements for SAS bombs.
It doesn't exist.
There's obviously a lot of complexity.
The dynamicism of cloud, you know, adds to that complexity.
The fact that I might have canary builds and maybe ten different versions of some thing in production adds to that.
What version of that thing would you like?
Do you want all ten of them?
And when do you want the updates?
Do you want them 10,000 times a day?
Because something in my environment of 100 microservices, those things are, you know, all that are going to be updated all the time.
So I'm not going to give you 10,000 files a day.
Yeah.
So I don't know.
From my personal perspective, I believe that the industry should move forward with this concept of essentially tracking the outward bound services that these services that as a consumer I can directly interact with along with the data.
Now here's the thing about Sbom s Bom is s bomb became a thing because ultimately, it's your environment that you need to protect.
And in order to protect that environment, you kind of need to know what's running in it.
So if I've got a vulnerable version of, like, log four shell again, right, if I know that this thing has a vulnerable version of log four j, and I also know that maybe it connects to LDAP, well, now I can deploy some very specific WAF rules and put a WAF in that service with a WAF temporarily to reduce my risk while that vendor actually replaced.
So that s Bom provides me a lot of things that I can do to protect my organization and its data because it's running in my environment.
Now, when we talk about the cloud, that's not my environment, that's somebody else's.
And as a consumer of a cloud service, let's go back to a stock quotes example.
Maybe it's a thing where not only are you getting public stock quotes, but maybe you're getting all kinds of other personally identifyable financial information, right?
Maybe it's a whole suite of different services that I get, and ultimately, it's the outbound services that I consume, and it's the data that I care about, not necessarily the environment.
So the things that I care about dramatically change.
And in my opinion, that's kind of the conversation that, as an industry, we probably need to have, because it's the data that's most important.
Like what types of data are going to what services that way, if I know if that vendor has a breach, I have a pretty clear idea on what that impact is going to be, and especially as it relates to the type of data that I care about.
That's an interesting approach.
Yeah, definitely a lot more murky when you're talking about SaaS services rather than deploying on prem or like a hardware device.
Right.
And we kind of coming back to service discovery again and SBOM discovery almost full circle.
And one thing that I did find rather clever in Project Quad is the discovery process.
Right.
And mapping kind of like skews to our URL to DNS patterns, essentially.
So you could do discovery that way.
And I really like that example because it's like, I think Alan used the example of in the podcast I had Nomis.
Like, does he describe sbos like a recipe list for a physical product?
And that fits well into the analogy here, right?
Like, if you buy, like, here's a screening box, right?
Like, you can buy these and resellers, like they have a barcode, right?
If I scan that barcode, getting that spam is a pretty natural thing to do, right?
So I like that discovery because it's like it's tapping into something already exists.
Like everybody who does physical boxes, they have some kind of skew or some kind of like identifier.
Because I mean, if you do retail, you have to have that anyways.
So how you map it towards cloud is different.
Like aws, they have skews.
I guess in cloud managers, they have skews on the products.
I'm not sure there is a mapping there conversations around that have you thought about that at all?
Or.
That was one of the challenges that we had when were taught, when were, when we had that CISA working group for cloud is what is the identity of the services?
I mean, a URL is not identity because again, my URL might be a load balancer and there might be ten different versions of that microservices behind that load balancer URL, is not it.
So what is the identifier?
It's not package URL, it's not CPE, it's what is it?
I don't know.
It's hard.
So I don't have answer for that.
Yeah, no, it is one interesting one to make that work at scale.
All right, let's kind of running out of time, but I want to last kind of finish off with the state of dependency track today because I think next to Guac, which is like a new entry in the audit space, dependency track is kind of the OG in that space.
Maybe people who are not familiar with dependent track give them kind of like a state of affairs today.
How can it be used?
Why does it matter?
And how you see that?
Yeah, sure.
So dependency track is essentially almost like the reference implementation for how all the other entries in this market are kind of compared to essentially dependency track consumes and analyzes bills and materials and VACs VDRs.
It is used by tens of thousands of organizations, you know, some of the largest organizations in the world, governments of the world.
You rely on dependency track on a daily basis.
And it is, it connects to a lot of different sources of vulnerability intelligence.
You know, the free ones like the National Vulnerability Database, the freely available ones like OSB and OSS index.
And then it supports a few different commercial sources of vulnerability intelligence as well.
So you consume and analyze bills and materials.
It supports licensing and EPSS scores and a bunch of other things that you would need as either a development team to track, you know, your s bombs and the, the risk of that inventory over time, as well as in procurement.
Right.
If you're procuring software, you know, getting, you know, getting.
If you get an S bomb from, you know, a vendor, you know, put it in dependency track.
We did an informal poll.
Roughly 30% of users were using it for procurement use cases.
The other 70% were using it for purely development purposes.
The current state is that dependency track is old.
It is eleven years old, and it predates the executive order.
It predates s bomb being a thing.
Right.
It wasn't designed for s bomb.
It was designed for full stack inventory.
And it was designed so in a way where it's a monolith, it wasn't designed to scale.
So a lot of the work, and again, there's tens of thousands of organizations using it in production, but we are running into situations where some of the adopters, they want 100,000, we've got one that wants a million, we've got another one that wants 10 million s bombs.
This is the type of scale that we're trying to redesign for.
So we are currently working on project hiatus, which is kind of a, it's a.
Not a rewrite, but it's certainly a major reorganization and refactor of how dependency track internals actually work.
So that is, it is much more horizontally scalable.
And we've got, you know, you can roll it out yourself and test it today, but we've got just some users in pension track community that have already tested it, kind of in their own little environments.
They're getting upwards of 20,000s bombs being consumed per hour, and it's going well over 100,000s bombs today.
So I don't know if we've actually tested it to a million.
Getting a million s bombs is hard.
I mean, there's 60,000s bombs on Maven Central, right?
We can get those, but getting, you know, getting a million s bombs is, and making them, you know, kind of different is kind of challenging, but that's basically where it's going.
So it's with all this enterprise use, lots of organizations are starting to contribute to it, which is great if people want to contribute to it.
Again, it's an open source project.
It's freely available, you know, come and, you know, provide, you know, GitHub issues, provide feedback, no contribution is too small.
Documentation, you know, changes.
Yeah, are highly encouraged.
We need to update our docs, but.
Yeah, they're not that bad.
I read through them, they're not that bad.
I've seen a lot worse.
Yeah, yeah.
But docs, that docs can be challenging for any open source.
Yeah, but, and when people use the vetture track, do they tend to consume it over an API or do they tend to consume it as a web interface?
No, most of its usage is over APIs.
Think about how your build server might interact with other things that it does.
When you release software, it automatically deploys it.
Well in our case it automatically pushes things to dependency track.
That's how most organizations use it.
Now for the procurement use case, I know that some organizations have actually built it into their CMDB's.
So when they do procurement.
Right.
They do have some API integration to depends track.
But honestly I think most of the procurement use cases are going to be manual because there is that manual use case, right.
You can upload manually the SBOM.
In fact, you can actually author.
Yes.
Bomb manually if you want to using dependency track because that was going back to the original use case back in 2012.
There was no file formats that did what I needed it to do.
So I basically had a web interface that allowed me to manually add components that use case still exists because there's still a need for that today.
Right.
Interesting last question I have for you is how do you think the future generation of compliance framework would look like?
We saw NIST 2.0 came out earlier this year.
Stop just try.
Of mandating s bombs.
They call for transparency.
How do you see this?
When do you think we will see SBOM hard requirements for compliance?
Will the next ISO update?
Or how do you see that changing and what's your timeline for that?
That is a great question.
If I could get out my crystal ball, I would likely say because there's a lot more conservative countries out there, I would guess that within the next three years you're going to see s bomb as kind of a hard requirement to do business either in most world, major world governments or as a regulation.
If you look at PCI, it doesn't specifically like PCI 401 for example.
It doesn't specifically say sbom I think, but it does say software and services.
So the inventory of your services are required for PCI 4.0.
Right.
So I think some specifications, some industries, we're slowly getting there and I think that's okay, right.
Because getting there too quickly is going to be too much change for many organizations.
But I do, I think commend the us government for, I know they're kind of the 800 pound gorilla, right.
But I do kind of commend them for trying to work with a lot of our allies.
If you look at like the Quad, which is the United States, Japan, Australia, India, they're trying to line those folks on SSDF.
Right.
And if you go to like the.
It's not the ASD website, it's one of the other australian websites, but they refer to SSDF as well because again, these are NIST standards.
Right?
Yeah.
And I think they've been doing a lot of harmonization because the last thing software vendors want is if I'm selling to this region, well, I need this standard.
If I'm selling into this other country, I've got this.
That's too much.
Right.
It becomes too costly.
Organizations will eventually say no.
So I think the us government has been doing a phenomenal job trying to harmonize and get everybody on the same page, which is phenomenal.
That's what we want, to keep costs down.
And as part of that slow roll, I think you're going to start seeing more and more, either industry or regional regulations requiring transparency and SBam specifically become more popular over the next three years would be like us.
I think that's a reasonable guess.
I would agree with that as well.
And it's.
Yeah.
And I'm really happy that it hopefully will spam span, suck to nist, all those things.
Like, you don't have to redo the effort.
Right.
I think that's the key.
Like it could tick so many boxes in an automated way.
Yeah, absolutely.
Keep on fighting the good fight.
Yeah, no, I think it's fantastic.
I think it's.
I'm very bullish in S bombs and I think we'll get there and there will be hiccups along the way and lost speed bumps, but at least we are moving the wrong right direction.
So that's very exciting.
And as long as we learn from those mistakes going forward.
Right.
And not being too theoretical about it, I think that's one of the issues.
There are a lot of white papers out there saying how you should do things, but as long if there are no tools out there that will actually do them, they're not worth the paper they're written on.
So I think that's something that is changing.
Good.
Awesome.
Perfect.
Thank you so much, Steve, for coming on the show.
Very much.
Appreciate it.
Have a good one.
Thanks so much.
Cheers.
Cheers.
Bye.
Found an error or typo? File PR against this file or the transcript.