9. Application Modernization Requires Good Security Practices

As application development and modernization moves forward, security has never been more important. This episode of the Tech Field Day podcast introduces app Dev Field Day with a discussion of the importance of DevSecOps featuring Paul nhti, Mitch Ashley, and Michael Van. Welcome To the Tech Field Day podcast, the only podcast that daress to be both on topic or on premise, and sometimes yes, this week on location, on premises at app dev Field day.

But we're recording this one first, so we're not quite on premises yet. Each time we meet, we bring together a group of IT experts to discuss a single idea or concept in the industry. On this episode, we're talking about the relationship between security and application modernization and why security is desperately important if you're gonna modernize applications.

Before this discussion starts though, let's meet who's on the panel today. Hi, Steven. My name is Paul Nati.

I am the practice Lead at the Future Group for the app dev, uh, application development and monetization practice. Hey, Paul. Hey, Steve.

Mitch Ashley here I am, uh, personal analyst, and also general manager of Textron Research. com and Security Boulevard, techron tv. Lots of great stuff.

Hey everybody, my name is Michael Levin. I'm an engineer, consultant, live trainer, and all things content in the Kubernetes and platform engineering space. And I'm Steven Foskett, organizer of the Tech Field Day event series, including app Dev Field Day, which I'm organizing with Paul this week as part of the future and group.

So, as you guessed from the titles, as you guessed from the discussion, uh, we're gonna be talking about application development, which is, uh, a step up from the infrastructure that we've often talked about previously in tech field day, but that's what we're doing here with app Dev Field Day, and that's kind of the direction that we're headed. But as Michael and I have talked about quite a lot in the past, uh, there's quite a relationship between infrastructure platforms, applications, et cetera, and one of the things that really stands out is the importance of security everywhere in this stack. So I guess to start things off, um, Paul, I'm gonna throw this to you.

Um, talk to us a little bit about the application development, application modernization lifecycle and why security is so important there, Steven. Absolutely. I mean, you know, when I talk to, uh, prospects and clients and, and vendors as well as organizations, CIOs, basically their number one challenge today is application modernization.

And whenever I'm talking about, uh, the practice and what I do in app mod and, and application development, I, I talk about in the context of past, present, and future. And there's the, the heritage applications that are still running the lion's share of a lot of businesses, the modern state of applications, which is containerization and using Kubernetes and orchestration. And then there's also a future state, which is may incorporate things like web assembly and serverless technology.

So there's kind of different approaches, but the underlying, um, thing that people really need to understand here is, um, you know, on top of the challenges of skill gap issues to, to get this done and refactoring or what not to refactor, what to refactor, uh, and, and also which applications are going to be part of your, you know, uh, your ecosystem is the underlying foundational pieces of security, making sure secure applications are being developed, not just for your new applications, but for your heritage applications as well. So there's a lot here to, to really talk about and unpack. You know, there, there's, I agree with what you said, Paul.

There's also, I, I think organizations have been overwhelmed with security for applications, whether it's vulnerabilities that are coming in, in open source. We've all heard of, you know, very kind of visible, notable instances of, you know, things that have impacted Linux and, and large quantities of software that's deployed out there. But now we're, we're, we're faced with thinking not just how do we fix vulnerabilities or not write code that has vulnerabilities in the software you we're creating or that we're using.

We also have to worry about or be concerned about the supply chain. In other words, the underlying tool chain that we're using to develop test CICD, integrate, um, deploy all the, all the elements of that and how we secure that pipeline as well. So I think we've kinda shifted thinking about AppSec as not just the APIs or vulnerabilities, but the entire lifecycle of the application and how it's built or the software's being built, and then the stack, if you will, underneath it, of what we're using to build that.

I see a lot of everybody thinking about the top layers. Uh, to your point, Mitch, like whenever I get a call around security, it's always, you know, how can I scan my clusters properly? Or how can I scan my pods or my containers properly?

Or what kind of, uh, mitigating steps can I put in? And my first question is always have scans been done on the code, right? Because you can secure a container, secure a pod, secure a cluster, secure a VM as much as you want, spend millions of dollars in tools per year, and look at CIS benchmarks and the national vulnerability database and just about every other compliance implementation that you can.

But if the problem is in your code, you're, uh, you know, none of that stuff is gonna help at all. Yeah. When we look at the modernization efforts, you know, there's a lot there to think about.

I think Mitch and Michael, you, you basically kind of touched on the steps to get there, but there's the many approaches on how to get there as well, like using the CVE and understanding what's, you know, go doing code scanning is important for sure. Um, but it's also what I'm seeing in the modernization approach is when we take applications that are, you know, monolithic or, or heritage applications and we refactor them, um, there is an effort and some way to think about, and maybe the audience can kind of think about this as well as ways to, um, basically reduce the attack surface, right? And, and, and do slimming down of those applications, right?

So if you take in microservices and containerization, maybe you do your microservices and put the common elements in certain areas and only use the business logic in certain other areas. So you're reducing the attack space. So there's different approaches you can take, but obviously this is a big, big concern.

We see that, you know, there's executive orders in place that are out there, right there. We see that organizations are brought down. I mean, I was just, uh, working with a friend of mine who was buying a house and she was ready to close the house, and then she, her closing got delayed six weeks because they had a, a, a cyber attack and shut down the mortgage company.

So that was just crazy, right? So like, this is a real life real impact thing that's happening today. It, it definitely is.

And I think the analog of, you know, we, we talk about shift left and a lot, a lot of times that has meant, well, let's throw it on the developer's shoulders, one more thing for them to do, right? That's not a practical answer. Great people, they can't do everything.

Um, but I think more, more kind of effectively is thinking about how we build security in, you know, if we said, uh, I just bought a new car at the dealership, and they said, well, before you roll it off the light lot, would you like us to add some airbags in that for you? Like, what do you mean they're, they're not built in, you know, we would say that's insane. You would never do that.

So it's kinda the same thing about our software. So you, you, Michael and, and Paul, you both mentioned, you know, containers and containerization, microservices and things like that. A lot of those things emulate, like, for example, microservices look kinda like a network to security people, right?

Here's APIs talking to each other across microservices. Some are egress ingress, some are internal, um, but it's not unfamiliar. So those are concepts that we can build on working cross-functionally with like, well, how do we secure that?

Okay, here's an API gateway to do that. Maybe we design certain microservices, uh, so that they're hardened a little bit better if they're gonna be externally exposed or distributed across different applications. But that's part of the design process, not just coding secure software.

Right. You know, it's interesting that you mentioned that. 'cause um, I thought I was crazy thinking that this sounds like network security, but I'm glad to hear that I, that I, that I'm not, because it really does sound like how we build, uh, networks of systems.

You know, we have all these different things and we have to think about, you know, you mentioned, you know, the a**l analogy of, of a firewall, um, you know, we've got fuzzing of, of APIs and services. We've got, uh, you know, one insecure device can, uh, open some, you know, open the whole network to an attack. Well, it's the same thing here, right?

I mean, you know, we use one insecure component and it can, um, you know, undermine all of the security practices of everything else. And another aspect that reminds me of the data center is essentially the fact that you're relying on components built by different people at different times with different, different practices. And you're hoping that all of those things are gonna be secure too, because there again, one, you know, one mistake in one of those systems is enough to bring the whole house of cards down, right?

Steven? I couldn't agree more. I think that there's something that is an kind of an, I won't call it the elephant in the room, but it's something that we should talk about here as well, is security.

And when we talk about application protection, container protection, and we talk about that application modernization approach, that's only part of the story. There's a, there's a complete security element that's on the infrastructure side that wouldn't, we're not talking about, right? But when you talk about from the, the app dev perspective, the DevOps teams, the DevSecOps teams, they're looking at the business logic, right?

And everything that you mentioned, Steven, and, and Mitch, you kind of alluded to it as well, and Michael as well. The, the underlying infrastructure just needs to work. It just needs to be dependent and working.

And, and that's, that has to be secured. If you don't have that in place to, it's a house of cards, it's gonna fall down. And we, we know this, right?

We know that that's a, that's an area that we, uh, we want to double, you know, double click down into. It's actually, uh, interesting because to your point, Mitch, when you were talking about like, everything's kind of API driven right now, it's totally true. Like how we build our infrastructure right now is all programmatic, right?

Like, if we're doing it the right way, it's all programmatic. So now that I'm thinking about it, and after this conversation, app dev and, and infrastructure, software development, whatever you want to call it, kind of falls into the same place, right? And even from a security perspective.

So if you want to be really, really good at security, you have to be really good at one of two things, or both networking or software development, right? Because you're either helping security in the networking side and infrastructure systems all kind of fall there, or on the application side. So kind of without us realizing it, they, they all kind of touch each other in, in, in one way or another.

You know, to, to that point, Michael, a lot of times, where does the app end and where does the infrastructure begin, right? It's, there's not a bright line there in many cases, you know, the way you've designed and configured Kubernetes and how you're using it in your app to distribute functions of the scale or whatever it might be, that's all part of the app, right? It's just not suddenly kind of done for you, and you never have to worry about it.

So to your, to your point, I would add a third kind of skill, and that's kind of having a systems understanding about how this works. Not every developer's gonna have that. Not every infrastructure or CIS admin or DevOps person's gonna have that, but you have to put the pieces together to know how the whole system's gonna work together.

And the few people that can kind of keep all of that state in their mind and understanding are gonna really help you kind of make sure that it's all working and glued well together. Yeah. So, Mitch, I think that there's a, there's an element there that you, you touched on, um, where workflows and templates kind of come into play, right?

If you, if you wanna work within organizations, and maybe the audience would agree with this as well, if your organization is looking at specific compliance and regulations and rules in place, um, Michael, you talked about how infrastructure is built up as code I and infrastructure as code comes to mind. So having those templates and having those rollouts of templates makes a lot of sense. We see this a lot with workflows.

We see this a lot with automation, right? Um, and, and when you have actionable insights, if you see an issue occur, you can go back and deal with those, those, uh, those issues. Um, Mitch, one thing I wanted to kind of pivot a little bit towards is, you know, when we talk about, uh, security and we talk about application modernization, you know, there's the element of having SBOs, right?

And, and having those SBOs in place and having DevSecOps being able to do more around, uh, you know, secure delivery and make sure that everything's in the package that should be in the package. And then those, you know, uh, bag characters are not getting in there. What are your thoughts around, uh, how, you know, the audience can take that information and use that towards their modernization efforts?

Well, SMOs are, are a starting point, right? And it's, it's the kind of ingredients on the label of something we might eat. I also analogize it too.

It's the photo of the package that got delivered that's sitting on our doorstep. It doesn't tell you what happened before, what happened after the conditions might have changed, right? How did the package get wet?

What happened? But, uh, in, in, in SBO m world that's produced as an artifact of creating some component of software through a build process, delivery, et cetera, the, the real key to it is how do you use that information, right? How do you, yes, I can put it in a contract that'll give you SBOs, but if I'm have 40 suppliers all sending me SBOs every time they generate a new piece of code, that's not gonna help me at all.

Right? I think the, the real step to move to next is none of these things are static. The software we're building isn't static.

The environment we're building it in isn't static. The environment we're running it in isn't static. The code that we're injecting into our, into our workflows isn't static.

It's a flu. Software is a fluid, it's not a solid. And it's under constant change whether we, we acknowledge it or not.

'cause we may be talking to an API to a SaaS service that we don't know what's happening on the other side of that, that call that we're making. So I think the next step on, in, in SBOs is not only having it, but being able to analyze that data in real time when I need to diagnose something coming outta my observability system. Well, what does it look like at the moment in time that that happened?

And what does it look like now that's 15 minutes later, an hour later? And it gives you sort of that timeline of what has changed in your software stack. And if that's automated, then I think US bombs will be a tremendous benefit to us.

It's, it's, there's so many interesting metaphors going on here. Um, you know, Michael points out, uh, infrastructure as code. Uh, you're talking about bills and bill of materials for software.

That's, that's wild. And, um, and, and I think that a lot of the same things that can affect physical infrastructure can affect, uh, software application stacks. I mean, you know, one of the things that, uh, occurs to me, we recently had a big news story about the XZ util supply chain attack where, um, a, uh, component of the infrastructure was attacked specifically to, uh, in open up, um, a line of attack on all sorts of applications.

Um, luckily it was discovered, but, um, there's gotta be more and more of these things out there. Um, and, and, and of course that reminds me of that famous XKCD, uh, cartoon of, um, you know, the entire internet resting on this one little component that like, you know, one guy is maintaining in his spare time, is it really like that guys XC is exactly like that, right? This is a library used in, in Linux, many, many distributions, an encryption library, um, that was in maintenance mode, right?

And in that, that case, the new kind of attack we're seeing is, I call it the sleeper cell attack. You know, someone had, many years ago, a couple years ago, had gradually built trust with the maintainer, eventually got the maintainer bit so they could commit code and submitted something years later into the process. That's the environment we're running in.

I would make the case that those things are gonna continue to happen. You can't predict what the next thing's gonna look like that is gonna create a new attack surface for our software. So much like quality, the repetitiveness of improving quality by being able to do things quickly and incrementally.

I think our ability to release software isn't necessarily just to do 10 deploys a day into production. I think it's, maybe I only do one once a week or once a month, or once a quarter, but I'd need those times when I need to get something out in production in minutes or an hour. And so having that rapid ability to not only create code and get it through the pipeline, but make sure it's, it's secure as well, that's an important part of why we do DevOps, why we do DevSecOps, and why we automate this, not just to do hundreds of deploys an hour.

Yeah. And the other thing to think about as well is like, there aren't a lot of security centric people at organizations, which is why we kind of need to put this, the, this, these automated workflows in our pipelines. Um, I think I read somewhere recently that it was like for every a hundred developers, there's like maybe one security engineer, if you're lucky.

Um, 'cause organ, for whatever reason, organizations still don't see the value behind it. So if you don't have people to bring in to do this stuff for you, the next best thing, of course is putting all the automation within your pipelines within your lifecycle. And luckily, I mean, there's so many tools, whether it's, uh, enterprise, whether it's open source, various scanners that you can put into your integration tests, uh, or your unit tests, or just raw security tests within themselves.

Um, luckily it's, it's relatively straightforward right now from a, from a tooling perspective to put that into your, your life cycles and your workflows. I I, a question for you, Michael, uh, does from a platform engineering perspective, you know, there lots of parts to platform engineering. One of it is of course setting up environments and tooling for developers and lots of things.

How do you think doing those activities in a platform engineering group helps increase or improve security? What's your perspective on that? I have a particular view of platform engineering.

Uh, my view is, I believe platform engineers are the people building environments for internal engineers. Um, that could be the QA team, that could be the security team. That could be the IT team, right?

Like that could be the DevOps team, the developer team, whatever. Um, so my, my take on platform engineering as a whole is if I'm going in as a platform engineer, I'm building everything, everything from start to finish to get a platform up and running for people to be able to use, um, doesn't necessarily have to be like around IDPs and stuff, but just a platform in general, right? However you want to interact with it.

Gooey cly, API, whatever. But within that life cycle of writing the code, getting the environments up and running from an infrastructure perspective, um, getting applications deployed, getting the self-service deployed, there's a ton of security in there. Uh, which is why I'm a firm believer, like anything, platform engineering cannot be an entry level role.

I always say you should be a senior to principal level engineer to even think about platform engineering. Um, and with that, you should have at least a few years of security implementation experience. Uh, so 1000%, and I'm also a firm believer that regardless of what your role is, you should always be thinking about security in some way, shape or form.

Like, I'm not saying you need to be spinning up Calli Linux every day and trying to hit every box available on, on the Shodan website if anybody's been there. It's a, it's a fun place to go. Um, but you should still have some type of understanding of, of, of, of security at a base level.

Because again, regardless of if you're doing networking, infrastructure, application development, you have to be building it in a way that is somewhat sustainable. And security isn't about eliminating all risks. It's about mitigating as much as you possibly can.

Uh, that, so that's, that's my take on it just as a whole, Michael, I thought we were going to jump into an episode of Mr. Robot for a minute there, but, um, but that's, uh, that was really kind of cool where you were going with that. You know, I, I do wanna pull on the platform engineering thread a little bit because, um, you know, it, it, it, it's interesting when I talk to organizations, I go to a lot of different events and I go, I talk to a lot of different people.

And you know, it's funny, I walk around the show floors at some of these events and, you know, and I, and I will bet anybody a shiny quarter if they can find me somebody that identifies themselves as a storage and, um, you know, administrator or, or a virtualization administrator or, or a networking administrator, maybe Steven will. But, but like the, the, um, everyone's platform engineering. And, and the thing about it is, is I, you know, and I wrote a blog on it to try to kind of get some, some clarity in the market, like I was saying, like, who's, what is this thing, right?

And I agree with you, Michael, that there needs to be a maturity here, right? Um, uh, there are organizations that go it lines of business and then it DevOps and lines of business, it DevOps, sre and lines of business IT platform engineering in lines of business. And what does all of this mean, right?

And then when you start kind of pulling it all together, um, some organizations just don't know how to move forward. And I, I agree with you that the more senior level people that have like a well-rounded view from a platform perspective should be the platform engineering folks. And Mitch, you were talking about earlier about shifting left.

And, you know, not just from a security perspective, but from an application perspective, from everything that shifting left is more is happening in the CICD pipeline earlier in the build and release cycle than it is, you know, on the operating on the day two side, right? And the operations side. So it is an interesting kind of, uh, perspective to think about there as well.

Yeah, I think it's, you know, there's shift left shift, right? Doing things in production, there's shift everywhere. So those are the terms.

I think that's a, a symptom of shift left isn't the only answer, right? Because you've gotta secure not only your software, but the underlying tool chain and, uh, technology that you're using. You've gotta secure the stack to what Michael's talking about that this is all operating on.

And it seems to me having some expertise of really well honed expertise and platform engineering of building, uh, automating the building of those environments and making sure that the secure or addressing security when it needs to be repaired, that's, that's a systemic answer to part of the problem. Not just let's fix more vulnerabilities in the code that we're writing. Yes, we need to do that too, but you're taking care of a whole, you know, swath of the software that we're operating on, um, in our applications, in our code by doing that.

And again, their ability to react and provide that quickly, whether it's making a developer more productive, or I've gotta respond to this issue that just came out in the xz library. I've got that capacity. Think about it in that, in your modernization effort and how much that's gonna improve your AppSec right there.

Um, and, but it's still one of many efforts to take. So as well as I understand platform engineering, I think that it's something that I can really get behind because, uh, unless you went to medical school, you don't know everything and, uh, nobody can know everything. And, um, I feel like shift everywhere is a huge problem.

I want to key in on a word that Mitch said, expertise to me that is the core of platform engineering. The idea that you would have somebody who has real solid expertise, who really understands these platforms and is able to deliver something that is supportable, sustainable, secure, uh, other words beginning with s and that that would then be a foundation that you can build secure applications on. You know, that, that reminds me so much of what it has been trying to do my whole career.

You know, bring expertise to the table, figure out ways of collaborating with other people, figure out ways of, of delivering something that none of us could have done independently. And I think that, um, you know, most of the people that I know in software development space are, um, open-minded and self-aware enough to say, yeah, you know what, maybe we should have somebody who really knows the platform. Um, am I, am I misrepresenting platform engineering lavan?

Uh, is, is that right? Yeah, a hundred percent. You know, I, I think we, we unfortunately live in an odd tech world right now where, you know, Steven can attest to when things get too markety, I run in the other direction, I can't stand it.

And that's, that's like kind of where we are right now. And to your point of platform engineering, now that it's, it's a popular phrase and everybody enjoys it. The same thing happened with DevOps and cloud engineer and however far we want to go back, it, it just, it kind of is what it is like now.

Everybody wants to be that. Um, but the reality is when you go into an organization and when you're building a platform, you, you can't know everything like Steven said, but you have to have an understanding of how everything works. You can't build a platform without understanding networking.

You can't build a platform without understanding underlying infrastructure and virtualization. Nowadays, you probably can't even build a platform without understanding Kubernetes as a whole software development infrastructure as code security. Like you need to be well rounded, which is why I always say if you want to get into the platform engineering realm, you have to be at least a senior to principal level engineer.

It doesn't, it's not really about years. It's more about experience as a whole under your belt, um, before you can even think about it. 'cause there, if there is any entry level platform engineering roles, there should not be, in my opinion.

Now, Steven, I was convinced you were gonna say you didn't go to medical school, but you did stay at a Holiday Inn Express last night, so, but you didn't, so I was left to do it for you. Well, you know, my, my wife actually did go to medical school and, uh, one of the doctors at, uh, an MD PhD made a joke that, uh, the last course they teach you at medical school is called everything else. And, um, and app.

So doctors are self-aware enough as well, but as, as Michael said, I a hundred percent agree, it's not about gray hair, it's not about, it is about knowledge. It is about understanding, and it's about expertise. And if you really thoroughly understand, for example, the Kubernetes platform, you can build something that absolutely is brilliant and, and and scalable.

But if you suffer from Dunning Kruger, like so many people, uh, you could build something that is pretty terrible. Um, so let's get back to the, uh, back to the topic at hand to kind of sum up here. Um, I've heard the word DevSecOps mentioned a few times.

Um, I've heard a lot about platform engineering. I've heard a lot about modernizing applications. Um, and I like this metaphor that that software is a lot like infrastructure.

It's helping me to understand how this thing goes. So before we go, I guess let's kind of sum up here. What's your, what's your pitch?

How will we be able to help, um, bring better security practices to application modernization? I'm gonna jump in and say there are principles in DevOps, and I'm not talking about doing DevOps, but the, the principles behind DevOps come from the, the theory of constraints and manufacturing and that kind of thing, which is, you can't eat the elephant in one bite. It's an incremental process, and you work on the pieces that are blocking you from accomplishing what you wanna accomplish.

But you also work in smaller elements and components, and that's why microservices and all those things work really well. But you're doing it in the context of a larger effort. The way I think about DevSecOps, again, is that kind of full SDLC environment, whatever's in the tech stack from the tooling to build to the software that you're building, take those elements and work with the Michaels of the world and build the platforms that are gonna improve your security of that work with your, uh, security champions who are gonna say, great, let's implement these secure guardrails that will make it a little more seamless for developers to avoid certain things.

Or for us to encapsulate code to make it more secure work with your security, uh, with your, uh, security teams to understand their knowledge of the threat landscape and how we can apply networking and infrastructure ideas. Zero trust, you know, those kind of concepts are not, uh, they apply to software as well. So there's so much we can do by working together and dividing this problem up and incrementally making improvements at it.

I, I'll just add in one little piece here, and Mitch, you kind of summed that up nicely. The one thing that I will say is, you know, all of this really applies and does matter. There's also the factor of time to time to value.

Uh, you see that there's a lot of time to value. CIOs are being, are at task to do these tasks. They have skill gap issues.

They're putting pressures on vendors to make things more, uh, less complex and more frictionless to deploy. Um, so, and, and also organizations just for the audience, if you're looking at doing this, you know, if, if you don't have the resources in hand, work with service delivery partners, work with people that can actually get the job done for you. 'cause CIOs have limited timeframes to get these things rolled out.

And it's important to that time to value is important. I'll bring it down purely to the app perspective. You know, I, I don't care if you're putting it in your QA process, uh, I don't care if you're putting it in like a security style linting tool.

Uh, if you're using something like Sonar Cube for, for the, the full view of it all, understand the security needs in your underlying code. Uh, I can't explain that. How much easier it's gonna make things if you just start there and work your way up.

Well, thank you guys so much for joining us today, um, for this episode of the, uh, tech Field Day podcast. And also thank you for joining us at App Dev Field Day. This is the first time we've done App Dev Field Day.

Uh, it's sort of the, the prototype, but we're gonna be doing more of these, uh, going forward, and I very much look forward to seeing the three of you and the rest of our, uh, app dev delegates at Field Day, uh, this time. And, uh, beyond that. So before we go, um, if folks are interested and wanna continue this conversation, where can they find you and where can they continue the conversation?

Best place for me LinkedIn. You can see everything there from my videos, blogs, books, all content, and I also post twice a day, so you'll definitely get all the tidbits over there. Great.

Um, LinkedIn also, Mitchell Ashley is, is my tag. Uh, I also recommend, uh, go to Textron Research. We just released a, uh, new pulse meter white paper report on Secure Guard guardrails, what I was talking about.

com? Well, I encourage the audience to check out our app dev Field Day. Really excited about it.

This, this, uh, this event is gonna be, uh, amazing and I'm really excited about it. com and we also have the DevOps dialogues. And the DevOps dialogues allows us to, uh, kind of talk in the, in the context of conversations like this, around the impacts that, that impact organizations around DevOps and modernization, as well as, uh, moving forward for the application space.

So looking forward to talking to you there. Great. And, uh, as for me, um, you'll catch me here on the Tech Field Day podcast.

Uh, every Tuesday we also have, uh, a whole season of, uh, utilizing Tech, our Monday podcast that's gonna be, uh, gonna be launched shortly as well as of course our Wednesday News rundown. And, uh, I would also recommend checking out the Tech Field Day website for a complete schedule for App Dev Field Day and other Field day events. com, on Security Boulevard.

Uh, for lots and lots of great coverage on these topics and many, many others, thank you so much for listening to the Tech Field Day podcast. If you enjoyed this, please do, uh, subscribe. You can either subscribe on YouTube if you like the video version, or you can subscribe in your favorite podcast application.

This podcast is brought to you by Tech Field Day, home of IT experts from across the enterprise. com/podcast. Thank you very much for listening, and we will catch you all next time.