Securing Your Cloud Strategy with Matt Johnson - Developer Advocate Lead at Bridgecrew

(Joel Beasley at 00:00:03) Hello, my friends. Today we're talking to Matt, the Developer Advocate Lead at Bridgecrew, and we discuss the challenges of providing a secure cloud experience for every use case, lessons learned from working in both startups and large enterprises, and how maintaining company culture requires effort from everyone that's a part of it. All of this right here, right now on the Modern CTO Podcast.

(Matt at 00:00:32) Here we go.

(Joel Beasley at 00:00:33) This is the Modern CTO Podcast. On your Twitter, you said you love whiskey, and I have a friend that's like a big whiskey guy. Like one time he insisted I try his glass of it that was a $70 pour, which I just thought was ridiculous. And it tasted like hand sanitizer. But I was just curious, like, how into whiskey are you?

(Matt at 00:01:11) Yeah, I've got a worryingly sized collection in the other room. I'll send you a picture after this. I wouldn't say it's like—I wouldn't say it's something I spend any time per day getting into, but in terms of, you know, visiting a distillery if I'm close to it or learning about different types of whiskey, I found that with the pre-COVID—with the amount of business travel I was doing, there was always kind of different American whiskeys, you know, Japanese whiskeys, Irish whiskeys. And it was just kind of a cool thing to attach to a location you were at, in the same way I quite like craft beer. You know, there's always kind of a different style of beer wherever you go and a different story. So it was something to do which blended kind of activities and alcohol. But yeah, I've probably got about 40 bottles, I would say.

(Joel Beasley at 00:02:03) It's not crazy.

(Matt at 00:02:04) No, no. It's not over the top. But at some point, that probably does need to be a proper tasting session.

(Joel Beasley at 00:02:12) Well, so let's talk about things related to this podcast. How did you first get into technology?

(Matt at 00:02:23) Yeah, so I have always been—I never came up on like the coding side of tech. I came up on the really like hacking, breaking things, like enjoy a challenge side of tech. So my real entry into computers was probably because my parents had kind of technical roles. My father worked for the national grid electricity companies here, so that was all kind of varying maths, power grid, you know, that kind of based. And he had these really old work laptops that he'd used for like CAD and designing circuitry and stuff. So I kind of got introduced to those from quite a young age, and kind of growing up in the north of England—you know, not exactly a big Silicon Valley tech hub—maybe there weren't quite as many access to systems and things like that available. So yeah, that from a young age. And then through family friends, someone was really into Linux. And I'd hooked onto, as I said, AV. I'd hooked onto networking in a big way. I found like the way the internet worked from like dial-up and understanding IP addresses and understanding how things talk to each other. Like I think that was my first real passion. But obviously, as kind of a teenager, you don't really have access to the kind of equipment, your Ciscos, your, you know, big networking vendors at the time. There was no real kind of software-defined networking. So someone put me on to Linux, and I actually ended up learning Linux to learn the networking side because obviously it was a lot easier to kind of mess around with networking in Linux than it was in Windows at the time. You had a lot more access to the stack you could kind of understand. And that took me off on this kind of wild tangent of wanting to understand how Linux worked. And so my first kind of job, you know, Linux all the way through uni. My first kind of job after uni was actually as a senior hire into a company that needed a back-end Linux engineer that also could debug. It was for a SaaS security product. So they needed people that understood networking to a high level, could kind of debug packet captures and things like Wireshark, but also it was an entirely Linux-hosted system, so they needed someone with Linux skills. So yeah, kind of weirdly fell into that through passions and what I was learning on the geeky tech side rather than specifically my computer science degree.

(Joel Beasley at 00:04:45) Yeah.

(Matt at 00:04:46) But as I was saying earlier, I think the time that university gives you to kind of play around with those passions without having the kind of nine-to-five—like, I definitely wouldn't say I could have done it without going to uni because it gave me that time to kind of explore those hobbies and things like that in a very free way.

(Joel Beasley at 00:05:02) Yeah, absolutely. I mean, I'd say my full-time job today is totally built on lots of ancillary skills that were learned just kind of existing through college, not necessarily in the classroom.

(Matt at 00:05:21) Yeah, 100%.

(Joel Beasley at 00:05:23) But so when you were talking about networking, you mentioned Cisco, and I saw that you worked there for like a long time right before Bridgecrew. What was it like moving through the various roles in the company, and how'd you find your way to Developer Advocate, which is what you're doing at Bridgecrew also?

(Matt at 00:05:43) Right. Yeah. So as I said, kind of always liked kind of a hackier side of, you know, you could say like ideas, breaking something to rebuild it, understand it, kind of proof-of-concept side of things. Obviously, you can't really be in Linux and in kind of any kind of operations engineering role for very long without kind of needing to at least script fairly well. And so, you know, my first role kind of brought me into—we were writing some stuff at university—but into kind of really problem-solving and automating through scripting and then programming. So it kind of forced me to kind of bridge that gap between, I guess, what you'd call like dev and ops nowadays, but I definitely kind of started very much in that ops camp. Cisco was really interesting because at that time, the product I was working on was kind of coming in through an acquisition, and it was all bare metal. And again, just through kind of hacking and general interest, like I was pretty familiar at that point with virtualization and VMware and the kind of open-source alternatives. My degree thesis was actually on comparing how close you could get with open-source software to building out like a Microsoft-style user experience in terms of federated identity and authentication and login and kind of all the Active Directory Microsoft stuff back then that was on-prem. It was all about kind of how close could we get with OSS. And so, you know, when it came to look to move from kind of a bare-metal environment within that kind of Cisco-acquired product, I found myself kind of in the middle of, well, there's these new things called containers, and we already know about cgroups and jails, and do we want VMs? And so I got quite a lot of experience with, you know, almost my first modernization project, if you will. Like, how do you take a 22-data-center bare-metal infrastructure and start thinking about virtualizing certain bits and start thinking about moving some of those into more programmatically updatable, programmatically definable things? So that was pretty cool. And I found that very quickly, a lot of that work, just as much as it was about technology, was also about building allies and making sure people weren't just saying no because they were scared of that change. And, you know, some people that have been used to it the way it was or didn't necessarily have the background or the experience with kind of virtualization and things like that. So I found myself kind of doing that internal advocacy role just as much as the technology role. And that kind of stuck with me because then every opportunity since then, what we were trying to build was actually seen as really useful, you know, those common building blocks, that kind of platform, the automation around deployment. So I ended up taking a position in a platform team that was trying to abstract those ideas to make it easier for other teams to adopt kind of non-bare-metal deployment strategies. And so we tried to build kind of a platform for all the future SaaS products to sit on top of. But again, that was a lot of winning friends and influencing people as much as it was technology, because if people didn't get how they would use it or why they would use it or how their day-to-day development lifecycle or the day-to-day kind of workflow changed, then it doesn't matter how good your technology is, right? You're never going to get the adoption that the whole point of a platform like that needs because it's only cost-saving to the business when you're actually getting the economies of scale on something like that. So yeah, every role since has been very heavily in kind of developer experience from a "use this to save time," you know, automation evangelism. But I just found that more and more, it was just as much about the people as the tech. And I think that's how I kind of found myself eventually full-time in a developer advocacy role. At the time, Cisco was kind of heavily pushing the fact that most of their product, most of their solutions did have APIs, and it wasn't particularly well-known. It wasn't well—you know, you had customers asking for fixes on features that they didn't necessarily maybe know there was an API that they could actually add that feature themselves if they wanted to, potentially quicker or at less cost. And so there was a team, DevNet, spun up to really evangelize the power of APIs and the power of programmability. And I ended up doing kind of so many talks while part of a CTO, cloud CTO office while at Cisco that the team eventually just said, "Hey, do you want to just come and work with us directly because you're already a speaker at most of our events anyway?" So yeah, that's kind of how it snowballed. But it was never a—it was never a plan. I never went, "I want to become a Developer Advocate." It just kind of happened through that kind of balance of people and technology.

(Joel Beasley at 00:10:28) So would you say being a Developer Advocate is like as much convincing the developers to use certain tools as like convincing other people in your organization that certain things developers want to be working on are worth their time? Like, that's kind of what I was gathering there.

(Matt at 00:10:47) Yeah, it's—I wouldn't say so much convincing, but like—

(Joel Beasley at 00:10:52) Yeah, when I was saying it, I was like, that's a bad word to use.

(Matt at 00:10:55) More like, yeah, if you're not getting the feedback from the developer about whether what you think they want to do is or isn't what they want to do, then yeah, you're more marketing or sales than you would be dev advocacy in my perspective. Yeah, it's all about the UX for the developer. If it's not working for them, then we need to ask ourselves why.

(Joel Beasley at 00:11:19) Very cool. So what caught your eye about Bridgecrew? What made you decide to leave Cisco and do a similar role at a new company?

(Matt at 00:11:30) Yeah, it's a very good question. The lockdown definitely had a lot to do with it. You know, the first time you can kind of stop and be in one place—and I'm not saying at all that it's not a world and a life I want to go back to—but I was doing a lot of traveling for my previous role. And obviously, all that came to a very abrupt halt with the lockdowns and COVID and all the kind of travel restrictions put in place. And at that time, you know, you realize that while travel is amazing and you get to speak to a lot more people face-to-face, and I do miss that kind of human interaction side of the role even now with things not quite opening back up, it also allows you to kind of focus on, you know, maybe take a step back and think, actually, the travel serves as quite a distraction. Like, what is it actually I'm trying to do? What is it I'm trying to grow into? And, you know, it kind of always harks back to that fact—the one passion that hasn't kind of waned through my career has been that like pen tester, hobbyist attitude to security. And so when this opportunity came up to do something, A, with a huge open-source basis to the company—you know, our open-source tool, Checkov, from Bridgecrew was like the first thing that was written when Bridgecrew was in stealth mode. Like, you know, it's deep in kind of cloud and, you know, still requires that kind of bottom-up like developer buy-in, but it's all related to kind of securing your cloud infrastructure. Like, it just couldn't have been a more perfect combination of things that I'm not just enjoy doing for a job, but actually passionate about. So it was just right place, right time, and it was just too good a growth opportunity for me to turn down, really.

(Joel Beasley at 00:13:17) That's really cool. So I know a big part of Bridgecrew is moving—shifting cloud security left. And as I was preparing for this interview, it reminded me of this other company we had on quite a while ago. They're called NowSecure, and they also kind of shift security left in turn, but for app security. They're more focused on making sure mobile apps are secure before they go out so they can like do that check. But with Bridgecrew's focus on cloud security, I'm just curious like what it looks like in practice. How different types of security are like different from each other from like the company's perspective working on it day to day, whether it's cloud security versus app security or—I don't know, I feel like there's like 10 other different types of security to focus.

(Matt at 00:14:09) Yeah, the joys of the blanket defense-in-depth, "you need them all" argument. Yep. But no, I won't be that lazy. So yeah, I think the way I try and put it is, you know, if we go back a few steps in IT and computing history, you know, you would have bare metal, for example, or you would have on-prem data centers, and those on-prem data centers would be behind firewalls. And so the idea—the notion of cloud security isn't really a problem because there was no quote-unquote cloud. There wasn't a public set of APIs that anyone with the right token could access. You know, the lowest access point you had was to your, you know, your application database on a physical server or to your application deployment running code on a physical Linux or a physical Windows installation. You know, you didn't have that like lower-level access under your application stack, under your operating system stack. And obviously, the cloud being public and API-driven, we now do have that. And so things that were never really a problem, or they were a problem, but they just weren't as obviously exploitable—for example, you'd have to be inside that user's network. You'd have to be in that enterprise environment. You'd have to find your way in through firewalls and all that kind of stuff rather than just going to Azure or Amazon or Google—you know, pick your favorite. I hate singling one out rather than the other. But, you know, rather than just kind of firing something at an API and seeing if the token works and seeing if you get back a list of IAM policies or IP addresses or security groups or whatever service it is. So I think with that change, there's kind of a learning experience. You know, there's a lot of switches and knobs and buttons for each of the cloud provider's different products, and they're adding more products all the time. And kind of on a slight usability versus security tangent, which we see all the way through the industry since the beginning of time, the default settings which are easy to explain, that are easy to get someone up and running might not necessarily be the secure ones that are going to guarantee you compliance and are going to make it harder for an attacker to move laterally if they do manage to break into something. And so shifting left for us with cloud security is all about, look, if you're a small DevOps team, you know, you are not expected to know the thousand-page CIS benchmark compliances for Kubernetes and AWS and Azure and, you know, everything else that you would need to know. And yet all of these items are literally the first attack point. They're below your code. They're below your VMs.

(Matt at 00:16:59) If you don't get those right, there's no point having your application security scanning. There's no point having your container image scanning because someone can go in at a lower level directly into your cloud environment. And so for us, it's about utilizing snapshots of that, and we do a lot with infrastructure as code because it's declarative and just like we try and move to declarative things for everything in infrastructure these days because it's repeatable. So if we can define our infrastructure as infrastructure as code, be it Kubernetes manifest, or Helm, or Terraform, or whatever your preferred infrastructure as code language, Bridgecrew works to then go, hey, okay, I can see the objects you're about to try and create declared as infrastructure as code. Did you know that actually that, for example, default S3 configuration for a bucket you want to create isn't secure? You should enable logging. You should enable versioning. You should encrypt at rest.

(Matt at 00:17:57) All of these things that are not done by default, turn all these on. Or, hey, did you realize you are leaving this load balancer open to the whole world? Did you want to do that? Or is that an oversight because that's the default security group? Things like that. Just allow effectively, we like to think of it as like a virtual security team. And we try and surface this information in places that developers would be anyway. So we try to annotate pull requests or merge requests so that it's part of a developer's review cycle anyway. Like, hey, you probably don't want to push this new infrastructure's code to production because of these issues. We're not trying to say, hey, go and become a security team in your own right and go and have all these other security-based dashboards. It's just trying to surface this information via a VS Code plugin or alerting in Slack when we detect drift between what they think is running in production and what is actually running in their AWS account. So all these kind of little things that we can do to help developers almost have that virtual security team.

(Joel Beasley at 00:18:57) Okay. That makes a lot of sense. Thanks. I feel like you explained that super well. So it's like a kind of a virtual assistant that is extremely well integrated with the cloud providers to be an expert in all the various deep settings of the cloud providers' offerings to know which ones are secure, which ones aren't for which use cases also.

(Matt at 00:19:22) Right. Right. And I'm glad you said that because I thought I ranted far too long on that explanation. So I appreciate it.

(Joel Beasley at 00:19:29) No. No. It was great.

(Matt at 00:19:31) It actually did make sense through all the tech words.

(Matt at 00:19:36) Cool. And obviously, it's not the be all and end all. There will be certain use cases that boil down to, well, we cannot possibly know whether this is something you meant to do because that choice is based on your individual business's requirements and a person has made a decision somewhere as to whether that is or isn't needed. So at that point, we can only flag that issue up as, hey, this is potentially against a PCI DSS or pick your favorite compliance policy. And there will then need to be a conversation within the business as to why that setting's there, does it matter. And we allow things to be skipped and reasons to be given again in the code. So you've got a record for future generations of engineers. But, yeah, it's never quite as, you know, click and done. It's a process just like anything else. But, yeah, we try and put that process where the developers are. That's key.

(Joel Beasley at 00:20:33) So I know your platform also does infrastructure automation. Do you ever come across potential clients that are pretty hesitant to let you modify their infrastructure in any way? Like having a lot of inertia there?

(Matt at 00:20:48) Sure. So we very much believe in GitOps, and that's a horribly overloaded buzzword. So I'll rephrase. We very much believe in source control being your record of truth and history and changes. So if we do make suggestions to fix things, the preferred method, and our platform can do this, is automatically raise a pull request into your code base just like a developer would to fix something manually. And at least then that change is documented and part of source control and things like this. I was having a rant at a conference last week about this. This is going to be way down a technical rabbit hole tangent, but about mutating admission controllers for Kubernetes. Things that will take the definition of what the developer or the ops team is saying they want Kubernetes to do, and then changing it in some way before it goes on to the cluster. And it's like, well, that is the opposite of read-only immutable infrastructure because you don't, let's say someone breaks that admission controller or changes the rules of that. You don't know that a deployment, even though it's in Git and it should be final, you don't know what that actually looks like by the time it's running in production.

(Matt at 00:22:08) So, yeah, we take a very strong, this should all be in Git. And the only time we don't do that is to alert that, hey, you deployed this from infrastructure as code stored in Git. What is now running in your AWS environment doesn't look like it did when it was in Git. So we think that that triggers a drift detection rule because we think that maybe one of your engineers or someone or an attacker has gone and manually made a change to that object in the cloud. But the recommended remediation would still be to rerun your infrastructure as code to bring that back to where it was rather than go into the cloud and make even more manual changes.

(Joel Beasley at 00:22:49) So being extremely transparent is a big priority.

(Matt at 00:22:55) Yeah. 100%. Yeah. Security shouldn't be, oh, go and ask Bob two weekends ago what he did to fix that bug. It should be there just like another commit, just like a feature, just like a typo in a web interface.

(Joel Beasley at 00:23:09) So what's one thing you had to learn coming from a developer advocate at Cisco now at Bridgecrew? Bridgecrew is a smaller company, obviously, than Cisco, working on a pretty niche but very intricate problem. What was the challenge for you coming to this company?

(Matt at 00:23:35) It was a completely different way of working. I get to, I'm going to kind of take the cop-out easy way of saying this because I can honestly say that I really liked the way of working. I think it would have been harder if I'd come in and gone, oh, I don't like this at all. But, actually, I quite like that when I joined, I was employee 22. There were few enough employees that you could literally learn everyone's name, and what everyone did, and what teams everyone was on, and what everyone was working on. And it was small enough that you could spend time with those other teams to learn the product and to learn how product management works and how marketing works and how the production team was building some of the production automation. So as someone that quite likes knowing how things work, I actually really enjoyed that. And also the autonomy because there wasn't enough people for everyone to be doing each other's jobs. So you kind of did have the, I don't need to ask four levels of corporate approval to do X, Y, and Z. I can publish this blog. I can write this code. That was pretty nice to me. Although, you know, you do work pretty hard for a startup. So either way, it was, no, it was really good.

(Matt at 00:24:51) I think the one thing I found maybe a little bit strange was obviously with that kind of everyone talks to everyone. I'd be super useful at Cisco, for example, only updating a couple of colleagues because they were the only people that really needed to know what was going on and what was working on. But communication in a startup is absolutely way more key because everyone's working at lightning pace. And if they don't know what you're writing or when that's going to be released or what code that maybe could help someone else or a customer you're talking to about an issue, you know, it'd be very easy to waste that precious 22-person resource on repetition and things. So I definitely needed to improve my kind of internal communication skills, especially working from home and things. That's definitely been an interesting challenge, just getting used to that cadence of pace of change. But, no. Otherwise, it's really positive. And my only other startup experience was straight after university when we were working for a company that was building a connected data center for the NHS, and they went bust before we got live. But that's another story.

(Matt at 00:26:04) So, no, it's been many years in the making, and I feel like this is my proper first kind of proper startup experience. It's taught me so much, learning the other teams and getting a real visibility into teams that you would never have otherwise spent time trying to understand the inner workings of, like marketing, like HR, like startup recruitment and things like that. No, super interesting.

(Joel Beasley at 00:26:29) That's really cool. Yeah. I got to say, I mean, we're technically a startup here at the podcast, really small. And yeah, I don't know how you count employee numbers because people have come and go, but as of right now, I'm employee number three. But it's, yeah, I really like the concept of everyone is pretty clearly the expert on whatever they're doing. And so that was something I had to learn really early on when I came on as the audio engineer guy. And I would ask someone else a question like, hey, is it okay if I do this thing with the audio? And they're like, I don't know. You're the audio guy.

(Matt at 00:27:12) There is no one else to ask. Yeah.

(Joel Beasley at 00:27:14) I was like, oh, okay. So I just kind of get to decide. And, yeah, that's a really cool thing. I mean, obviously, you said, owning your expertise like that obviously comes with harder work, but it's cool because you own it and it's yours.

(Matt at 00:27:31) It's nice to have that really fast feedback loop of seeing out what you put in kind of thing. You know, you've worked on this piece of content, you've ideated, you've created, and it's there. Or, you know, the customer had an issue, you've worked on it, it's done. It's really nice to feel that really tight loop rather than in a few months' time going, oh, yeah, I remember when I did that work. It's live. That's cool. It's, you know, just those little wins every week are definitely worthwhile.

(Joel Beasley at 00:28:05) So you're employee 22. How many people are there now?

(Matt at 00:28:10) I think at time of acquisition, and don't quote me on this, I think there were 43. So, yeah, we doubled in size pretty quickly, to the point that when I joined, we could all fit on a single Zoom screen. And for our team meetings, just about and then two weeks after I joined, we'd spilled over onto page two. So, yeah, it was a crazy time, but super cool to witness the growth and witness new customers coming on and new products and features. It was, yeah, super exciting.

(Joel Beasley at 00:28:43) And you mentioned the acquisition. I guess I was under the impression that Palo Alto had already bought Bridgecrew before you joined, but you were there for the acquisition?

(Matt at 00:28:53) I was there for six months, yeah, before the acquisition.

(Joel Beasley at 00:28:57) Oh, that's really cool.

(Matt at 00:28:58) Yeah. I joined in August of last year, and the acquisition closed in March.

(Joel Beasley at 00:29:05) Nice. So what's the relationship like there? Because I feel like the vibe I'm getting is that it's still very much Bridgecrew startup culture that exists within Palo Alto. Is that correct?

(Matt at 00:29:20) Yeah. 100%. Having only ever seen acquisitions from the other side, never done it this way around, exactly that. We're still building out our product. Yes. We're an API-driven platform. So there's integrations going on to share data from existing products to build feature sets into other products within the suite. But in terms of my role in DevRel, in terms of what Bridgecrew's mission is, the product, you know, what we're trying to enable for developers. It's business as usual, which is really cool.

(Joel Beasley at 00:29:55) Yeah. That is really cool. So before we kind of get towards the end of the podcast, is it cool if I ask you some leadership questions about your role there?

(Matt at 00:30:07) Yeah. Sure.

(Joel Beasley at 00:30:08) So do you run a team there? And if so, what's your approach to leadership like? How would you describe that?

(Matt at 00:30:14) Sure. So I've run bigger teams in Cisco. At the moment, I would say no because we are a team of two, and it doesn't really seem to be much point in having a manager-employee relationship for what would effectively be a straight line up to my director. So, no. We basically work as just a team of two at the moment. I think from historically speaking, in terms of leadership style, I made some pretty bad decisions in the past, which helped me course correct pretty quickly, which was trying to do what I myself hated, but accidentally fell into, like micromanaging a team of engineers when I had an idea of how I wanted something to look technically. But at the same time, I wasn't really the one doing all of the coding work, and so there was no point pushing implementation details on the people that were. And, understandably, that got people's backs up. So, yeah, really going back to what we were saying earlier, the idea that you hire people for their skill set. And I like to think of it like when I sat one of my favorite exams ever, which was the back in the day, the Red Hat Certified Engineer exam, and I think I was in my early twenties. I was on a placement year. They gave me the opportunity to do this, and it didn't actually matter, the exam was marked by scripts running against the machine or the VM you were on to see whether the business outcome they had set you for a configuration or for something working was like it. It didn't really matter how you got to it, because different people would do it in different ways. All that mattered was did it survive a reboot? Did it actually do the thing that the instructions had asked it to do?

(Matt at 00:32:06) And compared to a lot of exams these days where you're kind of having to decipher the mindset of the exam question writer to work out what they want the answer to be, I really liked that kind of, you know, no, all we care about is the results. And I think management style, like I said, made mistakes. You're hiring people for their skills. You're bringing them in. You're giving them the job because you trust that they have that skill. You trust that you're bringing someone in that will ask if they don't know. They will ask for help. You know, they're the right cultural fit to not be afraid to do that within the team. So let them go and do the thing you've asked them to do. Like I said, I'm definitely guilty of not practicing what I preach there. But, yeah, fingers crossed that is how I would manage future teams.

(Joel Beasley at 00:32:53) But that's why you're an expert on it because you have not practiced it in the past. So that's why you changed.

(Matt at 00:33:02) Definitely the best learnings are the ones that you make mistakes on for yourself. Right?

(Joel Beasley at 00:33:08) So how would you describe the culture at Bridgecrew?

(Matt at 00:33:13) I mean, I'm a Brit. Right? So I would say it's quite British in its directness. You know, a spade is a spade kind of thing. And disagreements do not necessarily have to be seen as arguments.

(Matt at 00:33:31) You can disagree and you can come to an agreement, and then you can all just agree to execute. I actually found it really refreshing compared to the politics that go with large companies. It just allows everyone to kind of get on with what they're doing. So yeah, quite open, quite respectfully discussion-based, if I had to coin a term. But yeah, there's definitely no stress about the politics, which is nice.

(Joel Beasley at 00:34:02) That's really cool. So we hear from CTOs on the podcast a lot and cofounders that talk about culture as something that they have to really actively cultivate and keep a finger on the pulse and make sure everything is going as planned. But in your role, how do you view your responsibility to maintain the company culture and keep that healthy?

(Matt at 00:34:32) Yeah. And just to comment on that, I was actually just about to say that I definitely feel the culture I came into when I joined was because of a concerted effort and a maintained and sustained effort by the founders. You could kind of tell that the culture was only like that because they themselves were practicing what they preached in that respect. And I think it's the same, right? I think anyone joining a team is going to at some point subconsciously want to kind of fall in line or do as they see or, you know, quote unquote, fit with how the rest of the team seems to be working, whether consciously or not. And so I think to maintain a culture, you kind of have to practice that. If I enjoyed that culture when I came into it, I am just as responsible for making sure that the next people that join—and I do a welcome onboard meeting and show them what we're doing in DevRel and show them our current projects and things—you know, I have to also be setting them up for that culture as well.

(Joel Beasley at 00:35:40) So before we wrap up—I've also, by the way, fantastic answer. Sorry, I didn't mean to glaze over that.

(Joel Beasley at 00:35:47) But before we wrap up, is there anything else that we want to get out there that we didn't get a chance to touch on today?

(Matt at 00:35:54) I think one of the hardest things we're seeing from how to plan for security and if you're a CTO, if you're a team lead and you're looking at, okay, compliance, security, blah blah blah, like, what do we do? Where do we go? We are in the cloud. Are we sure we're doing all this cloud security stuff? One issue we see a lot, which we've been really trying to focus on recently, is, you know, if that team or that product is planning to make, I don't know, a million dollars a year, you're not going to spend 5x on security tooling. You're not going to spend 5x on a security team and things like that. And a lot of the times, I think it's so easy to look at—as you said, there's probably 12 different types of security from cloud security to scanning your dependencies to looking at your application code, to looking at CVEs in your containers and things like that. And it's so easy to look at all of that output and go, well, if we started trying to pick through this, we're actually not going to deliver the product. So what's the point in securing something that isn't a product because we won't have time?

(Matt at 00:37:07) And it sometimes feels like a bit of a lost cause. I'd like to kind of have a conversation around that with anyone that's interested. I think more and more this is becoming a thing. You know, we as an industry are really good at adding new layers of abstraction, which may come with their own security implications. But we're very bad at collapsing historic ones when we don't need them, even if everyone is taking a single path through that abstraction and it's not really needed anymore. We never really collapse it. So all the kind of baggage around it from a security perspective might still be there. And yeah, my only point of that would just be there are small things you can do that will make a big impact on your security posture. You are not going to put a two-week sprint aside and go, right, we'll get security fixed, we'll patch all the CVEs, we'll get it done, and then we can move on with the product again. But even just using automation if you're moving into this kind of cloud-first DevOps mindset of, you know, your developers aren't manually running tests. Your CI/CD pipeline's doing it. You know, your deployments are happening automatically. There are so many little things you can do, first of all, just to add to that CI/CD pipeline to get a visibility of maybe the security issues you're dealing with. And that doesn't mean you have to fix them there and then. It's better to know and prioritize and think about them than just think it's too big a job and not do anything at all. So yeah, incremental steps, utilize any automation you already have to start getting that visibility. And, you know, by all means, come chat to me, Twitter, Slack, et cetera. I'd love to have conversations about pain points with security because a security team that seems like a blocker or even if it's in automation, right? Even a modern security tool that spits out a thousand errors the first time you run it against your repo is just going to piss off your developers. And that's not actually benefiting anyone in terms of security posture. So a security team that went, hey, we can see all these issues. Let's prioritize. Let's maybe fix one a sprint. I know it's going to take a while. I know it's a backlog, but, you know, it's a much more realistic way to approach it. And I think it puts a lot of people off less than trying to do the whole security as a button that if we work hard enough, we can push it.

(Joel Beasley at 00:39:29) That was a very developer advocate perspective on it, which I think—

(Matt at 00:39:35) Slash bordering on rant. But yes.

(Joel Beasley at 00:39:39) No, that's awesome, man. And yeah, I guess prior to today, didn't have that great of an understanding of a lot of the different niches of security and the value, I guess, of focusing in on them. But I mean, the way you described running cloud security and how you have to have all this expertise around each individual cloud provider and the various security—what's the word, not threats—weaknesses of settings and tools that are available. And I can very easily see that being a thing in every other security niche. And it's just you just got to focus in on it. And yeah, I don't know, there's tools out there like Bridgecrew to help you do it.

(Matt at 00:40:33) Yeah. And I think more and more, tools like Bridgecrew, you know, like you said, many other vendors for the rest of the stack, the idea that these aren't things that can be laid on top. They are things that, you know, you do need to be working with developers. You do need to be kind of where the developers are and not feel like security is just a burden that's being draped over the top of the dev team. I think we'll massively increase, like I said, the kind of default security posture because it will stop feeling like such a pain to start or implement or, you know, be something that another team needs to be hired to do. So yeah, hopefully we're moving in that direction. I think we are.

(Joel Beasley at 00:41:17) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague that you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.