Links

• LinkedIn: David Pollak
• LinkedIn: Allan Friedman
• spicelabs.io
• hbom.tech
• Mastodon: @dpp
• Mastodon: @[email protected]
• Bluesky: @dpp.me
• Bluesky: @allanfriedman.bsky.social

Transcript

Kate Holterhoff (00:04)
Hello and welcome to this Monkcast Conversation. My name is Kate Holterhoff, senior analyst at RedMonk. I am so excited to have two guests with me here today. first off, we have David Pollak, who’s a founder and CEO of Spice Labs, and also have Allan Friedman here. He is a technologist in residence at TPO Group, senior technical advisor at the Institute for Security and Technology, and he’s also an advisor to Spice Labs. Allan and David, thanks so much for joining me.

David Pollak (00:31)
Awesome to be here.

Kate Holterhoff (00:32)
Well, we are going to be having an excellent conversation on some of my favorite topics lately, things that have been coming up a lot in terms of RedMonk conversations, and that has to do with post-quantum cryptography and security. So excited to dig in here. I guess I’d I’d want to set the stage just with like a a a state of what’s going on and and also just kind of getting to know you both a little bit here. So maybe Allan, would you start us out here? I gave the short version, but maybe could you talk to me a little bit about your background and and what it is that that your your day to day looks like. What is what is it that you actually do?

Allan Friedman (01:07)
Sure. so I’m a failed professor who got suckered in a joining government ten, twelve years ago. made the decision to leave CISA last year. but I’m I’m mostly known as the guy who wouldn’t shut up about SBOMs.

Kate Holterhoff (01:24)
Ha ha.

Allan Friedman (01:25)
if software supply chain is your thing, SBOMs are kind of my fault and I’m I’m sorry, slash you’re welcome depending on whether you have to implement them.

Or you just have better security because of them. And so these days I advise organizations around the world on software supply chain and do a lot of public policy trying to help make sure that we’re making progress and we’re harmonizing between all of the different efforts that we see as transparency becomes a critical part of security technology and security policy.

Kate Holterhoff (02:01)
Fantastic. man, so we have the the godfather of SBOMs himself joining us today to talk about all this. that’s great. David, how about you? I mean you’re you’re quite the known commodity at at RedMonk Functions here, so so what’s a a little bit of your background?

David Pollak (02:16)
Known commodity and I’m still invited back. I don’t know, you know. Yeah. I’ve been doing software development professionally for 48 years. Got my start when some idiot at FEMA gave me

gave a 14 year old a contract to write nuclear BOM damage estimation systems. And as part of this, I got invited to Langley, Virginia, where FEMA had their communication center and they showed me what I thought was the stupidest piece of technology I’d ever seen, which was this packet switch network called DARPAnet that could survive nuclear attacks.

Kate Holterhoff (02:56)
Wow.

David Pollak (02:56)
I don’t know whatever happened to it. Anyway, I’ve been doing.

Kate Holterhoff (02:59)
Yeah, interesting.

Hmm I wonder.

David Pollak (03:01)
a bunch of stuff

over the years. And in the early 2000s, I was VP of engineering and CTO at a security cybersecurity company very early in the days. And we built the first automated pen testing tools, Hailstorm, if anybody remembers it. And that kind of got me thinking about adversaries. And then I went to Cisco, worked in the firewall group for a while.

and then started collaborating with this crazy engineer at Cisco who was collaborating with a crazy engineer at Microsoft to apply the same mathematical equations that Git uses to both after build artifacts and to the whole supply chain. And Æva Black, who was the crazy Microsoft engineer went on to CISA was one of Alan’s peers.

made an intro and also other people made intros. And one day we had coffee in DC and have just been having a dialogue ever since. you know, the, the core piece of technology or the core piece of open source that my company has is something called Goat Rodeo, which is a euphemism for something that can’t be said on this podcast, but you can look it up in the urban dictionary.

Which I think describes the state, even after Mr. SBOM has done his magic of software supply chain and, you know, overall compute supply chain and, kind of getting back to the arc of my story throughout the time that we’ve been building computers and building the network and building everything else. We’ve always put usability first. We’ve always said we can glom on security.

And now we are at this sprawling thing that connects what 70 % of our species that is deeply insecure and deeply unknown. And that’s a problem because it impacts everybody or at least 70 % of everybody. And we got to start taking that seriously. so having a conversation like this, being able to bounce ideas off of Allan, off the monks.

is really important because this is a hard, hard problem. And figuring out not just the technical solution, but more importantly, the human solutions around it are important to us all. Anyway, that’s my intro and that’s why I’m here.

Kate Holterhoff (05:37)
I like that you gave us a little bit of an intro to what you do at Spice Labs as well, since since you are anticipating some of my my other questions here. okay, so we are we are setting the stage here for the fact that the supply chain is something that we’re gonna be chatting about in great detail. and I just wanna to add here that I mean there is just nothing more important going on today in our AI era than

try tr trying to lock down the supply chain. the security issue is is I mean, I feel like there’s a new news story. Every day I won’t I I won’t belabor the point, but I I I’m just thrilled that we’re we’re able to spend some time talking about this. So let’s begin with SBOMs before we move into some of the post quantum cryptography part of this. So Allan, I guess I what I would be most interested in is like how

Wh where are we at with SBOMs today in 2026? I mean, what conversations are you having around this? Like how has it it shifted and so like yeah, just maybe like a a state of SBOMs?

Allan Friedman (06:39)
Sure, state of SBOMs So and just briefly to some of David’s points, part of the way reason I got into it in my my early energy I’ve been talking I w wasn’t my idea, I was like very clear. People have

Kate Holterhoff (06:49)
Ha ha ha.

Allan Friedman (06:49)
been talking about it for a while. I just happened to have a giant American flag in the federal government behind me when we started some conversations, first voluntarily, and then we brought in some regulation. But a lot of my energy was just driven by that most powerful drug, righteous indignation, of

How dare you, expletive, explitive, expletive, have the nerve to sell to the US government, to critical infrastructure, to the national security system if you can’t tell me what’s in your bloody software. right, and it still shocks me to this day that people think that this is an odd request. I’m like, it is, we should all be embarrassed for other people if this is a hard problem.

So we’ve been talking about it now for a decade or longer, and we’ve made a lot of progress. there’s widespread awareness, there’s a fairly healthy

David Pollak (07:47)
and

Allan Friedman (07:49)
tooling system. in fact that tooling system has evolved. There were a bunch of commercial tools that were just for

David Pollak (07:53)
Thank

Allan Friedman (07:56)
SBOM, and all of those companies have now pivoted because they realize the point is not to have the SBOM, it’s to use the SBOM.

We understand that it’s part of basic hygiene. It’s not supposed to solve all of your problems, you know. I’ve been working with SBOMs for a decade. Not once has it picked up my dry cleaning. just you know everyone always complains, SBOM won’t solve all my problems. Like it’s not supposed to. and it’s being it’s it’s one of the places we see it really widely adopted is

David Pollak (08:20)
So,

Allan Friedman (08:28)
in the application security side of things. all modern tool chains

can give you track this data and give it to you. And in fact, it’s one of the few security policies where it’s much easier if you’re a smaller business. Because if you’re a small business, chances are you have a modern toolchain, you’ve got a fairly constrained set of products, and so this is something you can just fold in. Why is that important? Because we’re seeing in regulations around the world.

it started off in twenty twenty one.

As a requirement to sell to the US government. It started actually even before that for medical devices. The big thing that’s coming down the pike for all of us is if you want to sell into Europe. almost any digital good will have to have an SBOM by the Cyber Resilience Act. So we’re seeing a lot of things there. And we’ve learned some core lessons. So we know how to prioritize. Where, if you don’t have S-bombs for everything, what should you focus on as someone who uses software?

edge devices, right? It’s facing the internet. You absolutely need to know what’s inside it because scanners are just happening that fast. Similarly anything with very large pa long patch times. So if you’re using a system where you know

It’s going to be a while before anything can be updated, whether because it’s sitting, you know, in a field out in the middle of Kansas, or your vendor is not responsive, you need to know what’s in it. and if they won’t tell you, you need to find a way what’s in it. And then the last piece I always mention is a lot of us use software that is sold to us by companies that did not build it. Right?

Companies get bought, they get bought, they get bought, and now a software, a piece of software is not a living, useful, feature-rich tool. It’s a single profit line and a spreadsheet. No one cares about its maintenance. So it’s up to you to know what’s in it. So what don’t we have today about SBOM? What are some the big challenges? One, it’s quite embarrassing, it’s non-deterministic.

We always forget that even before we got into generative AI, LLMs, software with a few exceptions was non-deterministic. And that’s happened for all security tools, right? You throw two static analysis tools at a piece software, then give you different outputs. But it does mean that if you’re trying to compare things, it gets a little messier than we might want it to be. There’s varying quality.

Of different tools. Especially some of the older open source tools aren’t quite as thorough. And their mismatched definitions. This summer, SISTA

David Pollak (11:22)
you

Allan Friedman (11:23)
released a new international minimum elements to sort of define what an SBOM now should be seen as. I’m guessing we’ll talk about minimum elements more. and one of the key powers there is

We need to have a way so that when a government requires something, when something ends up in a contract, we are all on the same page. and then the last piece is now that I have it, what do I do with it? It’s one thing if it’s just folded into a feedback loop in a modern AppSec toolchain, but if I have a bunch of software running on my network.

we don’t have the tools that I would love to see that really exploit it. And for me, that means integrating SBOM into our existing security functions. Right? The third-party risk management before I buy something, all my vulnerability management, all my asset management, SBOM, right? These are tools that organizations already have, and SBOM just needs to be a part of that.

Kate Holterhoff (12:24)
Exhaustive. I love it. This is great. Okay. No, this is good. You had the the had the points there. the one thing that I was expecting you to say though was something about AIBOM. I mean that’s that’s been blowing up here. Is that part of the

Allan Friedman (12:34)
we’re

Kate Holterhoff (12:35)
conversation?

Allan Friedman (12:37)
it it

It definitely is. there are a couple of perspectives. We can dive more into it later, but the short

Kate Holterhoff (12:43)
Yeah.

Allan Friedman (12:44)
version is AI is software and more. So an AI system from the software needs to be tracked. but there are some unique things about our modern AI systems that we’re gonna need to think through, and some of it is gonna be a particular challenge, especially some of the ephemeral pieces and the dynamic pieces where tracking assets has resulted.

resisted the attempts of some very large venture backed companies. So trying to build a usable spec that we can all use, especially with an open source tool, is not impossible, but it’s gonna require some more work and some more collaboration.

Kate Holterhoff (13:23)
Okay, I like that. A little teaser because I I tell you what, I I hear this dropped pretty often in briefings, so I I I know it’s on folks’ mind. okay, but a AI, absolutely gonna be coming into this conversation quite a bit. we’re here to talk about cryptography so I I I next wanna ask you, David, about a very particular kind of of BOM here, right?

so talk to me about what is a cryptographic bill of materials, and why are you arguing that it’s so necessary?

David Pollak (13:53)
So we have a universe of BOMs, know, it’s kind of like the Marvel BOM universe.

Kate Holterhoff (14:01)
I like that.

David Pollak (14:03)
Why do we need different BOMs? And I think the answer is the same reason why you have different superheroes. They have different powers and they deal with different things in different ways. So the software build materials is a list of contents. And ideally it’s a transitive list of contents and super ideally it also picks up vendored in code and all the other stuff that happens in the real world.

When we start thinking about how and where our cryptography is used, it’s no longer about the libraries, or it’s no longer solely about the libraries. So if we think about a cryptographic bill of materials, one of the elements in there is, you have libraries that are capable of performing the cryptography that you need? Does library X have algorithm Y? That is an important part of the cryptographic bill of materials, but not the whole thing.

There are other elements in the cryptographic bill of materials that are different from a software bill of materials. One of which is what is a cryptographic material? So what are the search? What are the Java key stores? What are the, you you go down the list of all the different ways that we have trust baked into our systems. Or trust that’s informed, it enforced with math that’s baked into our systems.

What are the assertions or attributes of that math? What are the things that we have to look at? So I’ll give you a key thing and this riffs off of Alan’s talking about edge devices and OT devices. One set of OT devices is unmanned autonomous vehicles, UAVs. And we, especially in the military,

have been using, making increasing use of UAVs. UAVs have to get their commands from something that they trust. And they enforce that trust by evaluating a digital signature against a certificate that was embedded in the ROM in the UAVs system itself.

Every single edge device needs a cryptographic bill of materials. So you know what trust, what things the UAV trusts and jumping ahead a little bit. The way that cryptography is done, the public keys that are going to be the trust material are also now attack surfaces once there are capable quantum computers. the public.

key that everybody says it’s public, everybody should know it. You can validate blah, blah, blah against it is now an attack surface for the private key or it will become an attack surface within a few years. So knowing what those public keys are, knowing what the trust material is, is critical. there’s, know, let’s jump back to cryptographic bills of material. So one part of the CBOM is what are the libraries and are they capable of doing the cryptography?

The second part is what is the cryptographic material? And the third part is where are the cryptographic call sites in the application itself? Are you actually calling what you’re supposed to call? And as an asterisk on that, and can it be configured with a configuration file or do you need to recompile your software? So a good cryptographic build materials will tell you, you have the libraries or you don’t have the libraries.

Here’s the cryptographic material you have. have RSA 4096 certs. Great, they’re FIPS 140 compliant. Or you have RSA 1024 certs, which are not FIPS compliant. Okay, you want to know that. And finally, how is your application actually using the cryptography and can your application be adjusted based on the new cryptographic material that it may be seeing?

Sorry, was that a long prattle or did that answer your CBOM question?

Kate Holterhoff (18:15)
I think it’s pretty good. I I well what it’s making me think about, just from a I guess an umbrella around these these BOMs is where these intersections lie. Like why do I need to have all of these different bills of material? You know, I maybe this is a good question for Allan. Like w what intersection points are there? And maybe like from a personal level, why why are you particularly interested in this particular you know, in the CBOM?

Allan Friedman (18:41)
So I I give a whole talk on the BOM explosion and and how these different means of transparency

David Pollak (18:52)
.

Allan Friedman (18:53)
can relate because there’s no single answer. but

Kate Holterhoff (18:57)
Okay.

Allan Friedman (18:58)
there are some core pieces. One of them which David got to is that a BOM is not just an inventory. It’s an inventory with structure.

And capturing the dependency relationships gets you a much more supply chain-centric view. Is this my problem? Is this this supplier’s problem? Is this going to re is fixing something or maintaining something going to be something that we can easily slot into a burn-down list? Or is it going to require renegotiating contracts, etc. etc.?

So, what I think about this in terms of why it’s important is it gets to the fundamental question that I talked at the beginning of, right? Just how do you not know what you’re selling? And as these BOMs get slightly more complex, we can still say, you know what? You still have an obligation to understand what is in your product.

And make sure that you understand responsibilities and that your customers understand responsibilities. You know, we spent a whole decade in the cloud revolution talking about shared responsibilities. Supply chain still has some of that, but it’s going to be configured differently. Getting into how these pieces relate is going to be a much longer conversation, but I

Kate Holterhoff (20:29)
Mm.

Allan Friedman (20:30)
will just say that the bare minimum is being able to cross-link them.

because often you are going to get different tools, especially as you get into and I’m I’m wearing my HBOM t-shirt. That’s a non-profit that I’m building at the think tank IST. You thought crypto is hard, you thought software is hard. Why do you get to semiconductors? But

David Pollak (20:53)
You

Kate Holterhoff (20:53)
No.

Allan Friedman (20:56)
But remember, let’s go back to David’s UAS.

Modern systems have all of these things. We need to understand how they cross-relate, and at very least, we need to have some linking. But at the same time, someone’s job is not to do all supply chains for a large organization. It’s going to be: my job this week is to think about PQC readiness, attack services, prioritization.

And that’s why it makes sense to me to pull out and and really devote some attention to making sure that we’re doing CBOM properly so that we can help these people who are trying to solve the problems in real organizations do it quickly and efficiently.

Kate Holterhoff (21:44)
Okay, that’s helpful. And you’ve referenced a couple talks at this point. maybe y for the show notes, we can add some links to those if if they’re on YouTube or wherever. Okay.

Allan Friedman (21:54)
Yeah, I think so.

Kate Holterhoff (21:55)
Amazing. All right. So it seems to me that the crux of this really has to, do in large part with the practitioners that are trying to implement this. So which which brings me to one of my favorite little arguments that I I hear pretty often, which you know, developers

David Pollak (22:08)
Thank

Kate Holterhoff (22:10)
don’t care about security.

That’s a bit of a stereotype. Nah, that’s not true for everybody. but I think that this this is it it holds the slightest bit of water here. So I think what’s interesting about all the BOMs really is try to figure out who who’s responsible for implementing some of these changes and and how to do it in a way that isn’t just like checking boxes, right? That isn’t just like I don’t know, security theater.

So maybe David, would would you take this one? how do you respond to that and and how is it that you are s are I guess encountering this I don’t know historical tension between security and developers as it relates to the CBOM and what you’re doing at Spice Labs?

David Pollak (22:57)
So first of all, will disagree with, well, I agree with your statement that developers don’t care about security, but I will actually go that one better. Developers

Kate Holterhoff (23:06)
Okay.

David Pollak (23:09)
should not have to care about security.

Kate Holterhoff (23:13)
Okay, go on.

David Pollak (23:16)
When you get in your car and turn the key or push the button or however you tell your car that it’s now available to go, do you think about how the gasoline in your car is being secured from the gas tank to the engine?

Kate Holterhoff (23:36)
Not once, never, absolutely not, no.

David Pollak (23:39)
If you drive an electric car, do you worry about, I going to get shocked and how do I avoid getting shocked when I drive my car? No. Or maybe a little bit because EVs are relatively new.

Kate Holterhoff (23:54)
All right.

David Pollak (23:56)
Developers, engineers who are writing app like business applications, their job is to implement business applications. It is not to think about the 75 different other dimensions. And you know, we have backend engineers who do backend work. do things that interact with databases, things that are interactive message queues. have front end engineers, we have UX specialists. Having requiring.

all of them to think about security is first of all, the dimension that I think is wrong. And second of all, is a dimension that takes away not linearly, but super linearly from their ability to actually do their jobs. So I think at a fundamental level, we have not designed the frameworks to allow engineers to succeed. We have foisted the problem onto them.

rather than building infrastructure and programming languages and that sort of thing that help the engineers succeed rather than forcing them to think about a lot of things they don’t have to think about. Now, I’ll give you an example of a step change in engineering that has stuck. Back in the 90s, every engineer, every program did manual memory allocation or within the mainstream programming languages.

And all of a sudden, and that was a lot of cognitive overhead. Are you allocating and freeing or are you double freeing or are you using a pointer after it’s been freed? All of those problems. Java comes along and it takes away all of those problems from the engineer. Garbage collection took that away. Garbage collection took away buffer overflows. That’s not to say every Java application is

entirely secure, but it took away an attack surface and a failure surface that shouldn’t have been there in the first place or that we had sufficiently large computers and sufficiently fast computers that it could be taken away. The fact that we have not done the same thing with security, think is an institutional failure, not an engineering failure. So getting back to your point, should engineers care about this? My answer is no, they shouldn’t.

but they need to. And so what can we do? At an industry level, we really need to be talking about secure frameworks and secure by design was a CISA program and it should continue to be. We should be thinking about how to create frameworks and such that are secure by default. But within security, we actually have to surface information.

And right now I think the information has surfaced in a really bad way. And we see this in the tension between the security groups and the engineering groups. Security groups run a scan, they run their tool of choice, and they say, there are 50,000 libraries that you have to upgrade across your 2,000 applications by next week.

That’s not going to happen. That’s not actionable. Whereas figuring out where the impacts are, not necessarily where the vulnerabilities can be exploited, but software is designed and built as a nest of dolls. We have libraries and those libraries are contained by applications. The applications are typically contained by images, know, Docker or containers. And those are typically run in virtual machines.

What is the overall impact and how can we measure the reach of a change across the whole swath? I think that’s an important part of the conversation. And one of the failures that I’ve seen is the failure and the friction between the engineering groups and the security groups. I think, you know, just as we have to solve the problem for engineers not to have to worry about security,

We also need to have a real good discussion about how this information, this raw information, the BOMs and other things can be used to actually have healthy conversations between the engineering groups and the security groups, how they can see what the right thing is. I’m waving my hands, I’m saying that’s the goal. And that’s why Alan’s here, because he’s gonna solve all of our problems.

Allan Friedman (28:30)
Ha ha ha.

Well, I mean, i Kate,

you y you talked about box ticking dismissively and it feels awkward, especially now that I’m no longer a bureaucrat and actually out there in the world trying to, you know, both do good and make money to to rise in favor of box ticking. But I think it it’s important how they can be useful, which is one, again, the very basics of would you trust someone that couldn’t give you this data on demand?

and second, even if you get the basic data and throw it in a corner, two very useful things emerge from that. One is when there is a crisis, you’re not making phone calls. It’s not a week worth of trying to get someone on the phone, it’s a morning’s worth of scripting. Or even less, it’s three minutes of prompting.

so that’s that’s one piece. And I’ll also say from a policy perspective, there’s often an important standard when there’s a disagreement about whose fault something was, which is what did you know and when did you know it? And so a requirement that just says the organization has to exist in the network, maybe the engineers aren’t excited about doing anything with it.

But somewhere there’s a risk officer or a deputy counsel who’s going to say, yeah, that puts us at risk, so let’s actually build some processes around it. So even just going through the motions has real value. But I think it also the the second piece I’ll say is from lessons from SBOM Land.

Is the hardest battle I think is won. It took us a really long time to get some of the largest and richest companies on the planet to own up to the idea that they were going to have to produce inventories of what were in their products. and their lobbyists were the fighting the last.

Battles. The engineers were actually kind of happy. You know, the head of product security for some of these giant companies knew that the code that they were fixing wasn’t written by their highly paid engineers. It was written by the open source developers that they should have been paying aside, but weren’t. and so then they had to go through all the effort of tracking down what needs to be fixed. And so from the beginning.

It was seen as a very good idea. and then the last piece I’ll say that I think a BOM approach, especially a CBOM approach, can do, is one one challenge I come across is: hey, I know there are changes I as a team lead need to make. But I’m not going to be budgeted and I’m not going to be given time to make these.

But now there’s a new shiny. The new shiny is I’ve got to have a CBOM. And I’ve got to either have a CBOM because someone on the board told me to, or because a government told me to. And because that’s a new shiny, I can make the space to build out what David started with, which is process and tooling to create what we need to write.

Collect the data, make sure the data is useful, turn that data into intelligence so that intelligence can drive action and priorities.

Kate Holterhoff (32:29)
Super helpful. So I I I wanna tilt back to the the the PQC issue here, and and maybe David’s the best one to to answer this question. I you know it still sounds so much like sci-fi to many folks, right? You know, where we we you know go to HPC conferences and see the big chandeliers and you know they have to be what you know below freezing temperature and all and all these things.

it’s all very future looking. So I’m interested in how you’re thinking about post-cr quantum cryptography as it applies to, developers today versus these developers in the future, anticipated developers, which I mean it’s just gonna be agents, right?

David Pollak (33:10)
Thank

Kate Holterhoff (33:16)
but also like, a thing we’ve been pointing to is organizational changes that need to happen. You know, it’s not just the code, it’s it’s how

organizations are structured, the governance, things like that, like you were you were saying Allan. So so yeah, how do you address people who are like, I’m not worried about PQC. This is I get that it’s coming. I can kinda see it, but maybe this is a tomorrow problem. And really I can’t even wrap my head around what things are gonna look like by the time that it actually hits.

David Pollak (33:40)
So let me talk about cold fusion for a minute.

Kate Holterhoff (33:43)
Okay.

Just a little thing. Okay. Okay, yeah, sure.

Allan Friedman (33:46)
We get there. I like it. I’m in for it. When

David starts on one of these tangents, you just buckle up and hang on.

Kate Holterhoff (33:53)
That’s it.

David Pollak (33:54)
No, this one is quick. This is a sound bite. PQC

Kate Holterhoff (33:57)
Okay.

David Pollak (33:59)
has always been coming at exactly the same rate as cold fusion and artificial intelligence. Except we got one of those already. Look, since the seventies, since the computer science and AI lab CSAIL at MIT, AI was 10 years away. And about three and a half years ago, maybe two years ago, I don’t know exactly what the epoch was, but it actually arrived, something useful and something actionable actually arrived.

We have thought about PQC and quantum computers as a 2035 problem. once in going back to organizational dynamics, most VPs are in their seat for 18 to 36 months. So all they’re doing is making sure that they look good. So they get their next promotion and sweep all the other crap onto the carpet for the next person. That’s the way corporations work. The fact that the White House, the US military, and French standards groups all over the course of a month came out and moved their PQC deadline up by five years.

That’s not something governments do lightly. Unless they’re looking to drive like, know, GDP numbers or something like that. you know, saying we’re changing our encryption five years earlier than we said we were, they know something that we don’t or that we can’t talk about on a public podcast.

That means it’s real. That means it’s coming at the same velocity that, you know, in 2021, 2022, somebody said AI is going to be here in five years. And some people may have said, yes, some people may have said, no, but it actually became the truth. you know, looking at some of Google’s papers and that sort of thing, was, the trajectory was there.

So PQC all of sudden became everybody’s problem in June. In June, the governments woke up and said, this is everybody’s problem run. And when the US government has a memo that requires every single civilian agency within 30 days to appoint a PQC lead, and within 120 days, submit a set of tools for that. each agency will use to create CBOMs for everything in the agency. That is wartime speed.

And that I think underscores the fact that, nope, whoops, this is real. And you intersect that with the Google paper that came out the end of March that said, we have a bunch of stuff and here’s zero knowledge proof of it, that Bitcoin wallets will be forgable by 2029. So PQC went from, it’s gonna come when cold fusion comes to holy crap, it’s here now. Did that answer your question? I don’t know. It may have gone on a few tangents.

Kate Holterhoff (37:36)
Okay. I’m here for the sci-fi, but I’ll tell you, things are moving so quickly that, it’s it’s hard to keep up with what to pay attention to and what is aspirational or or things that we’ve done in the lab, maybe. but yeah, I think increasingly we’re we’re hearing that this is something that

Everybody should be paying attention to. and I I think this actually intersects with the next question that I want to ask Allan about, which is the sort of regulations that we actually need to be paying attention to when it comes to this broader issue of of BOMs in general and CBOMs specifically. because yeah, I mean the CRA you mentioned, that one is is coming quick. but we’ve also got like NIST 2030/slash 2035. You know, there’s EO 14412, right? Okay, so you know, I I I th th these can get a little complicated and and maybe feels overwhelming to folks and and maybe they feel like this doesn’t apply to them. So I’m interested in how you guide folks who are saying that, I wanna do what is required of me, I wanna follow best practices, but I also maybe don’t want to go too far, you know. Maybe maybe I wanna break a few things to move fast, How do you see that balance right now and and where do CBOMs fit into there?

Allan Friedman (38:55)
Sure. I and I think CBOMs are actually very helpful with that because they give you the you know in order to know what to focus on for already, if everything’s important then nothing is. So you need to have some set of prioritization. Before you can have prioritization, you need to understand what’s on the table. and that’s really where CBOMs come in. And the nice thing is that’s something you can do today.

While you’re waiting for some of the details to shake out. So first I I want to go back to what David was talking about because I think for folks who were paying to attention to PQC for the last three or four years, it was about what are they going to find out? It was how are you good? They’re going to break confidentiality. I’ve got all this stuff encrypted, but someone will be able to decrypt it if they could sniff it now. And that is important for lots of organizations, but far more important is the fact that if I can forge a signature, then I can break things catastrophically and not necessarily without you knowing.

Or not necessarily of you being aware. And so that when I think of prioritization, that’s what I get into. Now, some folks have already started this. If you are selling widely used hardware to organizations that care about security, chances are you are you have some things baked in. so the trusted computing groups.

did a giant lift and shift to make sure that all of the boot level trust based in hardware is PQ Surrey’s building on a lot of these things. So there’s some core infrastructure that’s being made by the giant organizations today. If you’re not one of those, there’s still probably some things that you want to start thinking about. and some of it Should not be news to you if you’ve been listening to Kate’s podcast for a while. Like, what are your organization’s unique crown jewels? Okay, now you have to understand what’s the various trust relationships, encryption, that those depend on. how do you do that? Well, they probably touch lots of different technology.

And by now I’m sure you’ve done your asset management. And if you haven’t done your asset management, please stop listening to David and me and go do that now and then come back and listen to the rest of this podcast. But the power of well-constructed CBOMs is being able to say what in a given system are the things that I need to care about. Ideally being able to map them to some risk prioritization. On the regulatory front, I’m not your lawyer but the few organizations that I’ve advised on this specific topic. I said listen, if you if you don’t sell directly to a national security system oriented organization, be prepared

Hold some budget, tell your board there’s spend coming. But this is not compliance today. This is mapping today so that you know how to move faster than your competitors tomorrow. because everyone is going to be kicking into action when the rules, when the the actual enumerated rules are going to be written. and agencies, right? The agencies right now are tasked with. Hey, start writing your requirements so that the next round of contracts will have this built into them. and then once those go public then everyone’s gonna be moving. So you can get ahead of them today. does that make sense from a a regulatory standpoint?

Kate Holterhoff (43:15)
It does. And I like that you qualify this with you’re not our legal counsel here. Very important. The the MonkCast is never here to to be anyone’s lawyer or financial advisor, so just don’t don’t look at us.

Allan Friedman (43:29)
Past results may not predict future performance.

David Pollak (43:32)
Thank you.

Kate Holterhoff (43:32)
That’s right. That’s right. very helpful here. okay. So I do I want to think about this in terms of something that I’ve been following when it comes to supply chain, which is there has been more of an emphasis on finding than fixing exploits right now. And so the incentives are absolutely on on finding right now. And so this is creating

David Pollak (43:55)
Thank

Kate Holterhoff (43:56)
all kinds of issues for Developers, especially open source maintainers who are just inundated from folks saying that they found whatever a zero day or maybe it’s just slop, who knows? So, very much top of mind. I’m wondering, maybe David, would you take this one? how are you grappling with this issue? Is this something that that that overlaps with your work with CBOMs?

David Pollak (44:15)
Not really, and this

Kate Holterhoff (44:17)
Okay.

David Pollak (44:17)
is part of having a small company. we have technology that is generic. Once again, applying the same Merkle Tree stuff to after build artifacts that was applied to the source code and even being able to link from source code, from the source code that produced class files and binaries into how are those linked into applications? We can see all that. And we started the company with the, can take over the world. And we have focused very clearly and very crisply on PQC because as a small seed funded company, we got to do one thing and do it well. But I will tell you,

Kate Holterhoff (45:04)
Absolutely.

David Pollak (45:06)
and this is independent of AI, this was done with no AI assistance. We found 360,000 packages in Maven Central that had vendored in code that was not disclosed in the palm file, in their SBOM, that contained higher critical vulnerabilities. This was by doing kind of this graph analysis. The problem is pervasive, and I think…

The place where there’s going to be a stick, but not too many carrots is the CRA, Cyber Resilience Act, because that’s going to basically say, look, if you’re shipping something, we don’t care whether you made it or not, if something in that supply chain has a problem, you’re responsible for fixing it. And that’s a stick, but that’s not the carrot. And I think Allan referred to the lack of carrot earlier with…

Yeah, you you have all these open source folks who are doing it, but they’re not doing it generally for money. And so there’s, there is a real asymmetric problem. In fact, at last year’s Monktoberfest, sorry, I to get a plug in for Monktoberfest.

Kate Holterhoff (46:21)
Absolutely do it.

David Pollak (46:23)
Yeah, there was a statistic about $8 trillion a year of value is generated off of open source, but the entire spend like on open source maintainers is in the, I think, single digit billions. So there are three orders of magnitude difference and that has to be rebalanced. I don’t know how to do that. But to kind of circle back to your question, how are we gonna do it? I have no clue, but we really do have to realign the incentives and they can’t just be stick oriented incentives like the CRA. I’m not complaining about the CRA.

Kate Holterhoff (47:02)
Yeah.

David Pollak (47:03)
I think it’s a good step, but we really do need some carrots to make sure that security is… part of everything. And that starts with the visibility. Okay,

Kate Holterhoff (47:16)
Yeah.

David Pollak (47:17)
I’ve totally lost the thread, sorry.

Kate Holterhoff (47:19)
No, you you’re right on the thread. No, that’s great. And I I mean you’re right. You gotta find it before you can fix it. and I think that’s why folks are caus calling for a pause when it comes to AI, because this backlog is is tremendous. and and the kind of issues that you’re identifying with the CBOM they might be a little bit in the future, but not really. I mean they they need to be addressed as well. So Allan, would you wanna take

David Pollak (47:42)
what?

Kate Holterhoff (47:42)
a stab at this one as well? Or or it sounds like David also has some comments here.

David Pollak (47:46)
Well, let me just also say that the way that we’ve been using AI to hunt for vulnerabilities is wrong.

Kate Holterhoff (47:56)
Go on. Spicy.

David Pollak (47:58)
we are asking AI to look at code and that’s wrong. AI is perfectly good at looking at code and can figure out patterns in code, but there are other patterns and other signals that we are not using AI effectively to look at. And those signals are what are CVE trends for particular packages. And this was one that I had some fun with back, I don’t know, eight months ago. pre-coffee I ping Gemini, not a security model and said analyze the CVE trends for Jackson data bind and log for J and show, you know, analyze those trends. Now analyze similar trends for the top 100 Java open source packages. Sound 10 RCEs that morning.

One of them was fixed and it turns out it was fixed in R2D2 which was a JDBC driver library and it turns out that the particular RCE was used as part of the solar winds attack. And so, you know, this is, don’t, we could be using AI to do stuff that would really help with visibility, which is, the, the patterns of problems in your code lead to a particular path.

That would be a whole heck of a lot more valuable than we found 50 vulnerabilities, go fix them tomorrow. And it can also lead to, by the way, here are seven other packages that have the same patterns because patterns are common. Maybe you should start a working group to say, how can we turn those patterns into something, a particular pattern into something safe because we’re all using the same patterns. Anyway, I’m sorry, I’ll shut up and let Allan talk.

Allan Friedman (49:58)
No, I No, I David, I agree with you completely. and I think one good security people have been doing that. I’ll I’ll give a a shout out to gentleman that I mentored for BSides Las Vegas this year, gave a talk where he just found a class of vulnerabilities, a CWE, for You implemented the crypto library wrong, you idiot. you accidentally did a check that would go positive on a null seed rather than reject a null seed. right. And and it turns out once you see this, you’ll go out looking for them. And and good AI researchers and good agents are doing exactly that, which is okay, here’s a thing, where else can I find it? They can do it at scale. So that’s one piece.

Pulling back to so and one other point that I think while we’re on the AI and then we’ll pull it back to crypto is things are just changing really fast, right? It’s early September as we’re recording this, Less than a year ago I had conversations with very smart people. I’ll call him out because he’s senior enough he won’t mind. Sounil Yu. And I had a couple of online debates about will SBOM be needed anymore in agentic world. because less than twelve months ago it looked like agents were just gonna write everything from whole cloth. zuning monolithic applications. And we abandoned that pretty darn quickly.

Maintenance matters, it’s much easier with third-party code and modularity. second is as we face the Vuln apocalypse and there are lots of vulnerabilities. Again, what do you do when you have a whole lot of badness coming at you? Whether it’s outdated cryptography or classic vulnerabilities, which is you need to prioritize and you cannot prioritize until you have your inventory.

And so we need this kind of inventory more than ever. the last thing I’ll say in terms of one of the things that I think AI tools have really helped us change s some of the curve shapes is I used to make fun of any vendor that would talk about reachability because I would sort of s make some vaguely coded reference to, you’ve solved the halting problem.

I now have a lot more faith that yes, it’s not provably complete, but we’re a lot better at reachability now than I ever thought we would be, just because you can do this kind of non-deterministic analysis fairly meaningfully. So, one other point when we think about cryptography and cryptographic libraries, that’s a good historical lesson that we can pull from the IPv6 transition. And David, I know that you also have some scars from that era. Is do you remember how

David Pollak (53:15)
Okay.

Allan Friedman (53:21)
bad the first three or seven or however many years of IPv6 implementation libraries were? Right? We took an entire ecosystem of networking drivers and networking software and rewrote them. and the first time we rewrote them, they weren’t very good, but we were still implementing them because we had to. Not your company, of course, David.

Kate Holterhoff (53:49)
Mm-hmm.

Allan Friedman (53:50)
and it took us a while to sort of get past that hump of Okay, what are the latest IPv6 flaws this month that we have to fix? And I think as we go into addressing all the cryptographic libraries and asset handling tools that are around them. Remember, it’s not just the am I encrypting, am I checking the signature, it’s all of the frameworks that are going to support those libraries will need to be changed as well. we’re going to have flaws and we’re going so we’re going to need both the CBOM and the SBOM to be able to manage that risk and track, okay, we fixed it, but now we have to go back and fix it again.

Kate Holterhoff (54:39)
I think that’s a good place for us to wrap up. Unless you have any final thoughts, David, because I certainly wanna have you pitch where folks can can follow you. But a any responses

David Pollak (54:48)
Thank

Kate Holterhoff (54:48)
to to to Alan’s piquant little little soundbite there.

David Pollak (54:53)
So. Allan talked about IPv6. I was around in the 90s when the initial cryptography libraries were being tested, initially TLS. And there was this huge bug in Netscape Navigator, is its randomness was predictable and you could break TLS on Navigator. That’s one of the lessons. It’s the analog to the IPv6. We are gonna go through that and we need

to know the libraries and we also, whatever libraries, know, the FIPS, what is it, 203, 204 and 205 certified libraries, those are gonna change in five years because they’re gonna be weaknesses discovered. Crypto agility combined with CBOMs is gonna be critical. You have to be able to replace the algorithm, not simply by replacing the library and recompiling your code. You actually have to be able to change the cryptography in a configuration file and you have to inventory those. So. Anyway, Kate, this has been fantastic. Allan it’s always a pleasure.

Kate Holterhoff (56:02)
Yes, yes, yes. Well before we sign off, I I would like for for you both to just tell folks how they can follow up in terms of, your social media or any any websites that that you recommend that they they look to in order to to learn more, blogs, whatever. Allan, would you go first?

Allan Friedman (56:19)
Sure. you can find me on LinkedIn, on the Fediverse, or on the Bluesky at Allan Friedman. and if you want to know more about HBOM, check out hbom.tech. I’ve got a couple talks out there on AIBOM, and always happy to chat more about the future of transparency.

Kate Holterhoff (56:45)
Fantastic. And how about you, David?

David Pollak (56:48)
Spice Labs, spicelabs.io I’m also available on LinkedIn. And I think I’m one of the few David Pollaks there. But if you look for Spice Labs, David Pollak, you’ll find me. I’m also on the Fediverse, but I can’t for the life of me remember my handle because,

Kate Holterhoff (57:06)
Yeah.

David Pollak (57:07)
you know. Back in the bad place, was DPP and that was easy to remember. have no freaking clue what I am now.

Kate Holterhoff (57:14)
It’s all good. That’s what show notes are for. We’ll get we’ve got a nice list of everything. So we’ll find it. Fantastic. All right. Well, again, my name is Kate Holterhoff, senior analyst at RedMonk here. I’ve really enjoyed speaking with Allan and David as my guests. and so if you have enjoyed this conversation, please do like, subscribe, and review the MonkCast on your podcast platform of choice. If you’re watching us on RedMonk’s YouTube channel, please like, subscribe, and engage with us in the comments.