Episode Summary

In this episode of Secured, host Cole Cornford chats with Neha Malik, Head of Product Security at REA Group, about building and scaling effective application security (AppSec) programs. They delve into the importance of empathy, communication, and relationship-building between security teams and developers. Neha shares her journey from a Microsoft graduate program, through external consulting at KPMG, and into her current leadership role. They discuss making security easy for engineers, managing security champions programs with realistic expectations, and learning from other disciplines—like psychology and marketing—to better influence and engage stakeholders. Neha and Cole also highlight how tailoring approach and tooling can differ for startups and large enterprises, and emphasise that collaboration, not confrontation, leads to long-term AppSec success.

Timestamps

00:20 - Neha’s Role at REA Group and Positive AppSec Outcomes

01:30 - Starting a Career in Security at Microsoft’s Grad Program

05:45 - Building an AppSec Program from Scratch at REA

10:00 - Startups: Embedding Security in Tools Over Heavy Process

14:40 - Security Champions Programs: Value, Expectations, and Incentives

20:25 - Learning from Other Disciplines (e.g., Psychology) to Influence Teams

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. Today I'm joined by Neha Malik, head of product security at REA Group. Neha has a really positive vibe and is an incredibly sharp AppSec practitioner. I always enjoy talking to her about topics ranging from making security Champions program successful because it is quite hard to get buy-in from developer workforces, but she's been able to achieve that in spades over at REA. She's also quite confident in leveraging her mixer tools. There's no silver bullet. She knows how to build relationships across business, and she's just a really positive and energetic person. That suits my kind of vibe, right? But it's something for everyone in this episode. I hope you'll have plenty of fun listening to our chat today. I think nearly we've just ran out of time, so too quickly. This is just so fun. Anyway, I hope you enjoyed this conversation and I'm here with Neha Malik, who is the AppSec lead at REA Group. Neha, how's you going today?

Good. Cool. I'm just waiting to see some sunshine in Melbourne. How are you?

There's no sunshine in Newcastle. I went out with my friend Khaled this morning and had breakfast and it was pouring rain next to us and we were just sad.

Where is the spring I was promised?

Yes. We seem to have got to rainy summer and skipped spring, right?

Yeah, exactly.

So Neha, it would be good to help our audience understand about you and your background because being an AppSec lead at REA Group, which is one of the most successful real estate technology companies is a pretty big role and responsibility. So how did you get there? Where'd you start from?

I was very fortunate when I was starting out my career because I started my job in Microsoft right out of uni and they had something called as a grad program. So at the time it was called an Apex program, and in that as a part of the program, you get to spend six months in teams that are participating in it. So essentially for two years I spent six months doing different roles across different teams. So I was developer, a project manager and a security person. And when I was doing my security rotation, I realized this is what I want to do and that's how it started.

I know that I actually really like graduate programs. I myself came through and I know a lot of people who've also come through grad programs. I remember it was kind of funny, I was at the ATO for my grad program. I failed many other interviews, but the one that I remember speaking to them about it was kind of hilarious to me looking back on it, but they were like, "What do you know about the ATO?" And being the person who knows nothing about the ATO, I just said like, "Ah, I think you guys had a lot of your staff members leave not that long ago, right?" And then they were like, "Yeah, it's very sad, isn't it?" I'm like, "Yeah, yeah." Anyway, apparently that was a good answer. So I got a job at the ATO.

That's why they were hiring.

That's it. I have a subtle feeling that it's because I was the only person who applied from Newcastle, but whatever, I'll take it. Also, so with my grad program, we had a similar thing. We had free rotations, so we had five months, I did Agile software development and then we had one month which was contact center. And I have to say that the reason that they did the contact center is they got the entirety of the ATO graduate pool, whether they were lawyers or tax professionals or IT professionals or whatever, to basically get on the phones and deal with questions about myGov and entry level tax stuff.

If I get paid a hundred thousand dollars per year, how much money do I need to pay his tax? It's just like, well, here's the way you do that kind of stuff, or how do I log into myGov? How do I log a tax return? What is my tax? And I think the really good thing about the contact center in my view was that a lot of these people who had literally never had to deal with customers at any point because they're all back of house folk, now have to be on the phone and actually understanding the business and I take that kind of attitude into how I run application security nowadays. Right?

Absolutely. Yeah.

That's when I moved to the AppSec and I've been in AppSec ever since and I am really grateful and think that grad programs are really smart and give people good opportunity to get their foot in the door.

100%.

Microsoft was good for you too?

Yeah. And it's so helpful to be able to see different perspectives when you're that early on in your career and to connect with your customer so you get to understand really what their problems are and where do you fit in the picture. So in the grad program, I was really lucky to actually do internal consulting to begin with, and at that time the whole security process was not as smooth as it was now. So we would get to actually speak to development teams and we had the power to be power at that time. I would not call it so much a power now, we would actually block releases if they didn't comply with security practices. So you could see what are the issues they face when they're out to release and what frustrations they have to actually overcome when they have to apply security fixes and matches.

Yeah, that's really good. So where did you move on from after Microsoft? Because were you there for a long time?

Yeah, I was there for maybe almost four years and after the grad program finished, I went back to a software development role and then after that I decided maybe I like development but also looking at it from a security lens. So I went into KPMG to do external security consulting and that was a real eye-opener as well because so far I was dealing with their teams internally, but now I was dealing with all sorts of organizations of different sizes trying to solve different problems for them.

Consulting, it's one of those things I think that everybody should give it a go at some point rather than staying internal. And the reason is because you get to experience so many different types of businesses, whether they're really small ones, medium-sized on big ones, different verticals. So you'll be in health one sec and then you'll be in banking and then you'll be in technology and then you'll be back to government.

And so getting a broad range of understanding, even if it's shallow, because doing an auditing kind of role or an advisory role rather than having a deep dive into something and see how stuff changes over time. I think consulting's good to help with that. And I guess you also learn how to do marketing and sales as a bit of your role too.

Yeah, true.

I don't know if you've ever had to worry about farming accounts or if you were just always an associate or did you have to go to manager or partner level?

I reached a level where I was expected to contribute towards sales, but yeah, I think my experience in consulting was a little bit like being thrown into the deep end. You have to figure things out really quickly and the same solution doesn't apply to different clients because the solution has to be very customized to clients. It's a fun learning experience.

A lot of my staff members, I'm like, well, we're a consultancy business. And so unfortunately if you go to a big corporate, they're going to invest a hell of a lot of time into training you, sending on the science courses, making you learn all these kinds of things. But the expectation for us is you've got to work really hard and do professional development as well as solve problems to customers. And you can't go to a job and learn on the job even though you are learning, but you have to come in with the expertise beforehand.

Exactly.

It's a big shock for me. I just did internal for seven or eight years before I started my business and accidentally fell into consulting, technically. I didn't know what I was doing. I'll run a business, I'll figure it out.

But I think that's a really useful attitude that you develop out of it. It's like you get that resilience and the skills to actually figure things out on the spot and be okay with the ambiguity that comes with it.

Then, so is that after that you moved into REA? Is that right?

So after consulting I went for a little while with Dell and I was back to internal consulting, but more architecture focused and then that's when I moved to Australia and I worked with ANZ Bank for about eight years doing different sorts of roles.

Oh, cool, cool.

Yeah.

Working financial services, there's a lot of different, the horizons are very long to make the changes, and I think a lot of people get frustrated by that because maybe something that would take three months in a small tech company could take three years to actually have an enterprise capability for something. So did you find that that was the case when you were at ANZ?

Yeah, absolutely. For me, I had always been at very large companies, so I was kind of used to that way of working, but it's after I left ANZ I'm like, "Oh wow, things go really fast and I love it."

So when you joined REA, did you have to start building an AppSec program from scratch or did you come in and inherit a program? What was your kind of experience there?

A little bit of both. So it was the start of a formal AppSec program and it was a launch of a REA-wide program, but there were AppSec things being done in bits and pieces by other teams. We needed a program to actually bring some sort of structure and consistency to what we are doing and also then take it to the next level in maturity.

Yeah, I know that there's definitely a lot of pockets of developers who say, "Yeah, I've got Sneak and I'm running it, so I think it's a good thing to be fixing dependency issues." And then you go somewhere else in the organization, they say, "Oh, we've procured Veracode and we're running some static analysis in the cloud or whatever." And then you realize that there's a lot of devs who want to do the right thing and know that security is important, but it's like no governance or policy to define what good looks like or how they should be running a program at all. And so I guess your first step is to just kind of get a lay of the land. Is that how you would start an AppSec program yourself if you had to go in fresh?

I think yes, yes. And a lay of the land can fall in the standard category, the people process technology. So sometimes you'll find that technology-wise an organization is very mature, but there's a lack of processes around it or there's a lack of buy-in what you're trying to do. So with REA, we have a fairly really good mature tech stack and everybody is aware of why we need to do security and what practices we need to put in. There was a bit where we have to get buy-in and help teams understand why this is important and also be kind of their partners in remedying issues. So yeah, to answer your question, yes, very important to get to the lay of the land, but also try to understand what problems is the business facing and what problems are the dev teams facing.

Yeah, I think that's one of the things I really wanted to focus on in my webinar on Wednesday was just really spending the time to actually understand what events matter for this business and then how do we build the right types of security capabilities to get buy-in from business. And even stuff like writing business cases and getting people to agree upon the value of doing an AppSec program, I find that that's a skill that's really challenging for people who've learned DevSecOps and all they really seem to know is how do I operate specific types of products, whether it's a WAF or an SCA product or a CSPM or whatever, they've learned tools and they don't actually understand how that tool fits into the bigger ecosystem and helps manage risk or enable opportunity taking, right?

And sometimes it's just a matter of time as well. For most dev teams, security is usually not the number one priority. They have things that they have committed to and need to deliver, and sometimes these kinds of things get pushed to the side or for later. So it's very important. That's I feel like is a major selling point for an AppSec team because we are there to sit with them and help and understand their problems. So how we did it in RDA was we are going to come there here with you and solve all these problems for you so that you don't have to worry about accumulating tech. And meanwhile, we'd also build the capability so you know how to handle it in the future.

But I know that whenever I've spoken to a lot of companies in Australia, and I guess one of the challenges is actually hiring people domestically who have that software engineering backgrounds and that security skill set. And I know a lot of people who work with an application security currently have effectively learned how to run programs or just do high-level architectural reviews or just go down checklists. And so you can't really ask them to say, "Hey, I'm going to jump in into the IDE and start changing the dependency versions or doing input validation creating libraries."

And I guess of REA, and this is why I think there's a two cadence type of approach to AppSec. You have people who've working in project-based organizations and you have people who effectively are part of a centralized InfoSec function and don't need to worry about chargeability against different projects and delivering an outcome for those projects.

And then you have people who are working in a product-based approach where it's always iterative. And I find that if you're in a project-based organization, there's going to be a lot of problems with you jumping into the code and making changes because there should be segregation of duties between the people who are writing the software and the people who are auditing the software, but that just disappears entirely when you go to a small team and everyone's accountable for making sure that the company wins.

And so I find a lot of people, especially when I speak to AppSec people, they talk past each other constantly because the tech people are like, "I don't know why you can't just ask your developers, your AppSec team to just jump into the code base and write things." And then the bank apps that people are like, "I don't know how you can actually have your employees jumping in. Isn't that breaking just normal free lines of defense? What are you doing?"

Yeah, yeah. I think it's less about jumping into the code base and writing things versus giving the power to the teams to understand how exactly to fix something. In some smaller organizations, it could be a matter of jumping into the code base and fixing it for them, but for larger ones, there's still an option of providing the fix and the team reviews the fix, understands why it's a fix, and then puts it in rather than having to figure out the fix themselves. And then the AppSec team comes and checks, "Oh yeah, actually this issue is not showing up on the tools anymore, so you're good to go."

And that aligns to what a good security Champions program would look like is that you are basically spending the time to effectively build a portfolio of examples of what bad stuff looks like, especially if you've seen bad in an organization and people can look at it and say, "Oh, I know that code that's for this one particular application I wrote that I'm ashamed." And then you can say, "And here's how it should look like." I think that that's kind of effective as far as Champions programs goes. But it goes back to I have multiple views on training, but what do you think about Champions before I go in and have too many spicy takes?

It's always a hot topic, isn't it?

Yeah, that's right.

I want to keep a more balanced view if it comes to Champions. I do have some strong opinions, but it's more like, yes, I feel like it's definitely helpful to have security Champions program because as an AppSec team, they are your window into the teams and they can give you insight onto with what the teams are struggling with and that can help you drive decisions or make security calls that will make security easy for the teams.

But there's a separate component where we have to manage our expectations around the program. So yes, you are training them on the programs. A lot of the times these devs are actually doing this as an extra work. They're not getting extra compensation, they may or may not get recognition for it, and the level of training they have received is not equivalent to the training a security person receives over the span of their career. So the expectations that you have from security Champions have to be managed according to all of that, which means at times they may or may not be fully engaged depending on the priorities that they have to [inaudible 00:16:09].

It's just an extra responsibility or an interest group. And I feel like I'm strongly opinionated. I think that Champions doesn't work when you get to a bigger organization. I think that it works actually really well when you're at a small to mid-sized org and because the investment in effectively creating a first line of defense for people who genuinely care, and usually I find that the smaller the organization is, the more that it kind of attracts star A grade employees who just want to work really hard and do the right thing.

And then as the organization gets bigger and bigger, you just need lots of really, really, really nice people who are okay at their jobs instead of attracting brilliant jerks who are amazing at what they do.

Absolutely.

If your workforce is heaps of those really brilliant people, then they tend to be very effective at security Champions because they take accountability and ownership and want to run with it, do it the right thing. And so you'll get good observability, a security function because your Champions are telling you what the problems that they're encountering are. It's the first line of defense because they're on the tools actually solving problems and the investment that you need to make a small Champions workforce work, it's not that big. It's maybe quarterly discussions instead of having to figure out how do I scale out video content or training platforms? Because there's no way that you can do in-person training and make it work to a larger organization.

And any big organization I've dealt with has tremendous employee churn. So you train someone in, then they immediately leave. You can't measure the value of a Champions program because it's intangible, and I know that there's always incentives for people to do other stuff or it's an opportunity cost. Let's say that you're working for a business that runs its own internal P&Ls, and if they're busy doing security work, well that doesn't necessarily allow them to do chargebacks to show that they're making money or doing feature delivery, which the general application owner would care about. So that's why I've got a kind of nuanced view again about the two-speed approach. If you're a product company, it makes sense. If you're a project-based company buyer beware. Or do you want to fight me on that?

Well, I kind of agree, but I also feel like we can solve some problems with technology, but it's also important to have those relationships within the dev team because essentially they're your customers. They're the customers, and we want them to adopt what we are offering with no incentive for them to do it. So it's important to have those relationships. We may or may not call them Champions, but it's important to have that to actually understand what issues they're facing and how we can solve it for them. Because I'm a strong believer of making security easy if we want people to actually adopt what we ask them to do.

This is why I continuously tell people always read The Design of Everyday Things no matter what if you're in security simply because it teaches you concepts like usability and affordances and design thinking. And when you start looking at those kinds of approaches to how you build systems and how people operate within those systems, then suddenly you realize why is it so hard for developers to actually stay up to date with security?

So what do you recommend for people who want to actually build that kind of attitude and knowledge? Because again, I meet a lot of security people who are in an adversarial mindset, it's us versus them, and they really struggle to especially move into AppSec careers where it's meant to be collaborative and honestly quite sales oriented because you need to be convincing, you need to be marketing that it's a good idea and then selling people on the value of doing security. How do you square that circle?

That's a really good question. I think that there's several ways. So one of them is definitely to have an open mindset, is to understand and empathize with the problems of your customers. And that will come from having a sales mindset, but also be willing to learn from other areas of discipline. So if you're security, if you're learning something from a marketing discipline or learning something from a psychology discipline and bringing it back here, that will actually add value to your customer in the end. So I feel like as an AppSec person, it's especially more important for us to empathize and be willing to learn and adapt our approaches because we are essentially the front line for many tech teams and what we are trying to achieve will not get accomplished unless we actually put ourselves in their shoes.

I often find that one of the issues of just going down that pure empathy approach is that either AppSec professionals can often become doormats, and if you are a doormat and people just walk over you, then are you actually achieving anything? Because you're too busy thinking about their experience and you're like, "Oh, everything's great," but just keep on building features and everything's good. And I've met many professionals in my career who have achieved effectively nothing.

If their role didn't exist, then the developers would have the same outcomes. In fact, probably have higher productivity because they have less meetings with this AppSec person. So I feel like that's one problem I see when they go too far down the empathy route. But you definitely don't want to be in the Dr. No handbrake to happiness route where you just say no to everything and make people angry and create that friction. So how do you get people to learn to balance both of those things because doormats are ineffective, but so are brick walls?

Yeah, it's a fine line to walk, I feel. I think it depends on what's the problem that you're trying to solve. If a problem that you're trying to solve impacts a large number of people, and if it has a major impact to the security posture of an organization, that's probably a place where you would not be a doormat to use your words. But if it's something that a team is probably struggling with and it may not be an externally facing feature, if it's something they have other priorities to deal with right now, then that's a place where you would be like, "Okay, I understand you're not doing this right now. Let's decide on a time where you can do it and we'll be there to help."

Let's shift in gears a little bit. Let's say that you were just joining a new company, a fresh startup. Where would you really want to be starting to build an AppSec program? What would you say would be the most important thing to begin with and why?

I think for me to start with, especially if it's a startup, I build it into the tools to start with because startups are really fast-growing and you don't want to start with a people or a process sort of approach because startups are by nature, anti-process because the process is going to change all the time and you don't want to be sitting and maintaining process docs every month or every two months. So maybe if you're in a smaller company, you start with building into the tools so that can be replicated and scaled. And once there's some stability in the company, that's when you actually introduce some level of process.

Yeah, organized chaos.

Yes, exactly.

That's how a lot of startups start. They'll try to do all sorts of things and figure out what works. Even running my business, I'm in my fourth year and this entire year is about operationalization, efficiency and effectiveness of back of house. And whenever I say that to a lot of my staff members, they sigh and they're like, "Oh, that's so boring. I don't want to have to do things like fill in time sheets and then map them against projects." And I'm like, "Yes, but now we can understand profitability per engagement, and then that helps me plan for the future or doing a lot of FinOps so I can understand how does contract creation go to accounting and make sure that process is smooth and seamless so I don't have to think about it anymore." Right?

Yeah, sometimes you have to do the boring things.

First couple of years, just do whatever. Just I'll go try something. I'll go call this person up, we'll go hire these people and just figure out what works and what doesn't work.

But sometimes you have to do the boring things to go further. You can go fast in the beginning, but if you want to go further, that's when you have to lay this groundwork foundation.

And I know that that's something I often see as a problem with a lot of, especially younger folk, is that they don't... We have jobs, right? I'm a CEO, I have a job, I gave myself a job. I'm not at a stage where I can be a chairman and don't really have a job, but give me time. I'll figure that out.

But when you have a job though, there's going to be a lot of aspects of it that are great and amazing, and then there's going to be aspects that are terrible and awful, and unfortunately you are getting paid to do those terrible and awful things as well. And so if you can come at those tasks with the same level of enthusiasm and rigor that you do to the stuff you actually care about and just push through and have that right mindset, you're going to go so much further in your career than the people who just get stuck and say, "I don't want to do time sheets because that's boring. I don't want to write policy and standards for AppSec tools. I just want to run them. Or I don't want to do sales because I'm not a sales person," which I love that one. It's the silliest one I've ever heard.

We are salespeople.

We are. That's it. At some point everyone's got to realize, "Oh, you've got a job. So how did you get that job?" "I had an interview." "Oh, what's an interview?" "Oh, it's how I got the job." But if you really think about it, what is an interview? You're basically a way to market and sell yourself to another company and they're just like, "I hate you, Cole. Stop it. Stop trying to trick me into thinking I'm a salesperson."

Yeah, I think sales has a very negative connotation to it at some places, but if you look at solving a problem that your customer is facing, that's a different way of looking at it. So I wouldn't call it sales, I would call it really understanding the problem there, understanding why your customer is not able to solve it, and then being there to solve it in them in ways that makes it easy for them.

Yeah, I think also Australian culture doesn't help as well. I think that at least when I deal with a lot of other countries, because we do work with people in Europe and people in America and people in just the Asian region as well, and there's definitely an anti-aspiration culture in Australia and a don't sell to me kind of culture. And people put an enormous amount of weight on referrals from other people as the primary way to do business. And so whereas if you go to America and you can just logically state out like, "This is how we solve these kinds of problems," people are usually willing to give you the time of day to listen. So it's interesting.

I feel like there is value in disdain as well. So there is value in what people are telling you is not pleasurable for them. So those are problems to solve as well. For example, writing process documents. No one likes to sit and write documents all day, so how do we make this easy? How can we automate this and reduce our time spent and effort spent in that so that we can actually focus on the more important tasks?

Just LLMs, right? That's all we've got to do. Just create an automatic AI standard creation and we're great. I haven't seen artificial intelligence do badly. It's fine, right?

So I want to move across to something a little bit left of field. I know you said that learning from other disciplines is really important, and I really agree with that. What disciplines have you seen, ignoring sales, which is its own discipline, but what other disciplines do you think would really help someone who's let's say a mid-level AppSec person to go and research or at least try to immerse themselves in that kind of culture?

So I'm going to start with the obvious. A mid-level AppSec person should learn more about how the dev world operates because that's who you are going to be dealing with every day. And you could do that by either having shadow days with devs in the team, or you could do that by attending dev conferences. And there are plenty of online resources to learn more about this stuff.

But there's also an aspect of, I feel like psychology is really helpful to learn, especially the psychology of what creates an ideal environment for people to operate and the psychology of influence because my core belief is that I want to make security easy. I don't want to be blocker or a roadblock and say, "Hey, you can't go live because you have, I don't know, an error handling issue in your application." So that's not the team or the philosophy that I believe in.

I feel like if we are essentially there to support the business, so we should be doing things that make things easy for the business, and by doing that, we have to actually empower devs to help release software faster and quicker with higher quality. So that's where the psychology of influence comes in.

And I know obviously I always, with my business, I enforce that almost everybody who joins my company has to have been a software engineer or can demonstrate software engineering capability as the very first interview before we even get to anything to do with AppSec. And it's actually crazy how hard a disqualification that is for most people who've applied for roles with me. But I simply believe that you can't empathize or influence software engineers if you haven't done it.

So you got to... I write really bad code. I'm happy to put my hand up and say that because I'm not really a software engineer anymore. I was 10 years ago, I'm not anymore. I'm a person who is a big bird, a founding feather, a galah, right? I'll go out and spread my wings and have fun with people, but I still have that experience to be able to sit down and say, "I've been participating in Agile release trains and I know what it's like to have a T-skilled workforce, and I know how to do story point counting and Kanban boards, and I understand the frustrations of having to refactor source code versus go and do accessibility or look at actual feature delivery and velocity of your team or collaborating with other people."

And if you haven't done any of that, it's really hard. A few other ones I like to think about is lawyers is a common one. I see this a lot where someone will sign, a developer will read a contract, and the way that they'll read the contract is like a computer program because computer programs are incredibly black and white.

The good thing about computers is they'll do exactly what you tell them to do. The bad thing about computers is they'll do exactly what you tell them to do. So the thing about law is that it generally, you can put in the contracts whatever you want, but then there's precedence and there's interpretation, and then there's judgments. So at some point you have to have effectively parties like prosecute and defend and argue about what does a contract mean, and then have a judge sit over it. And if you're treating judges like compilers, then I don't think it's going to work because it's not black and white.

Absolutely. And I feel like a lot of times, especially in AppSec, we are sort of at the coattails of what's happening in the dev world because every now and then there's a new tech that's been adopted by dev for various reasons, and we have more of a reactive approach to the new tech that's adopted. That's why it's even more important to be a part of their world and understand why they're going for a particular tech and what's the problem that they're trying to solve, and then help them in the security for that.

So I just noticed that we're coming up on time. I do have two quick questions for you. So question number one though is considering what you've said about psychology and influence, is there a book that you would recommend for people to help learn about those kinds of skills or a podcast or a course to build that mindset?

Oh, there's a really good book called Influence: The Psychology of Persuasion. It's by Robert Cialdini. I really don't know how to pronounce the last name.

That's all right. Robert, someone.

Yeah, Robbie.

Robbie. Good on Robbie.

Yeah. So yeah, I found that really good because it helps translate. It really highlights on what are the drivers of influence and how you can actually use those to do good or bad. Don't do bad.

Yeah. Don't be a bad person. Be a good person. We're not being con artists here. We're trying to convince people to do the right thing and write secure software, not convince them to give us money for no reason.

Exactly. And ultimately helping the company in general, right?

Not just helping the company just with being a better person, helping humanity. Right?

Exactly.

That's such an important thing for me, and the way I live my life is of integrity and taking care of other people regardless of how they would treat me.

Yeah, they do.

If you don't live like that, then life's short. This morning, my wife over in China at the moment, she sent me a message that a week ago, she met a cousin, and then her cousin passed away unexpectedly last night.

Oh, okay. Sorry to hear that.

It's okay. And one of the things I think about is if that could be someone that we know in the industry or the people that we're dealing with on a regular basis, they get too worked up on whether a SQL injection issue or cross site scripting issue is this, or why is their project not getting funded and all of that. And they just can't take a step back and say what actually matters. And it's like making sure that we take care of each other, making sure that we run, get these businesses to succeed, maybe make sure that we support each other in the industry. And so, yeah, just saying that's how I live my life. And I'm sure you're in a similar boat too.

Yeah, absolutely. And it's not just about the business, it's about helping the tech community in general. We want to be able to write good code and secure code and worry less about attacks, however improbable that sounds.

All right. Last question for the day. Just a quick one. Under a hundred dollars, what's the best thing that you could get as a gift for someone, because we're coming closer to Christmas?

That's a really interesting question. I have two categories of gifts. Under a hundred dollars would be probably an Audible subscription.

Yeah, okay. Just listen to lots of books.

I think that's the best gift. If you want to learn about something in life, there's someone who's already faced those challenges and we can learn from their learnings. But I also like going on Amazon and giving people plant gifts for under a hundred dollars, and that brings me a lot of joy.

Yeah, I think that they're really good. Obviously learning and education is one of the best things that you can give someone. But I guess my only thing is with Audible, are people going to listen to that or are they going to listen to the Spice Girls? And I was listening to Ben Folds earlier.

Just your disclaimer, I'm not getting paid by Amazon.

Secured, sponsored by Amazon and Audible. So well, we've had a shout-out. Thanks Neha, for coming on. It's been an absolute pleasure.

Likewise.

I wish you the best and I'll see you next AppSec conference.

Yep. See you there.