Navigating Software Security and 401k Investments | TSG Ep. 904

Hey everyone. A survey traces large amounts of breaches back to vulnerable code. Shocking.

You're watching Textron Gang. Hi everyone. Happy Monday.

It's Alan Shimel and uh, welcome to Textron Gang. We are thrilled to have you on here. We hope you had a great weekend, and, um, we've got a great show to talk to you to bring to you today.

Let me, uh, let me introduce you to our gang members today. We're lucky to have with us Jack Poller, who's a regular Mitch Ashley, and we have a new gang member today. I want to introduce you to her.

Her name is Wiki Wong Wiki. Welcome to Textron Gang and thanks for joining the gang. Yeah, My pleasure.

W Wiki, if you wouldn't mind, give people a little bit of your background so they know where you're coming From. Sure, yeah. My name Wiki Wong.

I have over 14 years experience in it. Security, compliance it, audit it. So, and I'm also serving as the emergent tech training group member in ISAC at, uh, Plaza.

I also have a nonprofit for emergent tech for cybersecurity, and I'm doing some investment on my debt In your spare time. Of course. Welcome to the Gang Wiki.

We look forward to having yawn. And then lastly, our dean, our Chief Content Officer at, at, uh, tech Strong Mike Fazar. So Mike, is this the Captain Obvious award here?

What are we doing? Let's, well, let's start this up a little bit. So our friends at Checkmark have a survey out that finds that 98% of folks have experienced at least a one breach that they can attribute to a vulnerability in code.

81% of them knew that there was vulnerability in their code, and more than a quarter, 27% say that they've been victimized four times or more around vulnerabilities in code that they probably knew about. Check marks has been running this survey now for three years straight. And Mitch, despite all our chitchat about DevSecOps over the years, it does not look like it's getting any better and we're gonna have more code than ever.

If you look at some of the tools that people are using out there, we had a show last week talking about some of the vulnerabilities that people are starting to see, but this does not bode well and it doesn't feel like, you know, for all our talk, we're not seeing a whole lot of action. Well, as Monica would say, on friends, there's vulnerability in code what now or there's gambling going on here. Yeah, yeah.

I, you know, I think if you kind of dig down a little bit more into, to some of the stuff, and this is a, a good, good reliable survey 'cause you can compare it across years. Um, I thought some of the other interesting things is, yeah, of course. I mean, what are attacks gonna come from social engineering configuration, errors, vulnerabilities, and code pretty much gonna cover majority of attacks or other, or others, of course.

Um, but when you look, when you looked at how do they feel prepared for handling threats when it comes to, to, uh, CICD pipelines or development environments, you know, only 15 14% respectively felt comfortable with, they were prepared when it comes to new emerging technologies, including, uh, API threats, things like that. It's still 14%. When you looked at generative ai, it was 12%.

I'm surprised it's that high actually. Um, so it was pretty interesting. There's some other stats about how, how how many people are using infrastructures, code scanning tools, dynamic, dynamic hyperlocation, security scanning, you know, those are in the almost 50% range.

So it isn't that they aren't doing anything about it. I think just that, that one, there's a heightened concern about the pipeline, the development pipeline, as well as the software that's being developed. And of course, you know, everybody is probably wondering what we're gonna do to secure, uh, particularly generative ai.

And I don't think there's any bought into strategies yet, at least not commonly applied. Hmm. I wonder, so are we blaming AI for this?

Nope, not yet. You sure not? Most of this stuff isn't even AI generated just yet.

They're using I don't think so. These are all vulnerabilities. Yeah, I think Alan, it's, it's, it's the opposite.

It's we're pitching AI as the solution, not as the problem, although it will become the problem because we're now gonna have AI generating code that another AI is gonna check for vulnerabilities. Yeah, I think, Yeah. So, so lemme ask Yeah, just try to give some like, uh, more insights on this side, right?

So for the supply chain security, it's, it's never been the small thing, right? Uh, back to 2021, I do look at some numbers. 2 trillion for the open source package industry, right?

Always being like a big, big market here. And also I can say recent trends, right? From, uh, because the AI coding is so popular right now, it's added some more risks in this area.

So I, I would like to say, like I, I, I do see some of the solutions already from the startup side, uh, but I, I would hope more solutions on the open source regarding the, uh, AI coding, uh, involved the risks in the supply chain security. Yeah. Well, but here, here's my point, guys.

Look, I, I get that a large amount of breaches come from vulnerable code, and I get that what, what kind of I think sticks in people's CR is that 81%, that's a, you know, that's critical mess. It's, I mean, that's over overwhelming majority, super majority our shipping code that they know has vulnerabilities in it. And I, I question, you know, I I mean some of these surveys and, and I gotta be fair, I I did a webinar the other last week with check marks with my friend Aaron, Iran, runner, and Tyler, I forget Tyler's last name from check marks.

The, the, the issue there is, is that 81% vulnerabilities, how many of them are blockers? Right? How many of them should have shut down the deployment shipping of that code?

Because they're truly blockers. If I'm not mistaken, within the survey, something less than 81%, but still a majority of those vulnera known vulnerable code in production numbers were blockers, which is mind boggling to me. If, if it's a blocker, it's a blocker.

If it's a blocker and you still ship the code with that blocker in there, I guess it wasn't a blocker, or you just don't care. Blocker doesn't mean blocker anymore, I guess. Yeah.

Or, Or am I just willing to take the risk because I'm gonna get beat up about being late for shipping code. So now I'm just gonna say, well, the hell with it, and then I'm gonna hope that the vulnerability doesn't get found or exploited. But turns out, Jack, maybe the bad guys are getting better at finding these vulnerabilities faster, and we're gonna have a lot more of these issues soon.

I think, I think it's part of that, and it's part of what you said just now, which is that developers and organ and organizations think about and prioritize future functionality and schedule over security. And we need to think about how do we flip that equation and say that, uh, you know, put some teeth into the penalties, that it's not just the risk of the code to the code or to an application when a vulnerability gets exploited, but there's some other financial penalties for companies that repeatedly ship vulnerable code that gets exploited, right? How do we make it so that companies care about security?

You know, we tried that in the previous administration when CSA had some teeth and, and they tried to put in a regulation that at least if you were gonna sell software solution to the federal government, that that code had to be free of known vulnerabilities. And there was such an outcry that that is such an artificial and impossible level to, you know, to adhere to that because there are always known vulnerabilities. But if they don't rise to the level of, you know, mission critical, serious, whatever the level is that you designate, right?

They, it, it, it's okay. Basically, it's okay that we can't hold people's feet to the fire and say it has to be free of all known vulnerabilities. And, and so, you know, the outcry was so great that they didn't go forward with that.

They didn't promulgate that regulation right or Wrong. I think on the, on the other extreme though, what we are seeing, and I would argue this is, you know, there's just too much complacency. We have made it okay to put vulnerabilities in these things in the ship code, and we've said, you know, we think, uh, you know, maybe we'll skate through and we'll hope for the best.

And, you know, this has become a society issue now, right? All these people are impacted by this software that they're dependent on that we're, and has no vulnerabilities in it. And at some point soon somebody's gonna get held accountable for it, and it's all gonna come crashing back to folks who just simply didn't pay attention to it.

That's all there is to it. 'cause on this show and a million articles all over the web, people are telling them that this cannot stand. And yet here we are.

Well, you know, it's, it's, it's, it's not a binary question of is it a vulnerability or is it a, a, a vulnerability we should care about, right? Um, so that's partly why I think a, the pushback was so hard on the, on the federal government of shipping with no known vulnerabilities is kind of be impossible a to do, but not all vulnerabilities matter, right? And I'm not saying that you're overlooking vulnerabilities, but some things don't.

I can't get exploited because of the way the code's built or the way the system's deployed. It's like, it, it's like it is in the, uh, it intrusion detection world, Alan, that we came from, right? Not every intrusion is one that we have to worry about because there are other countermeasures.

Um, you might say, well, this is behind an API gateway and the API gateway stops something that might be exploited. But I think we're talking here about do we, do we not proprio prioritize or do we overlook vulnerabilities and just kind of roll the dice and let it go out the door? Uh, it's hard to believe, well, I shouldn't say that.

I'd like to not believe that people don't ship blockers that are known vulnerabilities unless they know they can't be exploited. Um, but I suppose it does happen. You know, there's gambling that does happen here.

So it, it, um, it's, it's a little more nuanced than is it have a vulnerability or not. It's kinda like, I sneeze, do I have a cold? Well, it doesn't mean I have a cold until we know it's Do agree with, with M**k and Mike, right?

Uh, so here's something I feel like we should, uh, deep little bit dig, uh, deeper, right? So when we talk about vulnerability at the, actually in the enterprise, if I play my compliance hire, right? They do have a really good framework.

They, they do the testing pretty well before move to the production, all those different sort of thing. But the most important part, I think majority of the problem currently, like maybe 99% of the code base contents open source code, right? For this part of open source code actually make the big difference.

How do we try to hop on this side? Maybe we need to think more and see how we can reduce the vulnerability from this part. Yeah.

So I, I was thinking the same thing, wiki, because you know what, there was a time where we used to say open source code was more secure 'cause we had a million eyes on it, everyone could see the code. So of course it's more secure because everyone would've found any bugs or vulnerabilities before it got to you to incorporate into your code. And it Would get fixed fast and it would of all people maintain the Code, get a crowd source, right, from Yeah.

But that turned out to be a bit of a fallacy, right? That turned out to be kind of myth. A myth.

Because the fact is, most open source projects, even big huge open source projects you could count on, on two hands and maybe your feet, the amount of people who are actually contributing code, checking code, writing code, maintaining these projects, right? The overwhelming majority, 98, 90 9% of the people using open source code are just users, right? They use the code.

They may or may not test it for security, though the components that they use. And so what we have found, and, and unfortunately many breaches over the last couple years point back to open source code, and it's not that it's inherently less secure, but it's just not, it's not as well tested or, or, you know, there's not all those eyes looking at, at that, at that code that we thought there were. You know, speaking of eyes, looking at it, I think, I think AI is gonna have to change about how we think about generating code.

Because to your point, Jack, as we accelerate the amount of code that we're generating because of AI productivity increases anything that's manual, a manual process, somebody has to look at that, see if it's a real vulnerability approved, the fix of it, whatever. At some point you read a, read a reach a threshold of I can't hire enough people to review all the things that are being found by scanners of code because we're generating so much code. So if you think about it, um, you know, yes, scanning can happen earlier, but it's really the remediation and also the, the triage of vulnerabilities.

So if you think about a world where we're in doing that much generation of code, we move from prompts that generate code to really multiple steps, either LLMs or with agents that are finding vulnerabilities at the point the code is generated before it's presented to us as a complete solution. Otherwise, I don't see, you know, we're gonna hit a tipping point or I don't care how much Coda can generate, I can't, I can't work with it all as much. I'm getting, I wish to Talk to, I wish to talk to Attorney Shimmel.

So Hold on. Lemme see. I gonna start my billing.

Yeah, there's 500 bucks an hour. Yeah, thanks Mike. So, so imagine the following, right?

So there's a breach and now people are suing over the fact that there was some impact that they suffered as a result of the breach. And then they get into the court case and they find out that the company involved shipped vulnerabilities knowing full well that they were gonna be potential issues here. At what point does this not approach reckless disregard?

Gross negligence is the term. Yeah. Not just reckless, reckless disregard is a criminal case, you know, like mm-hmm.

Yeah. Gross negligence, Which is, um, but from my side, I'm thinking from, um, if you see the three components for the cybersecurity, right? People, process, technology, um, I think from people's side, we also have some question mark here, because for the open source, it's really hard to decide who's the comfortable person and who's taking responsibility for this kind of, uh, chat, right?

If some company use my open source code, do they take responsibility or I'm a volunteer for the open source, I need to take responsibility. It's hard to see, right? Well, but that, but that is in the license, that's in your o your OSI approved licenses.

It, it's basically, you use it at your own, you know, at your own re your own regard, your own liability. Though there, there could be cases brought back, especially when you have a deep pocket, like a Linux Foundation or someone that you can theoretically sue. But Mike, to your question specifically, there's a, there's a, a term of, you know, a term in a theory, in, in, in law, uh, uh, state of the art, right?

And it, the state of the art one could argue that the state of the art in software development is that you do ship with known vulnerabilities and you use them at your own risk. You assume the risk. That's the word I was looking for.

Wiki, by the way, when you use open source software, you assume the risk, it, you know, you don't want to assume that risk. Don't use the open source software, Mike, the state of the art in software development today and, and a and a, a survey like check marks could be brought in as evidence. That's the state of the art.

That code has that kind of, of known vulnerabilities. And again, you use it at your own risk. We saw this with the CrowdStrike, right?

The CrowdStrike suits or the CrowdStrike incident last year when it caused all those blue screens, right? Delta went down. How many people missed their flights?

Delta's, CEO blamed it on CrowdStrike. And he, he brought, what was it? Uh, I forget how many hundreds of millions, maybe it was billion dollar suit.

You didn't hear anything about that suit, did you? That went away. Because again, I think when you look in the licensings through these things, there is an assumption of risk.

They don't, they don't, there's no warranty that it's free of defects or vulnerabilities. It's the state of the art that would be $375, please. I, I, I think there's some legitimacy in that argument, but I don't think most people, when they sign those licensing agreements understand what that implication is.

Well, you know, ignorance of the law is, no, excuse my friend. Anyway, hey, we, we've beat this one up a bit, but we need to take a break. Let's come back and talk a little bit about the CRA.

It's, it's real. The Eclipse Foundation seems to be getting out ahead of it. You're watching Textron Gang, Discover Textron Group, the epicenter of tech innovation.

We are your go-to for reaching IT leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us. You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more.

Join our satisfied clients. Let's revolutionize your tech journey. Contact us today and tell your story to the world in the most powerful way with Textron Group.

Hey folks, we're back. And well, yeah, this block might be connected to the previous block. We'll see.

But we're talking about the Cyber Resilience Act enacted by the European Union is scheduled to go into effect in about a year from now. I think it's September of 2026. And the Eclipse Foundation, which happens to be based in, uh, Europe these days, has a little toolkit out there to help people find out how they're gonna become compliant with this whole new process.

And some would say that maybe the EU is taking the lead on what the next bar for software development actually is gonna be. Because to Alan's point, maybe the state of the art does need to change, and this is a way to get there. But Jack, what's your assessment of all this?

'cause a lot of folks are, you know, on the one hand, there's some folks who think this is great, and other folks who think this is like, you know, overreach. One more time. Yeah.

Well, there's a lot of people who struggle in the software world, uh, with regulation. Well, let's talk a little bit about what the CRA really is. So the European Union is, you know, federation of a whole bunch of European states that are trying to standardize how any software or hardware product delivered and used in the EU is secured from a cybersecurity perspective.

And there are standard, there are standards concerning software, bill of materials testing for critical things. Software that may go say into a water plant or a gas plant has to get to, uh, third party certification. So third party has to review the cybersecurity aspects of that product to understand if it's secure, if the companies followed the rules.

So it's bringing a lot of standardization into cybersecurity, which in general I think is a very good thing. The regulations as regulations tend to be, are prob are very complex and require a lot of effort to prove compliance to them, which is not a bad thing, but that you're compliant to it. But it does put an additional burden on companies.

So the Eclipse Foundation is putting together sort of a toolkit that's gonna help organizations navigate through this and validate that they've done all the right steps and really help them understand what the right steps are. And this is an open source product. Uh, I think this is a really good thing if we just take a look at one particular aspect of this, which is software billing materials.

Uh, Alan and I were on a podcast earlier this week with, or last week, um, with another Textron gang member, uh, who said that something like 50% of organizations still don't do SBOs. And so this is going to really force people to do something. Which you think about it is really kind of common sense is do you understand every piece of software that you've included in your product?

Do you know what it is? Do you know what version you have? Is it secure?

Have you, do you have any comprehension of that? Comprehension of that? And if you don't have, if you haven't covered those basic steps, I think yeah, you're probably gonna have vulnerabilities in your product and a whole lot of other issues if you don't know what you've included.

So overall, the regulations, I think are a good thing. And the Eclipse Foundation, bringing tool kits in and another open source toolkit to help particularly smaller developers, uh, do this, I think is a very good thing. I thought that was notable, particularly here, which you're pointing out Jack about smaller teams, smaller organizations, they don't have the compliance staff.

They don't have necessarily all the talent or, or enough people to do all of the reporting that, um, you know, is gonna be necessary as regulations increase. And people figure out what CRA means and for their organization and, and do they wanna play in those markets? Or what do they have to be do to be able to, so I thought it was good that, um, you know, this comes out of, they have a, cliffs have has an open regulation compliance working group or something like that, that they came up with this and things that help medium and small businesses, you know, hooray.

'cause it's, it's one thing to do it at scale when you've got the, the resources and maybe the talent to do it. It's tough when you're a smaller organization. It is, you know, so Mike, you wrote an article on this one, and I, I actually did a video interview that I think played later on, on text Trump TV today with the VP of community from Eclipse Foundation about this.

And, and look, kudos to them for doing this. I've got two issues though. So the eu, the EU clearly has more political will to enact regulation and enforce it than maybe we do here in the us, right?

We have a hard time getting, you know, if it's not an executive order or, you know, mandate like that. We, we have a very hard time getting these things through Congress, right? A lot of special interests to play and a lot of reasons.

And, and so, you know, kudos to them for having the political will to do it, but sometimes some of their regulations, and I'm not saying it's the CRA in this case, but in other cases it's been where you have non-technical generalist people making rules around very technical, uh, you know, uh, rollouts on very technical subjects. And so there's a little tone deafness. There's a, maybe sometimes it's overreaching, sometimes it's under reaching.

The EU is proven to be, uh, flexible in, in turning the dials if, if it turns out to be that way. Oftentimes they roll out these things like in a test hall, you know, in a test for a while until it, it starts having before penalties kick in or whatever. My bigger issue though, is generally these kinds of rules sometimes could do more harm than good because they tend to be the lowest common denominator, right?

A relatively low bar that everyone could hit. And because they're actually an official rule, even though it's the lowest common denominator, it becomes the only common denominator. People stop right there.

They never go, they never aim higher. And, and so I hope that, you know, I think cyber resiliency is a great thing. I'm now expert on the CRA, but is it, is it a lowest common denominator or is it everything you would want?

I think, you know, when you talk to people, you know, and, and there's a lot of emotion here, they feel like it's, uh, a much higher bar than previously. And they also feel like maybe, you know, there are other regulations that address some of these issues within a particular vertical industry. But to your point, I don't know.

I kind of feel like I'd rather have a stringent rule with exceptions than I would like to have something that is so low, a bar that everybody just ignores it anyway. Uh, I want to put some, uh, information here because, uh, information, I always help the isaka and the ci, uh, CSA to do some, uh, framework and standards, right? So from my understanding in the US we do have some basic rule already, right from the nest.

I think there's a, uh, there's a rule. Let me see, yeah, from the na, there's nas, SSDF, which kind of like gave some, uh, governance on this area. But I do agree with majority of people here.

Like we don't have a specific rule or act to give people specific guidance. You know, like eu, they, they always play ahead of time for the regulations. Uh, if you think about the privacy law, right?

Uh, the EU come first, and then we have California privacy law and other thing. So I would expect to see in the future, US will put more effort on this area as well. My prediction, let's see how that happens.

Uh, but in this area, uh, I, I do, I really want to know some details about this law, right? Like, do they, do they have like a timeline to disclose information? Or like, do they have like a threshold like materiality, uh, how much revenue the company should have to involve in this law?

Otherwise, it's very hard for people try to adopt this all. So I don't know the answers to that, but I, I know how they've rolled out previous compliance rules. And those are the kinds of things generally, like what they'll say is, look, this rule's gonna go into effect January 1st, but we're not gonna enforce it until the next January and we'll roll it out and we'll, we'll take, you know, industry feedback and, and see where it is.

And they, they generally seem to be reasonable about it, but like I said, they're not necessarily technology experts, right? It, it's more that they have this, you know, vision of what's what they think is right, and they try to get us there. But I, you know, I Don't, I don know the answers this, I'm sorry.

This, this is, this is the regulation that, I mean, there, there's specifics in it, and then there are, you know, the all devil's in the details and sometimes it's not. It talks about, you know, integrated cybersecurity throughout essentially the, the whole product lifecycle planning, design development, et cetera, uh, through delivery. Um, the first, I think the first enforcement goes, it's a, it's like a December 11th or December 12th, something like that of 20 27, 27.

Um, but there's also default and critical software. And this goes to hardware too, not just soft software in this regulation. I, I'm not an expert at it for sure, but there's a lot of nuance in this.

And you know, it, it tells you what, you know, you're supposed to ship products that are free of vulnerabilities. Back to that discussion, what we just had, again. So is it realistic for organizations to do that by 2027?

No, not at all. But you do have to maintain a software bill of materials. That's something that they can do.

So it, I think the enforcement of this is gonna be tricky, even by the way. Um, there are, I think it's 24 hours or 48 hours you have to report when there's a vulnerability in your product, in your code. Um, so there's even reporting requirements for that.

Oftentimes these things move and evolve as the regulation, as the rules kinda get in, put in place of what does this mean and how do we enforce it, and when are we gonna enforce it? And you know, much like tariffs, those dates when they're gonna be enforced, often move, Jan, do you think this is gonna drive a bunch of AI adoption? Because I think if I look at these regulations and I'm like, they seem to be a perfect use case for using AI tools to figure out what I need to comply with.

Yes, I agree with you a hundred percent, particularly because the here has done what they did with GDPR, which is they've actually put some teeth in the regulations, which is the fines are, I can't remember what the base cash, it's like 50,000 EU fine, but, uh, up to two and a half percent of your revenue, right? So it can be very costly for a company, uh, if they get in trouble with this. So people are going to want to, at the very least, prove that they've made a good faith effort in following the regulations.

And I think this is a prime example of where AI tools can help. You know, here's the checklist of all the things. Here's what the AI tool's done.

We've gone through and done this and this and this. Here's our SBO M1 of the other interesting things, uh, and I think, Alan, you might find this interesting from, uh, what does the regulation, sort of how good or bad it is, is they require you to keep the SBOs and all the information for 10 years. So if you end of life a product, you still have to essentially maintain it and be able to do something with it and understand what's going on for 10 years after the a OL of EOL of a product, right?

So when you have these orphan products that people are still dependent on, uh, IE let's say, I don't know, windows, whatever it was, windows nine five, that's embedded in so many different things, you still have to be responsible for it after the fact, right? I mean, 10 years I think may find, they may find to be just too long a tail, but that May, and that, that may be, but it's, I think the EU has put a stake in the ground and said, we need to start someplace. We're starting here.

We're serious about it. You guys better be serious about it. And, you know, AI tools and the Eclipse Foundation, I think there'll be a lot of professional organizations involved in this as well.

A lot of for-profit tools that are going to be involved in it, uh, particularly around third party testing services and third party validation services. But again, it's, you know, let's put some teeth into this. Let's be serious about it and prioritize cybersecurity, which was a cybersecurity guy.

I'm all for. Well, they put teeth into it, Jack, because there's different tiers on the penalties. There's like, you know, omissions and, you know, inclusions of things that didn't happen or didn't report.

5% of last year's annual revenue, global annual revenue. And he's like, yeah, that's a lot of money, obviously. Look, I, you know, I applaud the, again, we applaud the EU for taking astan Jack, as you say, planting the flag.

We'll, we'll see how it goes. And, and, you know, this is somewhere we've gotta do something right. And so more power to them and, uh, we'll see how it works out.

We've gotta take a break though. We're gonna come back and talk about crypto and pension funds, widows and orphans you are watching. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry.

com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more. com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more.

com. Home of Security Bloggers Network. Hey, folks, we're back.

And one of the things that we missed last week, 'cause we just ran outta time, was this whole issue that's emerging about linking, uh, 4 0 1 Ks to, uh, crypto funds and trying to equate some value proposition out of that, that I can't tell if this is good news or bad news. I mean, in theory, maybe it makes everybody's 401k better, or is this some sort of big kind of, you know, scheme that we're now connecting everybody's 401k to and suddenly nobody's gonna have any money when they need it. Alan, what's your take here?

Huh? I'm of two minds here, right? I, I remember when, uh, president George W.

Bush and his administration floated the idea of allowing people to, uh, invest their social security dollars themselves, like put their social security money into the market, you know, and, and they would, I didn't agree with that because I mean, the idea behind social security is that we don't turn our seniors out into the street homeless and panelists and unable to support themselves. Not that social security gives you such a great standard of living, but it's something we don't live in a world of pensions. The overwhelming majority of us, unless you have like a civil service or some kind of union job, you don't have a pension.

Even if you have a union job, you may not have a pension. We rely on 401k to supplement what we get from Social Security. And as I get older, this becomes more and more real to me, right?

I didn't really care about it as much 20 years ago. Um, uh, but at the end of the day, 401k is a voluntary mechanism. No one puts a gun to your head and says you have to have a 401k.

And part of the beauty of the 401k is look, if you wanna take the safe road in your 401k and invest it, as I said earlier, in the lead in widows and orphans kind of investments, stable, stable return accounts and asset, you know, verified accounts and so forth, you could do that. And if you want to be a little bit more, you know, less risk adverse and, and, and make your bets in some more volatile kinds of funds and stocks and investments, you could do that too. I think crypto, as we saw over the last five years, six years, is a very volatile in investment.

There's a lot of people made a lot of money in crypto, a lot of people who've lost a lot of money in crypto. It's not as maybe highly regulated as, as, uh, securities are and stocks and so forth. However, it's your money and your risk assumption of the risk, right?

That's part of part of what makes America, America. My, my only thing is though, if you're gonna go throw all your 401k into crypto and then you goes to hell in a hand basket because it's not regulated and there are scams, and we've seen these things happen, I don't wanna be responsible to pay your hospital bills, your food bills, or your shelter. You get your social security and good luck to you.

Um, so, you know, I err on the side of, it's a 401k, people get to invest where they want, but I don't want us to be responsible for people who lose their shirts in a, in a highly volatile, risky investment. How's that for playing both sides? There you go.

Jack, what's your take here? I know you've kind of been following some of the political machinations, but is this, is this an effort to shore up the crypto folks with our money? No, I think, you know, from a, from an investment perspective, there's, there's a couple things to think about.

First off, 4 0 1 Ks aren't individually directly managed. So you don't, if you have money in a 401k, you can't go and tell your 401k manager, I want to buy Intel stock or Nvidia stock, right? You can't, that's not how it works.

You buy into, you, you allocate your investment funds into a set of funds that are managed by professional managers who are continuously rebalancing and moving the money around in their investments, right? So the, you're a humiliating your, your managing the risk a little bit around that. The second part is this gives those investment managers a way to tap into yet another vehicle to invest in, which does have higher risk, but yes, potential for our return.

Now, as Alan said, and we're all of an age where we're thinking about what, how, you know, what's the balance in that, that account, and how much am I gonna have when I stop working in five, 10 or one year or 20 years? The people who are very early on in the workforce are much more, uh, are much less risk averse, much more willing to take the risk for the potential large gain, right? You know, when, when I entered the professional workforce many, many years ago, I didn't know what a 401k fund was.

I didn't understand any of this. And, you know, they're like, Hey, you should do, you know, my friends were like, you should do this. It's good for the long term.

They're like, okay, I put some money in there and I, I, I literally forgot about it, right? It just gets taken out of your paycheck and you forget about it. But people who are savvy might be very interested in saying, let's see what money we can make, right?

It's low risk to me because if I lose everything, my 401k after two years of investing, so big deal, right? I still got another 35 years to work to put into it. I, I agree.

I agree. I mean, you know, our generation, Jack and I include you in my generation, Mike and Mitch, I know you're in my generation Wiki, you might be a little younger, but we were really the first generation where pensions, we knew very few people who had pensions. 401k became the, the, the vehicle IRA's 4 0 1 Ks became our vehicles for, for retirement funding.

Now, I, I look at my children, right? I had them open 4 0 1 Ks from their very first jobs when they were teenagers, and, you know, they're in their early to mid twenties, and they, you know, they, they have healthy numbers, healthy 401k accounts already, and you know, they're only in their mid to twenties, early mid twenties. By the time they're my age that, that, you know, they should have some serious money put away in there, right?

If they keep at it, and I, and I preach this to them. Couple of things I want to make clear though. Number one, it's not just crypto money that can, or crypto investments that'll be allowed.

There's also private equity. You want to talk about playing roulette. There's private equity investments allowed and real estate, which is maybe a little safer, who knows than, than let's say investing in Bitcoin.

But the, but the deal is who's really pushing for this? Well, you have, you do have a president who has a financial stake in crypto companies. So there is a little self-dealing, there's self-dealing and self-serving there, but I think the real people pushing this are the banks, the, because it's the banks that most of the investment folks are owned by banks, right?

We, this was a recourse, recourse coming outta the, uh, great recession, right? The banks own most of the big investment houses, and they want the opportunity to take this $12 trillion or whatever it is, and turn it loose on things other than kind of boring mutual funds, Jack, right? And, and this is what they do.

You know, they figure people will be trading more, they'll be moving money around more, even if it's fun to fund or what have you. I don't know exactly how it's gonna work, but they want the freedom to play with that money, and they, they think there's profit to be made, and I think they're the ones pushing this Well, they make money on their fees and all of that, right? That goes through it.

So, I mean, you, you bring up Trump and there of course, there's also the, you know, he's the crypto president and has his own coin and all that kind of stuff. So he's directly conflicted. But I guess we'll get, I think, uh, see Friday he had his performance review with put Putin, so we should hear anytime soon how he did in his first seven months in his job.

So Absolutely. We'll hear about that later. Yeah, we'll, we'll discuss that later this week, but yeah.

But, you know, make no mistake, this is, I think Wall Street is behind this Well, absolutely. It's an investor community. Absolutely.

Mm-hmm. It's another, it's another product In the vehicle. Why did they care if there's more homeless on the street that we can then call in the national guardianship amount?

I'm only gonna be in town for the weekend. If I might bring one more thing in real quickly, which is that, uh, uh, the chairman of the SEC was interviewed by Maria Bar Roma this morning, and he basically said that he, the direction he was given by Trump and he believes in, is to make America the crypto capital of the world and to have the world run on American technology. Right?

And this is one of many things that are being done with sort of that in mind. But to your point, Alan, I agree that the banks and the trading firms make money on every time a transaction occurs and they see all of this crypto transaction happening and all of the, the PE equity transactions happening, and they're not getting a piece of the pie, and they would like a piece of that pie. But you know what, let, let's end it there though.

Wiki, thank you for joining us today and joining the gang. We look forward to having our future gang episodes. Jack, Mitch, Mike.

Hey, man. Way to kick off Monday. Let's, let's make this week happen.

We do have a, uh, a full tech drunk TV schedule immediately following today's show. Stay tuned for that. Uh, I think some more of our Black hat interviews might still be playing if you're into that.

Um, we'll be back tomorrow with another fresh episode of The Gang, more Gang members. Until then is Alan Shimel. We're out.