Bitdefender Completes Acquisition of Horangi Cyber Security
logo

EN

Products +

Services +

Customers +

Partners +

Resources +

DevSecOps, AppSec, and What Is Application Security Posture Management?

Attackers will always target the weakest link on a software supply chain, as in the case with SolarWinds. How can you secure your software supply chain? On this week's Ask A CISO podcast, we go developer-first and talk about all things DevSecOps and AppSec, and find out more about Application Security Posture Management.

Tune in to this episode of Ask A CISO to hear:

  • How to actually pronounce "Snyk", in case you don't already know
  • What Snyk is and how it works
  • What being developer-first is all about
  • What is one major cause of supply chain attacks, similar to the one on SolarWinds
  • How companies can build synergies into your security teams, platforms, and developers to foster a DevSecOps culture internally?
  • What AppSecOps is
  • What dependency confusion and Typosqutting are
  • What is Application Security Posture Management (ASPM) and is it the future?

About The Guest: Lawrence Crowther

Lawrence Crowther is Head of Solutions Engineering at Snyk and leads solutions engineering for Snyk in the Asia Pacific and Japan. 

Prior to Snyk, Lawrence was the senior director of solution architecture for Elastic’s APJ business and before that, he spent 6 years at Pivotal Software in various leadership roles such as Head of Platform Architecture APJ for their Cloud Foundry product, started and ran the Pivotal Labs business in Australia and Field CTO. 

He has extensive experience in open source software, distributed systems, and modern cloud-native development. 

In Lawrence’s 20+ years of experience, he has worked with successful high-growth software companies that have either IPO’d or have been acquired, so he knows what it takes to build a business at scale.

About The Host: Paul Hadjy

Paul Hadjy is co-founder and CEO of Horangi Cyber Security. 

Paul leads a team of cybersecurity specialists who create software to solve challenging cybersecurity problems. Horangi brings world-class solutions to provide clients in the Asian market with the right, actionable data to make critical cybersecurity decisions.

Prior to Horangi, Paul worked at Palantir Technologies, where he was instrumental in expanding Palantir’s footprint in the Asia Pacific. 

He worked across Singapore, Korea, and New Zealand to build Palantir's business in both the commercial and government space and grow its regional teams. 

He has over a decade of experience and expertise in Anti-Money Laundering, Insider Threats, Cyber Security, Government, and Commercial Banking. 

Transcript

Paul

Alright! Welcome, everyone to the Ask A CISO podcast! Today, we have Lawrence Crowther who's the head of solutions engineering at Snyk and lead solution engineering for Snyk in the Asia-Pacific and Japan region.

Prior to Snyk, Lawrence was a senior director of solution architecture for Elastics APJ business, and before that he spent six years at Pivotal Software and various leadership roles such as Head of Platform Architecture APJ for their Cloud Foundry product, started running the Pivotal Labs in Australia as a field CTO. He has extensive experience in open-source software, distributed systems, and modern cloud-native development.

In Lawrence's 20-plus years of experience, he has worked with high-growth software companies that have either IPO’d or have been acquired so he knows what it takes to building a business at scale. Welcome, Lawrence. Anything to add to that?

Lawrence

Thank you, Paul. That's quite a mouthful, that bio, isn't it? Maybe I need to shorten that, actually, but happy to be here.

Thank you.

Paul

Yeah, welcome, and it's a good bio. I mean lots of great experience, I think very relevant to the listeners as well, so great stuff. Yes! So how are you and how are you doing with Wordle? We kind of notice you play quite a bit.

Lawrence

Wordle! That's funny. Yeah, I was quite addicted to that for some time, and I was getting quite good, sort of getting into guessing it in three, it's all about the opening and second word right to get as many vowels out there that you can reuse but I stopped playing and I'll tell you why.

I found a hack to cheat so if you go to the browser, they may have fixed it now it's part of the New York Times, but when he had it on his own website, you could go and look at the source code through the browser, and that all the words are published there, I noticed that he does it in sequence so if you knew last, yesterday's word, you'd know next, tomorrow's word, so once I found that hack out it was all over for me.

Paul

Interesting, yeah, I guess it's very relevant in terms of this conversation we have today as well.

Lawrence

There's a better one out there. I don't know if you've heard of Nerdle with math?

Paul

I haven't but it sounds ...

Lawrence

Yeah, that's quite interesting if you're more math inclined than words, then check that one out. You have to work out the equations, have to add up to a certain number, and it's a similar idea where some numbers are in the correct, they're right, in the correct place, some numbers are in the wrong place, and then obviously some numbers aren't there at all, but it's quite interesting, same sort of theme as Wordle.

Paul

Oh, cool, yeah, I have to check that out. So to kick off with the question and one of the questions that kind of stumps everyone and one that I had to clarify with you just before we started recording. How should one pronounce Snyk and is it more like a snick or sneak and why?

Lawrence

It's a good question.

I don't know why it's such a tongue twister for people, like you just say it like it's spelt, right?

"Sneak" is how we say it. Some people say "snick" in the UK, but I think most people say "sneak" as in "sneaker" and we've sort of adopted that phrase internally, everyone's a "snyker".

But it actually stands for something. I don't know if you knew that. Snyk stands for "So Now You Know" which is sort of, I guess, a geeky security term, right? You know more about your security and know more about your application and the vulnerabilities within it, so it has sort of a double meaning, I guess.

Paul

Yeah, definitely, and then that's cool, I think. Like, you know, any time your name sort of gets people to ask a question, I think it's more likely they will remember it which is very similar to why we named our company Horangi which is the Korean word for tiger, and a lot of people ask what it is but once we tell them once they normally don't forget.

Lawrence

It's a good icebreaker, I guess, and the other ...

Paul

Yeah

Lawrence

good icebreaker as well, I don't know if you can see behind me like the dog logo that Snyk has as well as ... do you know what type of dog it is, by the way?

Paul

Oh, it's a Doberman. It's my favorite dog, actually.

Lawrence

That's great, yeah. Okay, well, you're the right person to ask.

His name is Patch, right? And you know, obviously, why is he called Patch?

Paul

Yeah, for security patching, I'm assuming.

Lawrence

Absolutely, and also, you know, Patch is obviously a very cute common name for people that own dogs, but it is a good icebreaker when we go to conferences. We just started to go to physical conferences again in Australia which is excellent. And people come up and ask about the dog and what type of dog it is, and then they get out their dog photos and engage in a conversation, so it's a great icebreaker, similar to, I guess, the tiger story, right?

Paul

Yeah, I mean you guys should have Dobermans at your booths at the conferences! We always joke about having tigers in ours but, yeah, why not? We could do it probably in Indonesia and Singapore

Lawrence

Like a real one!

Paul

I think, a little bit more difficult, but yeah, I think, definitely, that's one of the dreams for us is to have a tiger at one ...

Lawrence

I think they eat a lot, right? They're big dogs so we probably can't afford the dog ...

Paul

for a conference.

Lawrence

food.

Paul

Yeah, definitely, I'm very highly considering getting one because it is my favorite type of dog as I mentioned so if I do then I have to have them on the next podcast. Yeah, so ...

Lawrence

Do it.

Paul

So tell us a bit more about Snyk, and kind of what you what y'all do.

Lawrence

Yeah, so we call ourselves a developer-first security platform although if you hear our co-founder Guy Podjarny talk about the platform, he considers more of us as a developer tool than a security tool which is quite interesting, right?

Security is sort of the outcome we're protecting applications and code that developers write, but he sees our company as something that developers want to use and it can integrate very tightly with their tools, so that's why it sort of says we're a developer tooling company more than anything else.

Obviously, the main objective is to keep applications secure, but we sort of plug into various places, I guess, in the software development life cycle right from the way you're writing the code and the IDE, also into the source control system like GitHub where you can scan sort of before you check-in, continually scan the repo when things change, for example, when people make MITS and then of course through CI/CD, plug that straight in so you can automate a lot of the security scanning.

That's just not source code. It might be open-source libraries that you have dependencies, might be infrastructure as code scripts like terraform or cloud formation before you launch a production into the cloud, looking for like misconfigurations, if you will, and then container scanning as well to make sure that the source for containers like Docker file, because you obviously can determine what the base image is going to be, and any user software being installed that potentially doesn't have vulnerabilities in like the Linux kernels that you're using and the base images.

We can also scan directly into a container registry, like an ECR, for example. Obviously, most folks will store their containers after they have been built in a registry before they deploy, and then ultimately even in production, we can connect to like a Kubernetes cluster to scan container images right there and then as well. And I think when I talked about the sort of SDLC or the Software Development Life Cycle I believe it sort of extends into production as well because we want to monitor the code that gets deployed in production because if there's a Zero-Day vulnerability like Log4J, for example, obviously you want to immediately know about that, and patch the environments, but also you know there could be drift detection, right? So you wanna know if things changed in production.

Paul

Yeah, definitely I think that makes a lot of sense and you know I mean it's always a challenge for companies that are iterating quickly to keep an eye on this stuff 'cause, as you mentioned, it's changing all the time and there's a lot of different hands in that sort of process as well, and ...

Lawrence

Absolutely.

Paul

things can drift and if you don't have some of that stuff sort of automated and the checks automated, it can be very difficult to solve those problems.

Lawrence

Yeah, if you look at a lot of the supply chain attacks that have happened, obviously SolarWinds and there's several others in sort of the open-source community which I can talk about as well, but attackers generally look for the weakest link in that sort of supply chain. You can have your production secure as possible, right, like you can use the best sort of anomaly detection and malware detection and endpoint protection, right, but if you have a weak link somewhere in your software supply chain, attackers will find that and use that to exploit you.

Paul

Yeah, definitely, I mean it's going to be more and more common as well, I think, but sounds like you guys have a good handle on kind of helping companies solve that.

So you guys of course are a developer-first security company. What does that mean to you all and like what does it mean for the development cycle, specifically to like the different teams involved in that process?

Lawrence

Yeah, I think what it means is that the tools that developers are using, things like GitHub, things like IntelliJ for writing code, or Visual Studio or VS Code or CLIPS, whatever your favorite language is, and you know tools on the CLI as well. The tools that developers are using is automatically sort of plugged into Snyk, right? There's no extra integrations you have to do. It's gonna work quite seamlessly with your sort of toolchain, almost so that Snyk becomes sort of invisible. I like to say that because you know, a lot of the clunky sort of security tools of the past in-app security, that is, the way they worked is they had like a hard gate and sent a list back of vulnerabilities to the developer without any context, right? So they had to sort of go through this list.

Maybe it wasn't even prioritized based on criticality or what have you that developers have to have that high cognitive load themselves to sort of figure that stuff out. But with Snyk, when we say developer-first, a lot of that heavy lifting is done for you. You know it may sound trivial but even figuring out which version of open-source libraries there that the developer should upgrade to based on whatever vulnerabilities they have is non-trivial because of the what we call transient dependencies or indirect dependencies that exist when you pull in an open-source library, right?

You know that even if I have a small application, let's say one hundred lines of code, I bring in just 20 libraries, right? Those 20 libraries probably bring in you know hundreds of other dependent libraries which could equal sort of tens of thousands of lines of code when you actually deploy it into production, right, so there's all that hidden sort of vulnerabilities, the unknown unknowns that developers don't know about.

So you need to be able to sort of scan all those dependencies and then help the developer actually upgrade to the right version. The right version might be not the latest because that actually may cause breaking changes but the sort of next minor or safest version that has that vulnerability patched, right, so we're doing a lot of that for developers. They don't have to think about it, and that's what I mean by sort of Snyk is invisible. It's there guiding them but it's not going to get in their way. They can still develop fast and do what they do best which is write code and deploy.

Paul

Yeah, no, I mean I think that's the right way to think about, like security in the future is it just needs to be part of the process and not like just another dashboard to look at which a lot of the security tools that I started my career on are basically oriented around dashboard and auditing which is okay but you know where you really need to be at is actually helping the people who are responsible for that problem to solve it, which I ...

Lawrence

For sure.

Paul

think is great and actually increases security rather than just alerting on it.

So with Snyk, how does it actually work like is there an agent installed? Is it on a server just scanning code? Can you give us just kind of a general idea around that?

Lawrence

Yeah, good question.

So I guess the best starting point for developers is to connect their GitHub or any repo, so we support not only GitHub but like Bitbucket, Azure repos, GitLab, as well any of the sort of the major Git source control providers, as long as they are Git-based. They can actually just point their repos, once they're done the integration with the access key to their repo, they can just import projects and Snyk will start scanning automatically.

There's nothing to install, nothing to do, and the beauty of that is if they've got repos that has not only the source code but all the open-source libraries, they may have container configuration in there, and Kubernetes configuration, maybe they have Terraform files as well because that's the way sort of developers are working now. They hate to use the word owned but they, I guess, other custodians if you will of all of those components in that repository, right, and that's why it's important for them to also understand the security implications, right? Because that's a big responsibility to now own the cloud infrastructure configuration, right, but that's the best way to get started.

They can just import their projects. Snyk will tell them in a few minutes or under a minute where the vulnerabilities are in the different components, OK?

But as you know developers like CLI as well, so if they've got a project already on their machine they can use the Snyk CLI to do the same thing. It basically scans the code that's already on their machines or the other asset types they have on their machines, and get sort of the same feedback before they sort of check-in their code into the source control. Similar with the IDE right? So that IDE is nothing but a sort of wrap around the CLI so they can get the same experience in the idea as they're developing the code and gets all that real-time feedback about any issues they have in not only their own code but the open-source containers IAC too. Does that make sense?

Paul

Yeah, definitely, I think you know that's quite useful for them also. One thing that I kind of sort of always talk about with our customers here is security culture, and like it being like one of the easiest ways to sort of like implement security into a business. It's just like by making it part of the culture because I think like obviously with engineering if you can teach them how to think about it in that way and making it everyone's problem instead of just the security team's problem, the organization's security culture naturally just sort of reverberates but for you like on the DevSecOps side of things, how can companies build synergies into their security teams, platforms and developers building that like DevSecOps culture internally?

Lawrence

Yeah, I mean Snyk is, I guess not a silver bullet to magically have, turn on DevSecOps, right? I mean it certainly helps through some of the automation and the sort of heavy lifting I've talked about to make it easier for developers, but obviously, there's a cultural shift that's required as well. I think that comes down to identifying the roles and responsibilities of a developer, the roles and responsibilities of security analysts and operations as well, don't forget those, 'cause you know DevSecOps is built upon the good work that the folks did around DevOps, obviously.

So I think it needs to be clear and set expectations around everyone's responsibilities, right, 'cause I think I've seen a lot of companies still trying to figure that out and sort of tripping over each other, which makes it a bit clumsy. But I think the key thing is if you have engineers that want to upskill in security, that's definitely a good place to be, right?

A lot of companies in the last sort of five years have created the AppSec team or the Application Security team which didn't exist, you know, five years ago, right?

So to me that's the definition of sort of doing DevSecOps because it's probably engineers that have obviously the engineering background and domain knowledge better, have an interest in security, and if you sort of help them get cross-trained in security when they move into that AppSec team, they're going to have empathy for both the developers and security so that's sort of the middleman, I guess if you will, between security and development, but not to say that you know, your people who work in the SOC or people doing threat detection or whatever can't work with developers, but the AppSec team will sort of be the coagulant, right, and get involved with the developers from day zero building new projects, advising them on security.

So that, I think, that's the fundamental thing I would say is that shift in sort of ownership and people's responsibilities and make sure they're aligned.

Paul

Yeah, a 100 percent agree. I think like alignment you know within the security team and then I think across the company like really changes the way the organization functions. I mean, and I think this is probably true even outside of security just for business in general, but, yeah, I think getting the DevSecOps sort of culture built into the different teams that are responsible for security is quite important and something that can really kind of pay dividends in the long run, and definitely I believe that products do help this, right, because making it easy to transition information between those teams and providing value across is the key and making their jobs easier and letting them spend more time on doing the stuff that they should be doing instead of like remedial, like copying and pasting open-source library numbers, and slacking them to each other and things like that, which you know no one wants to be spending their time doing.

Lawrence

Yeah, exactly. Well said!

Paul

So Snyk, you recently added a IAC, Infrastructure-as-Code product. Maybe tell me a bit more about that, and like how do you kind of see that fitting into the overall security design?

Lawrence

Yeah, we had that a while there actually, probably at least in beta sort of early last year. And you know we saw that as sort of the fourth pillar, I guess, in cloud-native or modern cloud-native applications, and also we saw a trend in the industry as I said where developers started to own, or manage at least, that, those configurations because it's so close to sort of software development anyway, even though Infrastructure-as-Code is not actually true.

It's Infrastructure-as-Config but it's close enough, right?

It's not like there's business logic in Terraform but actually, I don't know if you've seen a new tool called Pulumi which will be Infrastructure-as-Code that uses languages like Python and Node and go to actually define infrastructure that's very interesting to me.

Paul

Yeah, yeah. I've seen that in some of our more advanced customers, actually.

Lawrence

Yeah.

Paul

It is very interesting.

Lawrence

We're early in that stage but anyway, let's call the Infrastructure-as-Code, Terraform, and cloud formation, and it's close to what developers are writing because, obviously, they have requirements from their application to deploy on the infrastructure. They know what sort of services they need to use in AWS for example, so why not let them define that as well, but it's a huge responsibility, right, because developers aren't security experts nor cloud experts and if they just copy and paste, you know, blocks of Terraform in there from stack overflow, what have you, there may be some misconfigurations in there like leaving too many ports open, or the, you know, IP range is too wide, right, it's not restricted enough for ingress and egress, and obviously, the most famous one is, you know, private security keys in the file itself, right? These are things that sort of ...

Paul

Yeah.

Lawrence

table stakes but that sort of opened up the door for us to also start having those cloud discussions which I think is interesting, and we made several other acquisitions also after we launched our Infrastructure-as-Code product. One was called CloudSkiff which had something called driftctl which allows you to check your desired state versus the actual state, right?

So you've got your Terraform file, let's say, that defines the infrastructure that's currently deployed in production in the cloud, but you know things may drift, right? It could just be humans going in or developers going into the AWS console and changing stuff, right?

Or it could be applications even that inadvertently change the configuration.

Either way, you know my advice would be to lock down the AWS console and make it read-only, and if you need to make changes to the cloud, go back into the source file, into the Terraform file cloud formation, update there and then send it through the CI/CD pipeline to ultimately update the cloud. That way you've got full accountability, auditability of changes that you make in your production environment because I mean let's face it, it's just as easy to go in a Terraform and change something and do a deploy, than it is probably easier than going in AWS console, right? There's so many things on their console now, you know what I mean?

Paul

Yeah, yeah, no, I mean definitely like that's like our business is built around the difficulty of the CSPs' consoles and kind of helping customers understand, I mean like just with like we do like CIEM, so Cloud Identity and Entitlement Management and there's like 10,000 different permutations of the permission structures for an AWS account, right, which is like obviously a human can't really go through and do what I was doing in my first security job, which is basically an access matrix, you know, with 10,000 permutations of anything, right? Like we'd be you know working for months on that, but yeah, I mean, there's a lot of I think opportunities to solve some of these problems with sort of software, which is an exciting space to be in I think it's ...

Lawrence

The other piece I want to mention is we acquired another company called Fugue which is quite interesting. More in the Policy-as-Code space, so if you, if companies have specific policies around how they configure infrastructure, you can set up your own rules and sort of codify that ruleset, and sort of bake that into your deployment process and have Snyk obviously scan against those policies and make sure that you're compliant. So a lot of the compliance use cases we see with customers start around that conversation to help them to get to some certification, you know, whether it be PCI compliance or ISO 27000, all the other compliances as well.

This helps, right?

Paul

Yeah, yeah, definitely I mean we definitely have that feature as well and use a lot for the customers that use this in their clouds. It's very common, especially with you know, the regional certifications which I think are important and we help them then do that also.

So like I guess like 2021 is kind of like a year of sort of the software supply chain is attack with one of them happening, a pretty big one happening at the beginning of the year with SolarWinds.

Can you maybe give us kind of a view of how that happened and how it could have been prevented?

Lawrence

Yeah, from what I know, and there's different sources of information, but that one they got in through the build infrastructure or CI/CD pipelines so someone, probably a junior developer, accidentally posted a username password in the public domain to a build server, and I were able to get into the build server with the intention of sort of slipping in some malicious code as part of the compilation or packaging process before it was distributed to customers or SolarWinds customers, right? And they have obviously 20,000 or more customers and a lot of them were U.S. Federal government agencies, right?

They were compromised but I think what's interesting here is the attackers found a weak spot, that their end game was not to attack SolarWinds obviously, that's small fish, right? You know this is what it could be nation-state related the end game was to attack U.S. Federal government agencies, right, and so they sort of traced the supply chain back to SolarWinds, found the weakest link there. We're able to go through sort of the back door so that's what I mean by, you know, obviously, the U.S. government have very tight security in their systems, but this managed to get through, right, so supply chain is definitely a real thing.

I can talk about another couple of examples if you want which may help the listeners.

Paul

Sure.

Yeah, I think very relevant and something I'm sure everyone's interested in.

Lawrence

Yeah, there was, so you might you may have heard of something called dependency confusion. The developers out there would have heard this, but basically, this guy called Alex Birsan who's a security researcher managed to hack into Microsoft, Apple, Shopify, Lyft, and about thirty other companies using this technique.

So what it is is he realized that a lot of these companies had posted public GitHub repositories and he looked at those repositories and saw that there was a lot of internal package names, okay? So you've got, they had a mix of sort of public repos that they were using but also internal ones, let's say for Apple, Apple internal lib one point zero for the sake of argument, right, which you know obviously was developed internally in Apple and used for something specific internally for building whatever.

He discovered that the package managers for Node and Python, so npm for node that downloads these packages and builds the applications favored a public version with the same name so he, if he posted the Apple internal lib one dot zero in the public domain, in the npm registry, right? When developers were building their code locally, it would pull down his code and compile it with their applications, right?

Paul

Yeah.

Lawrence

So he was able to get access to development machines within Apple, Microsoft, et cetera.

Luckily, he was a white hacker, ethical hacker, let's say, so he didn't want to harm those end users but he did collect over 100 grand in bug bounties.

Maybe we can post a link to the blog post that I'm referring to, you know, in the show notes but ...

Paul

Yeah, yeah, definitely that's quite interesting.

Lawrence

I mean it's quite fascinating some of these techniques rights I mean it sounds pretty straightforward but, oh my god, that is frightening, right?

Paul

Yeah, seriously, I mean I'm sure there's plenty of vulnerabilities out there like that that aren't really like, I mean, they're not like super hacky or super, like sort of difficult, I think, but can really destroy stuff just because of things that we understand as sort of certainty which may not actually be certainty in this case.

Lawrence

Yeah

Paul

Yeah, and I think that's pretty common also like people are just pulling packages from all over the place assuming it's the right package, but you know ...

Lawrence

It's a trust element there, right, you just trust your build environment to do the right thing, but God knows what's happening. The other one which is interesting as well is typosquatting. Have you heard of that?

Paul

I haven't, no.

Lawrence

Yeah, similar sort of idea but hackers intentionally having different permutations of a library name. Let's take a popular library and javascript called "map" for example, right? Maybe ...

Paul

I see.

Lawrence

you misspell it with two "a" instead of one "a" or the "p" at the end, what have you, in the hope that developers misspell it when they define their libraries in their code inadvertently downloading malicious code, and they, he would probably, they would put the correct code in the library, and so it does what it says it's going to do, right?

So they get undetected but also with, you know, malicious code.

Paul

Yeah, I guess it's very similar to like domain phishing, I guess when they're like changing domain names with a you know using a "L" as an "I" or whatever and then the website looks the same,

Lawrence

Yes.

Paul

and you like fill it out and you're none the wiser at least at the beginning so It's quite good, I mean a good idea, I guess from the hacker's perspective but obviously something to ... another thing to be cognizant of on the sort of defensive side here.

Yeah, I think it's very relevant. I mean if you have those links we'd love, will share in the ... because we'll transcribe this as well so they'll be able to read this or listen to it so it should be good.

Yeah, okay, so kind of I guess as we kind of wrap up here, where do you think we're headed in light of what's been happening in 2021, of course with the supply chain attacks. 2022 we got all kinds of new stuff happening in the world with the stock market being where it is and of course, the stuff is going on and, yeah, so what do you see on the horizon, like where is the cloud and I mean, security in general, headed and like there's some stuff here around like what are kind of the roles that you see being in high demand in 2022 and beyond?

Lawrence

There is a lot to unpack in that question, I think.

Paul

Yeah, sorry, like so three questions in one. My bad.

Lawrence

Yeah, so let's with what do I see coming, I guess.

So I think from I guess from our point of view in that sort of application security space, let me speak from that first, right.

I think we can do a better job at collecting more sort of, I guess, runtime information of how applications are being utilized in production and use that to sort of profile your application so that developers can make better decisions when they're fixing something, right? I'll give you a sort of basic example. You might bring in an open-source library that has a vulnerability, right?

But your code may not actually execute that library in production. Well, there might not ... another way to say that is there is no user path that can execute that piece of code, so therefore the risk is quite lower, right? So if you had that context from production in the development process, it could help you triage and prioritize issues that you have to fix, right? So, and then it could bubble up other more important things that are more pressing up to the top that you need to fix right now that has there's an exploit available on the internet for that particular vulnerability so you better fix it right now, right, versus something that can probably wait, do you know what I mean?

So I think at the moment we've got this huge deluge of information and developers need to sort of figure out where to prioritize their time, but if tools can help them do that, I think that's a good thing, so that's sort of where heading in the ... and you've heard of obviously CSPM, right? Cloud Security Posture Management, I would call this ASPM - Application Security Posture Management, sort of a new term.

Paul

Okay, interesting. Yeah, no, I mean I think that's the future here too. I mean we're building a lot of correlation because we of course have the CSPM side of things we have the CIEM and also the threat detection, so we're building correlation across them which I think gives higher validity to alerts and sort of findings which, as you mentioned ultimately, we're all sort of struggling with alert fatigue and you know kind of working through making those sort of issues sound, sorry, making them sort of more important and more impactful so they're fixing the things that are most relevant instead of just getting a ton of alerts. I think that's going to be huge and you know something you guys can definitely really push on especially for the developers, right, because like I mean so many problems with a lot of the source code sort of analysis out there. There's just so many false positives ...

Lawrence

Yeah, absolutely.

542

Paul

which we face, like where we have a services team too that does a lot of source code review and, yeah, a lot of that is actually making sure that the findings are real so some of the correlation around that, I think, can be very useful and giving more validity to the specifics of the findings that you guys find which I think is, you know, the way we all have to go right cause there's not going to be less code written, so we know there's only gonna be more so ...

Lawrence

Well, that's the thing, right, you know you have to ask your question: are you going to write more software? Yes. Are you going to use more open-source code? Yes. Are you going to use more cloud services? Yes, well then you know you better get on board.

Paul

Yeah, yeah, exactly. I mean I think that's the very real reality that we're facing and ... the same with the cloud which you touched on there too, is like we're not going to be using any less cloud in any company that's like not kind of already starting to think about at least the transition is probably going to have a struggle in the future and for everyone else, they're kind of either already fully in the cloud, like a company like, probably both of our companies, I don't know as much about Snyk but newer companies that started in the cloud, and then all those companies that are transitioning partially, I think over the next five to 10 years like it's going to be like 90 percent of the companies are, and the infrastructure is going to be in the cloud and 10 percent is going to be sort of more traditional, but yeah, exciting time to be and I think it's ...

Lawrence

Which is going to keep security professionals very busy, I think, in high demand.

Paul

I agree and a lot of great companies will be built in this space as well, which I think is exciting for everyone, and there's just going to be so much work to do as well, so plenty of room for lots of different companies to be successful also.

Lawrence

Yeah, I think just back on the ASPM but I think it kind of dovetails into CSPM right, there's obviously a lot of overlap there.

You know, for example, getting runtime information, like if you're running an application in production in a container, let's say. You know what code is being executed so why not sort of correlate that back with vulnerabilities or issues that you have in development, then you can see actually right now this vulnerability is being executed in production right now, so that's again back to the prioritization.

Paul

Yeah, and that's actually I think one of the most important things, right? And where a lot of companies struggle right like I've seen, I've worked with a lot of big banks and stuff, and like doing that by integrating like a bunch of different tools together is extremely difficult, and takes a lot of internal engineering effort, and I think in most cases and one thing we always talk to our customers about is like do you really want to invest in your team building security and integrating security software for you, or do you want someone else to worry about that and your engineers can be building what's important for your top-line revenue instead of this, right?

Which I think is a very important point to make to customers because yeah, I mean we should all be doing what we're good at and be focused on building the business in that way.

Lawrence

For sure.

Paul

Yeah.

Lawrence

And you asked me about the future like, I can't have a podcast without saying that, you know, machine learning is going to change everything as well, but I think, you know, in all seriousness, if we can get better profiling of how applications are sort of patched and managed, it's going to help us as security professionals as well to sort of better secure applications like, for example, we have this thing called Big Code Engine which sort of powers our static code analysis for example.

What it does is train itself by scanning millions of open-source projects on GitHub to figure out patterns where if an open-source project had a vulnerability, how was it fixed with what code, and use that to see if it's sort of false-positive or what have you, and help the developer-specific examples on how to patch their code, right, just stuff like that, you know, machine learning has a big place to play in the future, I think.

Paul

Yeah, definitely, definitely agree, and customization of that too, right, because it's everyone's environments or how they handle certain situations is going to be different so I think machine learning is going to be the key to being successful at this problem for many reasons one of those just being the mass amounts of information that you're dealing with, especially when you're a large organization with lots of engineers or lots of source code for that matter. So exciting time and something definitely looking forward to seeing what comes out in the different product spaces as well.

But, yes, I guess that kind of wraps it up, and thanks, Lawrence, for jumping on the podcast. I really appreciate the time.

Lawrence

No worries, Paul, I really appreciate it. I had fun.

Paul

Thanks!

Paul Hadjy
Paul Hadjy

Paul is a technology visionary working across the US, Middle East, Singapore, Korea, and New Zealand to build business in both the private and public sectors. Paul spent over 6 years at Palantir and was the Head of Information Security at Grab.

Subscribe to the Horangi Newsletter.

Be the first to hear about Horangi's upcoming webinars and events, up-and-coming cyber threats, new solutions, and the future of cybersecurity from our tech experts.