Skip to main content
Episode 149

Season 9, Episode 149

Unravelling Trends In Data Security With Danny Allan

Listen on Apple PodcastsListen on Spotify Podcasts

Episode Summary

Are you curious about the ever-changing landscape of data security? In this episode, we are joined by Danny Allan, the newly appointed Chief Technology Officer at Snyk, to delve into the evolving landscape of data security. In our conversation, we discussed his professional background and how he went from hacking security systems at university to becoming a security expert at Snyk. Hear about his experience in dynamic application security testing and the challenges and opportunities of working for large companies. We unpack how controlling human actions can reduce security vulnerabilities, the nuances of running cloud-hosted services, and how the techniques used for static application security testing have changed. Danny explains the importance of considering security aspects during the early stages of software development and how governance has integrated into data security measures. Gain valuable insights into the ever-changing landscape of data security, AI’s potential role in revolutionizing security practices, and much more.

Show Notes

In this episode, Guy Podjarny is joined by Danny Allan, the new CTO at Snyk. Danny shares his fascinating career journey that has taken him in and out of the application security space over the past 20+ years.

They discuss how application security practices like static analysis (SAST) and dynamic scanning (DAST) have evolved, with SAST becoming much faster and easier to integrate earlier in the development cycle. Danny reflects on what has changed and what has surprisingly stayed the same since his earlier days in AppSec.

The conversation digs into the intersections between application security, data security, cloud security, and how these domains are becoming more interconnected as the same teams take on responsibilities across these areas. Danny draws insights from his recent experience at Veeam, highlighting how practices like data immutability and multi-person authorization grew in importance to combat ransomware threats.

Looking ahead, Danny and Guy explore the potential impact of AI/ML on application security. From automating threat modeling to personalizing vulnerability findings based on developer interests to generating rules and fixes, Danny sees AI unlocking many opportunities to transform AppSec practices.

Overall, this episode provides a unique perspective spanning Danny's 20+ year career in security. His experiences illustrate the evolution of AppSec tooling and processes, the blurring of domains like app/data/cloud security, and how AI could radically reshape the future of application security.

Links

Follow Us

Partager

Danny Allan: Do you really want the developer to take a critical issue and hit the ignore button? Maybe your policy changes so that you need two people to agree, maybe the developer agrees with the security person, and so I think that practice of having controls spread out more broadly becomes important.”

[INTRODUCTION]

[0:00:23.3] ANNOUNCER: You are listening to The Secure Developer, where we speak to leaders and experts about DevSecOps, Dev and Sec collaboration, cloud security, and much more. The podcast is part of the DevSecCon community, found on devseccon.com, where you can find incredible dev and security resources, and discuss them with other smart and kind community members.

This podcast is sponsored by Snyk. Snyk’s developer security platform helps developers build secure applications without slowing down, fixing vulnerabilities in code, open source containers, and infrastructure as code. To learn more, visit snyk.io/tsd.

[INTERVIEW]

[0:01:10.4] Guy Podjarny: Hello everyone, thanks for tuning back in. I’m Guy Podjarny and I’m here today with a really exciting guest that I’ve known for many, many years and have gone in and out of AppSec. We’re going to explore all that and now, have the benefit of working with more closely at Snyk, and that’s Danny Allan, who is Snyk’s new chief technology officer, or CTO. Danny, thanks for coming on to the show.

[0:01:31.2] Danny Allan: Hey, I’m super excited to be here. Like you say, I think it’s been 20 years since we first met, Guy, for but I’m glad to be back with you again.

[0:01:39.5] Guy Podjarny: Indeed, I don't know, sometimes it’s like, makes you really feel old when you start talking in decades, you know? It’s like, “Ah, this thing happened a decade ago, was it two decades ago or one decade ago?” It’s like, “Okay, now I’m feeling old.” So, Danny, we’re going to dig a lot into sort of you know, experience in coming in and out of AppSec and all that but before that, maybe just kind of give us a bit of a primer about, I guess, what you do today and a bit of the journey that got you to it.

[0:02:00.2] Danny Allan: Sure. So, I’ve joined Snyk, as you know, as the Chief Technology Officer and I’m super excited about coming to the space. So, be back up and kind of take the career progression if you want to call it that. I started back career in the 90s. I was going to University and my friend bet me that I couldn’t break into the University systems and this was the '90s. It was before you were allowed to do those types of things or they cared about doing those types of things, maybe and so I did that.

[0:02:26.1] Guy Podjarny: So, I assume they catch you as well when you do it, it’s the type of time, not really that much attention was being paid.

[0:02:30.8] Danny Allan: Yeah, and so, they had a – it was a Honeywell CPS-6 mainframe on a Banyan VINES Network but anyway, it was fun. I found some vulnerabilities, I found an issue that you could break into the system and I went to the university and told them that they had this problem and they hired me. That was actually my first job, I was working for the University I was going to and that was a lot of fun.

I did network security, mostly network security, some identity and access management security for the first few years and went from there to a small startup that you probably know called Watchfire, and at the time, they were doing – this was around the .com boom. So, it was moving from the public sector to the private sector and they were doing quality analysis mostly of websites, scanning for broken links and things.

And over the course of seven years with them, that company pivoted from being a primarily quality company to an AppSec company. They acquired a company over in Israel called Sanctum. They had a product called AppScan and so they went from quality to privacy, to security and it became very, very entrenched and worked a lot with dynamic application security testing.

That company ended up being bought by IBM where we purchased a static application security testing tool. So, I got some exposure to that, and really, the interesting thing at IBM. So, I ran the security research team there and it was a very broad portfolio because they did DAST, a dynamic application security testing, they did static application security testing but more than that, they did network security IDS, IPS.

They had web servers, they had all the Tivoli governance things and it gave me a good understanding of the breadth of the security space.

[0:04:07.8] Guy Podjarny: That’s important, that noting that at the time, the IBM security division didn’t exist yet, and so all these things were sort of scattered all over the place, you know within whatever, rational Tivoli web sphere or ISS, et cetera, et cetera.

[0:04:19.8] Danny Allan: It was always one of my frustrations there at GIPO because we would go into a customer and we had the breadth of all these solutions but there is no single security division and so our biggest enemy at the time was ourselves, the salespeople will be competing with one another and I made the argument, if we combine these things together, we’ll have a solution that is unparalleled in the industry.

But it was an exciting time and I don’t regret it for a moment, it was fantastic, I learned a lot about large organizations, how they operate, and the breadth of the security field.

[0:04:48.4] Guy Podjarny: Yeah, no, definitely, there was a lot to do there it just sort of meant that a lot more wrangling internally.

[0:04:54.3] Danny Allan: Yes.

[0:04:54.2] Guy Podjarny: Of those but sorry, I cut you off. So, you’re just sort of going through those journeys which I shared all, like – I guess, maybe kind of worth noting for folks, you know? Like, Danny and I were coconspirators on some of that journey. I came over from Sanctum into Watchfire. We got to work together a little bit in some of the Ottawa and Boston locations and we go a fair bit back and so, some of those learnings were happening together or in parallel, I guess, as we were enjoying and babbling the idea machine.

[0:05:19.3] Danny Allan: Yeah, it was a lot of fun. So, then, I was at IBM for three years and one of the things that was very evident from the breadth of security is that people often were the cause of security breaches and issues and I had this idea that, “Hey, if we can control what people actually do, then we have a better opportunity to control the vulnerable outcomes that occur.”

And so, there is this startup in the Boston area called Desktone, and what they built was a platform that you would have virtualized desktops running in the cloud. Now, that’s interesting but the primary interest for me actually was that if you have consolidated, aggregated desktops all in one place in the cloud, then you have the ability to apply controls to them, so you could monitor and manage users and kind of prevent them from making poor mistakes on their own and so, this company was my first foray, really, into the cloud.

My experience with the cloud prior to that was mostly around virtualization and doing security testing in the cloud but this was building a platform for the cloud and it was very exciting. Our go-to-market initially was to go to market through cloud providers running this. Over time, we became a provider ourselves, which gave me a huge amount of experience in the operation’s side for running cloud-hosted services.

[0:06:38.6] Guy Podjarny: Keeping things secure, not just sort of finding the gaps.

[0:06:41.4] Danny Allan: Well, you know, it’s interesting, I remember many phone calls that went to one, two, three in the morning, when things go down, you’re just on the phone until, you know, the issue is resolved.

[0:06:51.5] Guy Podjarny: Indeed. A good sobering moment.

[0:06:54.0] Danny Allan: Yeah. So, I was CTO of Desktone for three years, and we were ultimately purchased by VMware. So, I had a period of time at VMware, that was a lot of fun. VMware is obviously the dominant player in the virtualization space. At the time, we supported all the hypervisors but that very narrowly focused us even the VMware ecosystem and I had a lot of really useful and valuable experiences there and understanding virtualized networking within.

To see our acquisition, which became NSX and virtualized storage and compute and had a lot of fun there but at heart, I like to go and build things, rather than being a cog in a larger wheel, and so went from Desktone to VMware but then, on to a company called Veeam, which was a data protection company. It was interesting at the time Ransomware was beginning to explode and the threats were beginning to increase against organizations and of course –

Well, I should say, not of course but at the time, Veeam did back up of the virtualized environment, VMware specifically, and so I joined VMware seven years ago and I was there for seven years, and over those seven years, we grew from not only protecting VMware environments to all of the hypervisors and all of the physical systems and all of the clouds and all of the SaaS services.

In fact, when I was there, we launched 12 new products and we tripled the company and size of revenue, we were over 5,000 employees and it was really, really fantastic growth. It was exciting to be there but at the end of the day, I was attracted back to the application security space and here I am, back at Snyk.

[0:08:31.9] Guy Podjarny: Got you back into it and at Veeam, that’s the last sort of section on it going from VMware to Veeam, I guess, got you into data. So, I think, I’m really kind of curious to pick your brain on indeed, the learnings from Veeam. They’re sort of clearly the most recent on it and data security also but the sort of network versus app security. Like, network security versus app security, versus data security, which is – are interesting to kind of compare and contrast, I guess and learning between them.

But before I do that, I think you have the sort of interesting perspective, which I don't know, I guess some people will get when they move around but it’s relatively rare, which is you’ve been in the AppSec space for a considerable amount of time and saw it and learned it and then, left, went to do other security stuff as you’ve described but I guess, not just security but security impactful, infrastructure changes.

And then, now you’re coming back into AppSec and that was we pulled you into Snyk. I mean, for me, I went from AppSec to the world of DevOps and that gave me the sort of, the – maybe a perspective that I think I wouldn’t have had if I had stayed in AppSec around some goodness in DevOps that we can bring into the world of AppSec. I’m curious, like, coming back into AppSec now, what do you see?

Maybe we start from like changes. Like, what feels the same and what feels different between whatever, the scary period of time and go through that ways, you know, like whatever it is, 15 years ago, we’ll call it, and to now.

[0:09:50.4] Danny Allan: Well, what would be the same I guess, I was surprised by some of the things that didn’t change. Like, dynamic application and security testing really hasn’t changed and I made the argument back 15 years ago that static application security testing was better because it enabled you to move earlier in the cycle and fix things faster and so, that hasn’t changed a lot.

But actually, one of the things that is interesting to me is the techniques used for static application security testing have changed dramatically. I remember the complexity of setting that up and kind of the headaches associated with wiring into that last check before you know, when you did your builds and that has become far faster, far better, far easier and so, that was exciting to see.

One of the things that surprised me, I expected there to be more correlation. It used to be 15 years ago that you had all these different silos, you would do your softer composition analysis, you do your dynamic application security testing, you’d do your static application security testing and they're all kinds of silos of activities. I would have expected them to have been more correlated or merged.

And so, kind of one of the surprises was that they hadn’t been merged to the extent that I would have thought they would but – so, many things are the same, many things are different is what I’m finding.

[0:10:59.9] Guy Podjarny: But it’s interesting like the comment on DAST staying the same is interesting because I think I agree that it’s DAST as a practice has not changed dramatically. I’m sure there are people that would contest that. You know, I think, technologically, it has evolved like now it includes a bunch of things like doing that dynamic testing by API. It includes things like whatever better handling go of like, single page applications or whatever the word of the day is for this Java Script base, sort of dynamic pages and so, some elements.

But you know, fundamentally, I think a lot of it is about the same but I think the – almost like the glory days have shifted. You know, when we started static analysis if you had to pick one, you would do DAST over SAST and I think today, you would do SAST over DAST. Like, I think maybe because of that ease that you mentioned, maybe the practicality of being able to run SAST kind of has won I guess, or the complexity of DAST. Does that sound right when you have this kind of fresher conversations with the security leads?

[0:11:58.6] Danny Allan: Yes, a hundred per cent. They would start with the SAST over the DAST and one of the changes as well I would add to that is back 15 years ago, there was less software composition analysis because a lot of people were writing kind of full stack code from top to bottom. They weren’t using open-sourced components in the same way that they are today.

Now, in the security leads that I talked to, not only are they starting with SAST but often, they’re starting with the SEA side of it because of course, application composition has changed over time. I ended up – I wrote an application, a web-based application back in I don't know, 2002 or so, and I wrote the whole thing, top to bottom. I didn’t use any open-source components and of course, now, you would never do that. You would go and assemble that as you’re bringing it to market.

[0:12:40.7] Guy Podjarny: Yeah, and I think that makes sense. I guess that’s the – maybe I feel like there are sort of two things to sort of note to there. One is of course, to some of the adaptation to technology change. At the end of the day, we’re securing what is being built. So, like what is being built or how it’s being built is different than we have. You know, the security industry has to adapt but the second is, I do think as a security industry specific, I guess sort of view or sort of change on it of, I don't know.

I feel like that has always evolved from the manual practice, right? Like, I feel like when we were doing AppScan back then, you know, it was the automation of the manual pen tester action and so, it didn’t start from a tech tool. It started from a manual action of someone, you know, bothering to put in a thousand different – if it’s human, not a thousand but 50-odd values into a text box into accumulate.

Surely, that can be automated and evolving it into sort of DAST. While I think SAST came more with sort of automation in mind right away. I guess, there was probably a practice of code review but I think people didn’t think about it as a scalable practice maybe, to begin with. So, I don't know if that makes sense and I’m kind of butting in a little bit to the journey but it’s interesting to sort of think about the changes that are because of external circumstances versus the changes to the AppSec industry that has been internal.

The correlation comment that you make is also interesting. Like, why, if you were to sort of guess, right? Instead of coming into it like, you know, what do you hear about, like, why? Like, why aren’t we? Clearly, we still need to correlate. Clearly, nobody likes duplicates on it, you know, prioritization, clearly, you know, as vivid the pain as ever. Do you have a sense of like, why correlation isn’t maybe at the pace you would have expected it when you left?

[0:14:16.5] Danny Allan: Well, I think it’s simply because it’s so hard to do. You're coming at it from two defend ways and it’s hard to connect those. You’re seeing it from the back of the picture to the front of the picture. I mean, if you're looking at a painting or a mural of things, it looks very different from the front than the back and connecting those two things together is very difficult.

Now, I think we’re about to change that quite honestly. I think using artificial intelligence and some of the techniques that are available to us now, that were never available to us in the past will change that but you think about something really simple like an input to an application. If you’re doing that from DAST, you’re seeing a cookie or form field, or a query string or whatever happens to be a header of an HTTP request.

And then, comparing that to the actual code in the many, many different ways that you can write that construct in a code, it’s hard to connect those two dots. Certainly, by name but even that, I mean, applications are assembled in real-time. So, it’s a hard problem to solve and I don’t blame the industry for not solving it. I just think they’ve operated in these silos and we now have an opportunity to bring the two together.

And ultimately, it’s not, it’s not, Guy, it’s not just about bringing the two together. It’s actually about making the organization more efficient. You don’t want to report two findings that slow things down and by making them more efficient, you can prioritize the things that you know are an issue as opposed to the things that you think might be an issue. So, it makes it more efficient and it enables you to go faster but gives you a more definitive view of the security of what you’re building.

[0:15:46.7] Guy Podjarny: Yeah. You know, we talked a little bit about sort of inner changes that are expected or unexpected. What surprised you for the better? Sort of, coming into it, looking now, you know, a bunch of things are the same, maybe or sort of, you know, kind of the same ladies, the same sort of, you know, group of people or practices, you know, just maybe different percentages.

But I guess you did note SEA to be a brand-new practice but what has been most impressive? What has been most like, positively surprising or you know, incline, positively inclined insight that you’re now sort of seeing?

[0:16:15.7] Danny Allan: Well, two things I would say. One is, that it’s moved far earlier in the process. We did SAST in the past for example. However, it tended to be at the end of the cycle when you were building software and now, we’re doing it within PR checks and we’re doing it much earlier in the cycle. We’re doing it in the IDE with developers and I think that is a very exciting positive change because of course, the earlier you do it, the more proactive you can be, the faster it is, the better it is.

And secondly, I would say, the speed at which that analysis is done. I remember doing string analysis and these long trees of tracing things from source to sync, and it would take forever. When we did analysis of applications, you know, way back, it would take not just hours but sometimes days in those big applications to do the analysis and now, the way that we’re doing translation of software into graphs and trees and very quickly doing the analysis, it becomes actually practical to do it as part of the cycle, as opposed to slowing things down.

So, both the speed and the timing at which the analysis is doing has impressed me and then, the other thing is I think just the realization, I guess of the market, of the benefit of being dev first, doing this earlier in the cycle. Before that was always a battle, you were battling people, “Hey, you want to do it earlier and earlier?” Now, I believe that’s just the accepted norm of the market that, “Hey, we should be doing this as early as possible in the cycle.”

[0:17:41.8] Guy Podjarny: Yeah. I guess I can relate. Clearly, I’m sort of, you know, part of that sort of conviction. The path on it has been very evident, even over the course of sort of Snyk’s existence. You know, maybe we can help kind of contribute or nudge at that change. Thanks for the kind of the findings again. It’s just like, it’s an opportunity, it’s one of these kind of fresh perspectives, you know, of coming back and sort of seeing you know, what has changed and you know, what isn’t the same when you walked into the house.

So, I’m curious, the other aspect, I’d love to tap your brain from the journey is just sort of the distinction between these domains, you know? Like having moved, sometimes, you see a lot of people that move from – I don't know which one is the dark side but like, from the practitioner the vendor. I guess, the vendor is the dark side, yeah, the vendor is the dark side, to the sort of the application or you know, you’ve sort of had the chance to be on the vendor side.

But dealing with you know, network security delinquent data security, the application security. I guess, any intersections between them or sort of learnings that you think are worth noting between these different domains, you know, areas in which you know, we can learn from one practice, something we should bring into the other?

[0:18:39.4] Danny Allan: Well, the different domains are very much interconnected. You hear a lot about DSPM, data security posture management and CSPM, cloud security posture management, and ASPM, application security posture management, and I think of them as distinct things actually. I’m coming from a company, from Veeam, seven years there that was very much data-centric.

And so, you’re looking at production data and protecting that and understanding how it was deployed and how it was configured and then if you look at CSPM, I know the C stands for cloud but I think a lot of that around the configuration of the operations as opposed to the data itself, like at Veeam we’re protecting the data but then you look to see SMP organisations in this but the configuration and application security posture management being about how things are built.

I do see, I won’t say a collision course but very much a complimentary connection between these different elements and I think the organisations that will win and the value that will be added is how do you take these things, put them together in a way that actually gives clarity to the organisation in prioritizing and making sure that they end up at the end of the day in delivering more secure services. I’m not sure if that answered your question.

[0:19:50.9] Guy Podjarny: I think it’s a really good observation on it and it’s interesting to acquaint this to what’s happening in sort of the DevOps land because I think a lot of times these same lines used to be much more blurred in terms of who handles them. It used to be that you had someone dealing with the configuration, you know what – you’d kind of open a ticket and the specialized team would set up a system and configure it.

And you’d want data, you’d open a ticket and a different team, you know, will deal with that data and today, you know, they’re all kind of all API pull away or a cloud-config away and oftentimes, the same individual, a developer or some sort, you know maybe varying between an app developer and a platform developer that would vary. So, it’s interesting, it’s a good observation I think to say that as that is happening, almost the security industry’s response to that would be to evolve these securities post management.

And that proceeded by fill in the blank to doing it but in practice, they might overlap. I am curious though like, because you look even within these SPNs, I mean, there’s some things that I think that I can sort of think of as we learn from one to the other but like are there – do you see learnings from you know, access PM, whatever it is, CSPM moving into DSPM, moving into ASPM or vice versa on it?

Like I guess, how do you see the flow of practices or are they sufficiently distinct domains that you actually don’t think they’re – you think the practice is surely quite different?

[0:21:08.5] Danny Allan: I think the practices will end up being different – will continue to be different for the time being, it’s my own kind of personal opinion. I do think there’s a collision course between DSPM and CSPM, the data and the configuration. They tend to be more operational and more in the run time or the DevOps and I know everyone that says, “Hey, developers are going to take over the operating things.”

And I know there’s different opinions on this but the way I think about it is developers typically like to build. They prefer not to have to run. You know, sometimes they’re pushed into it and in some organisations, they do. They not only build but they run but I expect the running of things to be the ones where the merging happens first and probably the building of things separate but having them very much complimentary in my mind is important.

You’re going to want to have the collaboration between the different domains and maybe eventually, they will come together but probably not in the timeframe that anyone here thinks. It might be two years, it might be 10 years. I use the analogy, sometimes I go into a grocery store, I want to pick up the groceries, I don’t want to bag the groceries. Developers want to build things, they don’t necessarily want to operate things and so I do expect to see the separation.

I just think we need more collaboration, more partnership, more interaction between the teams and that’s really what the industry is moving towards now.

[0:22:25.5] Guy Podjarny: Yeah, I think that’s fair. I guess I sometimes think of it as like centres of gravity. It’s like you know, there’s some things in which the sort of the source of truth that everything revolves around is like what’s happening to the systems. They’re running, they’re being operated, what’s going on, and so for that, you come along and that maybe brings you into sort of seeing DevOps and SecOps being closer to one another. They’re necessarily SecOps and AppSec, you know?

Like, it’s almost like, which part of that word do you want to connect and similarly with data. You know, you see a question as well, the centre of gravity clarity is the data and so is cloud the right scope for it or should it be because data flows between these different entities? And so, as long as the centres of gravity would be different, which I think is sort of similar to you’re sort of saying something similar from a human perspective of people’s preferences or where their attention is, which create those different centres of gravity.

[0:23:13.2] Danny Allan: Yeah, the data comment is interesting because when I came to Veeam, I always thought of data as databases. In my mind, it was all structured databases and I came to realize that data can mean anything that the organisation wants it to be. I mean, it’s certainly structured data and unstructured data, it was part of it but applications were a part of that, network sort of actually a part that.

And so, I do think there is an evolution of who is managing those different areas within an organisation. They just become centres of gravity. You have your, what used to be DBAs that tend to gravitate towards data classification and asset management and those kinds of things. You have your IT teams that gravitated towards the configuration in running and operational side of things.

You have your developers obviously, that are continuing to develop but doing more of the other items as well. So, I don’t know, it’s a great time to be alive. It’s interesting to see the evolution of the industry.

[0:24:00.6] Guy Podjarny: Let’s talk a little bit about data security, you know, and sort of dig into that. So, I wanted to pick your brain as someone who’s lived it you know, for the last sort of seven years. I guess, what are the key tenants right now? What do you, when you think about like the most important things when it comes to data security and maybe if there’s a perspective of like in your seven years, I’m sure data has clearly become more and more important kind of aspect of the ecosystem, is that centre change?

Were there sort of new security attention areas over those seven years that you feel have gone from marginal to central?

[0:24:33.1] Danny Allan: Two things I would say happened in the data space over the seven years. One was, at the beginning, Ransomware wasn’t nearly as big of an issue and what happened over the seven years is Ransomware came to the forefront of probably the most significant threat that organisations were facing. I mean, I know we talk about advanced persistent threats and vulnerabilities and CVEs and all of that.

But in the organisations that I talked to, the Ransomware threat was by far the most prevalent. The statistics were off the charts, almost every single organisation I’ve ever talked to has had at least one attack and so that resulted in some fundamental changes in the way data was managed and probably primary in that was the immutability of the data. So, when you have your systems, whether it be code bases.

You know, your application services or your database is structured and nonstructured data or your network configurations or your services, number one was to take a copy of that and put it in an immutable location and even the concept of immutability changed over time because initially, immutability was on-premises but the Ransomware would actually get smarter with that. It would go and look for the storage systems.

It would take root access and it would try to delete the so-called immutable systems and so immutability changed from being something that was on-premises to something that was up in the cloud outside of your control. So, even if you were an administrator, you couldn’t go and delete something that was in the cloud and actually, by the end of my time at Veeam, we were sending two exit bytes of data into the cloud on a yearly basis.

It was a massive amount and a big reason for that was protect the data, make sure that it can’t be destroyed or altered or changed. The other thing that changed I would say over the period of the seven years was the controls along with that. It used to be the administrator had full access for everything and over time, you saw a lot more multi-person authentication. You didn’t want to give anyone the control to do any single action.

And so, you saw a lot of multi-person authentication or four-eyes authentication, it depends on what you call it, for all of the sensitive actions not just deletion or changing of policy but a lot more governance in the protection of that data over time.

[0:26:37.6] Guy Podjarny: That last point was a really interesting one when you think about AppSec. I mean, do you think would you anticipate that the same thing happens like, I guess authorization oftentimes, I know identity is probably its own domain next to it but authorization is something that in AppSec and this sort of configuration very much comes close to those worlds. I guess on the login site, we’ve seen you know, two-factor authentication or something purpose like that that have gone further up.

Do you think like has the practice of that sort of multi-person, multi-stakeholder authorization, is it becoming easy enough that you could see it spread into assets that are maybe not quite as dramatic or as central as like your database and becoming a broader practice?

[0:27:18.9] Danny Allan: Yes, I think there is opportunity there. If you think about you know, a vulnerability that’s found within an organisation fell off for me, now I want to fix it, and they say, “Ignore it.” Do you really want the developer to take a critical issue and hit the ignore button? Maybe your policy changes so that you need two people to agree, maybe the developer agrees with the security person.

And so, I think that practice of having controls spread out more broadly becomes important and maybe even the decision of what those things are gets handed off to an ML-type system that says, “Hey, these things are of such severity that I’m not going to allow it and these things are of less severity and an individual can make a decision on them.” But I do expect to see that concept of two people turning the key to allow an action to become more prevalent in many different disciplines including application security.

[0:28:10.8] Guy Podjarny: Yeah, and it’s interesting to think about equating that to code review to some extent that is actually what we’re describing over here. It is actually totally the standard practice for checking in code. It is like you’re checking in code, by all means, you can be amazing. Someone should look at it before you do it anyway and that’s a typical high-quality team kind of best practice.

Why isn’t that being done for security issues? So, yeah, maybe an opportunity for some change. There is a lot like each of these things is like its own kind of rabbit hole that we can go down on it. I know that you’ve been thinking a lot about AI and you know, we’ve already referenced it I think like five times, you know? It’s like potential solutions, you know you can use them out for this, you can do it at – and I think it’s because you know, truthfully it’s impactful in various ways.

Maybe fine, you have all that sort of – we talked a lot over the past, we talked a lot about what changed and maybe sort of getting into the present. I know today at Snyk, you know you’re spending a lot of time on AI and on where it can lead us. I guess, what are your thoughts? Like, what’s the topic sighting kind of paths that you think it would unlock? Like, feel free if you want to sort of dig further into stuff that you’ve already mentioned or sort of new ones.

[0:29:14.6] Danny Allan: Well, the great thing is that Snyk is already using AI in a number of areas that I think is super valuable like just vulnerability identification is something that the deep code engine is using AI on it. I think continuing to iterate on that but if I look at kind of new and emerging areas that are interesting, one would be around asset classification. There’s a whole category.

DSPM actually as a category is mostly just about looking at all the data, classifying it, and making sure that the right people have the right information and doing all the identification and classification and prioritization based on that data. I think there is an opportunity to do something similar using ML techniques in the application space. In a standard organisation, they probably have thousands of repos and tens of thousands of different components within those repos and it’s a fairly manual and difficult task to figure out what all those things are.

So, imagine a world where you have some classification system that goes and identifies everything within the organisation, classifies it for you, filters it, prioritizes it, and assigns it. There is just a lot of opportunity just in the classification space using large language models to help the organisation be smarter about what they have. Another area that I think is super interesting is around threat modelling.

Threat modelling has been around forever. If you could see my bookshelf behind me here, I have a book on threat modelling from 20 years ago but very few organisations do that because it tends to slow down development. It’s hard to do, it tends to be the security practice, not the development practice and I think, well, using the modern techniques of static application security testing, we can understand the data flows in ways that we could never do in the past and could we automate using ML threat modelling for organisations?

Maybe we can’t bring it a hundred percent of the way there but maybe we can bring it 95% of the way there and then have developers iterate on the models that have been created for them. Not only does that help the organisation do more comprehensive threat modelling but it actually helps inform and prioritize the actions that they’re going to do based on what they have within the organisation itself.

Another one is just a human element. People are people and something that interests you may not interest me. So, if you and I got the same results of vulnerabilities that we should be addressing, I would be interested outside of you and I like knowing Guy probably is interested in fixing, I don’t know, sequel injection vulnerabilities and Danny is drawn more towards buffer overflows and he’s in unmanaged languages.

I think there’s actually an opportunity to use AI to understand human behaviour, which then drives learning and education and certification and focus points within the organisation at a human level. So, I mean, there’s a dozen different things I could think of but I think AI and machine learning and I’m being careful at my use of those words, can be used in many different areas. The generative AI specifically, Snyk is already doing this.

AI fixes. Generate the fixes for the developers or generate the rules that we use to test for vulnerabilities. Right now, that tends to be a manual effort. If you look back in the AppScan days and I’m sure even at Snyk, you have really smart security developers or security researchers that are creating the rules. Could you have an AI engine actually iterate on those rules because a rule that works for one person might not work for another person?

And so, it’s going to dramatically change this industry in ways that I think you and I can only begin to imagine at the moment and that’s why I’m so excited actually to come back to the AppSec space.

[0:32:48.2] Guy Podjarny: Yeah, I think all of those are spot on and you’re right, you can probably sort of spell out a dozen more pretty easily. I like, just in light of the conversation we just had, you know it’s interesting to think about threat modelling and just sort of harken back a little bit to the doubters that we sort of seen about static analysis 15, 20 years ago you know, where people basically thought static analysis cannot happen or cannot succeed because just kind of encode it as an NP-complete problem and you can never do it perfectly.

And that is almost the sort of assumption because you can’t do it perfectly today, you can do it later or that it has to be done perfectly to be valuable. Fast forward to today, static analysis is sort of it’s alive and well and it’s far from perfect but it is valuable enough that everybody is using it and embracing it in various ways. Today, you look at the code it’s like yeah, but can you really? Like the words is sort of the threat model, can you really do that?

I say, “Well, actually maybe we sit here in 10 years and talk about the same type of transition of the beginning.” It is clunky, it took a while, it was not terribly kind of valuable but as we sort of built it up and as we learned it, can we get it to a place that it's automated? But your point about the human changes is really interesting, sort of the picture that comes to mind is the – it’s almost like the Spotify DJ, you know, sort of pick the music I want to hear right now.

It’s kind of almost pick the vulnerabilities that I should be told about in ways that are more than just you know, the ones that kind of need to be fixed but also the ones that would trigger my curiosity that I would be best equipped to handle, etcetera, which I think is really, a really interesting and slightly mind-bending kind of path that for security people to think. Cool, well, Danny I think there’s a ton more than we can dig into over here.

I think we’re sort of running out of time. I guess, the good news for our listeners is you’re going to hear, you’re going to get more opportunities to get Danny’s insights and inputs, so more on that in the episodes that are coming and Danny before I kind of let you head out, you know, as you know, I like to ask sort of an open-ended question at the end and we just talked about AI. So, I think I would just stick to my question from past recent episodes, which is you know, if you could automate away any part of your job to AI if you could delegate that to AI, what job would that be?

[0:34:58.1] Danny Allan: It would, without a question, be the administration of my day-to-day calendar and email. One of the things that is interesting in coming over to Snyk is everything goes through Slack and it’s hard to know sometimes what is the ephemeral discussions versus the important discussions versus the things that need to result in a calendar invite and if I could have an AI engine that would help me with the administrative side of my life, that would be probably the most valuable thing that I could take from it at the moment.

[0:35:28.1] Guy Podjarny: Yeah, and it’s amazing how this question has kind of been leading people to a variety of levels, like whether it’s Slack or the calendar or the email, whatever it is, we just basically want to sort of focus on the substance, which is interesting and I guess I wonder as humans, I feel the same. If you sort of ask me the question, it’s probably my natural tendency as well.

I’m just sort of curious how much of that that we’re used to, that’s the pain we see, and we still don’t see the potential. We don’t, you know, still think about the internet of old and not how would we find I think maybe or sort of find some piece of information, think of it as a very big like encyclopedia that we can get information. We don’t envision whatever the e-commerce sense sort of right sharing and you know, other comparisons to it. I guess we’ll leave and see.

Danny, thanks for coming onto the show and thanks everybody for tuning in and I hope you’ll join us for the next one.

[END OF INTERVIEW]

[0:36:22.8] ANNOUNCER: Thank you for listening to The Secure Developer. You will find other episodes and full transcripts on devseccon.com. We hope you enjoyed the episode and don't forget to leave us a review on Apple iTunes, or Spotify and share the episode with others who may enjoy it and gain value from it. If you would like to recommend a guest, or topic, or share some feedback, you can find us on Twitter @DevSecCon and LinkedIn at The Secure Developer. See you in the next episode.