Decoding AppSec in the cloud age: A conversation with Sean Wright of Featurespace

Sean Wright: The thing that really scares me, we've seen it already with Python packages, MPM packages, Ruby packages, is those who actually intentionally put malicious code in there. There's things to steal secrets, crypto miners, the whole shebang. And that, that to me is probably the biggest worry I have around open source because trying to catch that. It's just, how do you do it? And just the massive volume that's there.

Andy Schneider: Hello, and welcome to Code to Cloud. I'm Andy Schneider, Field Lacework, and I'm looking forward to speaking with Sean Wright today. Sean is head of application security at Featurespace, the world leading enterprise financial crime prevention for fraud and anti money laundering. He's an experienced application security engineer, having started his career as a software developer. His expertise is in web based application security with a special interest in TLS related subjects. Sean, welcome to the show.

Sean Wright: Thank you for having me. I'm really excited to be here.

Andy Schneider: Wonderful, Sean. One question before we jump into, into the topic. Tell us a little bit about yourself. So who's Sean Wright?

Sean Wright: So I work at Feature Space. I started off as development, um, numerous years ago. And when I left university, there wasn't much in terms of security. So that's development, grabbed the first job and got into. Involved in development for numerous years and then managed to break into the security field. Been involved there ever since.

Application security kind of drew me in, I guess, being a developer side of things. I've stuck with it for the last, probably what, 10, 11 years now. 

Andy Schneider: You said that you started with development. I'm actually also like, I didn't start in development, but More than 20 years ago, and what I experienced, like, in the past 20 years is that big shift from, I would say, traditional software development to how it's done today. Also, in between, somewhere the cloud came in.

So, from your experience, if you really rewind back time, how did software development look like in the pre cloud era? And how did the cloud change that?

Sean Wright: Cloud is obviously a fundamental change. And if you look at like pre cloud, we're talking about on premise software that really you would probably get something and you'd have to configure it, install it in your data center, maintain it yourself. That required a whole team around to manage that. If you're developing it, then you have to kind of ship it, package it, all that kind of stuff.

And when you're talking about that kind of process in terms of development, like the old traditional models of like waterfall kind of makes sense then because a customer is not going to go and try to do this whole install every week or whatever. So those kinds of processes and that. Adapted well for waterfall and then you even look to things like the way even applications were developed, things like open source.

When I was beginning on my career, very, very early in the infancy, probably shared by age where you're talking about things like Ant for your, your bulge rather than Maven, Maven was just coming out and I was like, wow, this is awesome where you had to pull all your. Dependencies, manually, many companies built them internally.

And I guess that kind of also goes to the whole infrastructure as well, where there was a conception, Oh, we, we don't trust anyone outside the organization, be it software or infrastructure. So we're going to build everything in house, our own data center, our own teams maintain that. And if we look to where it's going today, With the whole cloud in that, it's completely changed the way that we think about developments, the way products get out to customers, and overall I think it's positive, but obviously this is a positive.

Some risks and drawbacks of that approach.

Andy Schneider: Totally agree. You mentioned that security almost didn't exist like when you started your career in software development. Did the application security part change? Actually, it changed, we know that, but how did that change and also how did the cloud again change application security?

Sean Wright: So, I think if we look today, where we have things like SaaS, which is software as a service, I mean, that's a very large element of cloud, where you can go sign up for a service, you don't need any infrastructure, you just need an account and away you go. Good examples like GitHub, those kinds of things. And it's really important that security is embedded in those because that's not all public, that's publicly accessible, where in the past, you kind of didn't need that, you could like, kind of segment that off, so It's I know one company I worked at, we had our own private repository.

And if you like a source code management provider, you don't then have to worry about that the floor has been exposed. If you're developing this for interning maintain with them. So certainly seeing that, and then also. If we look at the way like things have evolved, as I mentioned, open source, one of the big things about open source is there's a lot of ability to develop things quickly and that's great, but it can also introduce risk when you don't know some of the things that you could potentially introduce.

So things like cross out scripting with some of the JavaScript stuff, all these nice frameworks, thankfully that's changing with frameworks and libraries that kind of build security into it. But in the past, that stuff is, I'm kind of scared of even looking at my code back in the day. It's trying to see how many vulnerabilities are introduced.

So yeah, it's interesting to see that the focus change and I think now, security is becoming more and more important and I think one of the turning points as well is. Companies are now starting to realize that as well, or the media attention.

Andy Schneider: Yeah, absolutely. You mentioned open source. but before we go there, if you look nowadays from, from your experience to AppSec, which measures are really effective? Because there are like hundreds of things that you could do if someone would end up being in the elevator with you. Hey, Sean. What are the three most effective things you would do in AppSec?

Sean Wright: Number one, use a framework, a well known framework that has security built into it. An example I can give is, I got called to do a pen test for a group of developers. Who had like zero knowledge about security. I'm like, this is going to be great. I'm going to go pen test this app. I'm going to find all this stuff.

It was the most boring pen test I've ever done in my life.

Andy Schneider: Oh, really? Why?

Sean Wright: Because the app just handled everything. Like SQL injection was impossible because the app handled it. Cross site scripting was impossible because that whole framework just kind of shielded the developers. And I think that's great because. The developers don't have to worry about that.

They can worry about, you know, what they're there to do, build something, create something. And it's that whole shift where we get into like secure by default. So use a well known, well established framework. So like Django or Spring, those kinds of things. And they're constantly evolving, being improved.

Another thing is training or at least awareness, right? So when I left university. I don't know what SQL injection was. I don't know what cross site scripting was. So how am I meant to not introduce those into the code I'm developing if I don't even know what they are, even if they exist? And I was someone who was quite keen on security.

So making sure that you have your development teams at least aware of the things, preferably trained, at least trained 10? This will provide a very broad coverage. And then you combine that with the framework.

Andy Schneider: OWASP 10 didn't change that much over the last decade. So I think we are still doing the same mistakes in software development. Yeah.

Sean Wright: Yeah. We'll see where that goes. And then the last kind of thing I would say is break down barriers between the security teams and the engineering teams.

I don't see why there needs to be this friction. At the end of the day, you're working for the same company. You're trying to achieve the same goal. Work together, support one another. See each other's. Issues or frustrations, problem points, and try to achieve the same goal. And at the end of the day, it'll work out for everyone.

Andy Schneider: I really like that one because it's sometimes also, it feels like AppSec and like you could say DevSecOps or more infrastructure oriented security is really divided. But sometimes it might make more sense concentrating more on the AppSec than the infrastructure part and vice versa. So let's say if you put on your CISO hat, you should find a way to make most efficient security.

And it's always best to have like a diverse team, people that develop, people that manage the infrastructure. And actually also involving the business and other parts in there, in those teams. It's a good point. So you mentioned that bringing down those barriers between development and app sec and infrastructure.

So bring down the barriers between development and infrastructure. Are there also those boundaries between security and development itself? Do you see that still?

Sean Wright: Yeah, I mean, so it's the case of developers that they've been pushed to develop something and often like very tight deadlines, lack of resourcing. So they may view security as, you know, just another hurdle or it's not our problem to worry about. Which is probably a bit more dangerous. And then from the security side, it's again, similar thing, resourcing all of that.

They don't have the ability to help everywhere that they can or have eyes on everything. And at times things slip through and frustrations can happen. And this is where things like security champions could really, where you get someone on the development team to help the security team and act as like a liaison between the two teams and further break down those barriers.

It is getting better, I will say that, I mean, when I first started, it was probably like a very, very clear divide, and I think both sides are now, I wouldn't say quite there yet, but I'll get into that point where developers are now realizing the importance of security, and how it can actually directly affect them, because hey, your company gets breached, guess what, in these customers, you may find yourself being made redundant, obviously also, no one wants to work for a company that's in you. The media for the wrong reasons and by and large, developers also want to do the right thing. And then security people also can understand some of the frustrations that the development teams are facing when it comes to security and the old notion of, hey, you got to go fix everything because this report said so, where we now have to start getting a lot more intelligent about what we're going to tackle.

So seeing it from both sides is really important.

Andy Schneider: Yeah, agree. I actually really like the ambassador champions way of doing that. I see that with many of our customers. I've built that in a similar way. So Having those champions within those teams is a very, very powerful way of having like multipliers for security, but also very often the security people don't understand development.

So I've seen that discussing security with developers that are not AppSec engineers, but then actually come up with brilliant ideas and they had to explain to me the idea they had. Build more boundaries and more security. So I encourage everyone doing that. Something that you mentioned before was open source.

I'm a big fan of open source, but I also see like the risk. It's not just open source. It's like with every third party library, but if I look today at Almost the whole digital life that I have, I would assume that at least it's one third of that is built upon open source libraries somewhere. And of course, this comes at a risk.

So I remember Lob4j, I think is one of the very famous one, but it's only one of those breaches or incidents that happened throughout a third party open source library. So what's your opinion on that?

Sean Wright: I love open source. I think it's really good. As I mentioned, it can help from a security perspective with the libraries and frameworks. It can make sure security is embedded. Think of the libraries and frameworks, think of your crypto libraries, those kinds of things. So from that aspect, it can be great.

But from the other aspect, it's so widespread. It's so difficult to keep a handle on it sometimes because you have thousands of libraries often being pulled in. And how do you manage that? How do you maintain that? How do you make sure that they're updated? It's a constant struggle. Lock4J was a good example of that.

Where, Lock4J, I pulled out my hair when they first came out. The reason being is, back in 2017, we had Equifax with Strats.

Andy Schneider: Yeah, I remember that.

Sean Wright: That should have been the alarm bells. People should have been going off, Okay, well, we need to now make sure we know where our libraries are, where they're being used, rather than running around going, Oh my gosh, where's this library being used?

And what happened with log4j, same problem. And in fact, it's even worse than that because I recently read a news article. I think it's about one in four applications, obviously Java based applications, because log4j is only Java specific for the vulnerability. About one in four that tested or sampled had the vulnerable version of log4j installed two, three years later after the fact, and that to me just points to the, the whole problem.

Where I think the developers have this intrinsic trust that it's from the official repository. So they, the trust that once it's pulled down and then that's it. Not worry about it anymore, not realize like these things have their own life cycle of that. You have to keep on top of it. You have to keep updating them and not only that, making sure that you do some scrutiny on the stuff that you put in.

Another really good example is there's a package on NPM called dash, like literally there's the character dash, that that's all it is. This package does nothing. It has no value whatsoever. And you can go look it up now. It's still there. It's been taken over by the official NPM owners. I still don't know what this package or the intention of it was there.

But the point is, this package does nothing and it's been downloaded thousands of times. And it's still being downloaded thousands of times. And other packages have this package as a dependency. That to me points to the whole problem around the whole ecosystem, how people have this blind trust in it, and then maintaining and updating these libraries.

Andy Schneider: Yeah. And it actually happened quite often that there was no maintainer anymore left for packages. So someone else just took it over. And if you trust like the official repository, so the official source, you trust the owner of that. And it's that, that interesting. Feeling that you trust something, but you have no idea what's behind it. So I would also say that the whole ecosystem of libraries, even if I'm also supporting open source, is fragile. So it could collapse. It did not yet, and I hope it will never collapse, but I remember that in my last company, we ran a bucket, a couple of bug bounty programs and. They were really effective, but if a researcher found a vulnerability in an open source library that we used, it was out of scope for us.

We didn't want to pay for something that was not our work. So even if we used the libraries, so maybe there in the future, there might be a way to incentivize researchers finding vulnerabilities in open source packages, but someone would need to pay that. And I think there is no one there yet.

Sean Wright: There are some initiatives. I know the EU was doing something, not open source packages per se, but open source software. That's really popular. They were looking at bug bounties around that. So there's some elements of it, but certainly not to the degree that it should. I think OpenSSL is probably one of the most popular packages that they do actually have as part of it, given the recent history of that.

Another point to make about open source is just the sheer vastness of it. One of the things I've seen as arguments being used is like, Oh, okay. It's open source. So therefore you can scrutinize the code and then find any vulnerability. That's great, and that's true, but when you've got thousands, no, not even thousands, you're talking hundreds of thousands of lines of code.

You're not going to find out probably, what, ten lines, pieces of code, that has a vulnerability. And even worse, and the thing that really scares me, we've seen it already with Python packages. NPM packages and Ruby packages is those who actually intentionally put malicious code in there. There's things to steal secrets, crypto miners, the whole shebang.

And that, that to me is probably the biggest worry I have around open source because trying to catch that, it's just, how do you do it? And just the massive volume that's there.

Andy Schneider: Absolutely. It's a good question. So. If you look at those, let's just call them supply chain challenges that you might have, from your experience, from a tooling perspective or measures, what works well?

Sean Wright: so going back to the, like the whole Acrofax thing, one of the really important things is. Essentially an asset inventory, asset management of your libraries and software frameworks that you're using. So using things like SBOM, and don't just do, one of the things I've seen is like, Oh yeah, run this SBOM so you have this file.

Well, if you have, what, 10, 20 modules, then you're going to have to manage these 10, 20 files all over the place. And how do you search them? Make sure that they're all pulled into a tool that you can then centrally look up. Hey, there's this version of this library. What pieces of our software are using it?

How You got to enter it in and you can find it straight away. And then you can also get things like updates on your CVEs. And another really important one is CISO KEV. Cannot stress that. So the, the CISO 9 Exploited Vulnerabilities Catalog, those are the vulnerabilities that have been known to be exploited.

Starting to pull in that intelligence and going, okay, well, this is now on that list. This is something that we need to go and fix straight away because it's something that. Is actively being targeted. And then another really important thing is controlling what's coming in. And by this, I don't mean going back to the old days of security, like with the no stack, you can't do this, but putting guardrails into what developers can actually pull into their repositories.

Having a central repository, having the appropriate filters, Hey, CVE is above, I don't know, 9. 8, whatever you probably want to investigate first, having the ability to nuke. Libraries that you know are bad, that have been found to be malicious. Get them out of your environment, make sure they can never come back in.

I think a combination of those things, while it won't solve all the problems, will certainly raise that bar to a significantly higher level.

Andy Schneider: Yeah, absolutely. So, here comes a more philosophical question. So, you started around 11 years ago, you said, in software development. I have already like more than 20 years of security behind me, right? Mm hmm. So why is software still vulnerable? What's your opinion on that? Why do we still have so many flaws in software?

Sean Wright: I think it's a numerous reasons. So one of them, I kind of alluded to university. I did a bachelor of science when, when I left, like, I didn't know what cross out scription was. I didn't know what SQL injection was, but I was going into a company running production code for a service that was sitting on the internet.

All this stuff, as I said, I don't want to see what my code was like. I didn't know any better. So how can we expect people to write secure code if they don't even know what that is like? They're leaving universities. And I think this is still the state today, based on what I've been asking people is universities need to have some elements of this in the bachelor of science, computer science degrees, embed that in, make it part of the curriculum.

It doesn't have to be sophisticated, it can cover the top level stuff, but at least make people aware of it. That would be step one. The other problem is, I guess, there's this fixation on some of the more glamorous stuff in the industry. So we kind of ignore some of the stuff that really needs to be tackled.

Go look at SQL injection, go look at cross site scripting, those kinds of things. It's been around for decades, yet we still haven't solved those problems. And then they're not difficult problems to solve. We have the technology, it's there, it can be done, but instead there's a focus on maybe some of the more glamorous stuff, which, which is great.

But we also need to really focus on the stuff that at times is a real problem. It's been proven again, like SQL injection, how many attacks have we found that have been broken? I mean, move it was probably the most recent one where SQL injection caused a lot of problems and what we 2023 and we talking about SQL injection stuff and it's been around since the nineties, so yeah, it's a difficult one because until we get those things in place, I think we're going to continually see it.

And then the final challenge, I think it's just the speed of technology. If I compare the speed now to when I first started in my career, it's insane. You, you got all these new technologies, these new languages coming out, and now you have to not only know how to use those technologies, but use them securely.

And that's probably where we need to start looking at building secure by default into the technologies rather than as a bolt on or afterthought. It's kind of happened over the years as well.

Andy Schneider: It's like that privacy by design, but if you embed that from the beginning on, it's, by the way, it's always cheaper to do security early in the lifecycle than trying to embed it rather than doing it afterwards. Another question for me is like, there are even different languages. So, sometimes, I feel that we tend to choose very unsecure languages because it's, we might have more developers out there.

Is that a correct assumption or what do you think? Are there really those differences in languages? I

Sean Wright: are very interesting. I've seen it across several organizations, like how they, they came about languages. And most of the time it's about someone or some team or some group started this project and this language and that stuff. And then sometimes a company, especially a smaller company grew up around that.

And guess what? That's the language that that company uses. And it's not necessarily a bad thing. Like, I don't think there's a language that is terrible from a security point of view, main, main sources of languages. I don't know about some other, the weird quirky ones, but if you're using like say PHP, for example, you can do some really bad stuff with it.

Again, if you go to those like frameworks and libraries and that kind of stuff, they help a lot. So it's not so much a case of languages, but I guess some of the languages, but also the, how you use them, how you adapt to the modern world with those languages, for example, it's been around for a very long time.

If you use frameworks like Spring and that, that kind of brings it up to a more modern level. C, C has been a very long time. You do have languages that are kind of based off them, but more modern. So things like Rust, Go, but yeah, language choice is I think more often than not personal preference, at least from what I've seen, rather than a real, let's sit down, let's go through all the pros and cons, and then sometimes it is.

But things like performance in that, you're not going to put like, I don't know, Python on a hardware device, for example, probably not going to work too well.

Andy Schneider: So you mentioned Equifax and we had look for J, but let's, if you go really back there. Why do you think the industry hasn't learned? It's not just like the leaders, but also the cyber security industry. So even if I'm working for a vendor, we now have like thousands of security vendors out there.

It doesn't look like security problems disappear. So what's, what's wrong with the industry as a whole?

Sean Wright: I think sometimes as we as an industry focus on the latest and greatest and, you know, exciting stuff and all that kind of stuff. So like when Log4J came out, for example, I was looking at people's reaction. I didn't see one person going, Hey, Companies need to use this to generate S bomb to, to make sure that they watching out where they're using this package.

It was all about, Oh, you need to look for this file on this file system or monitor these, these network signatures and all this kind of stuff. And I was putting my hair out because not how you solve this problem. We see it today. One in four store have this problem. So I think sometimes we focus too much, maybe from the network side, the network security side.

You know, focusing from really the attacker side and trying to protect it from that side, rather than, Hey, let's just fix this right at the beginning. So I can't believe I'm saying this thinking like this, but if. You think of it, we're approaching it from like the right hand side of the SCLC, you know, it's in production, we'll fix it there.

We'll protect it there rather than focusing on the left hand side, making sure that we can fix it in the code and get it properly fixed out into production. And I don't know if it's because people are more interested in the more exciting stuff, obviously, but maybe one of the things, or lack of understanding, electoral awareness, maybe those who are pushing out all these.

Network signatures are saying you should go look at this, aren't aware of what actually it means in terms of software development. And another big problem is application security is actually quite immature. You go look at network, I mean, you got the Marta attack framework, you got all those types of things.

There's no real solid thing for software application security. A few years ago, I got asked like, Hey, what is the required framework for application security? Is there a document somewhere? And I went, it is getting better. So you have things like OSP SAM and that, but still there's no real, that is the go to place for application security.

Yeah, I don't know. And I don't know what the answer is. I still worry that we aren't getting enough people involved in application security. It's not coming to the center of the real same types of talks and visibility that some of the other security stuff has. It's getting better with things like Log4J, but it's still not where it needs to be.

Absolutely. So I hope that next year will be the year of code security in AppSec so that we improve that. Hopefully. Yeah. Fingers crossed. I hope so. If you would now have like colleagues from university joining your team, what would be your advice to them? What shall they do if they start either in development or in security?

Andy Schneider: What would be your advice?

Sean Wright: Welp. I certainly learned when I got my degree and went into my first crowd that you know, this much that's double what you learn every day. And as part of that, I kind of view it as more a journey. So one thing I see as a challenge today is as many people leaving university or especially early on in their career, and they go, I want to be there, superhero stuff.

And that's great. Great to have those ambitions, but it takes time. And. It's a lot of work to get there. If you try to push yourself too hard, you'll burn yourself out. A lot of these things also take experience. And the only way you're going to gain experience is time. Unfortunately, there's no shortcut to that.

You can't just go take a course and go, Hey, I'm going to get five years experience. You need five years on the ground. So as part of that, I say, Enjoy the journey and learn off one another. So spend time. Working with other people, not just in your own teams, but engage with people on other teams. One of the things I really like about security, especially with our current work, is I'm not just focused on AppSec.

I engage with other areas of a security team because the security department's pretty small. That means I get exposure to other things, or I can help provide outside influence or thoughts, opinions that could help. So don't just fixate in your bubble. Work with other people, share ideas. Get engaged, things like community, different groups, and learning.

One of the frustrating things for me at my age now is see all this tons of learning online. I'm like, if only I had that when I left university, that would have been awesome. It is. Incredible how much free content is out there. So grab it, use it. Yeah, it's gold.

Andy Schneider: Absolutely. Absolutely. I remember that I went to a gym vacation. I think it was my last vacation to a gym and they had super modern machines there. And then I watched YouTube videos to learn. I even don't remember. It was, I think it was Rust. I always wanted to understand, okay, what, what makes Rust so special?

Because It is being said that it has less vulnerabilities in there. I thought, okay, then I'll just watch it while doing my exercises. So this, this would have been impossible. When I started my career, the blue screens were a thing. So this was a normal thing. So nothing worked. It was an unreliable infrastructure.

One thing that I have to ask, even if it's a buzzword, but do you believe that AI could help us on that journey? It's like now there's super hype on AI, but actually it seems to look quite impressive what you can do with AI. And maybe it could help with application security.

Sean Wright: Yeah. So I think AI is a, is a buzzword and it's unfortunate because it's been done to death by many, I mean, industries. Hey, it's going to solve, solve all our problems. It's going to take all our jobs and all of that stuff. It's not, at least for the foreseeable future. It does have value used correctly. I think that's the really important thing, but also the difficult thing is cutting through often that the marketing, sometimes snake oil, not everyone's out there like that, but there certainly are some out there. It will not replace a human, but I think what it will do is replace the more mundane things that a human will eventually get bored and tired and, you know, switch off and miss. So things like code reviews and that kind of stuff, I can see it working really well. I am terrible at code reviews. I hate them.

I've even blogged about how I don't think they are of value. One of the reasons why I don't think they are of value is because You have two different humans, you're going to get two different outcomes in terms of code review. Even the same human reading ten lines of code versus a thousand lines of code, you're going to get two different outcomes.

AI, on the other hand, is a machine. It should operate in the same way regardless of whatever inputs and How much of that is, so that's where I think we can really gain a lot of value, those more mundane things, and then let the humans focus on the more creative side. Things like your pen testing, where you have to start really thinking outside the box on processes, your procedures, working with people, getting people engaged, AI is not going to be able to do that, but yeah, I think it does have value and, and especially to like talk about the open source stuff, finding potentially malicious code there.

So using AI to potentially scan all the code. Monitoring, maybe even running it in a sandbox, monitoring the behavior and doing, Hey, this is potentially malicious, flag it.

Andy Schneider: Yeah. I see that and maybe this is really brilliant use case for using AI to just crawl over all those open source libraries and try to find flaws in there because you have the code. You don't have to do fuzzing and other things. You have the code so you can just Use the AI to scan the code and at least get rid of that easy SQL injection, cross site scripting things that are more easy to find.

The more complex ones, I think, are difficult to find for AI, at least for now. If we look ahead a little bit. Where do you see the trends for the next years? What are the big things that are coming?

Sean Wright: So one of the things is definitely open source. It's becoming a bigger and bigger thing as we use more and more libraries. It's becoming more of a target for attackers. And that kind of scares me. I'm surprised that it's not actually being leveraged as much as it has been by attackers. I mean, to me. You go compromise one package, you can compromise potentially thousands of users or customers or organizations.

So that worries me. The other thing that worries me is just the speed and adoption of technologies. One of the challenges I have as an AppSec person is trying to keep up with it. I don't want to say we have to become an expert, but you kind of almost have to become an expert in all these new technologies.

So you have to know, okay, we'll do this and this could happen, do that, that could happen. Kubernetes, this framework, this library, so on and so forth. So trying to keep up with that, how's that going to scale? It's great from a development point of view, don't get me wrong. It's great. It's great to see the speed.

Andy Schneider: It's never boring.

Sean Wright: And then the other thing is kind of related to a point where AppSec is not really seen as important as some of the other stuff. Maybe it is and it's just the interest in it is maybe a better way of putting it. So if you go ask people, one of the things I always hear is like, I wanna get into security.

Great. What do you wanna do? I wanna go hack things. You know, you hardly any hear anyone going, oh, you know what? I wanna go get into like AppSec or DevSecOps. And my concern there is supply and demand. Really, we have a more and more companies now realizing like, Hey, we need to start making sure our software is secure.

So we need to hire people to do that. But there's not enough people coming in and going, I have experience and knowledge from security and development side to help us. I'm not saying you have to be a developer to become an AppSec person. I know some really great, great AppSec people, but it helps, especially if you're building out a team.

And you have very few resources on it. You need someone that has that context behind. So I think that's going to be a challenge as more and more companies start looking for appsec people. It's becoming more and more challenging to find appsec people. And I know people might go, okay, well, just hire junior people.

That's great. But you have teams that are already extremely stressed, under resourced. How are they going to spend time training that junior person up and help skill them up? It's going to be challenging, if not impossible. So at the day, you have a junior person suffering because they're not getting the support they need and the team not getting any, well, getting as much as they would out of that junior person if they were properly supported.

Andy Schneider: Now let's move to, we are almost at the end, so let's have some fun questions. What's the one tool that you can't live without?

Sean Wright: Oops, wait, definitely that tool is incredible. The amount of costs and what you can achieve with it is just, so yeah. That, if I don't have burp suites, then I'll quit my job.

Andy Schneider: I know you have a very interesting blog. You mentioned that. So if listeners want to look that up, that blog. Just Google for blog Sean Wright and AppSec, you will find the blog. What would be another way to, to get in touch with you?

Sean Wright: Sure. So my email address, Sean at Sean Wright, very, very creative, or Twitter or X, I, I, I, I'm losing, I'm getting old now, Sean Wright Sec or LinkedIn, you should hopefully be able to find me there as well.

Andy Schneider: Wonderful. Thanks, Sean. So that's all for us today. Thanks so much for listening. If you enjoyed today's episode, please subscribe, rate, and review. And we'll see you next time on Code to Cloud.