Summary

Shan Kulkarni is the co-founder and CEO of Nullify, a product designed to augment AppSec teams with AI agents capable of carrying out multiple levels of product security work autonomously. Prior to Nullify, Shan worked in roles such as Cloud Operations Lead at UNSW Redback Racing, and Cloud Security Engineer at CMD Solutions Australia. 

In this conversation with Cole Cornford, Shan discusses the challenges of starting a business, and in particular the challenges of hiring, the state of AppSec in Australia, what the future might hold for the industry, and plenty more.

Timestamps

1:30 - Shan's career background

5:30 - Why AppSec is so often inefficient and expensive

9:00 - Bigh tech has a monopoly on AppSec talent

12:30 - Shan's journey from consultant to founding a company

15:40 - Biggest mistakes when starting a business

19:20 - Selling products/services to devs is extremely difficult

25:00 - Where Shan sees AppSec going

28:00 - Consolidation of security products

32:00 - What security leaders are struggling with: visibility

34:00 - Rapid fire questions

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 Shan Kulkarni. Shan is the co-founder of Nullify and is currently their CEO.

Nullify is a company that was built because there's a complete lack of domestic capability for product security engineers, even though we need so many people to be able to do that role. And so we figured that using artificial intelligence, you can scale out AI engineering functions throughout an organization, right? So Nullify has been around for about nearly two years at this point. Shan's previously done all sorts of work in consulting at Mantel Group and CMD before he came into start his business.

Shan's a really smart cookie. I had a good back and forth of him about all sorts of things where it was raising capital or just the state of Australia in regards to product security and AppSec, about how big tech is a monopoly on attracting talent and how challenging it is to even just find AppSec professionals. So I thought it was really interesting. And yeah, you should give Nullify a go if you're interested in it. Anyway, hope you enjoy the episode.

I'm here with Shan Kulkarni, who is the founder and CEO of Nullify. Mate, how's it going on this beautiful Friday morning?

It's going great, Cole. Thanks for having me here.

Shan, I think it'd be really good if you told everybody who's listening to this podcast a bit about yourself, your background, and eventually what led you to founding Nullify.

Absolutely. So I started my career originally as a software engineer. A lot of security folks do I feel like really enjoy building things, especially developer tooling and infrastructure tooling. So I was doing a lot of interesting work over at Cisco as a software engineer. I was in Sydney, but my whole team was based in San Jose, so I got to work on some cool things there. But at the time I was doing a lot of exploit development and I guess you could say web app security and vulnerability research at the University of New South Wales. I really enjoyed applying a lot of these software engineering concepts to breaking software.

And around the time, AWS were trying to get students to work more with cloud technologies and cloud security. They were coming to campus and they were like, "Look, we're going to take 10 students. You guys are going to work on a special cloud security project." And this was back in 2019. There wasn't a time happening in CSPM or cloud security land, and decided to do this project. And that's actually how I met one of my co-founders, Tim. We built this open source project for deploying serverless application securely. It was called Unicorn, Unicorn.ca. But I had so much fun doing that project. I went to AWS and I went to the school of Computer Science engineering and I said, "How awesome would it be if we can get this going every semester?" So we get the best security engineering students and the best security folks from Amazon. We pair them together and we run this as a cloud security hackathon incubator style project course.

So I did that for about two years. I was a lecturer. Tim, one of my co-founders was one of the tutors. We got the students to work on some really novel problems, everything from automated threat modeling to dynamic API fuzzing, everything in between.

And off the back of that, I really got to understand how Amazon solves problems around scaling application security. So they have this thing called security guardians where they put security champions and engineers in every developer team. But when I went out into the wild into consulting for big enterprises, working an AWS partner to help customers build security on AWS, I found that most enterprises really struggle to capture that security engineering talent. So I thought, why not build something in Nullify that uses AI to feel like a real security engineer and can help organizations transform without scaling people.

So yeah, that was my journey. Really enjoyed teaching security. I also taught the masters of cybersecurity pilot to CBA with Professor Richard Buckland. That was a ton of fun. And yeah, it's really excited to see what's happening in cyber in Australia at the moment.

That's a really cool journey, mate. So I know that satellite security resourcing is a challenge. And I know that especially people who worked in big technology companies, you end up with teams of hyper skilled, really incredibly smart engineers with a couple of them who are specifically really good at security engineering and you just dedicated satellite resource into all of these different product teams and they're supposed to manage end-to-end security. But then when you go to large enterprises, that almost never works because they fundamentally lack the ability to attract that type of talent into those organizations.

But the other thing that doesn't work is that the way that they're set up on a operational, they do project-based delivery. And so security is usually a centralized function and then they charge our tasks to cost centers based on projects that are being delivered. And then that team tends to lead not to an AppSec program, but to an extremely heavy-focused on either risk or compliance and assurance activities. And we wonder why we spend so much money on cybersecurity. But I know that you've got a few thoughts about that kind of space as well. Why are we in this situation?

Yeah, it's interesting. I don't know about the whole internal agency model. I think as you said with... It might work for GRC, but for application security specifically, if you look at how Netflix or Snowflake or any of the big tech companies with really mature product security programs, if you look at how they think about it, they actually have product security partners because they think of product security as partnerships with engineering rather than like, "We're the internal security team here to police everyone."

So I think we got here by fundamentally, there was a fundamental misunderstanding probably when security had to shift to software development or, "Okay, let's just apply the same frameworks and operational frameworks to how we deliver other security outcomes in the business to delivering them on burning down risk in the SCLC," which is actually, I remember how you once explained how you think of AppSec, which is literally just discovering and reducing risk in the software development life cycle.

But yeah, I think it really, really needs to transition towards building trusted relationships with engineering teams to say like, "Hey, we're here to enable you to go faster. If you build more secure things, everyone's more happy and the business is happy as well."

I noted that can be quite a challenge, folk, especially domestically. Because to build trust of a lot of those teams, I feel like there's a... People like to say a triangle, but I think there's actually more of a square where you need to have AppSec people, they need to do four things really well. They need to know security reasonably well. They need to know software engineering reasonably well. They need to be good communicators and you need to have some level of business acumen. And if they're missing any of these gaps, they're going to struggle in the industry quite a lot. Because if you don't have software engineering chops, you're not going to be able to give pragmatic solutions to engineers. You're not going to be able to build rapport. If you don't have security chops, then what are you doing? You can't provide any advice. You're useless as a software engineer.

Exactly.

If you can't communicate, no one's going to listen to your advice regardless. And if you don't have any business acumen, then how are you going to get the funding or convince leadership that this is going to align with their other business goals, right? Because some of the things that we do in AppSec programs, as opposed to almost all security mechanisms, they usually introduce a shit ton of friction and slow things down, make life hard so that you can get protection and detection and response capabilities.

But a lot of AppSec programs actually enhance commercial value, not just from a "let's go open additional markets because we achieve a compliance outcome." Because things like build reproducibility mean that if your service falls offline, then your mean recovery objectives significantly shrink. You've got environment parity. Hopefully you're going to have significantly less bugs being pushed into production that you can identify and resolve them a lot quicker, right?

So I always push for these kind of ones as well, but that's because I have all four of these things. And I find that at least when I speak to AppSec people locally a lot of the time, they tend to just be focused on having learned a specific product suite very well and effectively turned themselves into system integration professionals. I think that that's what the majority of Australian companies think of AppSec people. And all of the good AppSec people end up getting stolen into big tech companies. So what do you think?

Totally. Big tech monopoly on security engineering talent. As a whole, especially application security, engineering talent is very real in my opinion. Because look, for better or for worse... And this is something that I've seen when we took Nullify to America as well. If you're somebody, as you said, who has all four, which is not very common, at least even at a practitioner level, let's drop the business acumen. Let's just say you can code, you can break things, you can build things, you probably want to work at a big tech company building complex products that have a large threat surface or need to not be able to be broken.

And so if that's the case, if you're a mid-market enterprise or a small business, it's a lot harder as a sale for you to capture this sort of talent. What can you offer, I guess, that they can't> but I think until we get out of that mindset or until we find better ways to incentivize security careers, we're not going to be able to bridge that three and a half mil or four mil or whatever the jobs skills gap is in cyber. I would say a solid 20 to 30% of that would be product security. And as a category and as a kind of subset of security, I think it's something that's going up in importance. Like, all the new physical products that are coming out, all the new wearable devices and driverless cars, I think as time progresses, that percentage of the skills gap that's comprised of application security jobs that aren't filled is going to increase and continue to increase.

Yeah, I think I'm well positioned running an asset consultancy, and that's because I look at the states and I look at Europe and I see that they're coming out with regulation. It's enforcing people to do things like understand your supply chain risks, make sure that you have SALSA compliance so you can understand the provenance of artifacts, be able to produce a bill of material, so the software that you're running in your ecosystem. And this is happening all over the world, but not in Australia.

And as much as I love the cyber Bible, the ISM, there's like two parts of it that say stuff like, "You should do OWASP things." I can go rant about OWASP another day, I have very strong opinions about the OWASP Foundation. But ultimately, I don't think that the regulations here yet in Australia to force companies to be doing these things because we're still struggling with endpoint and firewalls, let alone software. So it makes sense to the Signals Directorate focuses on those aspects with EA. But if I look at all the other advanced economies around the world, that they're all moving to software. And think then Australia's going to be disrupted, and then it'll increase and elevate in importance. So I think we're in the right spot to be.

We're getting there, absolutely. I think as you said, the last pillar of this is why you need to care about this is always going to be regulatory tailwinds and complying with government regulations. And from what I saw, I saw the SEC do some crazy things over in the US. And probably, ASIC is starting to do similar things around breach disclosure and vulnerability disclosure or rather data breach disclosure. I think things will start to get interesting when people with cyber insurance premiums will increase if they, for example, don't have a DevSecOps maturity roadmap or something. But yeah, I don't think we're there yet, as you said, but we're heading there, I hope.

Give it a few years. So then they'll be like, "What is DevSecOps?" And you'll be like, "I thought we killed that term six years ago."

That's so 2017. Gosh.

Anyway, mate, so [inaudible 00:12:31] changing gears a bit, what's it been like going from being consultants to founding a company? I know I've been through that journey. I founded a company, it's a services company and it's a bit different to a product company. But what have been the highlights and the pitfalls for you?

Absolutely. Yeah, it's been interesting. It's funny. Before I was in services, I wasn't product in software. I really liked how close to strategic outcomes you're able to affect in technology consulting. That's what I love the most about cloud and cloud security consulting. But I think I hit the ceiling quickly on what I was able to do without just building a product to do it.

In terms of what that looked like, I never really knew too much about startups, frankly. My third co-founder, Tony, who briefly was at AWS himself and then was running around America for a little while in 2022, he was the guy who knew all about how the VC game worked, how the startup game worked. I think what's important if you're selling a product company is to be exactly that, be really in love with the problem you're solving and the solution you want to build for it, and then later on get excited by company building.

Company building is exciting, obviously building a team, raising capital, building a product, going to market. But I think making sure that you have a unique insight first and actually have a solution for that insight is definitely more important. But yeah, it's been a crazy journey. It's been a lot of ups and downs, a lot of things to learn, but the growth has been. We've had a lot of great growth. We've been able to raise two rounds of funding since 18 months have been around. And yeah, I've just been incredibly grateful for, I think, a lot of the trust that both Australia and now American enterprises are placing in Nullify to build their AppSec programs. And yeah, it's been humbling. It's been a really humbling journey.

Yeah. I think that unless people have been through to pain of starting a business and then learning about all the different aspects that they need to do, then when they go back... Because eventually people get sick. I imagine at some point I'll say, "I'm done with that. I just want to go solve a specific AppSec challenge or a cyber challenge, or I want to do something else. Maybe I will be a fisherman. I don't know. Maybe I'll support my daughter's Olympic career dreams of... I have no idea. But ultimately, there'll be a point where I decide I don't want to run a business anymore.

And then I think that that makes me tremendously more employable to all sorts of people because you fundamentally get it at a C level. You have the networks, you understand all aspects of running it, whether it's doing sales qualification, doing the hard yakka for outbound cold calls or working out how to do, move people along in the right direction and getting them to say yes, whether it's being able to facilitate and run marketing that's against the right audience with the right messaging, bad med pick, all that stuff, then you go to the other side and you go to everything like finances and P&L and cashflow and profitability. None of this has anything to do with software security. I've had to learn it over three years and I tell everybody else that it's really good for your career, but it will be a slog because you're going to make a lot of mistakes very early on.

Yeah. Absolutely.

So I've made heaps of mistakes myself. What would you say in your first day involves your biggest mistakes have been so far?

Look, I think in terms of mistakes, there's no shortage for us, at least at the very, very start. I won't talk about anything in particular with people, but hiring is really hard. Hiring is easy to get wrong when you're an early stage startup, recently capitalized, looking to deploy capital into building an engineering team. Hiring is really, really difficult. And it's easy to make mistakes around building the right team. And it's easy to make mistakes for the people you're hiring as well by not managing them correctly, not being clear about expectations, not managing them with structure. People need leadership that gives them the structure or whatever they need to work best, and that's different for every person. And learning that I think if you've never done it before, it was just going to involve making mistakes.

It was humbling for me with my... Because I went and just hired a lot of my friends early on. And then I eventually realized that, "Yeah, shit. I know." I think you've done the same too. When you do that kind of stuff, you end up in a situation where now your personal friendships and you as a business owner have to make decisions. You're obligated honestly by AICD, but also by for taking care of your family and making sure that you set yourself up for the future. You can't be friends with everybody and you're going to have to have difficult conversations and you're going to piss off your friends.

And so I've lost a couple of my friendships because of that. And now I'm hyper aware that I don't want to bring people into my business if it's going to create conflict or something like that.

Absolutely.

And also as a startup, you are going to get access to a heap of money. And so it's easy to over promise and have high expectations, but you just would burn through cash a lot faster and make bad decisions about who to hire. It would be very different than when I was bootstrapped, because I have to have very sensible profit margins and if I deviated from those, I would just be out of business immediately as a services company.

Right. Right. Yeah, you're exactly right. I think another thing you touched on with go-to-market. I remember when we started, we had this dream vision of we're going to build this number one loved-by-developers application security tool. We're going to launch it on the GitHub marketplace. We're going to launch on product time. All these developers are going to start using it to secure their open source projects. They're going to start using it to work on the things that they're hacking on the weekends. They're going to love it so much, they're going to bring it to their manager, bring it to work on Monday, bring it to their manager and say, "Hey, we should use Nullify at work."

I can tell you now that whole product-led growth dream or mirage is exactly that. That's not how security products get procured, for better or for worse, right? Coming back to what we started talking about, security, unfortunately, is just not in this value stream for software engineers. It's not yet like an OKR for a software engineer, like, "Oh, how many vulnerabilities did you push this month?" Or, "How many did you fix this month?" And so that was something we got wrong. We had to pivot our whole go-to-market strategy from a product-led growth sales motion to a enterprise sales motion. That also means well probably we hired the wrong people to support that. And yeah, that's definitely something I would recommend to anyone. If something isn't working in go-to market, stop it after six months, especially if you're an early stage company. You probably have one, maybe two, goes at a go-to-market strategy and left in the bank.

And then after that you don't have the money to be able to pivot anymore.

Exactly.

I'm friends of a few founders locally who've been really struggling with that, because especially selling to developers, I think personally it's the worst audience to sell to. I don't know. Sorry, developers, on the call. The reason that I think it's really hard to sell to, especially in a product world, is that there's an enormous service subscription because developers say, "Cool, I'm a developer, I'm going to build a product." So devs tend to build their products for devs because they are their own target audience and they have the skills to build products. Whereas I don't really see developers like building apps for aged care providers particularly often, for example, right?

Mm-hmm.

And so you have these entire areas like agriculture or vineyards or whatever that are very much, unless someone's got a very specific niche, like they're a sommelier and they care really deeply about wine tastings and they wanted to find something as to be the automated sommelier of the month so that you don't have to pay $5,000 per sniffing or tasting to figure out what wine it is from sommelier, then that can get disrupted and be a great market fit. But I feel like going into an exceptionally crowded market is really hard.

And also, if you build it field of dreams, no, never seen it work ever. I tell every founder, "You need to have an outbound sales capability and have both branding that distinguishes you from your competition and the ability to generate a funnel for different types of events. But if the funnel is the way to get your inbound going, you can't just assume that you're just going to keep getting people popping into your funnel. You need to also go out there and pound the pavement and talk to people."

I meet so many founders who focus exclusively on building the right product, but then they can't sell it to anybody. Or even consultancy, right? If you're in the services industry and you're spending let's say 150% of your time because, come on, I'm going to be realistic, all consultants work overtime, you'd be silly if you don't do that, you spend 150% of your time focusing on chargeable work. At the end of your 12-month contract and you've got no pipeline, you are screwed.

You're in trouble.

I see this constantly, right?

Totally. Yeah. That's something that at the end, the best idea, the best product. And I think going to market, I mean you asked me about services, that's I think what helped with that. I mean I wasn't selling services personally and I definitely wasn't selling product, and that's something you just have to figure out. But it gave me an understanding of where does value lie in enterprise technology and what drives value creation and spend eventually. What are enterprises going to pay? What are security people, security teams or leaders, what are technology leaders going to pay for? What are the strategic initiatives that they care about? And that basically allowed me to understand, "Okay, well how does application security map to those strategic initiatives, like secure software development?" In our case, secure software development and gen AI productivity is the kind of two board level transformational priorities that we're very lucky to be sitting at the intersection of at the moment. But without that kind of high understanding of all what are the suits really want, you can go in with the best tool, the best product, everything, but you might not get buy-in.

That's why there's so much of a focus nowadays. In the past, it was all about let's just go take executives out for drinks and dinners apparently in the '90s and early 2000s.

Right.

I still think that's the case except a lot of execs are absolutely used to being taken out for drinks and dinners, even if they have literally no interest in participating or listening to you have any budget or whatever. And that's why there's so much focus on BANT and especially MEDDIC. I see MEDDIC constantly. I don't remember off the top of my head, I have to read it because I guess I haven't been on enough MEDDIC training. But using these qualification frameworks is really important to be able to understand is this someone that is likely to transact and actually has a real problem that they need to solve or are they a tire kicker?

I guess the other thing that I think is important is just having more conversations. One thing that I failed with early on was just relying on the network that I had. I thought I had a big network. I don't. And then when I started doing so much more things like going out, doing public speaking, writing blog posts, and just participating in a community at large as much as possible, that led to me having more conversations, all sorts of people. And eventually, you get to a point where you can start having people refer stuff around, which is great for services business. But with a product business, it doesn't quite work that way. You need to be doing outbound sales. You can't rely on your existing network. And it's also really hard to sell to your friends and people that you've known before. I don't know about you, but I've had very little success selling to people that know me already.

That's definitely hit-and-miss, yeah. I think understanding what are you building, who needs it, who buys it, why do they buy it, what are they doing right now that isn't working, I think is critical. That qualification thing you mentioned is absolutely critical.

So pivoting a little bit, we know where AppSec is today. In the past, I'd say that we started with having manual assurance, tools like Fortify and Checkmarx as being used to just as within a project delivery model, eventually moved into a DevSecOps flow. And then now everyone's all about platform engineering, which existed about 20 years ago as systems engineering. But whatever, we won't talk about that.

Where do you see AppSec heading to over the next couple of years? But spoiler, let's not focus on AI because I feel like we're in a trough of dissolution of that at this point.

Yeah, AI is just like the how and maybe might change the how a little, but the what is very much the same. The jobs to be done for application security engineering haven't changed, I don't think. I'm starting to think about it more as product security now moving forward. I don't know about you, but the most distinctive thing that came out of the Apple Vision Pro launch, at least for me, the most memorable thing that happened out of that was somebody getting a critical memory corruption vulnerability that bricks the Pro every time you do this. And I was like, "Wow, the new frontier of product securities is going to be of just such a higher level of importance as we start to transition to wearable products like driverless cars." Software is starting to interact a lot more with the physical environment in a way that we haven't seen before.

And so I think application security and product security, I guess starting to be used interchangeably now, but people are starting to say [inaudible 00:26:04] just because it kind of encompasses cloud security too. But securing the software that you build, if it isn't already, is just going to become a matter of national security significance. It's going to start to move up the ranks in terms of the priorities of any organization. A big part of that is just because everyone's a software company these days. Software has obviously eating the world as we all know. But something has to give. I think whether it's something like what AI can play a part in terms maybe balancing the scales or helping distribute security ownership at scale and bridge that gap of security jobs or something else, definitely a paradigm shift is coming in order to keep up with the pace that software is being built at. Otherwise, if we don't see that, I hope bad things don't happen.

The way I see the industry evolving myself is that I think that what we've been building in the past is a tremendous amount of point solutions that solve individual types of gaps within software engineering. Ages ago, it was custom written source code dependencies. Nowadays, it's going to be API, security exposure, attack surface management, cloud configurations and just other things, right? But there's still all point solutions solving all of these things.

I know that everybody holistically ends up wanting to be the, "We solve all the problems. we're the platform that just fixes everything." I see that, it's what was called ASPM starting to really pop up. Not so much domestically in Australia. Other than Black Duck, which is the rebrand for our good friends at Synopsys, I think they have an ASPM products, but I haven't seen it domestically in Australia. But I can see the value in companies saying, "I don't want to think about source code and dependencies and APIs and secrets and attack surface." But I feel like they've split into two different categories. You have the management of it before it goes live and the management of it after it goes live. And so there might be application detection and response and then application hardening overall.

Correct.

So I can see those being two categories to split into, but I don't don't know. What do you think about that kind of stuff?

ASPM and ADR have emerged as kind of... I mean, even now I think at least in the wild in America, we run into a lot of ASPM solutions. Consolidation, something you mentioned there, is a huge trend, absolutely. I think a big part of Nullify's product thesis was application security teams, or security teams in general, I think, want less tools rather than more. Security leadership want a lower total cost of ownership out of the capabilities that they're building internally.

And so I think the whole consolidation piece was like... What I like to think is the first almost incarnation of ASPM was like, "Can we just have one platform that just does all my security testing?" And then I think vulnerability, prioritization, and management then became the obvious persistent problem, like, "I have all these scan findings, I need to figure out what are the most important risks to me." And then now there are a lot more remediation platforms, like, "How do I fix it? Who do I send it to fix?" Orchestration around the whole remediation lifecycle of vulnerable dependencies or vulnerable code or detected hard-coded secrets and that sort of thing.

Yeah, I do see consolidation continuing to win. You're seeing still point solutions prop up like, "We're the best API security testing company" or, "We're the best secret scanning company" or whatever it might be. I just don't think that's what security buyers want or need right now. But yeah, it's going to be interesting.

I think that the prioritization does matter significantly because I think over time we've had an overemphasis on... I guess security companies in the early 2000s, they really didn't want to miss things. They were all about finding as many things as possible at end saying that it's worth the human effort because the human effort is better than paying for manual testers to find things, versus just triaging results should give you 80, 90% saving on costs.

But now we got to a point where there's so many things being found that it's... I know the whole high signal-to-noise is really important, a lot of products moving forward. And so I'm starting to see iterations on let's say SCA, where they focus on cool other function calls related to the CVE actually being called, because then we have reachability, and also, is this being deployed into a cloud environment that's publicly accessible or onto a server. And then you can hopefully reduce the amount of findings from 95% down to 20 findings to fix, which should be manageable for development teams.

I know that they've tried in the past things like keeping everything up to date, automatically patching everything, but that introduces so much system brittleness and makes it really difficult for engineering teams to do anything except firefighting and eventually not becoming DevOps experts, but just operations experts.

They don't actually do anything except like, "My job is to patch NPM packages. What about yours?"

"Oh, type script."

"Okay. All right."

Yeah, it's not where things need to be at. Reachability analysis is great. I think something even we started doing, we started with just figuring out whether something has been exploited in the wild, what's the exploitability. And then now looking at the context of the code and trying to figure out vulnerable components are being used. But I even think that's just scratching the surface on what's possible in prioritization. Like, business risk impact I think is where this sort of enrichment should go next. So okay, let's even say it's exploitable and it's reachable, but perhaps it's in a test repository or it's in a piece of code that never runs in production or it's a piece of code that runs some internal service that doesn't have any attack surface that can be touched from the internet. Or some sort of contextual enrichment that takes into account what's most important to the business and which asset is this particular vulnerability actually in.

I think that's what security leaders are really struggling today with in terms of software development security, is visibility. So where is their risk? What's our risk level today? Not just in where it is in terms of is it in code or dependencies, but which parts of the business is it in?

It goes back to my second guest on my podcast, Nina, who spent a long time focusing on asset inventory being one of the most important things by far. I mean, because if you don't have people who fundamentally own the software products... And also, what is the software products? Where are the gaps?

I find that this is such a challenging space and I love consulting in it because you could get all of these things. Like, we have a microservices architecture platform where we consume some of these things, but overall we have a monolith over here. It's like, "Cool, so what is my system? My app system, am I responsible for these shared components that I have to manage? Am I responsible just for the front end application that consumes it? Am I responsible for the infrastructure that's underlying?" I feel like those kind of... Especially even in cloud environments nowadays, because you might have dev teams who own the infrastructure, you might have a platform team who establishes the abstractions that people operate on top of, you might have just a cloud team who just spins up boxes for you to deploy things on, which I don't think that's very good when I see that, but it happens a lot.

But yeah, anyway, that keeps it very exciting for us. I'm happy that we're in a space that just is constantly changing and it's just fun to interact with.

Always changing, and as I like to say, never solved. You can't ever solve product security. Actually, you can't even solve any sort of security. It's always just about burning down as much risk as possible, but yeah, it's an exciting space to be in, totally.

Reminds me of when I went and interviewed for Facebook five, six years ago. They flew me over to Menlo Park. One of the interesting things about their campus was that whenever you were outside, everything was Disneyland. It was like flowers and beautiful and well painted and manicured and just exceptionally neat and tidy. But just as you went into any building, it were like cables hanging from the walls and half finished stairs and walls were unpainted.

I spoke to one of the guys and I just said, "This is bloody weird." And he said, "The idea is to tell people that the consumer experience needs to be at least Disney level quality. And if a consumer experience isn't Disney level quality, then we made a mistake. And secondly, back a house, software is never finished." So I know. Big tech, oh my God, just blows my brain.

Anyway, we'll wrap it up on that. I've got two questions for you to finish your podcast, mate. First one, what book would you give to one of your new starters and why?

The Art of War.

There we go.

I don't know why I would give them that. No, I think it's helpful. I think there's a lot of helpful business lessons in the Art of War actually. Listeners, take that as you will, yeah.

I know. I've read it so long ago. I don't think I've internalized stuff, but just things that are basic to me, like doing preparation and expecting things, and just if everyone's zigging, you zag, stuff like that. It's a good book, but I wouldn't take too many life lessons from it.

If they're a sales new hire, if they're an engineer, I'll give them probably the Golang book. We have a book on writing Golang because we're built in Go.

By Rob Pike?

Yes, by Rob Pike. Actually, Tim, one of the co-founders, CTO, he got it signed by Rob Pike at a conference.

There you go. So Golang is one of my favorite languages except for having to write if nil on every single ATO, i2a request ever. So anyway, we'll talk Golang, gRPC and stuff another time.

My last question for you is, best purchase for under $100?

Best purchase for under a $100, Monogram phone case from The Daily Edited. It's like six bucks, and it'll make you feel like a very proper person with your initials on your phone.

I love those things. They just make you feel special. I mean, my phone case is just pink and that's it.

Listeners can't see this, but here, this one's mine.

It makes a big difference because you can feel proud of it when you carry it around. Anything you can do to just make yourself feel better when in such a stressful job as being a chief executive, it's good.

Totally. Totally.

Anyway, Shan, thank you so much for coming on. It's been an absolute pleasure to have you on Secured.

Thank you so much, Cole. Thanks for having me. Appreciate it.

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.