Josh chats with Allan Friedman about all things Bill of Materials. Allan did a ton of work to help turn SBOM into what it is today. He has many thoughts and ideas around the new types of BOMs, a concept he’s calling the OmniBOM. Allan is always fun to chat with and he brings a ton of knowledge and advice.

This episode is also available as a podcast, search for “Open Source Security” on your favorite podcast player.

Episode Transcript

Josh Bressers (00:00) Today, open source security talks to Allan Friedman. He’s known for being the godfather of SBOM and is a senior technical advisor at the Institute for Security and Technology and advises industry as technologist and residence at the TPO group. Allan is one of my absolute favorite people in the whole world. So welcome to the show, man.

Allan Friedman (00:18) Thanks Josh. Always fun to catch up.

Josh Bressers (00:20) Yeah, yeah. I mean, Allan and I were talking before we hit record. Like it’s been a minute since I’ve I’ve really chatted with Allan. So this is very exciting. So you are here because let me pull up your article. You wrote an article that, other than being very amusingly titled, it was was a lot of fun to read. It’s Dirk Gentley’s Holistic SBOM Agency and

I think you break down kind of a lot of what I’m seeing in the world of SBOM right now. And I will let you kind of introduce it and explain the concepts. But it’s it’s a lovely article. There’ll be a link in the show notes for anyone paying attention. But but yeah, I mean take it from here, Allan, you know, maybe tell us who you are and then tell us about your article.

Allan Friedman (00:57) sure. First, for anyone who does click that link, I think I have like an open paren or two and it’s one of the meanest things that you can do to an old school programmer, so I apologize. second, so I was a professor for a while and wasn’t very good at that, so I decided to become a Fed and ran one of the first

Government programs on coordinated vulnerability disclosure, which is not in the news at all, but most known for sort of

Not being the guy who invented SBOM, but being the guy who said, SBOM seems like a really good idea. We’re gonna start talking about it, and I’m not gonna shut up and go away until we start to implement this. And so we built out a great community at NTIA, which is a tiny part of the US Department of Commerce. and that also got buy-in and participation from some of our friends in governments around the world. And then we moved it over to CISA, which is the US Cybersecurity Agency, and built out a

Community. and then sadly CISA has a much more focused mission these days, a little more narrow, and so now I’m off in the world doing acts of supply chain goodness. but as we were in a lot of conversations around

What does the future of SBOM look like? And first, I’m guessing a lot of people have heard about this. the analogy of SBOM took. And first, SBOM was a stolen analogy itself, right? It was, hey, I have a manufacturing bill of materials to make a widget. I need to know all the parts in the widget. We should have that same idea for software, right? So

We have that idea, and then some people started to say, Well, I want to know more about other things in the systems. And so now we have cryptographic bills of materials. And we have hardware bill of materials, which is something that I’m trying to sort of help usher into the world. And for anyone watching, I’m I’m wearing the t-shirt live. and I

Josh Bressers (03:12) Yeah.

Allan Friedman (03:14) Just wrote a paper on AIBOMs, which people have been talking about for a while, because of course, how could AI and SBOM not inevitably collide? So all these conversations about BOMs And I’ve noticed there’s sort of two general trends, and one of them is to sort of make the case for what I’m sort of calling the OmniBOM yeah.

Josh Bressers (03:40) Which I love that term by the way, OmniBOM, like

delighted me when I read that.

Allan Friedman (03:45) It’s and and there’ve been some other names for a little while. our friends in the Pentagon for a little while, a couple years ago, were talling it an xBOM little X, big BOM and indeed I also want to point out that, you know, we’ve been the good folks in OWASP and the Linux Foundation have been talking about just BOMs for a while. But the question is

When is it helpful to think about one big glorious OmniBOM? And when does it still make sense to think of these as separate pillars that we need to think about? so the and and I was worried that as we go a little closer to the OmniBOM world.

we’re going to have some problems in actual implementation. And there’s there’s sort of good reasons to go both ways. And I sort of was banging my head around that. And so then I said, all right, we’re gonna write about the holistic SBOM agency and see what we can do with it.

Josh Bressers (05:02) So, I mean, let me ask you maybe a question to help clarify some of this. Okay. So you mention in your article this idea of there’s all this data and it’s all vaguely related in some meaningful way. I mean, we’ll we’ll pick on I’ll pick on H BOM and SBOMs, right? HBOMs hardware BOM, SBOM software BOM. And actually one of my favorite examples of this.

Is the FIPS 140, it’s now three certification, which is a cryptography certification, which I guess could also bring in the the crypto BOMs, but I’m I’m not good enough for this instance. But depending upon the various levels of certification you get, for example, they will tie, you know, there there’s rules about how the cryptography works and getting the cryptography certified. But then there’s additional levels that say we’re also certifying the hardware the software is running on top of, right? And now we’ve kind of

Inevitably linked the hardware and the software. And I know we don’t always necessarily think about that because like I have a laptop, it’s running Google Chrome, but the laptop is kind of irrelevant in in my perspective versus we have like IoT is a great example, right? Where the the hardware of an IoT device is generally like tied to the software in a way that the two can’t be separated. So they’re functionally one device, right?

Allan Friedman (06:19) You

are you are going to compile different versions for different architectures, even for you know servers.

Josh Bressers (06:27) Yeah, yeah, exactly,

exactly. So anyway, there’s this I there’s the OmniBOM idea where we we have to collect this information. But I think the thing I struggle with is while I feel like the OmniBOM is the inevitable outcome of all of this, you know, I work a lot with people doing SBOM things in, you know, in my day job at Anchore and I can tell you now that the industry has not figured out SBOMs yet, and SBOMs like the easiest one of all of these.

Allan Friedman (06:56) D no, you’re you’re exactly right, which is so often when I get in conversations around HBOMs or AIBOMs it is easy to forget that people who are hip-deep in SBOM land, either because they really want to know what’s in a piece of software, or slightly more often, the government has told them that they need to have one and

even with all the work we’ve done on specifications, we’ve still underspecified, it gets tricky. And so I I love the way you framed it about the eventuality, right? The long-term destination

Is going to be the OmniBOM. It’s going to be a system engineering approach. Because at the end of the day, whenever you’re talking about big, mature technology, especially the stuff that really matters in life, critical infrastructure, large, complex medical devices, data centers, right, you got everything in there. But

If we’re actually going to help people understand what they need to do today, how to go about doing it, and create a path of maturity, you know, in SBOM we always talked about crawl then rock, walk then run. That was a mantra that Josh Corman brought to it.

you it really does help to focus on the columns individually. And so I think that’s where I I still end up at the core is we need to have some discussions so that I know as I’m building out my capabilities, we have a shared vision. Now why is why is it important and and what are some lessons from SBOM?

One is just expectation management, right? I can’t give you everything. I don’t want to give you everything. And even if I did want to give you everything, it’s expensive to give you everything. So what do I actually have to give you? And this gave us the idea of the minimum elements. right, when when SBOM first ended up in US government regulation, and I’m

I’ll pat myself on the back a little bit for it. One of the requirements I baked into the rule was before we have the requirement that goes into effect, the US government is going to say what are the minimum elements. and then last year CISA wrote a draft of what new minimum elements look like because the technology got better. I was on a call today where someone even said, Hey, you were wrong, the technology isn’t better. Here’s

Why we can’t do that. but what else did that give us in addition to sort of the expectations? Well, it gave us a target for tooling. Now, organizations that said we’re doing it had a certain common threshold where they could compete on lots of other things. What makes Anchore different from other things? but

The core was going to be ideally the same. And even more importantly, at the other end, the people who are going to be using the data had a shared vision of what that data was going to be like. And we’ve seen that as there’s a rush to add features, both from the vendors.

And from our good friends in the CycloneDX and the SPDX community who want to create new features. We don’t always have a clear idea of wait, are we making sure that you and I are implementing these features the same way? Because if we’re not, then it doesn’t matter how cool and shiny they are, we’re gonna have a hard time using them. and, you know, in AIBOM land,

We y you see a lot of that, where right there’s some stuff that we know is reasonably well structured. I heard a a great line today. it it’s not unstructured data, it’s just poetry. It’s metadata poetry.

Josh Bressers (11:38) Goodness, that’s brilliant.

Allan Friedman (11:40) So maybe our LLMs will be able to parse all of this, but non-deterministic parsing for risk analysis is always little dangerous. And so that’s where I sort of return back to the idea that thinking about these things in a specific context with a specific audience will be really helpful. I also want to sort of I don’t want to paint the

the people pushing for OmniBOM into a corner, right? They’re they’re they’re not idiots. there’s been one the there’s sort of a vision of profiles where they say yes we’re gonna keep all the data in a large collection and there are two basic visions. one of them is a very large graph that contains all the data and so you can have all sorts of different properties. It’s not just

flat JSON fields. So graphs are much more powerful than databases. And the other approach is it’s a little related, is to have a queryable collection. So this is some cool work that OWASP is doing around the transparency exchange API. And they’re building it to work with both CycloneDX and SPDX where, hey

I don’t care about the data. I care about answering questions and the again the long term vision is to say, you know, do you have anything by evil company X? Do you have something on list of badness Y? and that’s where we’re trying to get to.

Josh Bressers (13:27) Yeah, right, right, right. And I’m will say very sympathetic to your statement about, you know, the the I I I had I I won’t say OmniBOM folks, but the like SPDX and CycloneDX crew are forging ahead at I’ll say breakneck speed. And like one of the challenges we had with the Syft open source scanner is everyone was saying, we want SPDX three point support or I think it was CycloneDX one point six

I believe was a version, right? But it’s a Go application, and there were no guy Go libraries from the upstream for this. It’s like, and then they’re releasing the next version. It’s like, come on, help us out here. Throw us a bone. And I mean, I mean, in our instance, like Syft ended up writing a a huge part of the SPDX three point Go library because like we needed it. And don’t get me wrong, like that’s how open source is supposed to work and all that jazz. But like at the same time, it’s like we are a very small project, like we are carrying a lot of water.

Allan Friedman (14:08) And and you know I’ve been

I

agree. And f anyone who’s been in any aspect of the security standards world sort of knows that this is kind of how it works, which is right it’s it’s it one of these unfortunate truisms, the same way that people yell at policymakers and say the people who write the regs should be required to comply with them.

Right, you gotta spend a year actually filling out the paperwork that you’re making people write. And the same is true for technical standards, right? It’s the wouldn’t it be great if we could have this? Or this is a very elegant solution to this problem. And then you go to people designing and say, No, it turns out that if your use case is all software on the planet or all microelectronics on the planet.

You’re gonna have a lot of edge cases. It’s gonna be mostly edge case to a nearest approximation. And so that’s where having an iterative approach is important. But you know it

Iteration is hard when you’re doing regulation. I’ve had a hard time convincing the American government of that approach, let alone going over to talk to Europeans and say, all right, this was great, but what if you just every two years had a whole discussion about writing new security policy? Like, no, no, we’re we’re gonna do it now, and that’ll be good for the next eight years. Like, you know, technology’s

Gonna change a little bit.

Josh Bressers (16:07) I it doesn’t

change a little bit. It’s so one of the things, so we I mean we mentioned this before we hit record is just like the the volume of change and and everything going on over the last like probably six to ten months has been unlike anything I’ve ever seen before. And there I mean there are things we were talking about in the SBOM world a couple months ago that I feel like don’t even matter anymore. Just it’s

It’s un I I I can’t fathom how the policymakers hope to even possibly keep any of this in order.

Allan Friedman (16:41) So so we’re gonna veer into if an agent writes all my code, do I need an SBOM anymore? and I don’t know if you wanna wander down that path. I think the even in the last few months that story has changed, right? Because it has become clear that no, your agent is not gonna write a monolithic application from scratch.

Yes, your agent is going to pull in things and yes, there’ll probably be a lot more code written. Right? We know in absolute terms there’s unreal amount of code being written today. But

You’re still going to want to need to know and track it and be able to say, wait, hang on a second. The thing that you know Susan’s agent wrote last month, that then you know Bob’s agent rewrote, except for this container over here, we should know where that is. So you’re still going to need to track.

a lot of versioning, just now it’s going to be a lot of things that you wrote and that someone it’s going to be, you know, is gonna really get in trouble if you can’t find.

Josh Bressers (17:56) Yeah. So I I actually have a question for you that I do not know the answer to necessarily. And I don’t even this might be out of the scope of like the SBOM world is so speaking of agents, right, is there are people I’ve I’ve had like serious people make comments like, the agent I don’t need open source dependencies anymore. The agent’s just going to write the software for me, which is of course a ridiculous statement for a bunch of reasons, but the one I want to focus on is so

If you tell an agent, I need an HTTP library, it’s probably just gonna output a whole bunch of code that’s actually from curl, because that’s one of the things they really like to do. And I I I feel like in the SBOM world, do we account for an instance like that? I I actually don’t know the answer to that.

Allan Friedman (18:38) So the the this actually is one of these everything old is new again. One of the earlier products or product features in pre SBOM source composition analysis tools was snippets.

Josh Bressers (18:46) Yeah.

Allan Friedman (18:59) Which is I need to make sure that you didn’t copy paste something that belonged to someone else into it. Right? If you if a developer just said, I know I can’t import GPL code, but what if I just copy-pasted this function? Wouldn’t that be great? And traditionally, American companies have just YOLO’d on open source license or obligations, but

A lot of companies around the world, especially in Europe and Japan, took their open source licensing obligations very seriously and wanted that feature. And so I think we can now detect that. And even more importantly, you can even do patterns, right? You don’t have to do absolute string matching. One thing LLMs can say is: all right, is there any general functional structure that looks like

an outdated corner of spring in this that was pulled in and now I unknowingly have vestigial code that I would have refactored years ago if I’d known about it. So what that also does mean is now we’re moving away from easy to use open source tooling and

If you are the sort of person who’s caring about that, that may be a feature that I haven’t done the legwork to find out if there are open source SBOM tools out there that can do that kind of fine-grained analysis. But I do know that there are a couple of commercial proprietary ones that are leaning into that as an idea.

Josh Bressers (20:41) Yeah, yeah. I mean, I remember that from I mean, my early days at Red Hat, that was like a huge thing is people were obsessed. My favorite was always because it was Red Hat and it was all open source. They’d be like, Do you have any open source code in your product? We’re like, our product is literally open source code. Like yes to all these questions, just yes.

Allan Friedman (20:54) Ha ha

and and I had a lot of fun talking to the SCA vendors because one, yeah, the open source licensing pays the bills, but the stuff that made for fun war stories is you just copied and pasted the worst part of the Stack Overflow response into prod and you know, here we are.

Josh Bressers (21:23) Yeah. yeah. Yeah. I mean, in my favorite the the other interesting thing, most people don’t even know about that is a Stack Overflow started applying the Apache two license to their code eventually, but for many years there was no license on the Stack Overflow content, which technically means it’s all rights reserved for you are so you’re violating someone’s copyright if you’re using that code.

Allan Friedman (21:45) But was it stack overflows? Was it the original posters? It’s the why I’m glad I’m not an IP lawyer. and and and by the way, this is all now again folding back into not just

Josh Bressers (21:52) That’s a good question too. There’s yeah.

Allan Friedman (22:01) traditional applications, but now my AI system has a lot more software around it. And so we’re bumping into some fun challenges there of okay, I need to track the software, where did it come from? but also what’s the boundary around what I have to scope in this space? And you know we were talking in the beginning about how SBOM is not

Settled. It’s one of those little embarrassing secrets. One of the bigger challenges is how do I draw a box around my product? if it’s software as a service, sitting on someone’s infrastructure. I remember early on I had a high assurance government customer who said, I want to know down to the load balancer.

And I’m like, well one

which load balancer, right? There, you know, the the application owner probably doesn’t know your infrastructure load balancer. but also too, what do what are you gonna do with that data? and that’s where you want that vision of saying, okay, in this context, whether we call it just an SBOM or whether we call it an SBOM profile

We need to say this is the type of data I can have, and this is what I can do with it. And and that also gets me to sort of the last piece of the BOM world that’s still unfinished, which is we aren’t using this data well enough. We are generating a wonderful amount of transparency data. It is better for the ecosystem.

right, if for no other reason I want everyone who makes software or cryptographic products or hardware, microelectronics, or AI systems, to actually know what’s in their bloody code, what’s in their bloody systems, right? Don’t sell something especially to a high assurance world if you don’t know what’s in it. But then, hey, guess what?

The people who care about risk also have obligations to manage the risk, the users of the technology, and we haven’t done a good enough job of empowering them to use that data. I’m gonna put I’m gonna lay the blame at the security vendors because it’s always fun to kick security vendors. you know, I don’t know why vulnerability management software didn’t start to say early on we’re gonna integrate SBOM data.

Why is there only one asset management tool out there that can ingest SBOM data? and as we move into right, all your AIBOM compliance and your AI risk posture tools, let’s start to automatically hoover that data in. Will it be the complete be-all-end-all? No. But it’s data that shouldn’t form dashboards, it shouldn’t form decision making, it shouldn’t form procurement.

Right? Anything you can do to convince a sales engineer that they need to go to the product team and make some security changes is gonna make the world better. and the way that happens is you start to write it in procurement docs, and contracts.

Josh Bressers (25:43) Yes. So actually it’s funny you say that because I had I was at a a conference and I was speaking with someone from Boeing and they were saying how like they’re trying to get actually I’m gonna say that again because I don’t want to throw Boeing under the bus. I was recently at a conference where I was speaking with someone who works for a an aircraft manufacturer and they were saying how they’re trying to get SBOMs from their suppliers and they’re struggling to do it, and their suppliers are just saying no

Allan Friedman (25:43) And yeah.

Josh Bressers (26:09) And yeah, this is obviously one of those situations where it’s like it’s not in the contract, we’re not giving it to you. Whereas obviously in the future it’s going to be in the contract, so you’re going to have to give it to them. But yeah, I mean it I so kind of to address your question about why aren’t people adding this to their products and blaming security vendors and all that, I am seeing the tide start to turn. I am seeing organizations requesting SBOMs in contract language. I am seeing security vendors adding SBOMs. You know, as a company that makes an SBOM product, it was

convenient when no one else was making an SBOM product and now we’re we’re seeing more and more of that on the market. So but it’s good obviously ‘cause competition just makes everything better, I think. But yeah, so like I feel like there’s some hope there.

Allan Friedman (26:50) I think so. And I one of the things that I’m the most proud of in sort of the SBOM movement was the creation of all of these companies and startups and open source tools that were trying to meet this need. A bunch of people said, Yeah, this is good. Let’s go and, you know, get other people’s money and my hard-earned labor and and spend time focusing on it. the

Fun thing has also been to watch that evolve, right? Everyone said, no one pays for SBOMs What do people pay for? Well, they pay for risk management, they pay for compliance, they pay for broader security, and SBOMs contribute to all of those, and AIBOMs are gonna contribute to all those, and your hardware inventories are gonna contribute to all of those, right? Hey,

Am I so on the hardware side of things, just to sort of show you that there all this stuff is moving forward, US Congress passed a law almost three years ago now that said that the US government cannot buy anything from a contract if in the fulfillment of that contract the company used

Any microchips from the largest semiconductor manufacturer in China, the largest DRAM manufacturer in China, and the largest flash memory manufacturer in China. And for high for important contracts, it’s not even just the physical stuff that you give, it’s anywhere in that.

We don’t know how to do that today. And right now, compliance for that looks like pinky swear. You have to make a re the the regulatory line is reasonable inquiry. So I’m spending a lot of time trying to sort of build momentum around HBOM

What I don’t think is the best path forward for that is to have a whole bunch of conversations at the same time about every other part of the system. And I d and I’m not saying that people are trying to do that, but I’m saying that the path forward, the most efficient way to build an ecosystem around a specific type of transparency, is to frame it around that. And the same thing is true for AI.

Right? I need know what’s in an AI system. Let’s start with the basics. It’s gonna look familiar to anyone who knows SBOM. In addition to all the software and all the harnesses, what’s the model? What was the fine-tuning for the model? Track the long-term providence of that. What’s the data? How has that data changed? And then building out what that looks like, and then we can slowly roll that into.

A system that goes into my giant data center that has all of the application layer logic, all the AI logic, all of the hardware data, and we can start to pull it all together. I think you know, going back to what you’re saying, the omnibalm is the right direction, but I think it’s helpful if we sort of split up into forging some unique paths.

So we have the muscle memory for very particular uses, whether it’s right tracking what cryptographic assets I have in a system, so I can do post-quantum transition or so on.

Josh Bressers (30:49) Yeah, yeah. And I I think you mentioned something that cannot be understated and it’s around the regulation behind this is

In my younger days, I had this we’ll say hope that people would do security ‘cause it was the right thing to do, or people would do SBOMs cause it was the right thing to do. And I’ll tell you now, unless there’s regulation, it’s not gonna happen.

Allan Friedman (31:18) So and I think the the the the

The paper I wrote sort of walks through what that regulatory model would look like, for AI in particular, and says, Okay, how do you solve this chicken and egg problem where we don’t have it, so no one’s asking, no one’s asked so we don’t have it? And the paper is about looking at the supply chain and the demand side at the supply side and the demand side at this at the same time. So you’ve gotta make it easy for people to give it to you and you’ve gotta have some well worn patterns for how to ask for it.

Josh Bressers (31:28) Thanks.

Yeah. Yeah.

Allan Friedman (31:53) But I think

you can go a little deeper. I I had the good fortune of working with a guy at MIT named David Clark, who’s sort of in the top 20 people who invented the internet, and he’s just an incredibly smart, incredibly kind, and he’s a wise man. His his office door plaque just says Dumbledore. He’s he’s that kind of engineer.

And he has this concept called tussle space that he first applied to internet architecture as it was being built out, which is you want to limit the number of things that are affected by any given engineering decision. And so if we’re trying to sort out this stuff, and we are, like we’re building the plane while flying it. by the way.

Side note on that. Did you know that building the plane while flying it used to be a bad thing? It was it was disparaging. Well, it the the exactly, but it in the in the late 90s, it became a good thing. Like this is one of the rhetorical acts of rhetorical violence from Silicon Valley. is like, yeah, we’re gonna we’re gonna.

Josh Bressers (33:01) Wait, d well yeah, obviously. I’m not getting on that plane.

Allan Friedman (33:21) We’re gonna be airborne before you remember that the ground is far below you. tussle space is the idea that when you change one thing, you want to minimize the other things that you’re going to affect. So if we’re going to mature AIBOM or we’re gonna mature H-bomb one step, we wanna not screw with all the other pieces that are in our supply chain transparency architecture. Or if we say,

Hey, we didn’t used to be worried about this risk, right? All of a sudden, Josh does a weekend project and discovers that it turns out that code comes in multiple colors, and that purple code is really bad for security. And everyone’s got to go find purple code. That’s a new risk, we’re gonna have to figure it out, but let’s not try to break everything else while we’re figuring it out.

Josh Bressers (34:18) Yeah, yeah. I mean that makes a lot of sense. That’s I literally had this discussion two hours before we hit record about we have to make small iterative changes to this. We can’t go all in, which is it’s it’s but it’s easy to say, but it’s also hard to implement sometimes. So

Allan Friedman (34:36) It it it’s easy

to say it’s hard to do and it’s hard to do for different reasons for both engineering and policy. policy you only get a certain window to address a problem, right? Congress isn’t excited to say, Wait, didn’t we talk about this nine months ago? Why are you asking me about this again? Like if we didn’t solve it then, why did you let me vote on a thing? And in engineering, right, it’s you get money for big shiny.

and also repeatedly changing things underneath, as we’ve learned with I don’t know, patch bot and update bot or dependabot rather, gets a little frustrating sometimes. And so you know, working through on that side of things.

Josh Bressers (35:26) Agreed. All right, Allan. It’s time to I guess hi ironically I’m gonna say it’s time to land this plane, which we’re apparently building as we fly. But tell the listeners what kind of what are the next steps? What should we go pay attention to? What should we go look at? Obviously reading your AI paper, which link in the show notes will be part of that story. But what what’s next, man?

Allan Friedman (35:46) I so one is just figuring out the corner of the ecosystem that you’re excited about. and the cool thing is lot of great communities out there for SBOM. If you’re interested in HBOM hbom.tech if you’re interested in cryptographic bill of materials, I should have a resource to point you to. We’ll put it in the show notes. so there is a lot of cool work that’s happening out there already today. and of course,

Love for our friends in the OWASP CycloneDX projects and the Linux Foundation SPDX project. They are doing great work. what they do need are people who are implementing things who can say, maybe that new field that sounds really cool is actually gonna be hard to implement in practice. So we can do sort of some phased-in modularity based on what’s really useful, what’s available.

and what’s replicable, what we can actually duplicate across different implementations.

Josh Bressers (36:49) Yeah, yeah, that that’s great. And for what it’s worth, both SPDX and CycloneDX, OpenSSF, Linux Foundation, OWASP, they’re very receptive to people just like just show up and help out. Like you don’t need permission, you don’t need to go, you know, sign up to some fan club or something like that. Just show up and help. And they love it.

Allan Friedman (37:08) The one of the things that I don’t think we’ll people in Washington understand nearly enough is that open source radically changed how tech policy is done. because it just became a, now we can just build things and then say this is a thing we built, this is now part of our infrastructure, and it’s gonna make our infrastructure better. And and that’s traditionally policy discussions haven’t been that accessible, so that’s a cool side of it.

Josh Bressers (37:38) Interesting. I hadn’t I didn’t consider that. That’s a topic for another day, perhaps. All right, Allan. It’s been fun, man. Thank you so much.

Allan Friedman (37:40) We’ll talk about that next time. Yeah.

Always great to chat, Josh.

Josh Bressers (37:48) Until next time, my friend.

All right, I will hit stop. That was fine.