Latest / The MonkCast / The BOM Explosion & Why PQC Stopped Being 10 Years Away with David Pollak & Allan Friedman

Transcript

The BOM Explosion & Why PQC Stopped Being 10 Years Away with David Pollak & Allan Friedman · The MonkCast

• speaker-0: Hello and welcome to this Monkcast Conversation. My name is Kate Holterhoff, senior analyst at Red Monk. I am so excited to have two guests with me here today. First off, we have David Pollock, who's a founder and CEO of Spice Labs, and ⁓ also have Alan 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. ⁓ Alan and David, thanks so much for joining Awesome to be We are gonna be having ⁓ an excellent conversation on some of ⁓ my favorite topics lately, things that have been coming up a lot in terms of Redmont conversations, and that has to do with post-quantum cryptography and security. So excited to dig in here. ⁓ I guess I'd I'd wanna set the stage just with like a ⁓ a a state of what's going on ⁓ and ⁓ and also just kind of g getting to know you both a little bit here. So ⁓ maybe Alan, 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? speaker-1: Sure. ⁓ so ⁓ I'm a failed professor who got suckered in adjoining 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 S bombs. if software supply chain is your thing, S bombs 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 politics. speaker-0: Fantastic. ⁓ man. So we have the the godfather of S bombs 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 Redmunk Functions here. So so ⁓ what's ⁓ a little bit of your background? speaker-2: known commodity and I'm still invited back. I don't know, you know. We have fun. Yeah. I 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 bomb damage estimation systems. And as part of this, I got invited to Langley, Virginia, ⁓ where FEMA had their communications 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. Wow. I don't know whatever hurt happened to it. Anyway, I I've been doing a a bunch of stuff ⁓ over the years. And in the early two thousands, I was VP of engineering and CTO at a security c cybersecurity company. speaker-0: Interesting. Hmm. speaker-2: 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 cr ⁓ collaborating with a crazy engineer at Microsoft, ⁓ to apply the same mathematical Equations that Git uses to both afterbuild artifacts and to the whole supply chain. And Ava Black, who was the crazy Microsoft engineer, went on to SISA, 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. And, you know, the the core piece of technology the or the core piece of open source that my company has is something called Go 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. S Baum has done his magic, of software supply chain and, you know, overall compute supply chain. And, you know, 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 gotta start taking that seriously. And so having a conversation like this, being able to bounce ideas off of Alan, 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 speaker-0: 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 try 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 S bombs before we move into some of the post quantum cryptography ⁓ part of this. So Alan, I guess I what I would be most interested in is like how w where are we at with S-Bombs 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 S bombs. speaker-1: Sure, state of estimate. So and just briefly to some 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, so like very clear. People have 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, explitive, explitive, expl, 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 for them. 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 tooling system. ⁓ in fact, that tooling system has evolved. There were a bunch of commercial tools that were just for S Bomb. And all of those companies have now pivoted because they realize the point is not to have the S-BOM, it's to use the S Bomb. ⁓ 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 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 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 2021. 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 S bomb 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 pat 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 S Bomb? What are some of the big challenges? One, it's quite embarrassing. It's non-deterministic. We always forget that even before we got into, you know, generative AI, LLMs, software without 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 of software that gave 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 they're mismatched definitions. This summer, ⁓ Sista 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 or when something ends up in a contract, we are all on the same page. 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. speaker-0: 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 AI bobs. I mean that's that's been blowing up here. Is that part of the conversation? speaker-1: It it it definitely is. ⁓ there are a couple of perspectives. We can dive more into it later, but the short 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 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. speaker-0: 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, but we're here to talk about cryptography. So I I I next want to ask you, David, about a very particular kind of of bomb here, right? ⁓ so talk to me about what is a cryptographic bill of materials, ⁓ and why are you arguing that it's so necessary? speaker-2: So we have a universe of bombs. You know, it's kind of like the Marvel bomb universe. And why do we need different bombs? And, you know, 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 bill of 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 you know 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: do you have libraries that are capable of performing the cryptography that you need? Does Library X have algorithm Y. That is a 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 the cryptographic material? So what are the certs? What are the Java key stores? What are the, you know, 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 is 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 rifts 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 UAV's 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. So the public Key that everybody says it's public, everybody should know it. You can validate blah blah de 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. So this, you know, let's jump back to cryptographic bills and material. So one part of the C bomb 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 bill of materials will tell you you have the libraries or you don't have the libraries. Here's the cryptographic material you have. You have, you know, 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 crypto the new cryptographic material that it may be seeing? Sorry, was that a long prattle or did that answer your fumble question? speaker-0: I think it's pretty good. I I well what it's making me think about, ⁓ just from a I guess an umbrella, ⁓ aro around these these bombs is where these intersections lie. Like why do I need to have all of these different bills of material? I you know, I maybe this is a good question for Alan. 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 in the C bomb? speaker-1: So ⁓ I I give ⁓ a whole talk on ⁓ the bomb explosion and and how these different ⁓ means of transparency can relate because there's no single answer. ⁓ but there are some core pieces. One of them, which David got to, is that a bomb 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 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, et cetera, et cetera? 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 bombs 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 will just say that the bare minimum is being able to cross-link. ⁓ because often you are going to get different tools, especially as you get into and I'm I'm wearing my H-Bomb t-shirt. That's a nonprofit 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 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. speaker-0: ⁓ no. speaker-1: 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 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. speaker-0: Okay, that's helpful. And you've referenced a couple talks at this point. ⁓ maybe you for the show notes, ⁓ we can add some links to those if if they're on YouTube or wherever. Yeah. Okay. I think so. 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 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 bombs 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 are ⁓ I guess encountering this ⁓ I don't know, historical tension between security and developers as it relates to the C bomb and what you're doing at Spice Labs? speaker-2: So first of all, I I will disagree with ⁓ I agree with your statement that developers don't care about security. But I will actually go that one better. Developers should not have to care about security. speaker-0: Okay, go on. speaker-2: 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? speaker-0: Not once. Never. Absolutely not. No. speaker-2: If you drive an electric car, do you worry about am I going to get shocked and how do I avoid getting shocked when I drive my car? No. Or may maybe a little bit because EVs are new relatively new. speaker-0: All right. speaker-2: Developers, engineers who are writing applic business applications, their job is to implement business applications. It is not to think about the seventy-five different other dimensions. And you know, we have back end engineers who do back-end work. They do things that interact with databases, things that interact with message queues. We have front-end engineers, we have UX specialists having requiring All of them to think about security is first of all a dimension that I think is wrong. And second of all, is a dimension that takes away, not linearly, but superlinearly, 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. And I'll I'll give you an example of a step change in engineering that has stopped. Back in the nineties, everybody did ma ⁓ every engineer, every program did manual memory allocation or, you know, within the mainstream programming languages. And all of a sudden, and that that was a lot of cognitive overhead. Are you allocating and freeing, or are you double freeing, or are you, you know, 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, I 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 what can we do? You know, at 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 as 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 2000 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 a is designed and built as a nest of dolls. We have libraries, and those libraries are contained by applications. And the applications are typically contained by images, you know, Docker or containers. And those are typically run in virtual machines. What is the overall impact and how can we measure the 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 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 bombs 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. Now I I'm waving my hands. I'm saying that's the goal. And that's why Alan's here, because he's going to solve all of our problems. speaker-1: Well, I mean, it Kate, you 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 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 S Fawn 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. ⁓ It was seen as a very good idea. ⁓ And then the last piece I'll say that I think a bomb approach, especially a C bomb approach, can do, is 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 C bomb. And I've got to either have a C bomb 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. speaker-0: 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. ⁓ but we're not 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? but also like the 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, Alan. 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 kind of 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. speaker-2: So let me talk about cold fusion for a minute. speaker-0: Okay. speaker-1: Just a little thing. I like it. Okay. When David starts on one of these tangents, you just buckle up and hang on. speaker-0: Okay, yeah, sure. That's it. speaker-2: No, th th this one is quick. This is a soundbite. Okay. T TQC 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, CSAL at MIT, AI was 10 years away. And about three and a half years ago, maybe two years ago, I don't you know, ⁓ 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 as a twenty thirty-five problem. And, you know, once again, 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 under the carpet for the next person. And you know, that's the way corporations work. The fact that the White House mil US military and French ⁓ French standards groups all with 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, you know, GDP numbers or something like that. But 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 on a public podcast. That means it's real. It that means it's coming at the same velocity that, you know, in in twenty twenty one, twenty twenty two, somebody said AI's gonna be here in five years. And some people may have said yes, some people may have said no, but it actually became the truth. And, you know, looking at some of Google's papers and that sort of thing, it was the trajectory was there. So PQC all of a sudden become 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 C bombs 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 is all zero knowledge proof of it that Bitcoin wallets will be forgeable by twenty twenty nine. 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 I don't know, I may have gone on a few tangents. speaker-0: It not a bit. It I I feel like, you know, I'm here for the sci-fi. ⁓ but I'll tell ya, things are moving so quickly that 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 wanna ask Alan 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 bombs in general and C bombs 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 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 want to do what is required of me. I want to follow best practices, but I also maybe don't want to go too far. You know, maybe maybe I want to break a few things to move fast. How do you see that balance right now and and where do C bombs fit into there? speaker-1: Sure. I and I think C bombs are actually very helpful with that because they give you the, you know, in order to know what to focus on for right, if everything is important, then nothing is. So you need to have set a prioritization. Before you can have prioritization, you need to understand what's on the table. ⁓ and that's really where C bombs 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 wanna 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 we going to they're gonna 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 with 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 Sred is 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 C bombs 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? speaker-0: It does. And I like that you qualified this with you're not our legal counsel here. Very important. The the mugcast is never here to to be anyone's lawyer or financial advisor. So just don't speaker-1: Best results may not predict future performance. speaker-0: That's right. That's right. ⁓ now 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 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 CBO? speaker-2: Not really. And this this is part of having a small company. So we ⁓ we have technology that is generic. You know, 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 we can take over the world. And we have focused very clearly and very crisply on PQC. Because, you know, as a small seed funded company, we got to do one thing and do it well. But I will tell you, 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 on the in the POM file in their SBOM that contained cr ⁓ higher critical vulnerabilities. This was by doing kind of this graph analysis. The problem is pervasive, and I think speaker-0: Yeah. speaker-2: The place where there's going to be a stick, but not too many carrots is a 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 it if it 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 Alan referred to the lack of carrot earlier with Yeah, you know, 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, got to get a plug in for Monktoberfest. speaker-0: Absolutely. Do it. speaker-2: Yeah, that there was a statistic about eight trillion dollars 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. speaker-0: Wow. speaker-2: So, you know, there there are three orders of magnitude difference. And that that has to be rebalanced. And I don't know how to do that. But, you know, to kind of circle back to your question, how are we going to deal with 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. I think it's a good step. But, you know, we we really do need some carrots to make sure that security is. part of everything. And that starts with the visibility. Okay, I I've l totally lost the thread. Sorry. speaker-0: 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 C bomb, they might be a little bit in the future, but not really. I mean, i they need to be addressed as well. So ⁓ Alan, would you wanna take a stab at this one as well? Or or I it sounds like David also has some comments here. speaker-2: Well, and let me just also say that the way that we've been using AI to to hunt for vulnerabilities is wrong. speaker-0: Go on. Spicy. speaker-2: We are we are asking AI to look at code. And that's wrong. AI is perfectly good at at looking at code and can figure out patterns and 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 C V E trends for particular packages? And yeah, th this was one that I had some fun with back, I don't know, eight months ago. Pre-coffee, I pinged Gemini, not a security model, and said, analyze the ⁓ CVE trends for ⁓ Jackson Data Bind and Log4J. 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 R two D two, which was a JDBC driver library. And it turns out that the particular RCE was used as part of the SolarWinds attack. And so, you know, the this is we don't we could be using AI to do stuff that would really help with visibility, which is, hey, 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, you know, a particular pattern into something safe, because we're all using the same patterns. Anyway, I'm sorry that I I I'll shut up and let Alan talk. speaker-1: 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 B Sides 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 that can do it at scale? So that's one piece. Pulling back. 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. Soonil you, and I had ⁓ a couple of online debates. ⁓ about will SBOM be needed anymore in a Gentec world? ⁓ because less than 12 months ago, it looked like agents were just gonna write everything from whole cloth. ⁓ zooming 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 vulnerable 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, ever. ⁓ the last thing I'll say in terms of one of the things that I think AI tools Have really helped us change 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 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. 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 C bomb and the S bomb to be able to manage that risk and track, okay, we fixed it, but now we have to go back and fix it again. speaker-0: 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 to to to Alan's ⁓ piquant little ⁓ little soundbite there. speaker-2: So Alan talked about IPv6. I was around in the nineties when the initial cryptography libraries were being tested, you know, initially TLS. And there was this huge bug in ⁓ Netscape Navigator, which is its random si the 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, you know, the the ⁓ FIPS, what is it, 203, 204, and 205 certified libraries, those are gonna change in five years because there are gonna be weaknesses discovered. Crypto agility combined with C bombs 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, Al, and it's always a pleasure. speaker-0: 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. Alan, would you go first? speaker-1: ⁓ sure. ⁓ you can find me on LinkedIn, on the Fediverse, ⁓ or on the Blue Sky at Alan Freedman. ⁓ and if you want to know more about HBOM, ⁓ check out HBom.tech. I've got a couple talks out there on AI bomb. ⁓ and ⁓ always happy to chat more about the future of transparency. speaker-0: Fantastic. And how about you, David? speaker-2: ⁓ Spice Labs, S-P-I-C-E-L-A-B-S dot Io. ⁓ I'm also available on LinkedIn, and I think I'm one of the few David Pollacks there, but if you look for Spice Labs, David Pollock, you'll find me. ⁓ I'm also on the Fediverse, but I can't, for the life of me, remember my handle because, you know, back in the bad place it was D P P and that was easy to remember. I have no freaking clue what I am now. speaker-0: It's all good. That's what show notes are for. We'll get a nice list of everything. So we'll find it. Fantastic. All right. Well, ⁓ again, my name is Kate Holterhoff, senior analyst at Red Monk here. I've really enjoyed speaking with ⁓ Alan and David as my guests. and ⁓ so if you have enjoyed this conversation, please do like, subscribe, and review the muggast on your podcast platform of choice. If you're watching us on Red Monk's YouTube channel, please like, subscribe, and engage with us in the comments.