Automatically transcribed, so names and technical terms may be misspelled. The audio is the record.

The Colorado Equals Security podcast is your local source for regional security news, local events, and interviews with key individuals in the region. Now, here are your hosts, Robb Reck and Alex Wood. Welcome to Colorado Equals Security. This is the newscast for episode 275. We're going to be publishing this on the week of— or the week of June 9th.

Alex, I guess June is like really into summer now, right? Yeah, I think we're, we're summer. It's summery now, which means it's cool and rainy outside, right? That's how it goes. They— we came home from vacation earlier a few days ago and like the house smelled all musty.

It was like, oh geez, this is not Colorado. What's going on here? Yeah, you missed a whole bunch of rain and storms while you were gone. So I did not miss them exactly, Alex. Um, hey, you know, let's do a little bit of housekeeping.

We have a Slack channel that we'd love to see you in. We're trying to— we're getting some new energy in there. Um, go join Slack and get signed up on our mailing list by going to colorado-security.com and clicking the link to join the community. Yeah, uh, we'd also love it if in your favorite podcast player you rated and subscribed to the podcast so this gets delivered to your player every month and people know how great the show is. And as always, we'd love for you to tell a friend how great Colorado Equals Security is, not just the podcast, but all of the wonderful things we're doing around here.

And speaking of all the wonderful things we're doing, we have a few wonderful sponsors who have signed up to sponsor us for the year. Uh, big shout out, thank you to Armis, CrowdStrike, Red Canary, and Zscaler. Red Canary and Zscaler. Well, maybe we'll be talking more about that later. Yeah.

Speaking of news, Alex, uh, did you know that the pantheon of oversized animal statues in Denver is about to grow by one. It is, yes. So in RiNo, they are constructing a rhino. There is a new— it's actually going to be like a little climbing sculpture, you'll be able to do some, some rock climbing on it. But it's being put up in RiNo in a new development there.

And it looks pretty cool, more than 30 feet tall. And 22,000 pounds. That's heavy, which is more pounds than I can move. You'll only be able to climb 12 of those 30 feet though. They, they didn't mention a couple times in the article that they are staying within safe playground guidelines of the, the climbing, the height from which you want to fall.

Yeah. Um, so this will not be a big blue animal, is that right? Not big and blue. It will not be a big blue animal. It will be a kind of a multicolored, interesting looking animal.

Um, we do have You know, speaking of the rest of the oversized animals in Denver, obviously everyone's famous or favorite, the Blucifer, the Mustang. What do they call Blucifer? The demon or something like that of Denver out at the airport. What's another big blue bear at the convention center? Well, what was— what was the name of that piece?

I read in the article it wasn't I See You or You See Me or I can't remember. And then there was the last one I didn't know. Yeah, there's a buffalo somewhere too, I think at the History Museum or Colorado History. That one doesn't stand out quite as much to me, but obviously it does for some people. But yeah, we're adding one more.

The rhino looks pretty cool. This is actually part of a development that they're doing for the, the Denargo Market, which is a development that they're doing down there to bring back that market. I guess it was a big food market. Back in the '70s, and then there was an accident and it burned down. And so now they're, they're reconstructing some things there.

I love seeing RiNo get re— you know, rehabilitated. If you want to go take a look, it's already well underway. You can see most of the Rhino today at 29th Street and Arkins Court. And maybe drop us a picture at the Slack community so we can see what it looks like. I think we are burying the lead, though.

The most important part is that there is a contest to name the Rhino. So if you have a name, check out the link in the show notes and you can go figure out and put a submission in for what you want the name of the rhino to be. So that's true as long as you do that by June 5th. No, no, no, it's by the 12th. But so— or sorry, the 10th.

So I believe that the 5th was when you had to get the name in for the nominations. And then next week there is going to be voting on from the finalists. So like nominations get in by the by the 5th, and then you're gonna have about a week to vote. So I believe you will be able to get in there and vote on the, on the front. I assume that Rhino McRhino Face will be one of the finalists, of course.

And I probably won't make it, but will be one of the nominees at least. When I did look today at the page in the article, you were still able to submit. I don't know if that means that you will actually get that submission into the voting, but you, you could still submit as of today, June 5th. Yeah. So, but anyway, we hope that you guys will, will participate in the democratic process and, and, and get involved there.

We do have another piece of news, Alex. Why is there a passenger train going to Steamboat? What's going on here? Yeah. So there was some recent developments in the, the lease that the state has with Union Pacific for, for running trains through the Moffett Tunnel.

So as I think everybody knows, there There is the ski train that every year goes from Union Station to Winter Park, but there's been a lot of talk recently about extending that along that same line to go from Denver all the way actually someday to Craig, which is much farther than Winter Park. So there was a 99-year lease that was in place previously that expired. There's now a 25-year lease that allows for more use of the tracks. And this is made possible because there are fewer coal trains going these days. So there's more availability on the tracks to run commercial.

So I've actually never been to Steamboat. It's one of the places that's on my list of Colorado spots to go. Steamboat is great. Can I go? Can I do this train outside of ski season?

Or is it okay? Yeah, so this will be a train that goes all year round. It'll be a little bit before you can actually get to Steamboat. So next year, I think that they're, they're gonna start running the train from Denver to Granby. So you'll be 2/3 of the way to Steamboat.

And in the future it will go, you will go even farther. I think that the, the second stage is they're gonna do a sort of a commuter train from Craig to, it's like Oak something, which is south of Steamboat and kind of back and forth. And that'll be like for people commuting in and out of Steamboat from the areas around there. I think to help keep congestion down in Steamboat. And then the final phase will be that the train that runs back and forth between Denver and Craig, and there will be stops in Steamboat when that happens.

Awesome. Well, good news for those who want to get to Steamboat and myself on that list. Good news for me. Well, our next story is a westward— we actually have a couple westward stories this, this month. This one is about the renaming of the 16th Street Mall.

They've gone way off the rails with a brand new name. I don't know what these kids are thinking. What's the new name of the mall? Yeah, so it used to be called the 16th Street Mall. Yeah.

And now it is 16th Street. No mall. That is revolutionary. Yeah. But apparently this is just going back to what it was before.

Back, back until 1982, the 16th Street Mall was just 16th Street and it was basically Denver's Main Street, right, where, where people would go cruise and all the good shops were. I found this article in the Westwood— Westward by Alan Prendergast. Really interesting. He grew up going there. There's a picture of the, of the mall in the '60s where apparently it was a pretty happening spot.

And, you know, a little bit, a little bit of nostalgia for the old days. Yeah, for sure. The thing that I found most interesting and somewhat disturbing in the article was that Denver paid a marketing firm $100,000 to come up with the fact that they were going to change the name from the 16th Street Mall to 16th Street. So to rename it to that. Yeah.

I mean, just take away a word. That's good for them. A lot of interesting stuff in the article. You know, going back to the original change, this was actually driven by RTD. RTD, who was riding high on their, their new taxes that they were gaining, said that they, in order to clear congestion through downtown, they wanted to close this street and just allow shuttles to go back and forth to connect 2 bus stations, one station at each side of the mall.

And that obviously was successful. Took them a couple of years to do it. And it was interesting in the article, they talk about how during that construction in the early '80s, they ended up having problems where like sinkholes started developing in the middle of the mall and like they would have to close it. And it just reminds me of all the construction that that street has had over as long as I've been in town. Has apparently never been an easy spot.

Yeah. And I think we all know that 16th Street is still under construction for the work that they've been doing, but it will be done this fall, or at least is supposed to be done this fall. And then we'll be back to the way that the former mall, now not mall, was. They did a celebratory bash the last— basically Memorial Day weekend that— or, well, just after that, May 31st through June 1st, a celebration of the reopened mall, which is not quite reopened all the way yet. But they're, you know, they believe that this is a big part of revitalizing and, you know, kind of re-kicking off downtown.

It could use it, right? We talked about it. The mall has not been good in the last few years. Yeah, hopefully they can attract some folks down there. I know we didn't put the story in, but I know that Denver's development director who's been there for a year just left.

So hopefully they get somebody good to replace them. Yeah. All right. Moving on. We have a story from the Colorado Sun, our friend Tamara Chuang.

This is an update on one we did. Was it just last month? I think it was last month where we were talking about a potential revision to the Colorado AI law. Well, this is an update to say that that did not end up passing, ended up being killed. So there will be no revision and the AI law will go into effect as of February 1st, 2026, as expected.

Unless they— the governor calls a special session just to address this. Yeah. And it seemed like in the article they thought that was a likelihood. But as of yet, I am unaware of a special session. I think it'd be too early at this point.

I think that because it just closed, right, the regular session. A lot of times they'll do a special session essentially right after and keep people around. But yeah, I think it could happen any time during the summer. So. I, you know, I— it's an interesting one, or I try not to have too many opinions about things I'm not that educated about, but I, I can see both sides, right?

So, so you have no opinions? I have as few opinions as I can. Uh, I find both sides have an interesting point here. Like, on the, on the consumer protective side, protection side, if AI is making a decision, why wouldn't— yeah, why shouldn't I be told about it, right? Um, on, on the industry side, the real concern is I don't think it's about the disclosure.

It's about the competitiveness of Colorado versus other states. If Colorado is the only place that's saying, hey, your company is going to have to put these other disclosures in place, well, like, I'm just not going to move my business to Colorado and I'm going to move my business out of Colorado if that's a problem. So I can definitely see both sides. And when you're— this is part of the challenges of doing all these laws at the state level. We— it's— we're kind of perversely incented to not do the right things for consumers so we can, you know, keep that tax revenue and keep the great jobs.

Right. We all want jobs as well. So it's a, it's an interesting, tough challenge. Yeah. And I think some of it's in the details also, right?

One of the examples that they give in the story is about AI for fraud detection, right? You know, the example that they give is if when this goes into effect, because a fraud alert is potentially stopping you from getting a service, they, you know, banks, for example, in theory, would have to let you know every time an AI makes a decision that then stops you from getting the service. That may be a little bit overboard in the way that they're interpreting. But again, it's the details, right? And yes, we would want to know that AI is making decisions.

But maybe we don't need to know every time AI makes the decision. Yeah, it is a— you're right, the devil's in the details. And, and by creating the law, now you're creating the need to interpret all those details. Interesting stuff. Yep.

All right. Next story. This is a follow-up on the Quantum Tech Hub that is coming to Colorado and some of the work that they're doing related to the grant money that they have for getting that set up. This is another story by Tamara Chong. Yeah, she's been busy.

She was also the one who did that last AI article. So the tech hub, you know, they were given that grant of, what was it, $75 million, I think. And this particular one where they've actually found a way to get some training for none of that money. They're partnering with IBM to create a kind of relatively comprehensive set of training to create 3,500 new quantum-trained, quantum-ready professionals to help solve the presumably coming talent gap here. Yeah, it sounds like IBM mostly has this curriculum developed already and they use it internally, and then IBM will essentially be loaning it out to colleges and universities and other educational providers to then use that curriculum to train people in various areas of quantum.

A couple interesting elements from the story from my perspective. They, they are looking to mostly go with colleges and universities, but they specifically mentioned high schools as well and creating AP curriculum that folks can take in high school to get ready for these fields. And they also talked about that the intention is that all of these, uh, this education was in lieu of a PhD. Like, hey, you should be ready for, for this field without going to postgraduate studies. I think that's an admirable thing for folks who just want to go get a job, right?

For sure. Yeah, it's, uh, it's definitely a step in the right direction. They do talk about a couple other things that the, the group is trying to do. And it sounds like many of them are a little bit murky, kind of on hold right now, partially because there is a little bit of controversy and potential risk on whether or not this grant money that was given to them could be rescinded. Some of the other, not quantum groups, but other tech hub groups have had some of their grants held up by the federal government as part of a review process.

All right. Well, I think that's it on that story. Now we dive into the security-related stories for the month, and obviously a big one, right? There's a big local story. Big, big, big.

Our former employer of mine and a former vendor of yours, Red Canary, is presumably, allegedly, I don't even know what the right word is. There's an intent for Zscaler to acquire them that was announced just about a week ago. This is, you know, a thing that has to go through approvals and, you know, set to close, I think, in like the September or late August timeframe. This is big. And, you know, the financial details were not announced as a part of the original press release.

But subsequently, there's been, you know, Zscaler as a public company had to issue one of their public filings, and they did in that mention $675 million as the as a purchase price for Red Canary, and then incremental stock being issued to Red Canary employees for retention purposes. But that gives you an idea roughly where it is, like a pretty good outcome, maybe not as big as it would have been, you know, a few years ago. But Red Canary, you know, coming, having a nice exit, going to a big security company, you know, for me, it's a little bit of a bittersweet, a company that I've known for a long time and respect the heck out of. And I'm actually currently a customer of, Um, gonna be, uh, gonna be, you know, not, not their own company anymore. They're gonna be part of this bigger Zscaler family.

Yeah. And it'll be interesting to see where, where they go. Right. Um, obviously it's a, you have to have an exit at some point. Um, not every company can, uh, become a giant platform company that lives around forever.

Um, but, uh, but yeah, you wonder one of, one of the benefits of Red Canary is their independence. Right. And so you wonder if they can maintain that independence, uh, you know, continue to take data in from all of the companies that they continue to take it in from, um, you know, being under the Zscaler banner, you know, whether that's from, you know, other competitors not wanting to do it or other market pressures or anything like that. I, I hope that everything continues to go great for them, uh, in this new Zscaler world. And they're obviously going to have access to a lot of data from Zscaler now also, which I think will definitely be a boon to them as well.

Yeah, I You know, I, as I mentioned, as a current customer, I'm hopeful that they'll be able to maintain this vendor-agnostic element. That it's really hard when a big secure— a big company buys another company. You know, of course, Zscaler is going to want to make Red Canary start doing MDR on all the Zscaler products, right? And they don't. I don't believe they do today.

They do it on some of it, but not all of it. So they're going to have much deeper integrations and I worry that that gets in the way of the ability to continue being, you know, best in class at the Microsoft products and the other EDRs and the cloud products. And hopefully they're able to balance that. There's got to be the pressure to become, you know, fully integrated with Zscaler, hopefully while still providing that value to the other vendors. Yeah.

Knock on wood. Not Zscaler related even, but I think that there's, you know, lots of market pressures in MDR these days with all of the EDR vendors now starting to offer their own MDR services. And, you know, maybe trying to make it less competitive for independent MDR providers to use those EDR sensors to provide MDR. So I don't know. It's going to be interesting to watch.

It's going to be interesting for sure. Well, so that was the first article was basically just the news. Then there's a second article that we included as it is the big news of the month. This is from Dark Reading and it's kind of an analysis of this talking about from Zscaler's perspective, why would they do this? And it's all about the data.

Yeah, to your point. Yeah, exactly. And having access to all of that data and then having somebody that can do something with that data and Zscaler not having to develop that, uh, that intelligence service essentially internally themselves, you know, bringing in somebody like Red Canary that has all these services built, it's obviously valuable for both sides. Yeah, Red Canary has always been, I think, the best— I, I do believe the best MDR in the world at providing high scale. So like they don't have nearly as many humans for the number of instant or of devices that they're monitoring, but they're still able to do like the best in terms of discovery.

They just do a really good job with AI and rules and really scaling that out. And I assume that that's another big part of why Zscaler did it. They're getting all this data and they're getting a system that can scale at margins that look sort of like software. And that could be a really nice additive thing to sell across their entire environment. Be my guess.

Yeah, good stuff. Um, it's a, it's a hole that Zscaler didn't have in their portfolio either. So it's, you know, there are a few companies, I think Zscaler becoming one of them, that are going to be around for a long time as platform companies. And yeah, and they, you know, if you're a platform company, you got to grow by going into more markets. You can't just keep taking over everything that you already do.

Yeah, well, look forward to hearing what this looks like. Is it, you know, is it still going to be Red Canary or is it going to be renamed to to Purple Panda. You know, who knows what they're going to call this thing. Red Canary by Zscaler. I, I would imagine Red Canary, like a Zscaler company, seems like a reasonable potential outcome.

All right, what do we got next? Next, uh, we've got a story from Webroot. Uh, this is an end-user, uh, facing story, but talking about mobile security and how to protect yourself from text SMS scams. Yeah, I don't know that our audience on this podcast are are the audience for this blog. But I will say, after I read this today, I sent this as a link to my mom and my mother and father-in-law and my kids, because I— while I would hope that they know better, like, you know, these are, these are actually— there's actually good guidance in here.

It goes through what are the most common scams that you're going to get texted with. I, you know, I've— I know about you, I've received lots of these toll scams and the package delivery, uh, texts and, you know, the Uh, the fake, the fake number texts that they just want to build a relationship. Yep. Pig slaughtering. They give all the examples of scams and then they go into a nice set of here's what you can do to keep yourself safe.

Yeah, I think this is, it's really good. And I, I would say probably far too often get asked by various people in my life, hey, do you think that this text is real? And this is a perfect article to give to those people and say, no, it is not real. Take a look at this. It's going to give you more detail.

Now I don't have to explain it to you. Me Google that for you. Is that what you're basically saying? Kind of, kind of, but more nicely, more nicely. And, and it's, you know, it's going to be nicer than just a Google search.

It's, uh, it's all consolidated there and good, uh, good guidance. All right, one more story. We have a blog post from Ping Identity, Rethinking the Supply Chain Risk You Can't Ignore: Third-Party Access. Yeah, so, uh, I think we all know that, that supply chain security, third-party risk management, those sorts of things are very important in the security landscape today. This blog talks about it a little bit at a high level, and then, you know, goes into a little bit more about how identity plays into that and, you know, how, you know, you can use things in IAM like B2B IAM to help reduce the risks that you have around supply chain security.

Yeah, they have a set of best practices to reduce the risk, you know, verifying third-party identities and onboarding, Enforcing zero-trust principles with dynamic controls, you know, just-in-time access, phishing-resistant MFA, supporting federated SSO, delegating access management with built-in guardrails. Let them— let the third party manage their own access versus you trying to do it without knowledge of their environment, automating user lifecycle and offboarding, continuously evaluating behavior to look for anomalies and increase your assurance, and maintaining a clear audit trail so you can, you know, support continuous certification. Yeah, those are their steps. Like, you know, it's a good list. It's an important risk, something to do.

It's hard. It's nice to have a roadmap toward it. Yeah, all good stuff. All right, uh, those are our security stories for this month. Uh, let's jump over to events and we can talk about what's coming up.

Uh, obviously on our webpage website, we have a community event calendar that has all of the events coming up through the end of the year. And check that out if you want more details. But we're going to talk about some of the ones we've got coming up in June. We got 5 here in June, starting on the 11th. The Denver ISSA chapter has one of their special interest groups.

They are talking about the Colorado AI Act and its impact on US consumer privacy rights. Nice, timely, sounds pretty cool. On the 12th, ISSA Colorado Springs is doing Mentoring matters. On the 17th, Let's Talk Software Security has one of their meetings. Um, is there real ROI in security conferences?

Interesting question. Uh, maybe. I, I think it probably depends on who— where you are in your career, what you do when you're there. There's lots where there's not. I bet there's a, a good, a good chat that happens as part of that one.

Uh, on the 18th, Denver OWASP is doing a meeting A web CTF for everyone. Sounds like fun. Our final meeting of the month, ISSA Pikes Peak has their chapter meeting the 25th. I'm guessing that is ISC2 Pikes Peak, but check out the website. You're right, it's ISC2 Pikes Peak.

Somebody typoed that. Yes, me. Well done, Robb. Awesome. Well, that is it for events.

But do we have an interview this month? We do. We are talking with Kyle Mickey. Kyle. Mickey goes by Mickey.

So he is a friend of mine. We used to work together at Uplight. He left and started his own company called Corewood. And we talk a little bit about him and his journey and what he's doing. Well, I'm looking forward to getting to know more about Mickey and so much so that we are trying yet again to get to kick off an AMA with, with, with our, with our interview guests.

So we're going to have a chance. You're going to listen to the podcast, you're going to love the interview, and you're going to say, I just want to know more about Mickey. And, uh, what, come over to Slack, go to the AMA channel, and we're gonna kick off that conversation starting Monday morning. We have a few, uh, a few questions kind of pre-populated that we'll share at that point, and then you can just drill Mickey with whatever you want to know. And, uh, and hopefully that becomes successful this time.

It didn't work last time. We're gonna try again. We're gonna try again. Um, for those that heard it, I think that may be my first sneeze during the podcast in 275 episodes. 275.

Just don't do it again until we get to 550. Because of that, we're not going to edit it out. Oh, we never edit anything out. Yeah. Yeah.

All right. Well, that's it. All right. Let's, uh, let's go ahead and come back again in July. Sounds good.

All right. Everyone have a good one. Thanks, Robb. Hi, this is Jim Adkins at EchoStar. Welcome to Colorado Equals Security for Colorado security professionals.

Welcome to Colorado Equal Security. This is Alex Wood, and this is our feature interview for this month. I'm excited to have with me Kyle Mickey, but who everybody calls Mickey, here with us. And he is the founder of Corewood. And Mickey, you and I, you know, before you did this, we were working together at Uplight.

Yeah, I was working on an API governance system at Uplight that I thought was really cool because we were able to kind of separate what we exposed as an API from what was going on internally, and we added some control plane and data plane type logic to manage security ahead of deployment into the data plane. Yeah, it was some pretty cool stuff. Um, we'll get into some of that in a bit, but before we do that, um, I think, uh, well, I know that you have, uh, an interesting past and a, uh, a cool story of how you got to where you are today. So I'd, I'd love if maybe you could talk a little bit about, uh, yourself and who you are and, uh, you know, kind of your path to how you got to where you are today. I appreciate that very much.

Um, you know, I, I like to call myself a successful dropout sometimes, uh, because I did not finish my school, but I was studying psychology, which has nothing to do with technology and compute and security and all of the stuff I do today. And so the first technical job I got was actually in technical writing. And as a technical writer, we had to create a lot of charts and graphs and presentations. And I, my hand would hurt from clicking and dragging in Excel all day. It was no fun.

And so I taught myself VBA to automate my work processes and I ended up I kept going. I just automated and automated and automated, and I fell in love with the concept of technology as an automation enablement. That's awesome. And then I know you did that for a while. You ended up at Uplight, you know, sort of in an SRE role doing automation there.

And then, you know, after some things changed there, you know, you, you went out on your own and, and started Corewood. Yeah, that's right. So one thing that we see a lot in enterprise environments is infrastructure gets kind of deferred. Um, I think we get so excited to build functional, uh, behaviors into software that sometimes we don't think upfront about how it's going to run, some of the non-functional requirements of how the software gets built. And so being in the infrastructure side of things gives you a real perspective on where the operations meets the software execution meets the security and compliance requirements.

Yeah, and I mean, that was definitely one of the things that we were, we were working towards in the work that you were doing there at Uplight with the sort of the API governance and things like that. Trying to build in some of those things inherently as opposed to, you know, what happens a lot of times in security of sort of bolting things on afterwards or a bunch of manual processes or chasing things, but really putting it there foundationally. That's right. I think that we can really transform compliance from being something that's frustrating for organizations to work about around after the fact to being something that gets encapsulated in the way that systems are built proactively. And that takes this concept of governance, risk, and compliance from being something that you have to do to being how you do things.

It's built into the fabric of the system that it handles compliance intelligently. Yeah. So I know I know not everybody thinks in that way. And I know that, you know, you have a bit of philosophy behind that and some ways that you kind of came to think that way. I'm wondering if you can talk a little bit more, you know, about that.

And, yeah, I don't know, maybe some of the, you know, the unique perspectives that you had coming to this that maybe make you think a little bit differently as opposed to you know, many other practitioners. I appreciate that. So I've worn a lot of hats in the engineering industry. I've been a full-stack developer, I've been a tech lead, I've been an API and backend developer, and I've even done a good amount of frontend and JavaScript and all of that. But through that, I was an early adopter of Docker, largely because I was volunteering for— with an organization called Namlo that benefited people in Nepal, and they had a LAMP stack website on WordPress, and I was using a Windows machine, and I started with Vagrant virtualization and VMs, and then I discovered Docker, and this was before I even became a software engineer.

I used Docker to make things work, and then I learned to program using Docker. So this idea of containerization was kind of native to my perspective on engineering and development. And containerization does a lot of what we're talking about. It creates an abstraction layer that handles a bunch of concerns like dependency management for you. So I feel like that was really influential, as well as working as an identity architect at Trimble and working on IoT devices and GDPR-compliant login systems.

I learned a lot about compliance and security and the cryptographic exchanges that would happen for IoT devices. And that was really enlightening. Then I got turned on to this iDesign company with a book called Writing Software. It's kind of a funny play on words, R-I-G-H-T-I-N-G, like writing, like correcting software. And in it, Jovell Lowry, I probably didn't say that right, writes about how we do software decomposition wrong.

We do it functionally, like this is the account service and this is the user service. But there's so many concerns that get duplicated when you build systems that way. So he advocated for what he called volatility-based deconstruction, or basically taking your requirements and identifying what's likely to change and trying to keep change from having to perpetuate through your entire system. When those changes happen. And so governance, risk, and compliance to me is a massive source of volatility in software engineering.

And in order to address that, we can encapsulate that volatility. The idea of governance, risk, and compliance can be encapsulated into specific systems to manage governance and risk and compliance instead of having to sprinkle bits of GRC throughout your entire software ecosystem. Right. No, that's great. So you recently, I don't know exactly how recently, but you recently started Corewood.

And this was, you know, after leaving Uplight, obviously, you know, when you left, you had lots of options. You could have done many different things. You could have gotten another full-time job. You could have I don't know, you could have taken a big vacation. You could have, you know, lots of, lots of different stuff, right?

What is it that, that made you decide that you wanted to kind of start your own thing and, and, you know, sort of build a project and do this on your own instead of, you know, working for the man? Great question. So some of it is flexibility. My family decided to relocate to Costa Rica shortly before I was let go from Uplight. And as I was— you know that I am honest to a fault.

And so I would always tell prospective companies that I was planning a move out of the country, and that was not comfortable for a lot of companies despite my well-established history as a remote employee. And it just didn't work out with a lot of interviews, and it was a rough time to lose a job. The industry is undergoing a lot of flux and continues to undergo a lot folks. And so I thought that I could cut it as a consultant and a contractor, which, you know, I got a few gigs, but nothing that blew up the way I wanted it to. But one time my family was out of town and I was working with this idea of a PII, or private and identifiable information API that I had in my head, um, that basically would filter personal information before sending it to LLMs like OpenAI and Anthropic.

And I started looking at what I'd built and I compared the performance of what I'd built to equivalent performance with, you know, the most common way of building it would be with the open source Python packages for machine learning models. And it was very, very performant. And I said, I think we can build a company around this. And so we've been struggling to find our product market fit for a few months and What we recently found is that encapsulating compliance seems to be a product that we're getting some traction and interest in. We have a product called Master that takes database connections and allows you to say which fields you need to de-anonymize so that it can dynamically in real time provide de-anonymized data for research and development against that dataset.

That's awesome. When we were having a pre-chat about this a week or so ago, we were reminiscing a little bit about how hard traditionally it has been to do, or not hard, but how cumbersome, how not easy to do data masking and data de-identification has been. In the past with other systems.

Was that something that, you know, you came to sort of naturally or like, oh, I want to solve this problem? Or did you think, okay, I've got this cool technology, I need to have a problem to solve?

So I'm glad you asked that question because it's very interesting. I have a friend who works in medical tech and he kind of mentioned how data masking is a very cumbersome and expensive problem for healthcare tech because they have HIPAA and CCPA and even GDPR for European citizens, even if they reside in the United States and are using our healthcare software. Any software that uses European citizen data is under the purview of GDPR, which is very interesting. So all of these regulations made it so that these healthcare tech companies are very cautious, and they should be. I mean, this is private data, this is important.

And what they have to do is take their data, either ship it off to a third-party provider or have a team in-house that then goes through all that data and de-identifies it, which basically means take all the names and Social Security numbers and credit card numbers and all the sensitive information and replace it with dummy, non-real versions of the same data points. And this needs to be done consistently because to enable software developers, you have to have some level of referential integrity. Well, because this process costs money per the gigabyte that you mask, then you end up needing to create a smaller dataset that then gets masked, uploaded into dedicated infrastructure for engineers to develop against, and then redeploy this, you know, software into your production system after testing on a non-representative sample of data. Oftentimes the data volume metrics are very different, and so the performance testing that you have against your staging or UAT or test environment looks a lot different than the performance against your live systems. And oftentimes companies have to do additional performance tuning after releasing their new software features to account for the discrepancy in de-identified sample datasets versus the live actual datasets that they deal with.

It costs a lot of money. It delays projects by many months sometimes to just get the de-identified data. And that looks like a real pain point where our concepts of encapsulating GRC, governance, risk, and compliance, could really benefit benefit everyone.

So, uh, I'm curious why, why now? Why, why is this different than, uh, than it has been in the past? Why hasn't someone done this before, right? Like, um, the— it— while it's, um, while it's a concept I agree with, it's, it's not like it's, um, uh, something that someone couldn't think of before, right? So, so why is it that all of a sudden, you know, you, an agile startup, is, is doing something like this as opposed to, you know, there's vendors out there that do, that do masking and de-identification, you know, that's their bread and butter, big, you know, probably multibillion-dollar companies, right?

Like, you know, why now?

Well, I think that AI gives us an interesting inflection point. Because all of a sudden this data de-identification problem goes way beyond healthcare. Everybody knows that there are governance and compliance risks with shipping data off to third-party hosted LLMs. Everybody knows that it can be expensive and difficult to build your own LLMs. And oftentimes the models that are available on the open source don't do exactly what you might want from hosted models from Google or OpenAI or Anthropic.

And so they're kind of between a rock and a hard place where they want to develop business capabilities. Corporations, especially in highly regulated industries, are in a rock and a hard place situation where they want to develop using AI technology, but AI technology does not work with their current governance, risk, and compliance requirements. And so the opportunities are changing, the technology is changing, And then for a small startup like us to be able to use AI technologies to help us develop the software, we're able to think differently and act differently a lot faster than small startups have traditionally been able to do. Yeah, um, I think we definitely are at an inflection point when it comes to, to AI. Um, I, I feel like, uh, things are increasing exponentially, uh, related to it.

And then, you know, you kind of look over the horizon and it, and it could be continuing to be exponential, right? Um, but I, I know, well, it's sort of a problem you're solving, but also it's, uh, an inherent risk in the system too, right? People don't have trust necessarily, or at least full trust in uh, these AI systems, right? And, uh, and, and you're using some level of AI to help them have trust in AI systems. Um, uh, how do you kind of reconcile that part of it?

And, uh, and, you know, sort of what, what sort of things do you do to make sure that, um, you're not causing some of the same problems that you're helping to prevent through some of the, the masking? That's a great question. So first off, our operating model is in your environment. That is very important to me, that all of the applications that we write, even if they're using machine learning models, they run natively inside your environment. That might be on Kubernetes, that might be on VMs on AWS, or even on bare metal if you're lucky enough to still have a server farm.

The point is that You put the masking, you put the privacy handling where the privacy needs to be enforced, and that's next to your own data. We're never going— we will export telemetry into a cloud platform for billing purposes, for product feature development, for understanding how it's being used, but we'll never emit private data outside of your environment. That's very important to our concept as a governance, risk, and compliance centered AI infrastructure company.

That's awesome. Um, I also, uh, talking about sort of the AI inflection, you know, we're, uh, I think we're at a point now where you've got kind of 2 camps of people. You've got one camp where they're extremely, um, into and embracing AI in what they do and how they operate. And then you've got others that are probably just either ignoring or hoping it goes away, or, you know, let's go back to the way we were. That's how I like things, that kind of thing.

I know you were in that first camp of embracing things, and, or at least, you know, somewhat. And I know that you guys have done some work to help enhance your personal productivity as a small startup to try and move faster. I'm curious about your experiences doing that and adding on to that, your thoughts of how people should potentially embrace generative AI to help them do these sorts of things? 100%. So I'm going to start with some blasphemy.

Okay. The days of premature optimization being the root of all evil are over. The reason that premature— and that was, that was Knuth, wasn't it, who said that? Donald Knuth, that premature optimization was the root of all evil. I mean, one of the most preeminent computer scientists of all time.

And am I saying he was wrong? Absolutely not. I'm saying that the context has changed. LLMs as code generation tools give us the ability to prematurely optimize code, and it costs us very little development time compared to what it used to. You can prompt your machine to optimize a routine for memory.

You can write tests, you can do memory benchmarking and tell it to be faster and leaner and more efficient prematurely. So that's how I'm bullish on AI. However, It is just statistical inference. Part of the reason that AI works— generative AI works so well for code generation is that code has fewer tokens or possible solutions in what comes next than natural language does. And so it works very well because you have a subset of possibilities to choose from that's much more scoped in than natural language, where I could just throw in pink flamingos at any time.

And, you know, now you're thinking about pink flamingos. That's very stochastic and random. That's how natural language works. That's part of why it's so creative and generative for humans. But that's a huge problem for reliable business systems that want to use AI.

So now we need to think, okay, what is AI if it's— if you think of it as statistical probability inference, which is really what it's doing at its core, right? And so now it's like, okay, so are there other ways of thinking about AI? Absolutely. We have much more consistent and predictable machine language learning model or machine learning models that we can deploy for specific use cases that are trained to behave specific ways. When they're given the same inputs, they always make the same outputs.

That's not like the big LLMs with 70 billion parameters or 140 billion parameters or whatever you want to say there. Like it's a different system. And so I think what we see is we need smarter intelligence for generating code, but we need targeted intelligence for running inside of business systems. At Corewood, we have a machine learning genius. He is— his name is Zhao Chatino, and he is an incredibly smart person who knows so much about these systems.

And he works a lot with taking you know, base models and making them do specific tasks better and then making them more efficient and not use all of the intelligence they have, only focus on using the intelligence for what they're needed to do. So when I say I'm like, I'm not bullish on generative AI as being the solution to every problem, I'm recognizing that it's a powerful tool to solve specific problems. However, we still have to understand the business context the non-functional requirements, the performance requirements, the reliability and consistency requirements in order to use the right AI tooling for the job at hand. Yeah, and I actually heard the term small language model recently, which is what I hadn't heard previously. And, you know, kind of going along with what you were talking about just there, right?

Like, Okay, you know, you've got your, your ChatGPTs and things like that that are these giant big token systems that can do lots and lots of different things. But then you've got to, you know, you can make these systems that are much more smaller and focused to do, you know, a sort of specific task. And it's, you know, much more focused and smaller and quicker because you can focus what they're doing onto being really good at one thing. Absolutely. My friend Zhao that I was just talking about just shared a— I think it's a 24-page PDF with me with references and everything.

And he put this together in like less than a week. And I said, how did you learn all of this so quickly? And he goes, I just really like research. He— it's about using machine language models to refine how we handle electronic data interchange for healthcare software. So the insurance companies in the United States use EDI to transmit claim data.

EDI has a specification, but it's kind of messy. And currently nobody's doing much with personally identifiable information or protected health information redaction against EDIs. This is a possible enablement point for healthcare software because if we can generate realistic de-identified EDIs, we can enable development teams to build software to handle those types of messages more efficiently. Um, so there's a big market need there, and he wrote this entire PDF about how we could train language models to work with EDIs to be anonymous and more efficient and cover more ground more quickly. Those type of applications are huge for small language models.

Yeah. And one of the other things that I know has been a big topic lately is around agents and agentic AI and things like that, which I don't think is, you know, the road that you guys are going down. But I would think that the smaller models focusing on, you know, what an agent does and, you know, specific tasks that it's trying to do in talking with other potentially small, uh, small models to do, you know, a network of things to enable a bunch of stuff is, is along those similar lines. I think you're right. And one thing that I don't know, I feel like there's so much buzzword and hype and whatnot, because when you think of this concept of agentic AI, what you're really making is a microservice to handle a specific concern, right?

Like, I just— microservice AI, pretty much. And you're powering it with AI. But the real question is how you deconstruct the functionality of your business system and allocate responsibility to different aspects of applications to do that, right? Like, you know, the concept of an agentic AI is I provided an LLM with this prompt, giving it this specific instruction set. Okay, I provided this application with this source code, giving it this specific instruction set.

Like, prompts are becoming the instruction set for our programs. And so when we think about prompts as instructions, the more you can refine the instruction set and make it predictable, and have test cases to show that it's doing what you expect it to do, you're constraining these systems. So now you've got these multi-billion parameter models that are capable of understanding video and image streams and all kinds of data types, but you're scoping them into this one purpose. That's very inefficient. It's much better to then take your single purpose refine the model, shrink it down, and run it in your own ecosystem.

And now you have the equivalent of agentic AI without nearly the waste and overhead.

Yeah, for sure. Um, the— I think, uh, I mentioned it earlier with the 2 camps, you know, I think you've got a lot of people that are, uh, that are embracing this, and then you have a lot of people that are ignoring or, or struggling uh, with AI adoption for one reason or another. Maybe it's their, uh, they, they don't want to learn something new. Maybe it's they're scared. Maybe it's they have security concerns, you know, things like that.

Um, how do you, how do you think people that aren't there yet get started? And when they do, like you were talking about prompts, like what are the most important skills for them to figure out so that they can, they can really empower themselves and get going in this area?

That's a great question. So very famous computer science character again, Kent Beck, who I think wrote the Extreme Programming Manifesto, and has been involved in that community for a long time. I saw a LinkedIn post from him some months ago that said that he'd been using these LLMs and code, you know, to write code and to do programming with code generation via LLM. And he said that 90% of his skills are now irrelevant, but 10% have a greater premium than ever before. I am butchering how he expressed that idea, but it is somewhere along those lines.

And I think that that really hits the nail on the head if you're a technologist, then what you understand about technology is your value because you can instruct these machines to do things in ways that people who don't understand their technology can't. I'll give you an example. I was pairing with a designer who was prompting an LLM system called Bolt.new, which is one of these low-code prompt-driven application, full-stack application development frameworks with And looking at the language that he used in his prompts as a designer was so different from the languages that— the language that I use in my prompts as an engineer and infrastructure person, that it's like, figure out what you know best and write about that like crazy in your prompts, because that's how you get the LLM to yield the most value for your skill set. Because it's no longer about code. It's no longer about the individual lines of code or the efficiency of this routine or the algorithm there.

It's about context management because LLMs are very good at using the context that you give them. So you need to think more about your inputs, still check and measure and verify the output, I got tricked by the LLM. I thought that I had gotten my machine learning model to work in my API because all of my tests started passing. And then as I reviewed the code, I noticed that it had added a regex fallback in case the inference engine was unavailable. Why?

Because that's what people do in the code that the LLM was trained on. They take these shortcuts. They say, oh, let's add a fallback or add a mock in and we can do this later. The LLM should not have done that. And so then I provided several instruction sets of do not create fallbacks.

The purpose is to use the inference framework, but it tricked me. It used regexes to make me think that it had accomplished inference.

That's awesome. It makes me think, and I've had this thought for a little while now, you know, you're you're saying that the value is the knowledge that you have that you can impart to the LLM so that it gives you essentially better knowledge back. Well, there have been several announcements by companies. I think Salesforce is one of them. I think— trying to remember who else, but I definitely know Salesforce was one that they said, maybe even Microsoft said, hey, you know what, we're, we're not hiring any more junior developers this year, maybe not ever hiring junior developers because we're so much more efficient with LLMs that we don't need junior developers anymore.

I'm getting to the question here eventually.

If your knowledge in your specialization is the key, and, uh, you— and there are no— there's no more junior developers. There's no such thing as an entry-level position for, uh— and we can talk about developers or any sort of, you know, entry-level position that could be outsourced by, uh, by LLMs. Um, how is it that you get from, you know, starting to work and then being a senior developer that has knowledge that can then import that into the LLM to make things work if you never have those entry-level positions to gain the knowledge, right? You've got to have that experience to become the person that can have that knowledge and be an expert with an LLM. How do you bridge that gap?

How do you bridge? First off, I'm going to get into my personal opinion here and I hope it doesn't cause me too much trouble. But I think that it is criminally shortsighted and kicking the ladder up, like, from the people who are trying to enter the career path that we need to value more than ever. It's criminal. It is criminal to say we're not gonna hire junior developers.

It's shortsighted because how do you fill that pipeline? Like, if you care about your sustenance as a large organization over the long haul, if you want to be sustainable, if you want to be creative, you have to get new blood in. You— I mean, young people who are entering the workforce are the energy to the batteries of enterprise, right? Like, we've seen it all the time. The young people are the people who bring the new ideas.

They're scrappy. They're not beholden to the same ideas that us old heads are. And So I, first off, to any listeners out there, I just want to let you know that I, that are struggling with getting into the field, I want to say I see you and I'm sorry for your suffering. And I hope that Corwood is successful enough to help you someday because we're going to be building training programs. We are going to be hiring young people and teaching them what we know about the fundamentals of computer science and learning how you've got different perspectives than we do.

That's incredibly important. If you're a young person who is trying to break into the career set, I mean, my first engineering job was when I was 30. It took— I messed around for years. I kind of started getting my stuff together when I was in my mid-20s, and by the time I figured out what I wanted to do, it took me a few more years to crack into being a software engineer. And I see that that opportunity would not exist for me in the same way today.

And that's frustrating, but you have to be creative. You have to say, okay, how am I not a junior? How do I, how do I learn the skill sets that I need? One thing is that this isn't being gatekept. You can build.

One way you can move from being a junior to a senior is kind of what I did. Is I started building software well before I had a software job. I found volunteer opportunities with nonprofits. I read the seminal works of computer scientists religiously. I had my own side projects and I ran experiments and, you know, blew up my machine multiple times and had to try to get it back.

Like, these are all things that we all do and And I don't think that goes away, but I think it's sad that we think that people are less valuable because we've developed new technology. And it's more like, why aren't we reimagining how we train people? Why aren't we reimagining how we get more out of junior developers? I don't understand it. Yeah, I was reading something recently and it said that Um, the crux was basically, um, uh, AI should be enabling us, not us enabling AI, which is, um, you know, essentially the, the way that it seems right now with, um, you know, those younger folks being sacrificed to enable AI, right?

And I agree with you that it seems extremely short-sighted, and I don't know how you fill that gap, but some— something's gonna have to change if Um, if the way that we justify using AI is, you know, having less people and those people are the, the entry in the pipeline.

I saw an interesting analysis from somebody on LinkedIn who was a historian talking about how the coffee shops of Paris were filled with unemployed recently graduated lawyers in the 1780s. Yeah. And how essentially they similarly felt like society pulled the rug out from under them. And that led to the Reign of Terror of the French Revolution, where there were massive societal upsets. And again, I just think it's short-sighted.

Like, we— I don't understand why we wouldn't want to enable and uplift people who are starting their life journey. If we say that we value society, then I think we need to invest. I think we need to invest in education. I think we need to invest in enabling people to have a comfortable lifestyle so that they can contribute to society to the best of their ability. Yeah, one of the things that I've thought about is, um, for a long time now, uh, you know, software development has been a separate and specialized process.

Right? Like people who, who make software and computer systems, that, that's what they do. Somebody else tells them the requirements and then they build some sort of system, right? Uh, I wonder if one of the answers is we start merging because it is, uh, in theory easier. Uh, people can, can have, uh, have this knowledge more quickly through, uh, through LLMs and, and support in that way.

Do all of a sudden we, we have people that are, uh, are the, the business unit users, owners? Um, you know, maybe you're a finance person and you, you now are developing financial applications because you can do that as opposed to having a separate, uh, you know, development team or, or whoever developing those things. Do we merge and now everyone is a thing that they do and, you know, a system developer or something like that. Right. But most people don't enjoy the iterative process of building software the way that software engineers do.

Like, that's just— and if it is a source of joy for you, great. Like, build software. I don't want to gatekeep anyone. I want to say doors open, come on in. I want to enable, I want us to, like, I want us to work together to build really, really cool, powerful things that help people in the world, right?

So a really cool inflection point in my career was when I was building this kind of API gateway system that had this control plane and data plane, and I had all of these use cases in mind for how this this governance engine benefits the business, enables us to do APIs as a product more effectively. And I took it to the product leadership and their eyes glazed over at my, like, technical specs. And I saw it and I realized that I wasn't communicating well. So I ordered a textbook on Amazon called Mastering the Requirements Process, which is targeted to business analysts. And holy smokes, every software engineer should learn about what business analysts do, about requirements gathering.

And because for me, that enabled me to write a requirements document that addressed the business use case, the business context, the stakeholders that were involved, not just the direct users the software, but, you know, the leadership of the company, the investors of the company, and how it would benefit them, to think about stakeholders holistically, to think about the business context holistically. All of this, I, it was a fantastic document requirements document, and it tied right into the architecture diagrams and the architecture, because I was able to say, here's the business use case, here's the product use case, here's the implementation detail. And I feel like having that line, like you said, between the requirements and the product side and the implementation, that last mile gets severed. So you've got the product people who understand the business use case and the product use case, but then they don't really understand how the implementation ties back up into that product use case. So I see it as finish the chain, right?

Just finish it. Get that next layer into place and facilitate that communication between the business context into the implementation. That's awesome. Well, Mickey, we're running short on time. We're getting to the end here.

I've had a great conversation. Anything that— yeah, anything you want to cover before we get out of here? That we haven't covered? I can't think of much. I certainly can't think of any questions that you should have asked that you didn't.

Uh, this was a lot of fun. I, I kind of forgot we were doing a podcast a few times. What about you? Do you feel like there's anything we should have talked about? Uh, and I, I think I'm good.

Uh, I sort of last, if, uh, if people want to get a hold of you, they want to know more about you or what you Um, we, we are going to do an AMA in Slack so that people can ask you specific questions, but if someone wanted to, to contact you or, uh, or Corewood, how would they do that? Yeah, so we've got a website at corewood.io, C-O-R-E-W-O-O-D.io, and there is a schedule meeting button there, or you're welcome to email me at mikey@corewood.io. That is m-i-c-k-e-y@corewood.io.

Awesome. Uh, well, thanks, Mickey. I appreciate your time. Uh, it's always wonderful to talk to you, and I look forward to this, uh, this interview getting posted and, and seeing what people have to ask in the AMA. So thank you very much, and, uh, look forward to talking to you again in the future.

Thanks, Alex. This has been Colorado Equal Security, and we will talk to you next time.

Learn more about the Colorado security scene at colorado-security.com, where you can see information about local security groups, a calendar of upcoming security events, and learn more about Colorado Equal Security. Reach out to Alex and Robb by emailing info@colorado-security.com.

Until next time, remember, Colorado equals security.