OpenClaw Gets a Foundation While the Software Supply Chain Takes Four New Hits

Hey, everybody, happy Friday. Welcome to the Techstrong gang, and if it's Friday on the Techstrong gang, we must be talking about foundations. We'll get back to that more in a minute, but let's introduce our guests for today.

Jeff Rich, how are you doing, buddy? How are you? Doing great.

Have a french fry today, or a couple. Yeah. What's up with French fry day?

I mean- It's national french fry day. It is? And what's wrong with that?

I think French fry day should be on Bastille Day, shouldn't it? Is it today? I don't know.

You could have Crip Day on Bastille Day. That could work. All right, we'll see.

The French are partying one way or another. Jack Pollard, good to see you. Good to see you too.

Always good- It's been so long ... it's always good to be seen. And Tracy Reagan, how are you?

Good to see you. I'm great. Happy to be here.

As usual, there is much to discuss, and it looks like the Linux Foundation went out and created something called the OpenClaw Foundation, and this is the idea here that we're going to have some body of people get together and make a more secure, hopefully, version of the OpenClaw agent that is being downloaded by millions and millions of people without little or no regard for their security risks. But hey, that's the life we live in. Jeff, is the fact that there's going to be a foundation making you feel any better about OpenClaw?

Or are we just waiting for something bad to happen in the meantime? So I don't want to step on the intent, because that's good, but the answer to your question is no, it doesn't make me feel any better. And the reason being, I applaud the intent, and we're going to get there.

The question is, what's it going to produce, when, and how enforceable will that be? Just because you're going to have a foundation that says, "Here is now a secure version you can trust," how many people do we believe, or what percentage of users do we believe will actually engage that and use it? The security researchers that worked on this, that pretty much spawned the apparent need for the foundation, came up with a quote that I just have to...

I love it. I love this quote. They described OpenClaw as having the lethal trifecta of risks, because you can get private local data, interactions with external content, and you can communicate outward, which means you have access to the world with it.

So they're trying to find a way to rein that in, and that's good. I think having a version that will eventually be more secure is better. The question is, how do we clean up this big trail and mess that we've left behind right now?

And I think that may be the question we have to answer next. Jack, let me ask you this. Is it going to be feasible for security people to have the ability to force people or require people to use a, quote-unquote, secure version of OpenClaw, assuming that is ever achieved, versus just continuing to download whatever one they find out there, and they're not going to pay attention to the policies anyway?

Yeah, I think it is, because if they don't, all hell will break loose. And I think your security team is basically, at the enterprise level, they're going to say, "If you touch this thing, you're basically going to get fired or get gone," because there's zero way the existing OpenClaw can be secure. It was designed without ever once thinking about security.

We've talked about this before. It stored passwords in plain text in a file. When you get to that level of, we don't care about security, the entire thing needs to be rethought from ground zero.

Burn it down and start again is my opinion. I don't know what else to say. They never thought about what are the consequences of unleashing this agent that has access to anything and everything, and it's all stored in clear text.

It's the classic of, well, what could go wrong? And the answer is everything. Mm-hmm.

Yeah. So OpenClaw basically gives trust and credentials and authority to systems that consume untrusted content. So there isn't any way you can solve it.

I was surprised by this, to be honest. I was really surprised because the Linux Foundation already has an agentic foundation. And why didn't they bring in OpenClaw as a project underneath it?

I'm not sure why they had to have a whole separate foundation for it. It's confusing to me, to be honest. And I also feel that it's a huge risk for the Linux Foundation because this is definitely a Pandora's box.

And to take it on is brave. Let's just say that. It's brave.

Mm-hmm. Because it should be burned down and started over. But the box is already open.

We already opened Pandora's box, it's going to be hard to shut it. Mm-hmm. And I don't know.

This foundation is being brave taking it on, and I don't know what kind of potential legal problems they could have if they are saying now they're responsible for making OpenClaw more secure, if that's the intent, and they can't do it. So I was surprised. Well, I am surprised by the number of foundations and this being the latest of them, and I guess the point that I'm a little bit concerned about is, so everybody wants to have their own little foundation, and they're going to stock the board of these various foundations with whoever wants to be the contributor thereof.

And now I get a bunch of little foundations that are all targeted at a specific thing. Why don't I just put all these people in a proverbial smoke-filled room and cut a few deals on the backside, and we'll see who's going to win what, because it feels like it's getting a little too chummy. Or Jeff, am I overreacting?

Well, it sounds like you're saying, let's make AI great again, and I'm not certain I'm in favor of that either. Because I don't think we can go back. Tracy has it right.

" Good. That's a good thing. I still go back to my earlier statement.

That only addresses the people with correct intent and a level of accountability to say, "Yes, I'm going to use that version and nothing else. " The two issues we still have, though, as Jack pointed out, or I think it may have been Tracy, I apologize. I have trouble telling the two of you apart.

But the legal ramifications of if you say, "This is now a secure version," who is holding the bag when the first vulnerability's found and the exposure results from it? Add to that all of the other cleanup that we can use whatever metaphor we want. We can't put the genie back in the bottle.

Everything that's already out there is already out there. So it is now the Wild Wild West. What do we do to have voluntary, I'm not even going to call it compliance, voluntary alignment with what is presented as a secure version, and how do we make that work?

I think we potentially can, but boy, it's a heavy lift. I don't understand what a secure version is. How do you make OpenClaw secure?

What, are you going to say that we've done our proper scanning? We've done everything, we've looked at the code. It's gone through the Linux Foundation security process.

It's not the security process of OpenClaw itself. It is OpenClaw that is the security problem. It's all these skills that people are able to download, giving them trusted credentials, like I said, and to a system that then goes and consumes this content that's not trusted.

But how do you solve that? That's the essence of an agent. But in particular, these skills represent something new and different in that...

And the bigger problem's going to be it's not necessarily the big companies are going to be using this. I can see smaller companies relying on something like OpenClaw and these skills to build out really important pieces that are interfacing to their end users without realizing they have these exposures. Yeah.

So we- That's right ... internally at Textstrong, we started out playing with OpenClaw like a lot of folks, and we put it on these Mac Minis to isolate it. But increasingly, we find that we've got to give it access to some data to have it do something useful.

But the more we do that, the more problematic it got. So then we switched over, at least some of us, or many of us, switched over to Perplexity because the idea was, well, at least this is a SaaS app, and maybe they've actually thought through some of the security issues on Perplexity Computer. But Jack, is there a way to do this safely, or are we just kidding ourselves?

Well, I think Tracy had made a great point, which is the architecture of the system is let's give an AI agent access to everything you have and give it the ability to communicate out to the rest of the world. And this is something we'll talk about in the third segment as well, is that's a recipe for a disaster. And that is you've architected an environment where it is very hard to put the right constraints on it to prevent it from going wild and doing something you don't want it to do.

And we've already had... The amazing thing to me is, in the security world, usually we operate in an insecure environment until somebody somewhere gets burned. Right?

So we didn't start taking identity seriously until, for instance, the Octa incident with the casinos in Las Vegas, right? And we didn't take ransomware seriously until big events happened. We've already seen somebody, very prominent person, the head of safety for Meta AI, Facebook Meta, she got burned when OpenClaw decided to delete most of her mail archive when she said, "Don't delete anything," right?

And that was a very simple thing, and people haven't learned from that yet. And I'm of the opinion that you don't touch this stuff until you understand it. You're playing with fire.

And if you don't have a fire extinguisher nearby, you're going to have a problem. But I think you asked earlier about the foundation aspect of it, and I think there's another part that's driving all of this is I picture the Scrooge McDuck diving into the swimming pool full of cash and coins. And I think from a foundation level, we have a big swimming pool full of cash and coins, and everybody's diving in, trying to grab their share of the cash.

And I think that's what's happening here. And I don't believe anything that this is motivated by a desire for how do we make OpenClaw secure, because there are many ways within foundations, as Tracy pointed out, there's many other avenues they could have taken. This is let's grab our piece of the pie and a little power play, a little money play.

But I'm a cynic, so that's fine. " So is this just the invention of fire all over again, Jeff? No, I think it's more like the discovery of what you could do with phreaking- ...

rather than the discovery of fire. Because fires are a naturally occurring phenomenon, right? We can create it as well, but it is naturally occurring.

There's a number of reasons why it can happen. This was done on purpose with blinders on to say, "Hey, here's what we can do," and then someone looked back and said, "Whoa, there's a big mess behind you. " And I think that's where we are, and that's why I use phreaking rather than the invention of fire because there are so many downsides to this.

I'm all for let's find a way to do this right And I'm not certain we can burn this down. I think this is here to stay. There may be a version that has better clamps for controls that you can install, potentially.

But I think we're here to stay. Mm-hmm. I think that the process is here to stay.

We do need what OpenClaw offers, it's just that it's not the right model. Well, we should talk about Nemo Claw then. That was part of our homework assignment.

Mm-hmm. An enterprise tool that's trying to solve the problem. They're different tools, but they're addressing something similar.

But at least Nemo Claw has a kind of a governed runtime, right? And Mike, you talked about trying to sandbox and create protections. That's what Nemo Claw is going to help companies do when they start building out these larger agentic processes.

So, runtime controls, restricted network access, being able to protect credentials, human approvals, even though a human approval may not be useful if what they're being shown is not accurate and is false, which happens. But at least Nemo Claw's making an attempt to build something that it's secure by design, for lack of a better word. Mm-hmm.

Well, let me argue this then. Jack, might this result in some good? And here's how the good could play out.

We recognize that OpenClaw and these things are problematic, but maybe we will do better in terms of our IT and application architectures to limit the scope of a potential impact, and we'll actually revisit how the entire AI IT stack works so that when there is an issue, it's not quite as catastrophic as it might be. Yes. I 100% agree that there is good that will come out of this effort.

And I think a lot about the history of computer science and enterprise computing. And when Java came out, the very first versions of Java, I called it the virus description language, because that's really what it was, and the way it was implemented and the way people used it. That was 25, 30 some odd years ago now.

We've come a long way since then, and there's been a lot of understanding of the potential for bad and the potential for good, and how do you build the systems around it to accommodate for that. And I think we're at the very early stages of the OpenClaw, Nemo Claw, et cetera, and it is good that we're understanding that there are some security issues, or many security issues, and we have to think about those. I wish there was a way we could put the surgeon general's death head warning that we do for cigarettes on a package.

When you download Nemo Claw, you get one of these things, or OpenClaw, whatever it is, sorry, OpenClaw, not Nemo Claw. When you download it, you get this warning that says, "Beware the redragon hero. Use at your own risk.

" Mm-hmm. For me, that would be the very first thing that we need to do is really be very explicit about the risks that are inherent in these types of tools. And I will say that it's not just the claw, lobster, whatever these things are called, type agents.

AI agents in general have a lot of security ramifications and access ramifications that we don't yet fully understand, and don't have the correct models and security controls in place in the enterprise to deal with correctly. There's one thing on Nemo Claw that we haven't mentioned yet, and I think it's the right incentive structure that's going to help get us there. And that Nemo Claw benchmark says there's a 10X cost reduction when you run it against similar models.

And boy, that's a great incentive when you look at what everyone's paying for tokens and AI, and saying the costs are going through the roof, saying, "Hey, you could do this for 1/10 the cost," and we're finding a way to offer more clamps or just add-ons for security and controls. I think that's a great incentive package, and that I think is what's going to help us drive forward. The foundation will be a good thing, but it won't be fast, and it won't give us all the right incentives.

" No, we don't need any more agents. So Jack, you mentioned the meta issue, right? And that experience.

Right. Given how widely OpenClaw is being used, frankly, I would've thought there would be more incidents by now. So, are these getting maybe, I don't know, swept under the rug, or these are now the- Absolutely.

So I firmly believe, having been in the security industry for quite a while, I firmly believe that somewhere north of 90% of all security incidents don't get reported. Because at the personal level, people are too embarrassed by it, that they got suckered by a phishing war. They ran OpenClaw and it deleted their email, and they're not self-promoters, and they're not going to go and advertise that they screwed up completely.

And at the enterprise level, with the amount of liability that comes with admitting these cybersecurity attacks and what gets leaked, if they don't have to report it, they're not going to because they don't need a black eye. So I would be highly skeptical of anybody that says that the meta incident is the only major incident we've had. It's the only one we know about, and I think that's two different things.

Yeah. So Jeff, there's these things in the world called prediction markets now. You make a prediction, you place a bet.

" So I'm going to add a skill to place a bet for me- ... on a prediction market. And I think it's going to be very soon.

" And most large companies, I believe, are going to try to get their arms around, "I don't want to have to recover from that. " We need to pull back the CEO that read in a magazine how great AI is and all their competitors are doing it, maybe not yet. So I think you're actually going to see some of that.

" I do believe we're going to see that. Jack, to Jeff's point about that, we talk all the time about how the federal government isn't really interested in putting a lot of AI regulations together, and yet we have a ton of regulations that already exist. And it seems to me, looking at OpenClaw and a lot of this other stuff, they already violate existing regulations in many ways.

So, the auditor's going to come around soon and start asking some hard questions. Yes. , a cybersecurity incident that affected your customer data files and exposed customer data has to be reported.

When your lobster agent, whatever you call it, goes and deletes your email or deletes your intellectual property, and you go and recover it from backup tape, and it costs you a week or two of screwing around with it, they don't have to report that. That's the same thing as an employee being stupid and deleting my intellectual property, right? Nobody reports that stuff.

That doesn't mean it hasn't happened, right? And to the regulation question, this is not the type of stuff that you can really regulate. Oh.

So again, it changes too quickly for governments to keep up with it. Maybe. I think here's my prediction.

My prediction is that soon, auditors and other folks that enforce compliance tools are going to show up with their own AI agents to scan your environment to see what your AI agents are doing, and then they'll levy fines accordingly. Possibly. Sounds like you're, are you pitching for a VC for funding for this, Mike?

Because I'm all in. Seems like the most logical outcome. All right.

Yeah, I always say if AI got us into it, maybe AI can get us out of it. I guess that's what you're saying. Yeah, or get us arrested, one or the other.

So something's got to happen. All right, Mike, you got four co-founders here for that. All right.

Here we go. All right. I'm going to shift the gear here because the theme is similar, but if you have noticed lately, there seems to be a lot of, well, first of all, research into how to penetrate into our software supply chains and compromise things like our CI/CD platforms.

And then there's been some poking around that goes beyond research, and the North Koreans apparently are playing around with our AI coding tools. And then there's been some talk about how the AI coding tools themselves are vulnerable. Tracy, as you look at all this stuff, are our software supply chains under increased attack, or are we just noticing more?

No, I think that they're under increasing attack. I think it's getting worse all the time, to be honest. And there's a lot to unpack here in this.

So let's just go over some of the stories that we were talking about. So Cordyceps showed that a valid GitHub workflow behavior could be kind of chained together, allowing outsiders with a free account to GitHub to execute code using a maintainer's privileges. Steal credentials.

By the way, OpenClaw did that, too. I think that that lesson is teaching us that CI/CD workflows are privileged executable code, not YAML file configurations, and they have to be secured. But some of these workflows are old, and I just don't know how quickly people are going to jump on it.

Then there was GhostApproval, demonstrated that these malicious repositories could exploit Unix symbolic links, so agents write outside its approved workspace, which is crazy. How do you find some of that stuff? And then HalluSquatting, and it goes further by registering fake repositories or skill names that AI assistants can consistently hallucinate on, then using embedded instructions to make the agent fetch and execute attack or control code.

It's a mess. It's really a mess. And then, of course, you mentioned the North Korean-linked groups, famous Kolyma and App37.

modules packages. So together, all these incidents show that organizations can no longer trust a repository because it looks legitimate, and a workflow because it passes a syntax check, or an agent because a human clicked approve as we talked about in the last session. So I don't know where we can do continuously validate code and dependencies and workflows, but I think we're going to have to start thinking differently Because AI coding agents can compound the problem because they can read instructions, modify the files, download dependencies, and run commands with the developer's privileges.

So when you think about that from a DevOps perspective, it's sort of frightening, to be honest. Mm-hmm. So I think CIC pipelines have become privileged attack surfaces, and they hold really important things like credentials, signing keys, and release permissions because they did deployments to production environments.

So yeah, we have a problem. Jack, do we need to start over here with application development tools and frameworks? Because it seems like everything we have is pretty much broken, or how far do we need to go?

I don't think we need to burn it all down. I think we need... The phrase that Tracy used was right, which is that it is a privileged attack surface, and it's just we hadn't thought about it that way.

And there was this perception, again, that we're creating static files, not that they're not instructions to code, when it turns out they really are instructions. And this is something that executes. It's not, or at least my understanding up until very recently was, it wasn't AI, it was a deterministic workflow, and it's a deterministic execution, which makes it a lot easier to put appropriate security controls around it.

That doesn't make it easy. It makes it easier than putting security controls around the agentic workforce, so to speak. Mm-hmm.

And so I don't think it's a burn it down, but I do think it is a very good moment for reflection, introspection, so to speak, and to say, "Let me look at everything I do with respect to not the code I write, but the process by which that code goes from keyboard to production and executes," and look at every step along the way and say, "Are the appropriate controls in place and what happens if", and do the, what we call in security for enterprises, tabletop exercise. What happens if this gets compromised? What happens if this step, et cetera.

And do that, and we've not done that yet in the CICD pipeline, or at least I don't know. I'm not aware of that. Right.

Jeff, it's clear that this is not a good thing, but on certain perverse level, is this not some ways a celebration of the ingenuity of humankind, that we can come up with these things to get around these machines? What do you say? Yeah, I was not expecting that question.

You could make that case, but then I'll go on the other side of it. Why do we have to have a non-expiring GitHub app key? Because once that got leaked, that's the keys to the kingdom.

That was one of the issues associated with this. So, there's still, no matter what, it is concerning. I agree with Tracy, and I also agree with Jack that I don't think the whole thing is completely broken, but we don't necessarily have complete control of it, and we still have stupid people pushing buttons.

So when you wrap all of that together, we have an environment that's easily abused, that I think fixing the CICD pipelines is a more doable aspiration than saying OpenClou is going to be secure. If I want to compare the two we've talked about. One of the things that strikes me from what you said, Jeff, is that we are very insular within these communities in technology development, where we're not applying lessons learned from one area to another area.

For instance, we have understood for a very long time that long-lived certificates and identities are a bad thing, and we are in the process of cranking down certificate lifetimes for the identities for your website. When you do SSL, and you get the little green lock, or you used to, and the website said it was secure, we used to accept 10-year lifetimes for those. We've gone down to, I don't know, what is it?

Two years now, and we're working to crank that down to those will only be valid for 47 days. Because if that site gets compromised, you don't want people to accept that compromised site for two years or four years or 10 years. We've known about this issue in SSL and secure communications for a long time, but we're not applying it outside of that particular environment, and it would be really nice if there was some way at RSA or some other way that the industry could sort of say, "These are lessons that we've learned over here.

" And we don't seem to do that as much as we should. Mm-hmm. Tracy, are we about to lose something here?

Because one of the joys of software development has always been the collegial feel of it. Right? We all kind of, sort of trusted each other, and including the people who contributed to the open-source code, and you may not have ever met them, but you felt some kinship, and now it feels like we're moving down a path where we can trust no one.

Well, I think we double down on trusting each other even more actually, because it's not everybody who's the problem. Mm-hmm. The more we talk about this, and the more we work together to solve it, I think, the better off that we will be.

As many people know, I've been trying very hard to get the CD Foundation and the OpenSSF Foundation to talk more. Because these open source, the OpenSSF, have some really interesting tools to put security around, say, your Git repos. There's a tool called GitTough that could probably help the ghost approvals.

So I really believe that we have to even build a stronger fort around us and work more closely together In order to identify when a real attack happens. I think it's the only way to do it, because it's like we all have to be talking to each other and understanding where these things are coming from before they happen. So there's some good news, right?

OpenSSF is trying to make repositories and SBOMs, and they have tools out there to improve security around the software development factory floor. DevOps engineers have to start understanding that these are real problems, and they have to start addressing it, and they have to start talking to each other about how to address it. So, in that article, it did say something that I thought was good news.

It said that Anovia has scanned something like 30,000 high impact repos and confirmed that 300 had exploitable aspects, including ones that were connected to Microsoft or Google environments, probably open source tools. I thought that was a pretty good average, 30,000, you have 300. So, I felt that that was a good sign that we're making good progress, because in particular, shoring up your Git repositories, there are tools out there to get that done.

We just have to do it. Mm-hmm. So here's my issue.

At the rate we're on, in order to resolve these issues, I'm going to have to have another foundation set up to provide the communication layer between the OpenSSF, the CD Foundation- ... and the Open CLAW Foundation in order to go solve all these particular issues that are plaguing software. And the AI Foundation.

And the AI Foundation. So, at what point does the weight of the foundations just get in the way of solving the problem? I think that depends on the foundations and how they decide to start talking to each other.

Mm-hmm. Right? It's all about outreach and communication and working together.

And I believe that the Linux Foundation has the framework for building out a better discussion between the foundations, but the foundations have to want to. Yeah. And the problem in a lot of these foundations is the one group that founded the other foundation is made up of a bunch of companies that don't like the companies that made up the other foundation.

So we wind up with this kind of push-pull me kind of thing going on. But we'll see how it all comes out. Well, if you look at the discussions we were having at Open Source Summit, there was one glaring problem with some of the tooling coming out of the OpenSSF according to the people that were doing DevOps.

They're command line and they don't scale, so they have to add them to every single workflow, which is a non-starter. So that's a simple discussion they can start having. How do you make these scalable?

How do we solve it so it's scalable? Because everybody knows we're a 10 minutes to value kind of people now. If we don't see a tool that we can have value out of it and implement in 10 minutes, we walk away.

Mm-hmm. All right. So I would like to see maybe the next Open Source Summit be set up with...

I know they did it last time. They tried to have these various days for different foundations that are kind of affiliated therein, but I think there's just got to be more of a concerted effort for that conversation to be had versus just kind of all sharing the same tent at the same time for a couple of days. Well, yeah.

CDCon, we did a whole half day and invited OpenSSF to it and had all OpenSSF projects come and present so we could have that conversation. And we had an hour and a half town hall to talk about it. Mm-hmm.

It was extremely powerful. All right. Here's what I think needs to happen.

A bunch of people have to be designated as the, let's call them open source diplomats, shall we? And their whole job is to go walk around and have these conversations between these different foundations, because that's what's going to make this work. At the end of the day, we just need some good old-fashioned diplomacy.

All right. Now, we're having a chat on the next topic because Jack has a knack for finding these weird, obscure little things out there- ... that people can do with security that will mess with your mind, and he's got another one here that suggests that maybe this whole concept that we have air-gapped systems is obsolete, but Jack, I'll let you explain.

Well, we've had these types of issues for a while, and this one is a variation of a theme, which is how do you export data from an air-gapped environment? And we've had people who have said, well, if I introduce malware in this environment, I can blink the keyboard lights or blink an LED, or do something with the disk drive so it makes noise. And you can do audio, you can detect the audio or detect it visually.

And those have been proven to work, but they're also very slow communication channels, so they're running in kilobits a second. And so it takes a very long time to exfiltrate significant volumes of data using that. These researchers in China figured out a way that they could manipulate pixels on the screen, or that would not be displayed necessarily, but would change the transmission frequencies and stuff that's going on on the HDMI cable, that's therefore creating an RF transmission out of this.

So basically using the video to create radio waves coming out of your video cable, and they're able to communicate at eight megabits a second. So now we're getting to the speeds, order of magnitude quicker, but the speeds where you can actually exfiltrate real data in a time when people really can't detect that you're exfiltrating the data, especially because no EDR tools, no network security tools are going to find this because it's not coming out over the network. So, you get into a situation where your air-gapped network isn't really secure.

And we have this assumption that air-gapped means if we just put it in an air gap or virtual air gap, nothing can come out. It's this secret vault, and nobody can disturb it. And now, you still have to get the malware on the system in the first place, but that turns out not as hard to be as we thought it was.

Thus, the way the Israelis were able to get the malware or the scatter malware onto the Iranian air-gapped networks and destroy their nuclear centrifuges, right? And there's a lot of different ways to convince people to put USB sticks or log in or whatever it is on this air-gapped network and get the malware on. Once they do that, now there's a valid way to get the data off relatively quickly.

So we need to really understand and rethink of what air-gapped really means and what types of protections you really get. So yes, there is sort of a secure thing, but we're sort of destroying now the assumption that the secure vault is really a secure vault. So- Yeah.

Go ahead Okay. " Absolutely brilliant. Brilliant.

And I was blown away that at 208 meters, I think you said- Yes ... that was in the article. Yeah.

At its peak speed, a file could be exfiltrated in under two minutes. Brilliant. It is.

The Chinese, they're working it. They're working it hard. They're seeing a cyber war here, and they're working it.

" So that part in and of itself, and it's a great find, Jack, by the way. That part in itself is probably pretty easy to address but the bigger question about does air-gapped mean anything anymore? I think that's the question, and I think the answer is not always.

You can't count on it like you could 10 years ago, that if it was air-gapped, you felt safe. You can't do that anymore because if it's not this, then there'll be another opportunity to find a way to make the data center floor vibrate at a certain frequency and have the tracks for the tiles. This may sound silly, but that may be the next one, and have the tracks for the tiles in data center be the transmitter antenna.

Now, the counterargument to all of this is that it's the classic security statement of how much is your data, what's the value of your data, and how much do you invest to protect that, right? Do you put $5 in a vault that costs you a million dollars, or do you put a million dollars in a vault that costs you $5, right? So now what we're saying is this vault is not secure as we think it is.

Now, from a military perspective, we've thought about a lot of this for a very long time, and there's this concept of what they call tempest, T-E-M-P-E-S-T, shielding of a computer, which basically puts your computer inside a Faraday cage in a dark room where now basically it is truly air-gapped in that there's no communication channels in and out, and the only way to use the computer is to sit down at the keyboard, and the signals don't go out because it's in a radio wave shield and a visual shield and all of that. So people have thought about this, but that's the million-dollar vault for the million-dollar secrets that the military needs to deal with. For the enterprise, do we now need to think about those things and go that far?

I don't know. But that's sort of, again, is air-gapped really as secure as we think it is. " So is this something that three-letter agencies have already been playing around with, do you think, or what?

I don't know on our side of the world if our three-letter agencies are playing around with this, but I will say that the philosophy of communism in general, and China in particular, is that the state owns all the intellectual property. In fact, the state owns all property. There is no individual property rights.

So the Chinese researchers, if they've thought about this and they're doing it, the state now owns it and has control and access to it. So I would not be surprised if they are using it in places where they think they can. Yeah, I think it's being deployed now, and I can't speak for the US government, but I have worked in research on government grants and contracts, and it wouldn't take much for a basic researcher to do something like this.

And the thing about basic research, it's not classified. As long as you're not dealing with a classified data or classified environment, you can do basic research on it. I would be really surprised if something along the same line isn't being pursued somewhere.

All right. Tracy, are you prepared to take your entire teams to a basement somewhere that is a Faraday cage that will protect your intellectual property? How far are you willing to go?

No, because the first thing they're going to want to do is connect to the cloud and Google and ChatGPT its vault. So I don't think that we could do that, and most companies can't, and I don't even think the government can in most situations. And I do believe this is part of cyber warfare.

This is what we're seeing. And the DoD is right now exploring a new force called Cyber Force, and when I read articles like this, it makes me think, "Yeah, they should spend the money, bring the budgeted a budget for 20,000 cyber experts to start working on some of this and doing more research because we're right now sitting on our hands, and our adversaries are not. It's true.

They're not. Right. Jack- We're worried about votes in Georgia.

Let's just put it that way. There you go. All right, Jack, last word on all this stuff.

Is all this kind of happening around us, but we're not paying enough attention to it? Or what's your sense of why isn't there just more urgency on all of this to begin with? Because it's scary.

It's really, really, really scary. Right? When I first got into cybersecurity years ago, I was talking to my mentor, and I was like...

" And I read the first one, I'm like, "Oh my God, there's nothing sacred. " And that's really what it is, is we get scared when our illusion of security is pierced, and that bubble of protection is pierced. And so a lot of people don't want to talk about a lot of this stuff.

There's a lot more out there that are conventional wisdom, generally known, but aren't generally discussed because either we don't know how to solve the problem, or it's not a big enough problem. But it's still there, and it's scary and depressing, demoralizing that we're not as safe as we think we are. And it doesn't improve anybody's bottom line.

Yeah. Right? That too.

It's not a money-making thing. It's kind of like testing. We had to tell people, "Test, test, test," because it's better to find things before you release.

It costs less money. But these are board level discussions, but not around making money. Right.

So we always get pushed back. And Jack, you're right. It's not that hard to get something like, what was this called?

TrojPic or Trojpik? Yeah. Onto something.

I mean, think about the Israelis put a pocket bomb into walkie-talkies. Mm. The Russians put a CVE on modems and called it Acid Rain, and blocked communication in the early days of the Ukrainian War.

Wow. So it's not hard to get these things out there. Everybody is walking around with a supercomputer that has microphones and cameras in it wherever they go, and that thing will end up inside of somebody's air-gapped network environment, sitting right next to the air-gapped computer with a way to blink lights and take pictures, and listen to radio signals, right?

So it's not going to be that hard. Mike, I'm sorry, I have to bring the tone up just a bit. Because- This is all true.

I get it. But you can also make the case that I don't know how many of you took... I took driver's ed in the '60s, all right?

Just here's where we are. And we used to have to watch films. " And you could just see pictures of cars that were destroyed, and people that were killed because of the accidents.

" That doesn't work for us. We, for the most part, are aware of what sort of behaviors can lead to that, what sort of conditions can lead to it, and most of us do our best to avoid those. I think we can be in the same situation here.

Even though it can all be terrible, it doesn't mean that everything's terrible. All right. " So there you go.

Well, that means you didn't have to see "Death on the Highway," which was horrible. It was. That's true.

It was horrible. My wife still talks about that particular movie. So there you go.

Anyway, I do not want to leave everybody with the sense that it's unsafe to leave your house. But there are people- ... out there who are very clever, who are up to things that you should think about and just take that extra measure because, hey, if you spent $10 million building something and it matters to your company, you don't want it stolen.

And, well, these days, as Jack points out, it's not so hard to do. Hey, I want to thank everybody for spending their time with us and sharing their insights. Please stay tuned for the rest of the techstrong TV replay lineup, and we'll see you all guys Monday.

And to our guests, as usual, thanks for spending time, and take care.