Techstrong Gang – April 15, 2024

Hey, everyone. Happy Monday. It's another great week here at Techstrong.

We've got a lot to go over today. How smart will AI get open tofu and an open war with HashiCorp seems and what, what's going on with DevSecOps and the the Cyber Resilience Act? All this and more on Textron Gang.

Hey everyone, welcome to Text and Gain on this Fire, fire Monday. Let me introduce you to our gang members for today. First of all, joining us remotely, again from the Mile High City, our CTO and Chief for Research Officer Mitch Ashley.

Hey, Mitch, welcome. Hope is well. Hey, good to see everybody.

Well, hello from the Mile High City. Yep. And also joining us from out West New Mexico style.

Our, uh, frequent gang member guest, Tracy Reagan. Hey, Tracy. How are you?

I'm good. Glad to be here. It's always a it's always fun.

Always, always fun. And then here in studio at our Boca Raton, Florida headquarters, the ultimate Yankees fan sporting his Yankees shirt. Well, they're off to a good start.

We'll talk to me after July 4th, the all-star break. We'll see if he's still wearing it. Mike Ard.

Hey, Mike. Hey guys. How's everybody doing?

You gotta represent, man. You gotta, you gotta look. They're doing well.

They're playing Cleveland and we will, we'll see what's happening. Anyway, so we've got a busy Monday as usual. Mike, you want to kick things off?

Sure, I'd love to. Last week I've had the pleasure of going out to the, uh, Google Cloud next conference out in Las Vegas with about maybe 20,000 of my closest friends. Mm-Hmm.

Um, and it was interesting to watch the evolution of ai, and I'd love to get your folks' opinion about this, but what seems to be happening is we're rapidly moving past the platform is gonna generate some code or create an article to where it's actually orchestrating tasks. And the way that that's occurring is that there's reasoning engines are booming inside the LLM are able to coordinate things. So you'll be able to soon say, I don't know, uh, bill me a website.

And it will order those tasks, create the code, and then execute them. And then you can tailor it accordingly. And there's a bunch of startups in the, uh, cybersecurity space doing similar things.

There's an outfit called Symbian who has built their own LLM, and it pretty much does the same thing for cybersecurity tasks. So the question then becomes, how smart do we think AI is about to get? And I'll start with Tracy, but are we on the cusp of some changing roles for the way we think about our jobs?

Because it seems to me a lot of our effort will be automated and maybe our, we will just be a bunch of supervisors for all this stuff. But where are we headed, Tracy? I hope that's the case.

I don't wanna say that right off, because, you know, I have spent most of my career trying to convince people is to stop scripting. Seriously. We are, you know, we're, we're, we're software developers.

We create the most interesting software in the world. We, we automate banking, we automate trading, we automate medical processing, yet we can't figure out how to get rid of a, a script that does a DevOps process. Come on.

It is time. It is totally time that we get rid of the scripting process and what, uh, we're seeing from Google and, and there, you know, especially around DevOps is let's, let's stop scripting. Let's just let something else do that.

Because it, scripting is really a low level function, and I don't believe that any DevOps engineer should be spending time doing it. Uh, and that's just how I've always felt about scripts. And I'm glad to see that we're finally going, oh, we, we, you know, to be honest, these scripts, uh, open makes software that, my previous company, we had a rules-based engine that generated, uh, make, make an ANS scripts.

So it's way doable. It's, it, this technology has been doable for quite some time. And it's great fun to put a AI in front of it and say, you know, it's something new.

It's a cultural shift that AI is bringing into, uh, in, into the picture. And it's gonna allow us to get rid of some of these really mundane tasks that cause a lot of errors, because humans make mistakes in mundane tasks. So let a machine do it.

You know, Tracy, part of my heart hurts to hear you say you shouldn't be scripting anymore. Um, I just don't know how to respond to that, but I do understand why you're saying it, which is we don't need scripts to, to do everything like we have been. Right.

Like you said, we, we have already had tools to do scripting for us. And now obviously that's, that's where the, the role of this, uh, Gemini Cloud assist, you know, taking the co-pilot idea one layer further, which is good to see. We're moving out of the IDE and into kind of more the management console or the process of what's happening.

So I would imagine the tasks that you can give it or ask it to do, or code, code up something or write some automate something for you, or if it does it, um, we'll give more sophisticated over time. It was good to see us move into this era. And, uh, Symbian is also an interesting company.

They have, they have the model of, you know, it's manual now, then you do copilot, then we automate it, and then autonomous. You know, that's sort of the danger will Robinson phase. Yep.

You know, I, I understand that, that at attachment, I really do understand the attachment to scripting. I had one person when I was going off at a conference once about scripting and how we need to get away from it. He came up to me and he said, you know, I take pride in my scripts.

I I feel like I am the, you know, I, I'm, I'm the shoe cobbler making the perfect shoe. And my response to 'em was, yes. And your children never have them.

That's Funny. So that is the problem. It takes too long.

Um, you know, so I'm listening to this and I, I've got a couple of thoughts on this whole subject. There's no surprise. Um, but first of all, I'm reminded of the old two song Meet the New Boss, same as the old boss.

So what we're saying is, instead of humans doing scripts, let's let AI do the scripts right. And AI will write the scripts better. Okay.

So we'll have AI write the scripts better, but overall though, when we say things like, how smart will AI get, we're not really talking about smart in my mind. 'cause when I hear how smart will AI get, I'm thinking, are we reaching general intelligence? Are we getting to the sky net point and, and Skymaster, whatever the heck it's called, point.

What we're really seeing here is the continued evolution of the gen AI technology that we saw come out about a little over a year now ago, you know, with open AI and in the commercials, you know, out into the open. And, but this is what we thought it was going to do. It was going to continue taking these baby steps and, and piecing this stuff together and getting better.

I think what surprises us is at the speed of the evolution, at the speed of, you know, any, well, I'm gonna show my age, but how many people remember the Roers strain? Oh, one of my favorite movies. What a great movie that was.

Right? And if you haven't watched it, go watch it somewhere on, it must be available somewhere. It is for free on YouTube or something.

But anyway, the thing about the Roers strain was that that alien bug or whatever in a virus, it started the, the replication sped up so much as it, it was like continuously evolving in, in rapid time. We're saying the same thing with this AI is it's, it's continuously evolving in a faster and faster, in a more condensed timeframe. So yes, it's doing, you know, tasks like that.

I had a chance, you know, it's intern season. We've got a lot of people calling us here at Techron to do internships. And one of the questions I've been asking the interns is, Hey, you're in college right now.

You wanna be in marketing, you wanna be in coding, you wanna be in tech, or you want a job. Right? How do you think AI's going to impact by the time you graduate school?

And some of these people are juniors, sophomores going to juniors, rising seniors. Well, well now you're just scaring 'em. Well, we know.

I want make sure nice to be mean to the kids. Alan, I'm not being mean. I want that.

Because the answer I'm looking for is, it's not gonna replace me, but I'm going to use it to be better. Mm-Hmm. Right.

I'm gonna be the jockey of this horse. It's not riding me or making me up, sending me to the, you know, to the horse meat factory glue factories or the glue factory. Yes.

I never understood the glue factory thing. It was just the hoofs that that's where they went back in the day. But, um, anyway, I think that's the, that right there is the key.

I think as we go forward, everybody's gonna have their own really a digital assistant. And that assistant's gonna be a lot smarter than you think. And it's gonna be able to do things for you that previously you would've thought, well, let me call, you know, this one, that one, that one, that one.

And I'll orchestrate all this stuff. And you know, sometime in about four months from now, I'll get it. It's gonna be more like, you know, a couple hours.

I'm gonna get it. What's gonna be interesting to me is the cultural side of this is, well, let's say we can all spin up a website in half a day or whatever it's gonna be, well, if you do it, I do it. And we're all working in the same company.

We kind of have to figure out how to align that a little bit. And so there's gonna be cultural issues around how we make all our digital assistants kind of come together and, and, and collaborate. We're gonna have to find ways to check the output for all of that, since some of it might wind up being redundant, some of it might be even conflicting.

So we gotta figure out, um, all these cultural issues. And to me, that's starting to become the bigger story. I mean, I think the technology side of this equation is being solved rapidly, and, but I'm not sure that we have actually thought through all the cultural implications.

Absolutely. I think there's a I agree. I think there's a place.

So I think the cultural issues are an, is that that's where it's at. It's us being able to adopt it and understand it. I think of the cultural issue also of when does AI move past a single person's use a single user, you know, AI's in the IDE and helping you do your one thing.

Well, how do you do a website when six people are working on it? Right. And AI is working with you to help create that.

So we aren't all creating the same but different websites, by the way. Um, I'm claiming it here. I've looked, and I haven't seen anybody use this term, so I'm officially gonna make it one that I came up with even if I didn't.

But, um, in the, uh, in the Bruce Willis genre, the Aerosmith genre, we have a new term for this dystopian state. It's now called AI Mageddon. Okay.

Is that a Christmas movie? That is, yes. Yeah.

But, um, so how long though? So even having an AI assistant, there's a very thin line between being an assistant, a manager, and then ruling you. Right?

And it, at what point do we start needing sort of asimov's rules of robotics here to, to put parameters and stops around how much that AI helps you? Um, and, and did we wind up, what was the movie where humans were just fat blobs sitting in chairs on a spaceship and, and kind of the robots and the ai, Every, every science fiction movie we ever saw? No, But there was, I think it was Wally or Wally or something like that, right?

Yeah, yeah. It was Wally. And, um, you know, how long until we reached Wally mode or not Wally say that's a different mode.

But, um, I, I think that's, You know, the, the technology is going to skyrocket. Um, I like, I like to call it apply to AI because now when we write software, we can, we can begin sorting out these different, um, basically algorithms and AI models that we could potentially incorporate into building solutions. Um, but I don't know if we're gonna be there in our lifetimes where, uh, that, that machines are taking over.

I, you know, I I don't really believe that can ha that will happen. And, you know, maybe it could, uh, and maybe machines will take over a lot of the mundane things that we don't wanna do. Um, I wouldn't mind having, I want a robot like in, um, lost, lost in space.

I want one of those robots that can pick heavy things up. It could keep my house Probably the robot. Wouldn't that Be awesome?

I like the more benign robot of the jets, of the jets since, you know, she's a house clean, the manic Depressive Robot. Yeah. I mean, in the, in the, yeah.

The, the robot in the lot space can go right away. So I would say there's two issues that have not been addressed here, right? One is we do tend to overly rely on the machine and we trust that machine because somehow or other we think it's convincingly telling us something.

And we all know people in our lives who convincingly tell us things that are routinely false. Um, so we need to trust and verify. We Need, don't need to go into politics, Mike.

We need, we need the Ronald Reagan doctrine here for AI Trust Verify. Yep. And then You, you mentioned the, um, Andromeda screen, which is a Michael Kreton book and, and movie.

I think it was the first movie made out of one of his books. What's interesting that spoiler alert, if you haven't watched him by now, it's still worth watching you. But I'll give you the spoiler alert.

What happens is the, uh, the virus or, or the, the cell ends up, um, replicating and changing itself so much. It becomes benign instead of being dangerous. Maybe that's a possible path for AI too.

Maybe it becomes dangerous and it keeps evolving and becomes benign as well. We don't know what the, But, but do we survive? That is the question.

We May be not be around to see it, but, But our pet Keep mind. We have, we have seen the dangers of ai, right? If it's true about the, um, the targeting of the World Kitchen, uh, volunteers, if that was something that was pushed through an AI process, and as Mike pointed out, we, you know, may have trusted, but there was no verification, then we as humans have to acknowledge that there can be danger in ai depending on how it's applied.

It's obviously in war, it can be extremely dangerous. And how do we as humans, from a cultural perspective, start using AI and put the correct guardrails around it? And, and to that point, we also have to figure out how to debug these issues when they do arise.

'cause sometimes this stuff is so complex that, and that clear to me, we're gonna know exactly how it went wrong. You know, to, I think a good analogy for this is the whole autonomous driving thing. You know, the autonomous driving capability and software has really advanced, let's say over the last seven years, right?

But it's kinda like when we, when we, uh, subscribe trans, uh, transcripts, 90% sounds great. Wow. 90%, but then nine outta 10 words are good.

One outta 10 words aren't good. 500 word article 50 words aren't good. Uh, allowing AI to automate cybersecurity is great until it's not right.

Because 90 percent's not good enough, 99% may not be good enough. So the, the, the question becomes, what is the acceptable threshold of AI control, automation, whatever you want to talk, call it, that we're willing to say, okay, let's, let's turn it over to the ai. I think there's a whole area where I don't think we've explored enough either.

And that is, how do you recreate what AI did, especially in generative AI since it's non-deterministic and its outcomes. So if you, if it, we did have something bad happen, like you were talking about Tracy, um, can you truly go back and look and see what actually caused it, right? When the same outcome may not be the same every time, or maybe we need another governor in AI that says, I need you to be consistent.

Needs you to come up regulated with the one answer that you think is the best answer, not lots of answers. That might be good. Fair enough.

Hey guys, the AI is telling me we've gone on long enough on this subject and I've gotta cut it right now. Um, but thanks for talking to us on this one. We're gonna take a quick break on Techstrong Gang, and we're coming back with some open tofu.

Welcome back, everybody. It may come as a shock and a surprise to you, but there's lawyers involved in software disputes and there's guns And muddy, All right? The latest one involves Terraform, which, um, they changed some of the licensing terms over at Hashi Corp.

And, uh, they didn't on the face of it, look extensive, but it seems like they are having quite the downstream impact on a lot of folks out there. And that led to a fork being created called Open Tofu. And naturally it was probably only a matter of time, but some letters have been exchanged.

And the Hashi Corp folks are claiming that the folks who forked Terraform to create open Tofu might have, uh, lifted some code that they shouldn't have, even though theoretically it's supposed to be all open source code. So who knows? And, uh, you know, open Tofu this last week said we did not do so, and now the case proceeds from there.

But let's start with Tracy. You've been involved in these kinds of cases before. Is this kind of just a, an effort to Thor a competitor, or is there something more real here?

Uh, it's a shift that's not happy in my world. Um, if we think about it, uh, Terraform was always owned by Hashi Corp. It was a project that was never contributed to any kind of an open source foundation.

So, you know, they had it under, I think it was the Mozilla license. Um, and then at some point they decided to use the, the BSL, the Business Source license. And, and in a way that BSL is more like an escrow account, right?

It says, here's the source code, if you ever need to use it, you can use it internally to fix your, uh, your version if you choose to do so. Um, but you, it's limited in terms of you can't create a company around it. So it is restricting competition.

Um, what I didn't like about that was it was an open source project. It's like, what are we going back to, you know, England in the 12 hundreds where we had Lords asking people to do things that, you know, on pennies on what they were making and not get to the benefit of potentially using it in something that they may wanna take to market. Um, now it got forked, uh, by a group of people.

Hashi Corp is a member of Linux Foundation and CNCF, but that doesn't mean the project was, uh, a part of the Linux Foundation and CNCF. So while I believe that if you, if you wanna work on an open source project, I think this teaches us to be careful and don't go work on an open source project for a company who, who's gonna maintain that, that code and do what they want with it. It should be brought to an Apache or a Linux Foundation.

But at the same side, I don't know if the Linux Foundation should be, um, moving forward with Open Tofu. Um, it it, because it, they never actually own the code. And when, you know, it's, it's hard because did they work it before it went to the BSL or was it during it, its Mozilla P period, you know, when would, when did that fork occur?

So I think it's gonna open up a really interesting lawsuit if that's where it ends up. Uh, but we, uh, at Deploy Hub and, and the TIUs team, we were using Terraform, we moved away from it. And we didn't go to Open Tofu for this reason, because we don't know what that, uh, what the result will be.

And I would say if I'm using an open source product, I would wanna use it from a, for a foundation that is managing open source projects because they protect, uh, they protect the open source contributor in this way. So I've got a lot, a lot of experience in this going back 25, 30 years. Mitchell lived this with me at Still Secure.

You start messing with licensing of software open source software, and them, they're fighting words to the open source community, even if it is relatively benign like the BSL is. But the BSL, if I'm not mistaken, jc, these sort of paying customers can start playing with the code. I don't think free users were allowed to play with the code, even just for their own benefit, right?

And, you know, part of an open Source that may be the case. Yeah. Yeah.

Part Of an source. The second Astro account, Part of an open source license too, is, is that any changes you make, you have to contribute back generally into the community. And then the open source maintainers decide whether they want to make that part of the, the mainstream or it's just sort of a, an appendage hanging out there.

That being said though, look, we didn't always have foundations ruling open source software, right? There was what I call the big brother era of open source, let's say from 2000 to 2012 or in that period where generally most open source projects were supported and basically run lock, stock, and barrel by a single vendor in Mitchell and MA's time. The big, the big examples of this insecurity were, um, snort, which was Marty Rash and, and the folks at Sourcefire versus, uh, tenable Security, Ron Goler and, and Rene Json, uh, of, of, uh, Mitchell, what's Tenable ness?

Nessus. Nessus. 7.

7, Ron and Reno said, you know what, it's no longer gonna be open source. It'll still be free, but it's, you don't get the source code and you could use it free in only certain parameters or whatever. The world exploded, much like we're seeing here with Open Tofu, right?

Everybody was up in arms, there was a fork made. I think the fork is called Open Vast. VASI think it might even still be out there.

The fact is, that code, once you release code under open source, anybody could take that code and run with it, right? So if the Open Tofu group takes the last version of, of Terraform that was released under the open source license slices and makes the fork from that point on, and we've had forks, right? Hudson to Jenkins is probably one of the most famous, but once, so if they fork from that code base, they could run any way they want and it remains open source and there's no repercussions, there's no legal ramifications or anything.

What's going on in, in this case though, that made it a little different was, number one, open Tofu was adopted by CNCF Linux Foundation as a project, which gave it a, a stamp of approval against a a a a, a corporate going against the interest of a corporate member of the foundation. And that is where foundations get a little sticky. 'cause politics come into play.

Number two, though, the claim here is, it's not that they did that. Of course you could fork an open source version, but what Hashi Corp is saying it, and by the way, this whole BSL thing has turned into a slight disaster for half Hashi Corp, right? Mitchell Hashimoto left Hashi Corp in December.

Uh, you know, they got real corporate people running it. Rumor is they've hired, uh, bankers to start selling the company or shopping the company and, and the community is up in arms with them about this move though. I, I feel if they just would've kept their heads down, it would've blown over.

But anyway, um, the claim by Hashi Corp is that Open Tofu didn't just take the last open source version and fork it, that there was a piece of code that was specifically put in after the open source for, after the switch of licenses. And that piece of code found its way into open Tofu. Now, the open Tofu people said BS that code was not from before or was not from after the license change and it's not in there.

And they've said a bunch of things. Friend of mine and Mitchell as well knows, and it's great. He probably, I don't know if you know Matt to say Matt, long time open source guy.

I've been talking with Matt since I was writing at Network World on, uh, open Source Fact and Fiction 15 years ago. Um, Matt Claims, and Matt knows what he's talking about. Matt claims that the code in question was put in after the change in license and that Open Tofu did probably use code that was put in after the, the, the license code change.

And if that's the case, they gotta take that out, clean room up a, a new module to replace that. And that's how you get, you know, that's the only way to go forward here. Open.

How old Tracy, how Are you? Tofu is in, sorry. Open Tofu has responded and said, here's the file book here, here's the file before the had that code in it, but they made some kinda loose reference to similar or light code or wasn't, it wasn't like word for word.

This is, you know, letter for letter, the code that was before the, there, before the license and after. So it sounds like Matt may be right, but there's certainly some gray area in what happened with this. We don't know yet.

Tracy, how hard is it to replace that code and is this gonna wind up being a proverbial tempest and a teapot once the code is replaced? Well, I think if it depends on how deep that code is, you know, if the code is something at a lower level that, uh, a lot of the additional, all the other functionality depends on, it's gonna be a, a challenge to take it out, uh, and to replace it where it doesn't look the same, right? Because that's the whole point.

You have to make it look, it has to function differently. Uh, it can't just change the way it's written. Tracy, if it was in fact put in after the license change, I don't think it's gonna be that hard.

'cause it's really relatively recent. Unless it's a, it was a fixed for something lower level. But if it's something at the higher level, you know, it, it shouldn't be a big deal to take out.

Right? And if it was, but you know what, Alan, I don't, I don't know for sure if Terraform was ever A-C-N-C-F project. Was it?

I know HashiCorp Was part No. Terraform, was it HashiCorp Terraform, right? HashiCorp was a sponsor member, active participant in LF and CNCF.

Yes. I don't think they ever donated their, I don't think they did either. Which al which also complicates this puzzle.

Yeah. Even though I realize It's a political issue that becomes politics, right? How much money is how she caught paying as a sponsor, and how much influence does that buy them?

Yeah. And that, that's exactly a question here. Um, And, and, and cs, uh, Lennox Founda, this foundation never owned the open source projects in the first place.

It was always owned by Terraform or Hashi Corp. And they had every right to change the license over without having any impact to anyone. No.

Yeah, I don't think anyone is denying Hashi the right to change their license, though. Open source users, as I said, they, that that's fighting words to them. I, we saw this in, in, in essence.

Yeah. It's, it's kind of a snotty thing to do, to be quite honest. Yeah, No, I, we Did all this work and now we're gonna make sure nobody can use it.

Let me, you know, I, so at the time, tenable did this, I was clearly on the side of you, just like you chasey you don't do that, it's not right. Blah, blah, blah, blah. Over the last 20 years, I've had a chance to be really good friends with Ron Goler and I respect Ron and his wife Cindy, and everything they do.

Um, and I've, I've talked about this with Rod while watching, you know, he's a big Baltimore Ravens fan while watching football, some Ravens games. Him and I sat and talk about it. What was the reason behind it for Tenable?

And I suspect it's the same thing around Hatchy, is that there were most of the vulnerability scanners on the market at the time, including our Ven scanner at that still secure called Van that Mitchell and I were two of the three co-founders on were actually using Nessus under the covers. That was the scanning engine, right? And almost the entire vulnerability industry was built on Nessus under the covers that was the scanner and Was Snort for Same thing would snort for I-D-S-I-P-S.

That was the, that was the I-D-S-I-P-S under the covers. And, and Ron was saying, Hey, all these companies, not only are they not paying us, they're competing with us using our old product that I'm paying money to keep up and maintain and continue developing. It's wrong.

And has she, coop, I think has the same thing. Now, if you wanna see a different way of, of dealing with that issue, look at Sourcefire, Marty Rush and the Sourcefire team, they never made Snort not open source. Snort remained open source and they continued developing it.

But what they did is they took a razor razor blade model. The engine of Snort was open source, but the rules, right? Your Snort rules set that recognized, you know, malicious software and so forth, they said that wasn't open source.

That was, that was proprietary stuff. And if you wanted to use the rule set, you had to pay source fire or you could get it free. But there was like a month delay from when they put it out until you can get it.

And for whatever reason, the open source community was good with that. Similar thing to Nessus, Nessus is only as good as the Nale scripts that identify key vulnerabilities. Ron could have kept the Nessus engine open source and just made money off the Nale scripts.

But, and, but people can write their own nale scripts as we did. We set up an operation in India that wrote our own Nale scripts, and we continued to use the old open source engine of, of Nessus. Other people were writing their own snort rules.

Mitchell, if Put your in the weeds, I'm Sorry, put put your CTO hat on for a second. When you see these types of licenses and you see the level of noise that gets generated by them, are you just gonna run away from certain terms and conditions and licenses because you know that there's gonna be trouble down the road? And so, you know, does this become a bigger factor in your decision about what software you're actually gonna use?

I mean, Tracy alluded to this at the top of the segment here, where she was saying, you know, she looked at all that stuff and deliberately decided to shy away from it. I, I think it's, it's an eyes wide open you have to take, which is, there are different models we've talked about with open source. There are, you know, a, a consortium or group sponsored projects.

There are company, uh, sponsored projects. There's in the basement of my house projects kind of things. And you not only wanna look at the license, but you know, look at who's, who's contributing, who's developing, who's supporting.

And you know, the, these kind of disputes are, are more rare. I think they're more pretty rare. They don't happen that often.

Um, part of it is because most of the, the industry operates on Goodwill, even to the point of, you know, some people see it as, I only work with companies that get it about open source, right? They truly support open source in the model and how all of that works versus the, I use this word, it's not my word, but the profiteer who's kind of using open source, sorta, but they're not really an open source company. They're just putting out a version of something that's open source.

So I I, you know, I think this is gonna be a wrinkle that goes away. You know, they said Stop and disease, you know, with, with what you're doing with Open Tofu, well, it'll have to get worked out. What, what happened and how do we fix it?

Right? They're not gonna stop open Tofu, tofu and unless is some widespread thing that they copied a whole bunch of stuff and that accusation shouldn't be made. So I, I think you just have to look at who am I putting my trust in?

Am I putting in something that's foundation supported? Is it a vendor supported? Okay, I know that I'm going in eyes wide open, or is it, uh, Mitch and his basement and his friends?

Or maybe just even Hint, which is kind of what those snorting nessus were kind of really individual people doing it. So, and I think that there's a broader conversation though, that we, that this is creating. Yep.

And that is about how to start a company. Can you monetize open source? If you're like deploy hub and you contributed 80% of your code base held back a certain section that you can monetize on.

Um, but does that make that, uh, less valuable, right? Uh, these, these, when we have these kinds of rifts, um, from a legal perspective, it, it does cause concern for products and companies that are built on open source. And to be quite honest, open source wouldn't exist without companies like a Deploy hub who are contributing code and creating a marketplace for open source code and monetizing on additional features that we can add to it.

So part of this discussion is a cause for concern for companies like mine that are, are living on in the open source world and believe in it and have a heart for it. And if Hashi Corp didn't have a heart for it in the first place, they should have always used a best cell. They should have never, ever open sourced it in the first place.

Because you have to be committed behind it. You have to be committed to your community. So I think Hashi Corp would say they are committed to their community and their community of people who help support them.

Their commercial project, they, they're also committed to their shareholders and investors and employees to keep the lights on. That be, that Is the problem. That becomes the problem, right?

That's the issue. Money always is the root of all evil. Yes.

But, but here's the, here's the bigger question on this or the bigger issue that really we haven't touched on. You know, I mentioned before the Big Brother era of open source and now we're in the foundation era of open source. And before that, I, I, this is my own stuff.

I don't, you know, like Mitchell said before, I've been using this though for a long time before the Big Brother era, I think we were in the cathedral and bizarre era. If you've ever read that book, great book, great book, you know, where you had Dr. Stillman's view of down with the Man and Killed the Pigs and everything should be free and open.

I think we are passing out of this golden era of foundational open source that was kumbaya. Everybody. We're going to give everybody a base.

And then you build on top of that base. And that's how you differentiate, you know, difference yourself from your competition. Um, I think the issue is a lot of companies are realizing it's really hard, really hard to make a go of it when 96% or 97% of the people using the code don't give you a dime.

And 95% don't contribute in any way whatsoever that other companies take the code that you're contributing to and, and become competitors. And they've got shareholders and investors and employees to answer for. And it's not just HashiCorp Red Hat themselves.

Red Hat did this too. Red Hat themselves have changed their licensing on RL. There's any number of companies that are really starting to review this now.

And that was always the big boogaloo about adopting open source in the enterprise. Who do, who am I gonna, who am I gonna call? Who is someone gonna pull the rug out from under me?

And this is something, you know, this one will get easily handled. 'cause I think it's a very isolated piece of code that's gonna be taken out of the open tofu distribution. And the open tofu people will have a clean room reversion replacement for, I've seen it happen before.

Bigger issue is do open source business models work in the next era, right? When AI starts writing your code, what's the open source license behind that? There's any number of things.

You go to CubeCon and you see how crowded it is and it's great how many of those companies become successful from a financial point of view because they all can't. And, and I think we're seeing that come through too. I think we might be moving into the next era, a post foundational era of open source where companies who like to deploy Hub Tracy have to do what's best for your investors and your employees in terms of, and you gotta balance that with what's best for the community.

'cause what's best for the community isn't always, always best for the software provider. With that being said, though, we beat this to death. Let's take a break on Textron gag.

We'll be right back. All right, welcome back to the third block. And we're gonna be talking about what's going on with all these different consortiums because, well, it's the next logical topic, but we've seen lover or hated that the EU has this Cyber Resiliency Act and it has, uh, arguably some prescriptive requirements for what you can do with securing your open source software, supply chain or software in general.

And the Eclipse Foundation is now saying that they're gonna create a framework someday soon, I guess, to, uh, help people execute that. But the challenge is we also see the Linux Foundation has open SSF and all kinds of different consortiums are running around. And frankly, Tracy, I'll come to you, but you know, I get a little confused as to what consortiums do and what do we have too many consortiums and do we need to figure out maybe a way to play nicer together?

I think so there are so many different, um, kind of groups of the giants that have decided that they're gonna take this on and solve, um, the problems. I really do feel e even within the open SSF, I feel there should be more collaboration across all the working groups, much less all these other, um, consortiums that are discussing this particular problem. It's a big, it's a big problem though.

Um, you know, everybody should take their, their piece of the, of the, of the puzzle and solve that piece of the puzzle. And I don't necessarily know if that's happening. I, because I can, I can't keep track of what everybody's, what everybody's up to.

Um, what the Eclipse Foundation is trying to do is address it at the development state, what the open SSF is trying to do it at, just to secure open source software. Um, there's other, there's other groups that are looking at creating standards. There's the, uh, the secure Software Development framework.

Um, there's the cybersecurity. NIST has their cybersecurity framework. It's a lot, it's a lot to try to keep track of.

Um, you know, the re the Cyber Resiliency Act. I haven't read through it in, in close detail, but, but a lot of this has been pushed or spurred on by the number of vulnerabilities we're finding. Well, they've always been there.

The reason why it feels worse today is because we're, we're recognizing the vulnerabilities. We're seeing them, we're starting to talk about them. So it feels like suddenly everything got worse really fast.

Well, it's been bad for a while. It has, but that doesn't mean we shouldn't fix it. I'm not saying that.

I'm just saying all of this, this, uh, buzz is because we're seeing more vulnerabilities because we have tools that are exposing 'em better, which means that we're, we're achieving what we're being asked to achieve by things like the Cyber Resiliency Act. We are looking at ways to harden the software, you know, supply chain. We're looking at ways to harden our, our architecture and our frameworks.

Uh, so yes, we should have these standards, but is it, uh, is this something that is, the world is on fire right now? Well, maybe it has. It is, but it has been for several years.

So I feel like we all just need to breathe, take a breather, look at what silos that we are good at, and fix those areas of expertise. And I don't necessarily know if that's what's happening. I feel sometimes that each consortium wants to boil the ocean.

Hi, I'm here. I'm from the government and I'm here to help. Um, I think, I think this is a perfect example where if industry doesn't police itself and you and the government gets involved, you're gonna have, not chaos, but you're gonna have, you know, this kind of suboptimal outcome.

Yeah. Well, in, in Yiddish they have a word mishigas. It means like trouble.

You're gonna have this, this mishigas and in England, you know, and, and then complicating it. It's not just the US government and Csar and the White House, but you have the EU and the eu, they're a lot more aggressive. They 'cause they fines, they have political will to get things done.

Um, and but what we gotta remember are the people writing the legislation, they're not open source experts. They get pulled and pushed and stretched from special interest groups as much of government as today. And so what you get is below suboptimal.

Um, look, software supply chain security is DevSecOps, right? I think our DevOps next, DevSecOps next report is gonna really reflect on that. And the fact of the matter is in terms of adoption by the industry at large by, you know, con not consumers, but developers of code, who I guess other consumers, um, it's, it's not as high as we thought it was, right?

It's, I mean our, I just, no, I'm not giving out any secrets yet, but I will tell you that our research is showing, it's not as widespread as we had hoped or thought. And that's really the issue. But do we need big brother coming in and saying, you can't release software that has any no vulnerabilities in it.

That's a bit of a bridge too far for me. Uh, it's just an impossible 'cause every software probably has vulnerabilities. It's just a question of when we, we know about 'em when they're exploitable and everything else.

Um, I I trace to your point, I would like to see us come together in a broader industry and maybe even in partnership with governments to have a single rule or a single set of rules. I think we're in this Tower of Babel kind of thing that we are now where everybody's making their own stuff, hoping that they'll somehow coordinate is, is pie in the sky? I think the airline industry went through this a couple of decades ago where, you know, they all got together and created safety engineering principles that they all follow.

And there's of course still issues that pop up every now and again. But, um, you know, the plane's not dropping out of the sky kind of thing. So, um, it, uh, it at least, you know, not as frequently as it used to if you're old enough to remember.

Um, and I think we need to do something similar. I dunno, Tracy, I, you know, I I think that there should be a conversation between DevOps engineers and security engineers or CISO offices because we're, you know, we're asking, I see so much of what we're we're that's being produced. It says the developer has to fix it.

The developer has to fix it, and developer's not gonna fix it. You know, to be quite honest, you know, developers come out. They're, they're our lowest level in terms of the, you know, technology in a, in a company.

You bring a, you bring a a, a engineer in from college, they start coding and now they're doing, you know, microservices. They're really, they're, they're kind of insulated to their own little service. They're not wor they're not thinking about security and the across the entire lifecycle.

They're just not doing it. And it's unfair to ask that, that persona to, to, to do the work. Now, I, I was so with you, Alan, this is a DevSecOps puzzle.

This is a dev evolving our DevOps pipelines to include security in that process. And there is no, the one reason why we can't do it easily is because of scripts. Yeah.

No, no. Thousands and thousands and thousands of scripts that we have, we have arrow. It's the scripts is the problem.

I keep saying that, you know, we have all these scripts we have to go and update. You can't go update. Uh, you know, Jenkins is doing, uh, cloud beans Jenkins, they support 90 million workflows a month.

Are we gonna go and update every single one of those manually? No, we're not gonna do it. It's not gonna happen.

There's gotta be a way to do this in an automated way, and we'll bring AI in. We have to have the AI intelligence to start helping us with that. But it is a DevSecOps problem.

It's a problem between the, the CISO office, the security engineers, the security teams, and the DevOps teams. That's the two personas that need to fix this problem. Developers certainly should have tools to do proper scanning and have maybe a little more knowledge about open source that they're bringing in.

But even then we can't, they can't know everything. They just, it, it's impossible for them to know everything. So it has to be done through the DevOps pipeline.

There is no other place for it. And DevOps has to evolve to DevSecOps. Period.

I feel like Charlton Heston standing in the top of the truck yelling scripts is code Scripps is code. Um, I think you're wrong about that. Money is the root of all evil thing.

Apparently it's Scripps. Well, I think that might be a good, we, we ran a little over town. I gotta wrap this up, but Steve, I I wanna throw in one thing.

Go ahead, ahead, rich. I think this is similar to the debate in security, not software security, which is, is a defense or is a response, right? We're never gonna perfect not putting vulnerabilities in software, period.

It's just, it's a flawed process. It's just not possible to be a hundred percent, you know, no security vulnerabilities. The other side of the coin is response.

How quickly can we patch it? How quickly can we fix it and roll that out everywhere. I think that's what we need to focus on also.

So the problem is it's all these, you know, xz, um, modules that are living out there that aren't easy to update. And if we make that update process much easier to roll out when there is a situation they won't get, won't get the publicity that it is. So it's gonna happen.

So let's respond much more effectively. Best yeah. Rapid response and apply chaos engineering Then.

Absolutely. Alright, we gotta wrap up text on gang. I hope you have a great Monday.

Come back tomorrow where Tracy leads the French Revolution against the script monarchy. Um, off with their heads. Let them take.

Alright, Mike, Tracy Mitchell, thanks for joining us. Thank you for watching us. This is Textron gang.

We'll be back tomorrow with more. Hey guys, this is JJ Manila with Mitch Ashley co-host of CISO talk where we have engaging bite-sized conversations for current and next Gen CISOs. You know, we have some of the best conversations on CISO talk with some of the greatest talent in security people like Andy Ellis who talked to us about optimizing security strategies and how to navigate the boardroom.

Lisa Bradley came on and talked about vulnerability management bug bounty programs and YS bombs aren't the solution to all your software security problems. Steve Reynolds was also another great guest and he talked to us about what not to do when a security incident happens, What not to do. Dos are great, but we also had Eve Mailer and Steve bitten on talking about security, uh, and third party software, SaaS applications, and weaponizing ai.

So go ahead and join us for the latest episode of CISO Talk. You can find us by going to Techstrong TV slash CISO talk.