Seth Law is Founder and Principal Consultant of Redpoint Security, an AppSec consulting firm that focuses on code security, as well as co-host of the fantastic Absolute AppSec podcast. Seth has plenty of experience with the nitty gritty details of software development, and Cole Cornford had a great time nerding out with him about static analysis tools and code reviews.

They chat about the potential for AI to improve AppSec, the unhelpful tendency to idolise big tech companies, the importance of good communication between developers and AppSec, and plenty more.

Secured by Galah Cyber website

Mentioned in this episode:

Call for Feedback

Hi, I'm Cole Cornford and this is Secured, the podcast that dives deep into the world of application security.

And if the first thing that security does when they walk in the door is tell them, "Hey, your baby's really ugly and you should just throw it out.", they just turn off. Because any of us would, if you don't show that you have understanding or empathy for the position that they're in, it's going to be antagonistic.

Seth Law is founder and principal consultant of Redpoint Security. Redpoint are an appsec consultant firm that focuses on helping people write secure code. Seth is also the co-host of the fantastic Absolute AppSec podcast, which I've been listening to for many years. Seth has plenty of experience with the nitty-gritty details of software development, and had a great time nerding out with him about static analysis tooling, code reviews, and so on, so forth. We chat about the potential for AI to improve application security, the unhelpful tendency to idolize big tech companies, the importance of good communication between developers and appsec, and plenty more. Forewarning, this is a heavily techy episode, so if you're someone who likes stories, this one might be a bit hard for you, but otherwise, let's jump right on in. And Hello, Seth, how are you going, mate?

Hey, Cole. I am doing very well. I'm excited to be here, I'm excited to chat. Prepped myself with watching some episodes and just trying to figure out what I would say actually being interviewed as opposed to interviewing. That's been my MO for the last few years. I think you understand how that goes. So I'm interested to flip the script a little bit rather than trying to pick someone else's brain. Actually have to think about my own opinions, I guess. I'm excited to be here. I'm rambling on now, Cole, so yes.

I've had a few guests who are on podcasts on as well. I had Karissa Breen, who's a very well-known media personality in security, and she was just like, "This is so weird. This is the weirdest experience. I'm not used to being in a hot seat and having people asking me questions. I need to be a targeted journalist that goes [inaudible 00:02:06]."

Yes, exactly. I'm used to asking, oh, I'm trying to get people to give spicy takes, as opposed to... I mean, we do say what we feel on the podcast. But yeah, it's just flipping the script for me a little bit, which is good. Right? I like to step outside my box once in a while, so I'm excited.

Crocs and socks.

Crocs and socks. Crocs and socks it is. I may or may not be wearing a pair of Crocs. I don't know if I can admit that, but yes, yes.

Well, I've got socks on, so there we go. Look at us.

Okay, there we go. So we got both.

We got both on the podcast, that's all. So I usually start by asking most of my guests, what kind of bird are you and why?

What kind of bird am I? Now, I put a little bit of thought into this because I had seen it and I had heard it. What I kept going back to was some sort of a hawk or a peregrine falcon, something that kind of sits up top, pays attention to details, but kind of rides the different wind patterns, and then once they focus in on something, really dives in, takes care of it, and then goes back up and soars some more. That's very apropos actually what I do on a daily basis and how, yeah, we've got a lot of stuff that's going on trying to maintain a pulse and then really digging in deep, going on a side quest, shall we say, all the way down, deep as I can, and then back out. So that's where I settled, was some sort of a hawk or a falcon, like one of those kind of birds. Seemed to fit.

The peregrine falcon is, I believe, the fastest animal on Earth. I think they dive at 350 ks per hour.

Yeah, yeah, exactly. When they're dropping down, it's crazy. So yeah, that fits. I'll take that. I'll take that. Yeah, yeah.

Do you find it you just find some kind of niche area and then you just go at it super fast and you have to really, really understand it's what the metaphor is? So you'd pick, I don't know, Ruby on Rails or Web3 or something and just say, "Today, I'm an expert in Solidity, I'm just going to go all the way down."?

Yeah, yeah. Well, I mean, I feel like I'm almost forced to do that, especially from a technical perspective. Client comes in, there's a new technology, or it's something related to something we've looked at like Rails, for example, like you mentioned Solidity, some of the Web3 frameworks just recently diving into NestJS or Next.js, sorry, that framework that's built on top of Node Express and having to become an expert in that very quickly to be able to build something, to be able to assess it. It all kind of feeds together, and then once you've done that, having to back out and apply security principles to it in order to speak to clients, to speak to the developers. That's kind of where I went with it, just because it felt more like what I was doing on a daily basis.

Yeah. It's good to have someone on that does code reviews, lots and lots of code reviews. Because I speak to a lot of people who are out selling products or were managing programs holistically or were doing pen testing, all sorts of other things, but I think you're the first guest who is a person who's so dedicated into the code review field. And a lot of my bread and butter is specifically code review, which funnily enough, agnostically, and also in a different way, I went out and learned the same thing, which is go smash through and learn the tech stack extremely well, and then go talk to devs about what I think could go wrong with it. And then a few years later, I got introduced to your course. I was like, what is this? Great minds think alike.

It is. I mean, I do like to tell people when we get in there or they're asking about it, I'm like, "Look, you're going to learn... If you do the same thing on a daily basis, you're going to naturally come to something that's very similar to what we do, and you're an example of that, that yeah, we got to smash our way through. We got to figure out how to do it, and how do I do that as quickly as possible so that on the flip side, from a business perspective, so that I am profitable and I can offer this service in a manner or for a cost that a client is going to be willing to pay?" That's that fine line that I always walk, and it's hard at times to figure out, okay, here's 3 million lines of Ruby on Rails code. How much time do I realistically need to get through this to give them a good experience to find items, to actually satisfy the needs of compliance versus their budget? And I mean, it's a balancing act. It's a balancing act.

How did you get your chops on code review? Because for me, it was actually just starting out with this is Fortify. I'm going to run Fortify, I'm going to learn how Fortify does taint analysis, and then maybe I could start doing taint analysis myself manually, because there are a lot of times where I just couldn't get Fortify to work. I'm sure there's plenty of people on the podcast.

I'm not surprised.

I agree with you. I love it. I still think it's a great tool, but at the same time, I have had many frustrations of... But how did you get started doing code review? What did you do?

Yeah, so my first experience with code review, oh, man, I'm trying to think. So we've got the story that we tell on our podcast about meeting up at a very, very large retailer like Ken and I, and at the beginning of his consulting career, and it was very focused on Fortify or... No, it wasn't Fortify, it was AppScan Source is what they were using at that point.

Ah, yes. IBM, I think?

Yep. Well, this was before IBM. This was Ounce. It was still Ounce Labs at that point. So before the IBM acquisition and then, yeah. So anyway, so we tell that story, but realistically, my first experience was when I was helping build a pen test team at a regional bank here in Salt Lake City where I'm at, and the developers, because I had just come from the development side of things, I'd done that at Iomega and we were starting to dig into where the bank was introducing their first online banking product for consumers. They asked us to actually take a look at some of the authentication routines and authentication code, and I just asked on kind of a whim and I was like, "Well, do you mind if I take a look at the source code?" And at first, the developers were like, "Well, why do you need to do that? What is it that you're going to look at?"

And I was like, "Well, I come from a development background. I've done code reviews in the past, and I know that there's these issues with SQL injection because I dealt with that at a previous company. I would just like to see what it is." That being said, I know my first code review was pretty weak. When it really comes down to it, all I was looking at the database interactions. SQL injection was the big thing at that point, but even I'm like, "I'm pretty sure it had cross-site scripting all over in it, and I didn't even really recognize it at the time, didn't have a real methodology."

It was just very, that kind of side quest idea or rabbit hole of, well, I'm going to go look at this thing, this very specific thing because I know that's an exploit and it's been exploited by people in the wild and then kind of stepped away from it. So it didn't have all of the bells and whistles that we talk about with the methodology nowadays. It was very much just a, "Hey, I'm going to come through some Java code and I'm going to look for this kind of specific vulnerability."

I guess when we all start out, maturity obviously isn't there because we haven't been formally trained in how to do something. I'd say that prior to your methodology being released, the best thing we had was the OWASP code review guide, which I don't like to look at, to be honest, because it's like, here's 600 pages of very esoteric bug classes related specifically to Java and .NET. If you're looking for, I don't know, [inaudible 00:10:33] references, that's probably not relevant for a lot of the other languages. If you're looking for, I don't know, what's a Java specific one? Like a marshalling problem, that's Java, isn't it? JAXB.

Yeah, JAXB marshalling. Yeah.

A security manager. That's probably another Java one. I don't know. It's been a while since I've looked at Java code. I'm happy about that one, mind you.

Yeah. Did you just cross? Yeah, come on.

Just give me a little bit of time just to be okay. So yeah, because it's hard, I know my early days, I kind of just took what Fortify said at face value, and I often remember having arguments with dev teams who were clearly in the right. And as a security guy, you'd dig your heels in and be like, that's the tool. The tool's perfect. It's big brain. It knows what it's doing. [inaudible 00:11:26]. And nowadays, I see other people who religiously follow the outputs of the tools and think to myself, "I remember. I remember when I was like that."

I was young once as well. Yeah. And then that's where it came. So I did that manual code review, which was not... I mean, it wasn't a full-blown code review at that point. And then the tools started to take off, so that's why I was introduced to Fortify not too long after that, and Ounce Labs and AppScan Source, but I still to this day remember looking at those tools as they came out. And having come out of school as a computer scientist and understanding, "Oh, they're building an abstract syntax tree." Behind the scenes, what was going on? And I'm pretty sure I still even have the book, the Secure Programming book that's by the Fortify guys.

With the flower in the front? Like the pink flower?

Yeah, yeah. Pretty sure. Yeah, yeah.

Yeah, I read that start to finish.

I still have that because yeah, it's good stuff from the actual theory behind how secure programming and how code review, automated code review happens in an abstract syntax tree. It's fascinating from a computer science perspective. And then getting into it and realizing that things like the problems with taint analysis, how it's actually identifying things and how the trust that the security community at large put into those tools and the output just didn't line up. Not to mention the fact that it was very targeted. Fortify and Ounce were very targeted at .NET, C, C# came into it a little bit later, but yeah, Java, .NET, C, C#, it was about it.

So trying to support some of these newer startups that were using, I'm going to date myself, but using Perl or even ColdFusion, there was no answer. It would do okay with... No, it wouldn't even do okay with ASP, like classic ASP. Even though it was super easy to read and identify things, the initial wax at it from those different vendors, it was... I mean, it was a little disheartening stepping to a place like a large retailer and they're like, "Hey, we're scanning all our code." And then trying to tell them, "Well, that's great, but you're not really finding stuff." You're spending a lot of money and you're not necessarily getting that value back out of it.

Fortify, it's like it took me a while to learn the pitfalls and benefits of using it, and I still think it's a great tool if you're doing a modern .NET application, an older Java application, something where it follows some kind of model view controller framework or it's a compiled language. Because that's what it was initially designed to do. And I see people shoehorning it into situations where it really shouldn't be, which is in a DevOps pipeline. I see that a lot and I say, "Okay, if it takes you six and a half hours to compile this application into a normalized syntax tree, not an abstract one, a normalized one, and then you're going to start doing some discrete mathematics to remove paths with too much cyclomatic complexity because if you A+B, and then you don't need to go down A+B because you've already stored using memoization, that you've already done that. You don't need to go down that path again."

So they've already done a lot of this big brain computer science and it still takes six and a half hours. So I don't think it fits into those kind of worlds, and I also see people using it for languages that aren't even compiled languages or for serverless. I see it frequently for small Python applications. How do you do taint analysis if you literally have one, you know exactly a very small thing that comes into it and it spits something else, and then you have Kafka sitting there waiting for events. We've had message queue since the '80s, I think. So it's not like it's a new pattern. It's just that Fortify wasn't built for that ecosystem. So yeah, I still recommend it. I just don't recommend it if you are a cutting edge serverless shop or you're starting to just use technology like Golang or I don't know, Carbon or whatever, Nix. I think people use Nix now.

Yeah, I haven't run into Nix as much. But no, I'm with you. As far as using the tool that's appropriate for the environment, we get a lot of the people that look at the Gartner Quadrant. And they're like, "Oh, Fortify covers all the things." And as a CISO, I'm not going to be fired if I go buy Fortify or I buy AppScan Source or even Checkmarx or Vericode or whatever it is, and they haven't necessarily talked to the developers first about what are the actual needs underneath the hood. And again, that's where I go back to my dev background, is that's where I initially struggled getting into security or understanding what the security viewpoint was because I was so sympathetic to what the developers were doing.

Having been on the other side, trying to sling code, trying to build things, trying to support all this other activity from the business, and then security coming in and telling me, no, I can't use this to push code out or I can't use this library even though half the application is dependent on it, those sorts of things were really hard to square in my own mind.

I think Gartner is an interesting one because I actually think it is quite accurate, but it's about what it's measuring, and Gartner is not measuring developer productivity and it's not measuring efficiency and effectiveness. What it's measuring is the ability to find security bugs usually. So it'll be breadth of languages covered and the level of bugs being found, and it's specifically organized for I give this to a security auditor.

But we know that that's not why people buy these tools. They buy these tools to give to dev teams to hopefully self-service and stuff. That's like modern appsec. If you're still running an assurance function, I would be balancing using an automated tools, a couple of automated tools, maybe open source ones probably with manual secure code review and white box testing, but that's... Most devs, we just want to give them something that they can use and run with. Yeah, that's how Gartner... I feel like if Gartner created a new category, which is just developer-led security, we'd start to see get up advanced security or sneak, but Semgrep just rise right up to the top and we'd see the other vendors that I don't want to slaughter, rise down to the bottom.

Come on, Cole, what are we doing here?

What are we doing? Okay. Yeah, hot takes. I feel like if you are in a situation where your product is used by security auditors only, then you may need to think about whether that's a large total addressable market in the future.

Yes, yes. You might want to pivot and invest in the DevOps pipeline.

This is where we say Redpoint. You should talk about Redpoint Security.

Yes, yes. Come talk to us. We can help you out. Yeah. No.

So changing tack, let's go to the manual code reviews.

Okay.

Because I like trash talking all the different static analysis tools out there, but I think we've already put a bit of time into that. So I know one of the things you mentioned is balancing speed and efficiency, as well as doing further deep dives. And in Australia, we have a bunch of different consultancies around... So there's ones who are Eltham that do exceptionally deep dive talented research, and then you have other places that are good at doing efficient quick ones that are very cost-effective, but they're not going to go in depth. And customers want both. I'm not going to call out what other agencies do the fast ones because they'll take it as a...

As a knock.

As a knock. But just because your business is meant to be efficient and effective, I think the pen testers working, and it might be a bit upset if I call them that they're not the deep dive researchers. So maybe we go with speed. What processes or what do you do to make your code reviews fast and target ad audience?

To make the code reviews fast? Actually, the best thing that I've found from a manual perspective is prioritization. Getting in front of the developers and the product owners and asking them just the simple question of what is it that keeps you up at night? And being able to hone in on three or four things that are the biggest risks, the biggest threats to an application, and then flipping that to, "Okay, what are the parts of the application? What are the parts of the code base that I should be looking at?" And then asking the simple question after that of, all right, so if we just cover those items, is that all that you want or do you want a full review? Do you want all the code looked at? Do you want 50-50? We always use the term of kind of t-shirt sizing the assessments. Small, medium, large.

Yeah. Same as Agile.

Yeah, exactly. Yeah, for small, we can get to some of this and we'll get to those highly critical portions of the application, but some of that low-hanging fruit that maybe you'd pick up in your white-box test or something else, guess what? We're probably going to miss that or we're not going to get to the configuration review, or sadly, in my heart, we're going to miss some of the logging functionality if we do those small assessments. But that's been the only way that I can really speed it up. Now, that being said, what has me excited now is the use of AI in this and the use of LLMs to actually speed that process up, because there's a lot of times that those companies will come in like it's a new dev team, it's a new security leadership team. They don't know yet what they...

Their fear is the unknown. We don't know what we don't know. And so I have to turn around and almost tell them, "Well, based on this code base, this is what I would be concerned about." And that ends up taking a lot of time. And so we're starting to investigate the use of AI to actually quickly analyze things like libraries, security sensitive functions, authorization functions, being able to pull that back out from something similar to Copilot that already has it all vectorized and the data. It's built its own trees about this code base because we spit it, we gave it to it, and then turning around and being able to ask those questions. So that's kind of the future state for me to speed things up, but right now, it's a lot of just manual questions.

I tried to use Copilot Chat to do the same thing, but it only worked on individual files, not on an entire repository, and I wanted to do a lot of metadata analysis. So what I mean by that is basically import the entire git commit history into an LLM, and then be able to just pull out a bunch of statistics, and these statistics can help me understand how to prioritize things because if I know that we only have one developer, then instead of even raising a code, redefining, I'm just going to say, "You've got a key resource risk and that's a more of a problem." Or we find parts of the application that haven't been changed in two to three years. I figured that that's a higher risk because no one understands at this point what that does. So that's a problem waiting to happen. Or your Node.js, like your package or yarn.lock files haven't been updated in six months, so you've probably got dependency issues.

So I wanted to grab the git history, throw it into... Get it passed by a model, and then be able to interrogate it quickly with a couple of questions. I just did that immediately the start of a code review to give straight back to the clients, to give them to some immediate business risk about a repository. I'm reluctant to implement it because I'm a consultancy and I'm very lazy and I like spending time with my kids, but I tried doing it Copilot Chat and failed. So if someone wants to go take my product idea like you and turn it into something else, go ahead. It's all good. I'll just go and use it and download it.

You'll just come use it, download it. No, that's exactly the same sort of inclinations that I have on introducing AI into that process though, whether it is that, I mean, one of the things that has been successful for us has been providing the packages.json, [inaudible 00:24:30] whatever requirements.txt files to Copilot Chat and then saying, "Okay, what is security sensitive?" And it does a pretty good job of mapping that out. It gives you a good list initially of, well, we know that the authorization is an issue. It looks like it's using this OAuth library. It looks like it's doing this is for templating... And it knows enough about security that it can start to pull that out. Now, it's not going to be exhaustive. You're still going to have to double check, but it does give you those quick hits, and I love git sponking. That's one, to be completely honest with you, I hadn't necessarily thought too much about, introducing the git history into that, so yeah, I might have to still that and push that in and see what it does on a current code review. Yeah.

Yeah. I'm all about just thinking of just the way that we traditionally approach security, which creates tremendous amounts of cognitive load for engineering teams or just even the fact that we're still charging at least 5 to 10 days minimum for an assessment. I feel like we've got to look at ways we can leverage new technology to speed that up, and I know that there's static analysis tools and stuff were golden child as a way to make a pen test super efficient. But I feel like we can definitely leverage AI within our consultancies. I'm not going to advocate for using it to write reports. I think that you can structure it in a way or have it give some generic advice about what XSS is, but I think that you should be manually writing, because that's what people are paying for, is your expertise and your time.

But I still think the whole idea around using it as a way to take some finicky tasks that you would otherwise have to manually program where you can now ingest a lot of information in and learn about something really quickly, I think that's a great way to prioritize your efforts and to not spend so much time getting your head around a code base. Because that's usually the thing that I find is the hardest is I encounter new technology and then I have to go learn that technology. And sometimes that's two to three days of the body code review because I'm like, "What the hell is MQTT?" It's like, "Well, why am I looking at gRPC? [inaudible 00:26:57]." I don't know.

Entirely new patterns, entirely new protocols and things I need to learn. I feel like if I can get a really distilled version of the... And just questions to a little helper while I'm doing the audit, that could speed me up instead of me having to effectively go down to Udemy and just smash through all the docs as quickly as possible. But yeah, AI's got a lot of promise. I just don't want to build a company with AI and then get slaughtered by OpenAI in a few weeks time when they release the ChatGPT version.

Yeah, exactly. Well, I mean, that's it. They do have the ability now with the ChatGPT-4, I think it is, to upload a zip file of all the code and then start to query questions or make queries against it. That's exactly where we're starting to go because it does speed it up. And yeah, I mean, again, that's what makes me excited about having those OpenAI tools available, but I still run into consultancies that don't necessarily, haven't even thought about it yet, and I'm like, "What are you doing over there?" They're just following their traditional model of, hey, we go in and we do a white box. We may have the code available to us, and we look at it for the last day to just do low-hanging fruit, and I'm like, you've got the code, and that's the last thing you look at. I'm like, I do not understand. But yeah, it's just kind of to each his own as far as those other consultancies go.

Yeah. I think that people, I was listening on your podcast to Jason Haddix, I think it is, and you were saying that some smart person in the industry just fundamentally refused to engage with AI and consider it beneath him. And I think that's a very naive... Maybe because me and you are developers, we are always excited by new technology and mystified and want to see how we can use stuff for the better, right?

Yeah.

Maybe that's why as consultants, we don't say, "Here's the process, here's how I make partner." Just I've got the rank like that.

Yeah. And it could be. I mean, maybe it does come from that developed mindset because especially as a consultant, we're constantly forced to learn new things, and I constantly feel like I'm behind what other people are doing. I see Jason Haddix, I see you, I see Ken, I see other people that are improving their own processes and their own technology, and I'm always like, "Man, I got to get to that." I have these clients that I'm currently servicing, and yes, I've got to help them as well. But the whole idea of constantly learning means that I have to constantly be open to those new ideas in order to meet that next client. Maybe that's part of it. I don't know if you found that when you were marketing things on your side or trying to identify new avenues of revenue that you just had to take on more technology and be open to that.

I think it's less about taking on new technology. For me, it's about separating what I do differently to other players in the industry. And domestically in Australia, the focus is pretty much on having a really good customer experience. I get that from application security because if you think about most security firms that end up coming immediately with an adversarial or compliance-based mindset, whereas I coming with a let's satisfy different non-functional requirements and get you to yes. That makes security approachable. That's why I'm pink and fun. And I know this isn't the sales pitch or whatever, but the idea is I looked at what other people are not doing particularly well, and how do I create a unique value proposition and own a category?

Yeah, we still do a lot of the services that the other businesses do, but we do them in a way that people want to engage us because we align with their values, or we have the experience around the engagements better. Because generally, unless you're a bank or a tech co or something, people aren't going out of their way to just say, "I'm looking for the absolute most technically brilliant hackers on Earth." Usually, they're just like, "Man, I'm just buried across site scripting because my devs are a little bit dumb. What do I do?" So I don't need to be the best hacker or code reviewer or whatever. I just need to help a business get to a level of safety that they feel comfortable with, that they can operate and be resilient if something does happen. And I think aspiring to be perfect is a terrible idea. So I just try to get people to be good enough for now, and then we can move to perfect, but no one even tries to get to here yet.

Yeah. Well, a lot of what you're saying though is we're meeting people where they're currently at and just being realistic about it, the whole idea of security coming in and shaming developers for making a mistake. Again, I have a really hard time with that, having been on that flip side, because you know how much time and effort and thought has gone into creating these features to creating these products. And if the first thing that developers or the security does when they walk in the door is tell them, "Hey, your baby's really ugly and you should just throw it out.", they just turn off. Because any of us would, if you don't show that you have understanding or empathy for the position that they're in, what's going to happen? It's going to be antagonistic, they're not going to listen to you, they're not going to implement those recommendations, and you're not going to be able to accomplish your job either. So yeah.

I just find a lot of the appsec teams operate little silos where they write a policy, a secure coding standard, and then they get angry that all the developers in the organization aren't following the standard. And they're like, "What? I just don't understand. The policy says that they need to follow the standard, and the standard indicates that we like to use Pydantic and SQLAlchemy, so why are people using these other things?" And I'm sitting there thinking to myself, "Since when did security get to make decisions about what a business needs to achieve?" I don't know. I think that obviously, that's definitely in the appsec space where you can make it more broadly in the cybersecurity in general. I've had a lot of discussions with people about how do we make people realize that cyber is not an IT challenge, it's a business challenge that needs to be solved from the senior executives.

And unless we start talking in a language that's in terms of like ROI or annual loss expectancy or these projects are going to be delayed, like time to market, things like that, instead of cross-site scripting, SQL injection, 0-day, threat modeling, so on, they don't care about this stuff. They care about... I'm a business owner, you're a business owner. If someone comes to us and says, "We have a critical vulnerability in your system, so you're going to go bankrupt tomorrow.", me and you are going to laugh because we know that it doesn't actually matter because we're consultancies. People pay us for our experience and our mind and [inaudible 00:34:05] critical vulnerability is that we're going to get kidnapped tomorrow, our businesses will probably be fine.

Yeah. Yep. Yeah. Well, and that's been reiterated to me through experiences the last, I mean, even six months to a year in dealing with a couple of different organizations where I've seen they're starting their application security program or they're trying to build it almost from scratch. They add all their developers, their security team leave, a new security and security leader came in, asked for some help, and as we went in there, what we realized is that the initial security team had done exactly what you were talking about. They had gone and created all these policies and all of this without ever engaging with the developers. And so when you went to the development team, they would just like, well, yeah, we know we have some sort of standard, but we got to build all this stuff and we've got to deal with it. And our product managers and executive management has basically said, "Get the features out the door because that's what pays the bills."

And just having the ability to say, "Yeah, we get that. Let's talk a little bit about security and how we can help, as opposed to we're going to tell you what to do." has done wonders for number one, them coming to us with problems that existed for the last decade and haven't ever been fixed because they never wanted to tell the security team about it. And then also training new developers. It's so hard to accomplish things in a silo, to your point, as if you're an appsec silo or a product security silo, you're probably never going to achieve that program that you want, and it's never going to be perfect. No organization out there is ever been perfect. We talked about Netflix, we talked about some of these others, they still have issues. Google still pays bug bounties, GitHub still does. They have issues that pop up that are critical and high. No one's perfect. So we've got to expect that a company that doesn't have a security team and doesn't have a huge development staff is also not going to be perfect.

Yeah, I think the idolization of big technology companies is a problem that I'd like to address.

Okay. Fix it. Fix it. How are we going to fix it?

I mean, as appsec professionals, we often see people who stand on stage, I don't know, just the Kelly Shortridges saying, "We need to be doing chaos engineering and Chaos Monkey approaches, and this is the way to resilience for an organization." And then I'm sitting there thinking to myself, "Well, turning off random telecommunication nodes probably isn't a great idea." Or I work in a live combat zone, so I'd prefer my oxygen to not randomly turn off. It makes sense for the context that you have a distributed server farm at Fastly or at Netflix or whatever. And for these companies, the consequence of something being taken offline is pretty negligible. It cost a bit of money, but ultimately, people will be like, "Eh.", and keep going on with their days.

So yesterday, we had a floor with one of our telecommunications providers in Australia where basically, the entire country pretty much got lopped off the internet because someone made some mistakes as part of a change record. I think it was BGP updates. I'm not saying that that individual's to blame. It could be the process around it. It could be because change records are usually pretty straightforward, it could be the logging around the process. But ultimately, the main thing is that he was able to cause so much damage with such a minor change and trying to replicate a chaos engineering approach in critical infrastructure, for example. It just doesn't make sense to me when the consequences are so much more severe. So I'm happy to say that Yeti's approaches can work fine. I just don't want us to be going out there telling everybody to [inaudible 00:38:15] everything, that's totally fine. Randomly turn off systems, maybe not.

Yeah. It goes back to the business requirements and what the business is trying to accomplish, what's critical for that business. Because if you did something like BGP updates and chaos engineered that for Netflix, yeah, that'd probably be a huge problem if you take down Netflix for half the world because you changed the route. I'm pretty sure they don't do it there. So they definitely have the same sort of sensitivity to that sort of critical infrastructure and what they're trying to provide. I don't know all the concepts that come out of especially security talks at security conferences, we have a tendency to idolize, again, kind of the offensive side of things, number one, but number two, also the new ideas that are new and shiny. And I know we laugh about Crocs and socks, but most of the companies that I deal with are not doing Crocs and socks style stuff.

The basics of security and the security process, and not even the security process, but just change management and approvals and making sure that people can't submit code when it's a manager as opposed to a developer or they can't promote it to the right environment or the wrong environment, I guess, I should say. Just those basics are so hard to achieve that when you find something in place, you've got to give some kudos to those organizations because they don't have... I mean, they're not a Netflix, they don't have 100 people that are looking at that sort of thing. They have one if they're lucky.

Yeah. And we often forget that the people who are working at those big technology companies are often some of the best people on Earth. They're PhDs, university trained in very specific disciplines, they have really high qualifications in some way. There's a reason that they get poached to go to join these companies. And if you're just like some guy who's just done, I don't know, five years at a bank, you're not going to have the same kinds of challenges or the expertise to even implement some of these things. It's like there was a period of time where everyone wanted to use Kubernetes because everybody was like, "I want to go work at Google. So the best way to do that is to be a Kubernetes engineer, because that's how I do resume driven development."

And then we saw a huge uplift in people just having EKS or AKS clusters exposed on the internet with no passwords for etcd and no firewalls. And you're sitting there thinking to yourself, "Oh, my God." And the people who work at these places moved on to those tech companies who are trying to be like Google as well because they got the experience and expertise. But yeah, I'm pretty strongly against... I like boring technology. There's a website called Boring Technology Club. I really like that website because I'm a fan of things that have known fail states and where we can just tell people, do authentication, use AES, hash your passwords, check log events that are suspicious, and actually look at the logs and you're sitting there thinking to yourself, wow, this is like rocket science. Crazy. But most code reviews we do, we never encounter half this stuff.

No, and that's it. Going through that list, you could probably write half of those code review reports that I do, because that's what it comes down to, is you start looking at the basics and I'm like, "Yeah, it's really great that you want to implement the latest Next.js or React framework with GraphQL, but we still haven't figured out how to log people in securely and use 2FA. We're struggling to not expose people's social security numbers or account numbers through the API. Like let's not reinvent the wheel and create a new API that we'd have to worry about even more things. But naturally, the developers want to develop the new things like Kubernetes or on top of that new technology as well. And so again, it's kind of that balance that you have to fight when you're talking to the developers, when you're talking to management, where do they put their effort? Where do they put security dollars, development dollars, and all of that that goes into it?

I want to move on to, because I'm just mindful of time, let's move on to the fast questions before my daughter runs in and slaps the laptop closed.

Okay, we can do that.

All right, here we go. So first one for you is what's the best book you're going to give someone for Christmas?

The best book?

It better not be Static Analysis or Secure Programming in Java or whatever. You can give it to them and use it as paperweight.

It can't be that?

Has to be something else.

Probably The Subtle Art of Not Giving a...

Yep. Don't worry. This is not a PG podcast. You can swear as much as you like.

Okay, yeah, yeah. Okay.

The Subtle Art of Mark Manson.

Yes. The Subtle Art of Not Giving a F*ck. That's a good one as far as one of the things that I had to learn as I was building a consultancy and kind of stepping out on my own and realizing, "Hey, I've got a voice that I have, or that my experience is valid, I guess."

One of the lessons in that book I think is if it's not a fuck yes, it's a fuck no. Which I think is a pretty good lesson, to be honest, because there's a lot of people sit on the fence and say that they're going to participate things and not enjoy that they're doing it. And I think it's better to be clear with yourself that I don't enjoy this activity, so why am I hiking or kayaking or eating a tuna? Actually, I'm not good. I'm just going to say no to that. You can do it gracefully and with tact, but at the same time, I think you can apply it for most things in life, really. I love public speaking. I don't love Fortify auditing anymore.

So I'm not going to do that anymore.

So I'm not going to do that.

You can go to somebody else.

Yeah, other people could order. I'll tell them if they've made a mistake, but I'm not going to go in there myself. Cool. So how about best $100 purchase for yourself?

Oh, best $100 purchase for myself. Honestly, I would have to say, this is one of the things I love to do, but probably a super nice pair of running shoes.

Yes. Crocs?

Crocs. Well, not necessarily Crocs. I'm using Brooks right now. But yeah, just investing in a nice high quality pair because of how you use them.

Yeah. I've gone through a bunch of different shoes over the years. I've had like Hokas, Nikes, and Allbirds for a while. I actually really don't like Allbirds anymore because they just fall apart too easily and their soles have no grip, so if it rains, you'll just fall on your bum.

You slip. Yep.

So it was really cool when I wanted to be trendy at Westpac for a couple of days, and then I was like, "Wait, no, I don't like walking in the rain, slipping constantly." So they're nice to wear at home, but also, I'm in a Chinese family, so I don't even wear shoes at home, so there's no point having them. So I'm out to go buy my new shoes, so I'll have to go have a look at Brooks sometime.

Mm-hmm. Yep, yep. They're decent. They do a good job.

There we go. Sponsored by Brooks.

There we go. Yeah, apparently.

And last question is, who is your favorite guest on Absolute AppSec? And it can't be me.

Oh, wow. Come on, Cole. You were great.

Thank you. I know I talked about consultancy stuff, and I know this one, we've talked a lot more about actual appsec, so it's been good.

Yeah. Yeah. Let's see. Favorite guest? Man, I'd probably have to go look through the list. I mean, off the top of my head...

Is it Ken Johnson?

Well, Ken's not a guest. He's a co-host. Ken is one of my best friends, so we can get that out of the way. Jason Haddix, he was recently on, has always been so informative, and it's super interesting because he's more like appsec adjacent with what he does. I really enjoy Leif as well when he's been on. I mean, we had a really fun time when Manico came on. This was years ago. But Manico is just a really big personality, easy to talk to.

Oh, yeah. I've dealt with him when I did the OWASP cross-site scripting cheat sheet. I just rewrote it from scratch to make it consumable for developers, and me and him would get on video calls a lot because he was like, "This is my baby. We need to make this the shmickest thing in the world." This is literally the most consumed resource in OWASP, and you are rewriting it from scratch, Cole. And I'm like, "Yeah, yeah, I am." And yeah, words were said, and I love it because he's intense, but he's cool.

Yeah. Yep. It was a good time. So I mean, that's probably what I would say. I guess I don't necessarily have a favorite guest because we enjoy it so much.

Yeah. Well, Seth, it's been absolute pleasure. Look, I think we've got so much we can talk about. But we've got to wrap it up here.

Okay.

Thanks for coming on, man.

Thank you, Cole. We'll talk soon.

I'll catch you later. Bye.

Bye-bye.

Thanks a lot for listening to this episode of Secured. If you've got any feedback at all, feel free to hit us up and let us know. If you'd like to learn more about how Galah Cyber can help keep your business secured, go to galahcyber.com.au.