npm Supply-Chain Worm and AI Agents Hacking Agents Put Open Source Security to the Test

Hey, everybody, it's Wednesday. Welcome to "Techstrong" gang, and well, every time you turn around, something's happening in the open source software world. Somebody's attacking somebody, and there's all kinds of chaos going on.

But folks, thank you for watching the latest episode, and let me welcome Robert Reeves. Robert, how you doing, my friend? I'm doing great.

Thanks for having me, Mike. Always a pleasure, my friend. Jack Gold, good to see you as well.

How are things? Great, thanks. And relatively new member of the gang, but he keeps showing up for more, so he must be a glutton for punishment.

Drew Gutstein, how you been? Good. I'm actually super excited about the topics today.

I think they're issues that I've struggled with for a long time, so I'm looking forward to this conversation. All right. Well, this week we've seen yet another one of these Shy Halud attacks, this time affecting multiple MPMs, and it's like 1,200 of these things, and it seemed to distribute itself pretty rapidly across all kinds of repositories.

And of course, Black Hat USA is this week, and everybody seems to be having a conversation these days about, well, how are we going to secure the software supply chain, which is heavily dependent upon open source software. Which begs the question, Robert, as we see all this stuff, can open source software be saved, or have we reached some sort of impasse here? And I ask the question because, well, the sites that people are spinning up using AI now are very hard to detect if you're a mere mortal developer.

They are actually, it's not typosquatting anymore. They look pretty real. They look pretty accurate.

These things you download, and they instantly start to spread, and they're self-replicating worms, and the AI is just taking this whole thing up to machine speed, and it's not clear to me that we can maybe respond fast enough to secure our open source software. So what's to be done, my friend? Well, you're right.

Humans are going to lose this race. And so to protect this, we need to figure out how do we automate and speed verification. " And just because an open source project is released, it has lots of downloads, everybody loves it, doesn't mean that you abdicate your responsibility as a consumer of that open source package to verify that it is not going to cause problems.

Remember, open source licenses have no guarantees. There's abdicate complete liability. It's use at your own risk.

" And it's not. Open source is only free if you have no value for your time. It is a choice that you're making as a company to take the benefits of open source, multiple eyes, lots of people working on non-differentiated tech to support your business so you can build that differentiated tech.

If that's your foundation, you have a responsibility as a business leader to make certain that your teams are protected. You need to be asking these questions inside instead of being upset at a maintainer or a foundation because most of these people, these maintainers are doing it for free. My open source project, I do it for free because I like it, and if there's something that goes wrong, my response will be, well, help me.

Help me, community, if you depend on it. But Mike, I know that's not an answer that you like to hear because you seem to be... You're always on the enterprise side and on the business side and looking at their needs, correct?

Well, I don't know. I'm going to ask Drew this question, though, because there is a certain amount of responsibility here that Robert's pointing out, and it does seem like the enterprise folks are basically lined up at the free bar, taking down those drinks, and they're pretty much not paying for anything, and then they have the temerity to complain about the quality of the booze served. So...

I think we're not going back to some prior era. This is a new era, right? So back in the day before open source, you paid a lot of money for things like a threading library and your operating system.

This debate was argued long, long ago, and once all the enterprises adopted Linux, it's over, right? So the era of first-party applications ended decades ago, right? Every tool that we use that's built on open source is second party.

It involves some of our magic sauce and some on it. Unless you're talking about a platform or something like that. So this has been a place where we've had this risk this entire time.

AI isn't really adding anything new here. It's just providing a lot of incentive, right? So, breaking into NPM repositories has been a thing before.

It's been going on for a long time. Node is notoriously messy in that way. But the traditional idea that we're just going to be able to look at something and know whether it's safe to use or not is just completely misguided.

Right? Humans can't do that. We need to get back to some more fundamental controls that are unfortunately very restrictive.

We have to find ways of doing them that doesn't impact business velocity. But this is the world we're in, right? There's no silver bullet that's going to fix this.

And maybe we don't need to fix it, right? Is it better to have the transparency of open source in this era than not have it, right? Well, let me ask Jack this question, then.

It's almost to me, it's not just a technical problem that Robert called out, but it's a cultural one, right? I've got a bunch of developers who are used to just pulling down stuff willy-nilly, and then throwing it into an application. It goes through a DevOps workflow.

" Yeah, look, whatever happened to trust but verify? That's the bottom line with anything, right? That's open source.

And we've gotten way beyond that. NMP does not stand for no more problems, right? We're going to have to deal with the fact that there's stuff out there, there are people out there that aren't on our side, that aren't very nice, that are trying to harm us.

And this is not a fraternity house, right? Where all the guys and all the gals or whatever are just, we're all friends, and we're all taking care of each other. It doesn't work that way anymore, not in the world that we live in.

So unless you can figure out a way, again, trust but verify. Unless you can actually figure out a way to verify open source code, you're taking a big risk. You don't know what's in there.

You can look, right? But the whole point of open source is someone's done the work for me, and I don't want to have to do it. If you're an enterprise and you're trying to guarantee that you can move forward with your business and you're using that approach, you're in trouble.

Mm-hmm. Robert, will people move back away from open source? Because you do hear people talking about how, "Well, with AI, I'll just write it myself, and then I'll have this neat little fork that no one will actually know anything about but me," and, or alternatively, maybe I'll- Sure ...

rely on proprietary commercial software. But is that feasible? Well, companies do that.

There are companies that will fork a package, and they will identify a security threat and fix it and use that fork. Now they're on the hook for maintaining it. Now they're on the hook for taking all those upstream commits of other fixes and bringing them in.

They could go to that, but what they're doing is they're incurring a cost. So companies need to make the evaluation of, is it more expensive to maintain that fork and the care and feeding of it, in essence, to be a secondary maintainer, or do we have the structure in place that we're allowed as an organization to send that patch upstream to continue to use the fixed version, and hopefully, it gets into the mainstream, and they can move to that? Companies have a choice.

Are they going to err on the side of lock everything down, which will slow down the business and incur costs, or figure out a way to use this speed, and improve and benefit the open source community? Remember, like your example about the bar. Okay, yeah, it's a cash bar.

Tip the bartender. Come on. And it really comes down to, I think what's missing in our coverage of these things, our discussions, is that the maintainer here is a victim.

Where is the DOJ? Where is CISA? Where are the folks going after this and suing them?

They all got laid off, Robert. Yeah, and these are also nation state actors. I know.

This is a problem. But it is a response- This will always be a problem. Yes, but these are the things that we need to support.

Look, we need large organizations like the DOJ and CISA to go after these nation states and bad actors. It's up to me as a single maintainer to protect my little dot dev project? Come on, help me out here.

And so, uh- Yeah, but- ... uh ... Robert, that's not practical.

Look, even if I go after those guys, I go after them in court, the legal process is going to take two, three, four years, five years. It's not going to help. There's never going to be- Understood, but that's why I said CISA as well.

We need structure in place that's going to monitor these threats, and I would like to see them partnering. If we're targeting maintainers on GitHub, how can CISA and the community work with GitHub, which hosts a huge amount of these, to make sure that these maintainer accounts are super-duper special? That we are watching these and making sure that there's nothing nefarious going on.

So what's interesting is in the commercial space, what's started to come up is open source maintenance as a service. So I think Google has an offering already. There's a few others that have, these are a set of very common dependencies.

We've made sure that they're clean. Get them from us, don't get them upstream, and then you won't have any problems. And that's a great solution.

That gives us that sort of distance that you need between the ongoing attack and our own environments. But you don't need a third party to do that either, right? Nobody should be deploying their software based on what's at the head of the NPM repo Right?

You need to keep those dependencies internal so that they're always available, and you don't upgrade it automatically. Any upgrade needs to be very rational, right? It's hard.

It's a very hard problem. Well, I think there's another piece- At least look at the change log first before you merge that Dependabot PR. Come on.

Sure. But the standard, what's going to be the review, right? Okay, so- Mm-hmm ...

" What am I going to do? I'm going to check to see how many other people have downloaded it, and I'm going to check to see when the last time it was updated, and I'm going to take a look at the license and make sure we're allowed to use it. There's nothing else I can really check, right?

If we have a lot of money, I can download the package and throw it into VirusTotal or whatever to detonate and see what's in there. But realistically, yeah, that's not a great option. So we only have these very cursory reviews already.

Problem is trust. We trust these systems way too much. We trust them as first parties.

We need to create second party level of trust that no organizations are doing today. There is another piece to this, Drew, that I want to draw on, and I think you hit on this, and that is, aside from trust, if you're an enterprise, you also have to put guidance in place that says you can use only certain types of open source, whatever your risk factor is, right? And a lot of companies aren't doing that.

A lot of companies still have IT that can go out and do pretty much source software pretty much anywhere they want, build anything they want within reason, and that's a big part of the problem because- Sure ... I can walk down the street in most major cities and buy fake Rolex watches for $10, but it ain't going to do me a whole lot of good a year from now when this thing isn't working. And the process has to change, and I don't see that happening yet.

Well, what is interesting is, I don't know when this flipped, but it used to be the case that any company resource was just so locked down that it was almost useless. The expectation now is the exact opposite. Like, I should be able to use my laptop and do whatever I want.

That's such a different ball of wax, isn't it? Well, it flipped because most enterprises looking at open source said, "Think about all this licensing revenue that we don't have to give Microsoft," or whoever your favorite guy is. That's why it flipped.

And so now we're finding that, yeah, you just saved a whole lot of money by using open source, except that now you're going to spend $10 million trying to figure out where that hack just came in from. The classic business race between greed and fear. Here's the part that I don't understand how it's going to work.

So theoretically, there's Robert sitting there with his little tip jar, and he's going to be updating some software on some sort of continuous basis, but Robert doesn't have the ability to update that software continuously. " So what is, to Jack's point, the process that's going to change here? Robert, thoughts?

We need to have a conversation. We need to have a conversation as an industry with these parties. We need to, I think, bring our maintainers in.

We need to bring in our consumers, our large Fortune 500 companies, the Global 2000 that are depending on this, and we need to bring in our government agencies. We need to figure this out. " I don't know what the answer is, but I guarantee you it involves all stakeholders getting involved and coming to an agreement, and the first agreement should be we're going to improve this.

Pointing fingers like the Spider-Man meme does us no good. All right. Well, Drew, I think what Robert's really calling for there is some sort of national summit, and it sounds difficult to do, but yet- Right ...

back in the day, when we needed safer airplanes, we got everybody in a room, and we made safer airplanes. So is this feasible? And no one asked for permission to create Agile, right?

Things can just happen. But I think it's not going to happen soon enough. There are mitigating controls that we need to be using, and they're fairly standard.

We need segregation. We need isolation. It's tied to how we think about malicious insiders.

We need actual malicious insider controls because that's sort of what this becomes ultimately. And so it's not something that can be eliminated, but we can manage it. We can reduce the risk by adding additional controls.

Why do we run things without a WAF? It's so weird. Why would you ever want to do that?

And a lot of these things exist, they're just not very widely deployed. All right. So is there a model, though, longer term where, I don't know, maybe there is some sort of government agency that is a clearing house for validating all the open source software that people are going to download and- No.

That's sort of what Google said. I want a conversation. I don't want a decision right now because I don't know if that's a good move.

That's a terrible move. The other thing that's kind of lost in these conversations is patching. Patching is not a viable control.

We need more than just that. And there's things that can be done to sort of circumvent attacks that we know about that don't require upgrading the software. We need to be using that.

All right. And look, AI has a role to play here as well. We talk about AI code generation, but Mythos has proved that you can go in and find a lot of security flaws if you have the right AI model looking at this stuff.

So maybe there's a way to have AI oversight. I don't know what that would be, and we'd all have to agree on what that might be, right, and how well it would work. " Maybe it's only 90%, but that's better than 0%- Yeah ...

whether it's any good. Yeah. And I think that's totally right.

This helps attackers, but it also helps defenders, right? Right. Utilize that to our advantage.

Double-edged sword- Sure ... like nuclear power, man. You can blow stuff up or power things.

So, what I got out of this, and I'm going to try to summarize Drew here, and I might get this wrong. But I think what we're saying is there needs to be a mechanism to apply some type of control and maybe even some virtual patches in near real-time to mitigate some of these attacks as they're occurring, and we need AI to help us do that while we're waiting for Robert to get his tip jar filled enough to actually create the patch that will permanently solve the problem. Was that fair?

That would be fantastic. And hopefully nobody spikes his drink at the bar- Or you could send Robert a PR. Oh, I'm sorry, Jack.

No, I was just telling Mike, and hopefully nobody spikes his drink at the bar while we're going through all of this stuff. Which the spiking of that drink is actually a malicious PR, right, essentially? Sure.

This is a great metaphor. It's got a lot of legs here. I like it.

Okay, guys. Too much caffeine this morning, I can see. All right.

Well, I'm going to leave this here because I don't feel like we have a solution just yet, but I will leave this little caveat. History has shown that if the industry doesn't solve the problem, eventually the government steps up and tries to solve it in a way you probably won't like. " This is going to be a problem.

All right. I am shifting a gear though a little bit, but it is Black Hat Week and there's a lot of talk about cyber resilience. And we've been talking about this thing for a while now.

And part of the problem with cyber resilience, and this is in a survey I think that the folks from Accenture did that's up on Security Boulevard, it requires a level of collaboration between security teams and IT teams, and even the application development teams, that frankly just doesn't exist. And part of the issue is the people in charge of backup and recovery to respond to a ransomware attack are a bunch of IT folks who the person with the least amount of experience is now in charge of backup recovery and does the backup, and no one tests the backup to see whether it works. And then the ransomware attack comes in, and we go, "This is okay.

We're ready for this. " And then we go look at the pristine files in the backup, and either they've been poisoned by malware because nobody tested it, or they're corrupted, or they haven't been run because somebody's stuck in some sort of mechanism to thwart the backup in the first place, so now we didn't have the backup anyways. Now we're paying the ransomware whether we like it or not.

Jack, I got to ask, are we our own worst enemies or what? Always. But aside from that, the real issue, Mike, is how do we define resilience anymore?

And I look at resilience, let me use maybe a simpler example. So, in our area, we have a fair amount of thunderstorms, and the power goes out when we have really severe thunderstorms. So a lot of people around here, myself included, have backup generators.

If the power goes out within some small period of time, a few seconds, 30 seconds, the generator kicks in and my refrigerator doesn't spoil my food, and my heat comes on if it's in the wintertime. Resilience for most enterprises means that if I get hit by something, ransomware or bad actors coming in and doing something to my files or shutting down my systems, it can take days, weeks, or months for me to get back up. That just doesn't work.

And enterprises need to start thinking about the fact that resilience means not offline for eight days or 10 days or 15 days, or not even finding the problem, which this is a bigger part of the resilience problem. I might not even know that I've been hit for a week or two weeks or a month. Resilience has to be redefined as knowing that I've been hit and knowing that I can recover.

It's the power goes out, the generator kicks in, and very few enterprises are there. Resilience for most enterprises is, I have these backups. Maybe I've done them in the last 12 hours.

Maybe I've done them in the last 12 months. If you tell me your system goes down, you get in the queue with the 300 other people that's in the company that your system went down with, and I'll get to you when I can, and that could be weeks. And by the way, depending on the company, every minute that I'm down is a million dollars or $10 million that I just lost in customer revenues.

So resilience has to be redefined. Now, does AI have a role in this? Maybe.

AI can help with hopefully finding the attacks, and letting us know that they're there. Hopefully, if we get smart enough with AI, they know how to kick in. And kick in the generator, reconstitute those systems or have backup systems.

But right now, for most enterprises, resilience is just a word. It's certainly not optimum to keep my business running if there's a problem. All right.

Drew, what is wrong with the recovery process? Because, I've talked to some folks about this, and it's not just the data. Often, I have to reconstitute the systems and the applications, and nobody knows exactly what to recover first because there's all these dependencies on all these different things that need to be in place.

So, the chances that I'm actually going to recover are slim to none? I'm reminded, this is a while back, we had an audit, and the auditors were asking us to pull up some seven-year-old database backups. " It's on a tape in Iron Mountain.

We order the tape, it arrives, we read the stuff off, and it's a database that doesn't exist anymore and only runs on a hardware device that doesn't exist anymore. And it's all binary. You can't do anything with it.

" Especially if you're talking about those kinds of horizons. Seven years is a long time to back something up for. That said, I think there's a huge conflation in the industry between what's called business continuity and disaster recovery.

Those are two very different things, right? So everybody needs to have business continuity. That's the question, how long can I survive with this not being around, right?

And you'll have the backup plan. You'll flip a switch, you'll fail over, you practice it, you have run books, blah, blah, blah. Right?

The disaster recovery is when none of that works. So think Hurricane Katrina or 9/11. Those are disasters.

You have no comms. You have no identity anymore. You don't have access to your devices, right?

That's what an actual disaster situation is like. So, there are things that companies need to do in advance. I need to build a backup place where I can actually call people and get in touch with them when the phones don't work, things like that.

And you need to have a way to repave your environment when these events happen, because it's going to happen more frequently. Again, the tools exist. If you're not using declarative infrastructure right now, start working on declarative infrastructure.

That will help you when you inevitably get popped by an AI and need to repave everything. Second, backup's a lot harder than you think. There you go.

I don't have a solution, it's just really hard. But it's being managed by the person with the least amount of experience, so what could go wrong? Yeah.

It's true. How would the person backing up the data have any knowledge about what's in it, right? It's a broken control, I think.

All right. But it gets better. Jack, I bought a cyber insurance policy because I kind of know that I suck at recovery, so I'm figuring I'm going to go buy some insurance policy out there, and it'll cover my losses.

But I think, as of late, the cyber insurance people have gotten wise to this game. They took a bath early on, but I think that they now have so many clauses in there that the odds that they're actually going to pay out on a claim is almost zero, because there's so many things in there about my ability to recover that I'm never going to be able to meet. So has that become something of a joke as well?

It's a fair point. Yeah. Yes and no.

People still have it. They're still going to do it. You have to.

Your board of directors are going to ask you why you don't have insurance, right? On the other hand, what does that insurance cover? Generally, it covers your backups.

It covers some level of your systems going down. What it doesn't cover is the 20% of your customers you just lost to your competitor because they're never coming back, because you screwed up their business by you being down. That's not generally covered.

You get a bad reputation in the industry. That's not covered. You don't get that back.

And so yeah, cybersecurity insurance is fine, but boy, it doesn't cover anywhere near what you need to do to get everything back and running on your company. And getting those customers back usually is expensive. You're going to have to give them- 10 times what it costs you to keep them, at least.

Yeah. So- Mike, that- ... Robert, what's your assessment here on all this?

Because as I listen to these guys, I'm like, wow, these big companies, they look like they are really tough and strong, and they're going to be hard to take down. And then it turns out they all have glass jaws. What's going on here?

Well, the bigger they are. Yeah. There's a lot of lessons in other areas that we can learn.

And look, I'm ex army, and when I was in the army, we trained and trained and trained. We went through all sorts of different situations, and we had fun going through like, "Okay, here's the situation. There's the enemy.

" And I would like to see, well, or rather, the companies that I have seen that are the most successful go through a recovery exercise. Okay, we've done a backup, so over here, let's go and create. Can we create a newer version, smaller, we're not going to blow out the whole thing, but can we replicate our production environment?

Just answer that question. Can we do that and show it and go through the process, and iterate on it and improve? That's how you get better.

" Well, answer that question. Now, whether X is too big Great. The next thing you do is how do we get that number down?

You cannot improve what you can't measure. Somebody famous said that, right? Drucker.

Probably. And so I would like... The companies that I've seen that are really successful with this are the ones that try to inject chaos in a test environment, and they go through it.

And I think IT development, DevOps friends, security friends, would like to see these exercises. We could have fun with it and encourage them to do it. " And then maybe that lowers the insurance costs now that you have this system.

The downside, though, Robert, is that with most companies today, honestly, they don't want to spend the money. IT budgets are going down, they're getting cut. I get it.

You're absolutely right. I don't disagree with any of that. But can you get a company management that actually buys into it?

I agree. You're absolutely right. Humans are very bad at making decisions unless they're experiencing pain.

Yeah. And so, pain is instructive. They might see a peer that goes through this, they might themselves go through this.

But I would hope that the lesson is the way you get better is you practice. Yeah. You can't just say, "Oh, well, our 22-year-old new hire is doing backups.

" Yeah. And Drew, now- Testing backups is a thing for sure in a lot of regulations. There's some rules in India that actually came out last year about this that were fairly onerous.

I think there's a part of this that's kind of just more of the same, right? Resiliency is hard. You can have an entire parallel.

I've worked in places where we have an entire parallel environment that we could fail over to within milliseconds because the outage constraints were so severe, right? So yeah, I think you have a really good sense of how long you can be out. Have a really good sense for how you get back up, you know?

Well, in theory- Do you know how to re-shard your root of trust, right? Some of these things are really technical and hard and need to be practiced. Well, in theory, a lot of people thought that just by going to the cloud that they could get away with this, right?

Yeah. It's a cloud, it's backed up, everything, data's distributed. If New York goes down, I got Seattle, or Paris, or whatever.

And in reality, it's a far more complicated process than people think. So Robert, I'm going to end this, but you know what being in the army and cybersecurity have in common? No budgets?

I think we should be afraid to ask. It's a thankless job. That's what's in common.

It is massive amounts of sheer boredom punctuated by a few moments of terror. Yes. That's true.

And that's where we are. Well, hopefully, maybe, I don't know, there'll be another government-led initiative somewhere to help us with all this stuff, because maybe we got to get better at this somehow or other. But I don't know if that means that they should do it, but I do mean it's a conversation that needs to be had.

Speaking of conversations that people are having, there's some weirdness happening on LinkedIn. And if you've been floating around LinkedIn for a while, you will have heard about the phrase robin sage, which is basically an attempt by, I guess there's no other word for it, spies acting on behalf of other nation states. " And they want to have a conversation, and they want to know what you know about a certain company.

" And they'll ask you about different contexts, and it won't feel like they're actually trying to elicit information from you. It actually feels like more of a job interview, and you might give up some more information because you think there's an employment opportunity at the back end of this thing. Now, Drew, we have moved into the age of AI, and it looks like this is coming back in full speeds because people are now having conversations in AI and coughing up all kinds of interesting secrets on LinkedIn.

Does this surprise you in any way, and is there something to be done about this? So again, more of the same, right? Humans have been the weakest link for a long time, and it's a far greater problem now than it was, simply because the scale is much bigger, and the signal is much weaker, right?

Security training maybe works the first time. Right? Like if you've never heard of phishing attacks, okay, now you know.

Any training after that is pretty much pointless, even though it's required. So relying on everyone in your company to be a perfect human lie detector 100% of the time is a terrible control. It's god awful, right?

And now we're at the point where we can honestly say, "Guys, even the smartest people in our company, even our CEO, will fall for this," right? And they do. Yeah.

I've been in spaces where we have crypto wallet access, and those people are getting this kind of attack constantly. Deepfakes, so scary. You don't know if you're talking to somebody, it could be an AI.

" That's not going to be a problem soon. We're going to solve this using actual controls that we know work. Authentication.

If I'm having a conversation with someone and they are not authenticated, that should be a huge red flag for me, even if it's someone not at my company. But the tools don't surface that information. They make it really hard to tell.

Like, next Zoom call, just try to find out what's the domain on the end of that person's account. It's really hard to dig out. The way I solved for this, I just changed it so that only authenticated people can end up in the conference room.

Everyone else goes to the lobby, and that actually works really well. It creates enough of a observable event, like, "Oh, why is the CEO in the waiting room? " Trust authenticated people.

Don't trust unauthenticated. And I'll tell you something else, man. Jack, correct me if I'm wrong, but I think this comes under human nature.

I'll be very guarded about what's happening in the company I currently work for, but if you start talking to me about places I used to work for, I get a lot more cavalier and a little less inclined to be careful because I'm just that much removed from it. And so, do people wind up giving out more secrets unintentionally about places they used to work? Oh, I'm sure they do.

I think you're right. I think that's just common nature. It's like sitting at a bar, having a beer with your friends, and you talk about your past jobs, or past relationships, or your spouses, or whatever.

Absolutely. The bigger problem, though, from my way of thinking, the humans are the weak link for sure, but the social media organizations, LinkedIn is getting as bad as X when it comes to this, in not patrolling who actually gets on their platform. Yeah.

They know. Yeah. They know that there's 1,200 North Korean hackers on their platform sending out this stuff.

They can tell. It's not beneficial for them to discover that and let you know about it. And I think that's an even bigger part of the problem, specific to LinkedIn or X.

Pick your favorite one, they're all about the same. WhatsApp, they're all pretty much the same. Yeah.

Humans will always be susceptible to social engineering. Of course. You're no aware of it.

Well, look, you're in a hurry. You've got 13,000 things you're trying to get done today. Someone sends you a note, looks legit, you're going to answer it.

It's just the way life is. " Yeah. Do we need that on...

Is LinkedIn the new bar where we need a label somewhere that says, "Loose lips sink ships"? What do you think, Robert? You're the bartender here.

Well, yes. We need to educate. But this is what is old is new again.

It comes back. And so this is just a honeypot attack, that's all it is. And look, Drew's a little more nicer about the CEO making these mistakes than me, because there was a business case that I remember from B school, and it was years ago, made a huge impact on me, about a construction company that had a very low accident rate.

It was ridiculously low compared to peers. So the people that were writing the case study, the professors, went out to the job site. They were walking around, CEO's saying, "Well, I don't know.

" And while he's having this conversation, he walks into this area where he wasn't supposed to be, and everything stopped. " Yelling at the CEO, and what did the CEO do? "I'm so sorry.

Thank you. " He's wearing a suit, obviously CEO. And so their culture was calling people out for safety and those sorts of things.

Mm-hmm. What I think companies need to do is have that culture of educating their employees and being able to call it out. When you're in that meeting, authenticating meeting, and there's a bunch of people waiting, this is an opportunity.

Take a screenshot, kick them out, have the meeting, but then share it with others to learn. We're human. We need to learn from examples of others from stories, and I think that there needs to be a concerted effort from the company to educate its employees.

Relying on the platform to do this, like Jack was saying, they know they're there, and they're really not incented to get rid of them. So it's up to the companies to help educate people. There is a bigger problem- Maybe CISA should do this.

There's a bigger problem, though, and that is that, especially with the younger generation, we've gotten them so used to these social platforms that they don't see this as a problem. They'll share anything with anybody, for the most part. And- Oh, my kids are pretty good at spotting the fakes.

They live on TikTok. I've got family members that say some really... We won't go there, but- Yeah.

But you- Thank you. That's all right. Drew, do I, as a former employee, have any obligation in my former employer to be responsible about some of these secrets that I know because people are just walking out the door, and they do their little exit interview at HR, and then they start to forget every rule they ever heard.

Do they sign a non-compete or an NDA? Because that's what you do Yeah. But here's the thing, people think that the information in my mind is somehow going to be super useful when I go to this other company, and it's not.

We've stopped writing our own software a long time ago, right? We're using the same open source operating system as the other guy. There's no special sauce, right?

And the special sauce that's there is so specific to my infrastructure that it's not really replicatable. So there is information that's important, and sensitive, and secret. The code is not really where it's at.

It's a lot more like the personal information. Data is actually the thing. But we tend to focus way too much on the source code as stuff like that needs to be trusted.

And honestly, don't trust it. You didn't write it. So use that posture when you deploy it.

Yeah. And I think this is, again, the whole question about Robin Sage and how people are getting fooled again. It never ended.

It's just the newer iteration of it, right? And after social media, there'll be, I don't know, holographic media. We'll all fall for the same scams on that one, right?

All right, folks, I'm going to leave this here, but if you happen to be at the social media bar, and somebody sidles up to you and starts telling you how smart and handsome you are, and how good-looking you are, and all these wonderful things, be suspicious immediately. All right. I would add that you can do some research.

When I'm talking to stealth startups, it's actually pretty easy to find out what they're up to by doing an AI research. It'll find all their job postings and stitch it all together. We're not doing a great job in general of keeping those things secret, so I don't see why it's so important.

There you have it. Gentlemen, thank you as always for being on the show and sharing your insights. I want to thank everybody else for watching the show, and please stay tuned for the rest of the Techstrong TV lineup or the rerun thereof for the rest of the day.

And hey, the good news is we're going to do this again tomorrow. See you then.