Skip to main content
Episode 40

Season 4, Episode 40

Large-Scale Digital Transformation With Brian Sodano

Guests:

Brian Sodano

Listen on Apple PodcastsListen on Spotify Podcasts

Brian Sodano: “When I worked in IoT I never believed that voice stuff would be real five years ago, and now I have an Alexa in almost every room in my house. There's not going to be any shortage of jobs for security professionals anytime, ever. There's a lot of change going on in the industry right now. There's a lot of players in the market, there's a lot of tools, there's also almost a lot of noise just in the market itself, and I think as a developer it's a little confusing. One of the things we had to figure out was how to get the developers to care about this.”

[INTRODUCTION]

[0:00:33] Guy Podjarny: Hi, I'm Guy Podjarny, CEO and Co-Founder of Snyk. You're listening to The Secure Developer, a podcast about security for developers covering security tools and practices you can and should adopt into your development workflow. It is a part of the Secure Developer community. Check out thesecuredeveloper.com for great talks and content about developer security, and to ask questions, and share your knowledge. The Secure Developer is brought to you by Heavybit, a program dedicated to helping startups take their developer products to market. For more information, visit heavybit.com.

[EPISODE]

[0:01:07] Guy Podjarny: Hello, everybody. Welcome back to the show and thanks for joining us again. Today, we have Brian Sodano from Liberty Mutual. Welcome to the show, Brian. Thanks for coming.

[0:01:13] Brian Sodano: Thank you for having me, Guy. I appreciate it.

[0:01:16] Guy Podjarny: Brian, we have a whole bunch of topics to cover. Before we dig in, can you tell us a little bit about yourself? What is it that you do, and how did you even get involved in security in the first place?

[0:01:27] Brian Sodano: I've been in the software development industry for about 20 years. I've always been an engineer, so I consider myself an engineer. I don't get to write a lot of code these days, but –

[0:01:36] Guy Podjarny: Yes. It's that engineer's heart.

[0:01:36] Brian Sodano: I have my side projects, so that keeps me busy. I've always found that security is actually a very important aspect of this. I've watched it evolve over a long period of time from anything from physical security down to AppSec stuff. I've always been part of the process from either – I remember 20 years ago, setting up servers and physical stuff and worrying about actual physical security, all the way down to now. I'd say I got very into this a few years ago. I worked at a small cybersecurity startup that was actually here in Boston.

I got very involved with analysing different vendors in the space. Static security, pen testing, dynamic security, emerging runtime security market, looking at all these different aspects. I found it fascinating because there's so many different angles, and everyone has their different take on what's important and how stuff works. There's some elements and essential stuff.

I came to Liberty Mutual about two years ago and I've been looking at ways to improve that there, while working on a digital transformation project as part of their platform, which I will gladly talk more about too.

[0:02:35] Guy Podjarny: For sure. So, you went through this great journey in your engineering, and I love that. I guess, just as a cycle, you also have done about maybe still run the local Node.js meet-up group here?

[0:02:46] Brian Sodano: I did. In fact, that's where I first met you. It's been about five years ago, now.

[0:02:50] Guy Podjarny: It's been a little while there, but I seem to recall you had a security interest then as well.

[0:02:56] Brian Sodano: It's funny, first of all, I'll never forget that you showed up and you pinged me out of nowhere and said, “Hey, I'm going to be in town. I want to talk about this stuff.”

I'm like, “Okay. I don't know what this is, but it’s fine.” Security had become a very popular thing. I remember two things from that meet-up. One was I asked you, I said, “Is this like NSP? Like, Node security project?” And your answer was, “No. This is way better than that.”

[0:03:21] Guy Podjarny: Good to hear I was confident, even back then.

[0:03:23] Brian Sodano: You were. I said, "Okay. We can go talk.” Basically, Node.js meet-up in Boston is this monthly-ish meet-up. Sorry guys, if you're listening and you're at Node meet-up, I've been slacking a little bit. I've been busy. But we have regular meet ups. I think that when one was security-themed and you said you'd come in. The second thing I remember by the way, was you had the little –

[0:03:43] Guy Podjarny: The magic wands?

[0:03:43] Brian Sodano: Magic wands. Those little plastic things that you roll up and then you throw it up in the air and a magic wand appears. My kids still have a bunch of them at home, believe it or not. We found some when we moved and they're still throwing them around.

[0:03:55] Guy Podjarny: They continue to be our – I like to say that, “If we've achieved nothing as a startup, we've perfected swag with these magic wands.”

[0:04:01] Brian Sodano: You need more magic wands. We've got to bring them back and keep doing them.

So, one of the things that I found very interesting about that, also as an aside. By the way, this is not a plug on Snyk, I swear. The audience really resonated with what you're talking about at that meet-up. You're talking about how Snyk works, how it is very developer-friendly. I don't think it was so much that it was a security software. I think it was the fact that you were actually talking to developers as a developer, and showing them how to do this in the code and going through.

I think they were like, "Okay. This is super easy. This makes sense. I understand this. I could see where this is going to evolve. It's easy to put it in my processes.” It really hit me at that point, I was like, “I think they're on to something." I think about that over the past few years as I've looked at other tooling and stuff like that too. Because I think the entire security market as I've looked at over the past three to four years is so tailored towards certain audiences and certain end games of what people are really looking for, and what it is that they need to support as part of their stuff. But it was really the first point I saw somebody really seriously targeting the developer audience.

I took that. I remember, I got tremendous feedback on that. “You need to have more developer-oriented stuff.” Actually, it's funny, because we really talked to and I started gearing towards other companies when they started coming in. “You really need to start talking about the APIs you offer and the kinds of ways you can interact.” You did change my mentality a little bit about how to run that meet-up, which was good. It was that great turnout, that great showcase, but I think it was really resonating with the developer that really drove that stuff.

[0:05:31] Guy Podjarny: That's awesome. First of all, it's awesome to hear that it left a good impression. We got a chance to maybe move this back in, which is this whole theme of the developer and security has really strengthened over those years since that talk way back when. Maybe, let's dig into this one for you. You come into Liberty and you're not in a security title. You come in to do really a digital transformation project and change it. Tell us a little bit. Paint a bit of that picture and what's the scope of the initiative and how does security play a role in it?

[0:06:08] Brian Sodano: So, Liberty Mutual, has for the past two years undergone what's commonly called a digital transformation. Folks who are not familiar with that, they were operating in a very waterfall software delivery model, they weren't necessarily following Agile practices. A lot of things were tied to big, long delivery dates, project-based. They had a lot of analysts write up a lot of papers and make these project plans and deliver stuff. It was slow. It was essentially, in order to deliver new functionality, it was a very difficult transition to be able to actually get stuff out the door and move stuff in.

They moved to Agile methodology. They moved towards a very developer-centric model and they shifted the way in which they work. We're very similar to a Spotify model. You have product owners. We have development squads. Their task is now to maximise customer delivering impact as we go. Everything is customer-centric, everything is customer-focused. The teams are consistently looking to deliver the right kind of value outward.

One of the reasons why they're doing this is, in this industry, they're looking for central operational efficiencies to be able to drive more adoption of folks, and to be able to buy insurance online. We are certainly a very successful business for getting folks to come in and work through agents and partners and call centres and reps, but sooner or later the customer demands. I can think of younger folks and millennials that don't even want to talk to people on the phone.

[0:07:32] Guy Podjarny: You didn’t want to go online somewhere, right?

[0:07:34] Brian Sodano: Correct. I mean, look at what insurer techs are doing. You look at other startups in the space, in FinTechs. They're gearing everything towards online. They don't have the giant distribution network that we have going for us, so they're making a shift for the benefit to that. As we do that, as we start to drive through, you look at these different teams that are building that. We have a bunch of teams that are working down here in Boston and up in New Hampshire, Seattle, Ireland, and they're looking at ways in which to engage the customer faster.

Now, what's funny is typically most people wouldn't think to engage with an insurance company very often. I mean, how often are you going to go do this? The name of the game is speed to attract them in from a sales, point of sale perspective. Able to draw them in –

[0:08:16] Guy Podjarny: Capture some attention.

[0:08:17] Brian Sodano: Correct. Of course, price matters in this, and there's other factors that go into that. But once you do that, there's also the speed factor and convenience, and I have to deal with my insurance company. I have to make payments, I have to file claims, I want to have a pay-out. What is it that you said you're covering?

In order to transform those particular experiences, we're developing software super quickly and trying to see essentially in an Agile way, what sticks. We're constantly testing and measuring. We're constantly throwing stuff out there. As you can imagine, a lot of this means that stuff is changing all the time. When you start getting in that environment, and we also embrace an open source mentality, moving from a lot of primarily Java proprietary stacks into a JavaScript open source community, full stack.

[0:09:04] Guy Podjarny: Sounds like a wholesale change there?

[0:09:06] Brian Sodano: It was a very wholesale change, but as we made that change now you're opening up a nice broad ecosystem. Which on one hand is great, because you have access to all these commonly used libraries, and you cannot reinvent the wheel every single time. The con is that there could be potential vulnerabilities that are opened up in these particular libraries as well as new methodologies in which we're deploying software while we're throwing it out into the cloud, and different mix methodologies of hybrid environment as we move into a new way of working.

What's been interesting and what's been a continuously evolving way in which we've operated is the best way I could say this, is when you have the market teams and the digital group that we're part of, continuously pushing out these changes, and they're constantly churning through it. You don't have these big project plans or these big things anymore that you can hand over to your network operations. Your data centre folks said, “I need to provision this kind of hardware to go through these things. Here's my security plan.”

[0:10:06] Guy Podjarny: Kind of fluid force. There's no gates, there's no review points as much. It's continuous.

[0:10:11] Brian Sodano: Correct. It is a continuous change deployment. Everything that has to happen there, so we have to come up with a new way to operate. I would love to tell you that we have figured everything out. We have not. We are constantly re-evaluating the best ways to operate both with our security partners, our global cyber security group, as well as our SOC, getting the alerts and understanding who is responsible for what.

It's interesting. I think the tools that we can introduce from this market delivery perspective to help really, literally, the shift left mentality of developers do more have immensely helped to help shove down those catching things, essentially, before they even get off a developer's machine. To be able to understand what library choices that we use from an architecture perspective. But we're also continuously looking at the best kinds of architecture patterns and practices for deployment as well, and how we actually work with our partners.

[0:11:06] Guy Podjarny: So, this is a fascinating transition, and you're describing the change of really everything. I know about how do you operate. I think you rightly describe this as changing how we operate. If we focus on security for a moment, you're inside and your title is director of engineering, right? The title isn't a security title, and you're describing security activity and you're talking about shifting left and building those security components in. From an organisational perspective, how has security changed from within the company? Is there a separate security team that's a part of this digital transformation? This like, digital Liberty Mutual? Is it the security team that's learning - how do they adapt to this new surrounding? Security responsibility, instead of trying to enumerate the options, how is that being handled in that context of all this big change?

[0:12:06] Brian Sodano: It is a brave new world in terms of how we're doing this, so a lot of the drive begins with, what is it that we're really doing to the customer? As we keep pushing that, we've had to evolve and understand and have certain people assume certain roles. We have the concept of what we call solution engineers, or more or less like a solution architect. It's the same idea. A lot of those folks essentially have taken some of the leads from a market and digital delivery perspective, understanding the kinds of risks that we're going to be throwing out there, based on what it is that we're making. Whether that be writing to web clients or chatbots, or text SMS interaction, along with our new web apps, and then helping to work on new plans that essentially didn't exist in this continuous deployment model, to be able to put together the kinds of checks we need.

For example, if we have Snyk as part of our CI/CD pipelines, that now has become our responsibility, because previously we would have thrown this in a monthly release cycle. It would have gone through all –

[0:13:13] Guy Podjarny: Someone would audit.

[0:13:13] Brian Sodano: Somebody would have checked all this stuff and checked all the boxes and said, “Are you doing all these things? Yes or no?” When we said, “We're not doing this anymore, we're going to deploy at will and at demand,” we had to come up with our own methodologies to be able to incorporate back into this. We are taking lead on this.

[0:13:29] Guy Podjarny: Was that a conscious decision? So, there was this set of, “Hey, from a compliance perspective, or just the security policy, here are the things that needs to go into a release, or whatever code that got shipped into production and code that touches private and personal data that you touch. How will you be satisfying it?" Or has it been more the dev team being security-minded because it's a different perspective, a different breed?

[0:14:01] Brian Sodano: There's the aspect of how we chose to go with an open-source ecosystem, a very popular one too. You talk about full-stack JavaScript. We're on the hook for understanding the kinds of vulnerabilities we're continuously bringing in or potentially bringing in as part of that. There is another aspect where we're trying to figure this out now too. I said, teams are moving into the cloud, you get into a dynamic security aspect. That's been a joint effort between a centralised security group, as well as partners that we have that might be maintaining like a WAF or application firewall, rule sets and scanning that go along with that, as well as bending those rules and modifying them to meet our needs.

[0:14:46] Guy Podjarny: These are groups that are – these partners are the same teams that would have secured the pre-digital transformation teams? Or these new teams that got formed for this purpose, or new individuals that got tasked with –

[0:15:00] Brian Sodano: They are the same teams that existed, but they've evolved. They have become a newer entity on our global cybersecurity group that exists within our world, and their role is essentially to still take on this centralised security response in an incident management aspect. Where we've had to come together is a newer understanding of the architecture that we're proposing that we're doing. You talk about things like moving into the cloud and serverless. You talk about getting rid of giant monolithic applications that are much easier to manage from a security perspective, because it's one spot, and everything's there. As we move into service-oriented architecture, you can call it microservices, or you can call it whatever you want. But essentially, as you move into the service-oriented architecture in the cloud we are redrawing out the ways in which we're inter-operating.

What we found is super interesting, is that there isn't really one side or the other side. There's a lot of shades of grey that go in between, both of these sides. There's granular and fine-grained abilities that some of us want to have and not, from a security and centralised security group perspective they want to know if there's a potential incident or there is a potential problem, or if there's a very broad scale vulnerability, and be alerted to it, and understand that somebody is going to be looking at remediating it. Or whether they are going to be involved or whether they'd have to get us involved, everything like that.

But there's a lot of fine-grained detail that goes into what we're implementing all day long, and boldly speaking we outnumber them. We have several hundred developers in the digital group alone and over a thousand developers inside the US alone. They are a security organisation that is centralised doesn't have that many folks. It's a much smaller ratio. I don't know if it's 100 to 1, but it might be, in terms of that size. So, how do you operate in this, knowing that the developers are essentially now pushing and changing everything as a growing force and have the capabilities to do this too? Where do you draw the line?

We've worked to a new model where there's a little bit of the central group, and essentially what their needs are, and then there's a group that's evolving under the market level or the digital level, say under me, where we have security champions and we have dedicated folks that are involved in part analysis, part plan, part architecture. It's a little bit of blur. But essentially, it'll boil down to procedural dev ops automation things, anything that we'd be doing to essentially carry out those checklists. I think it's just going to keep growing as we keep evolving.

[0:17:35] Guy Podjarny: So, this would be – to echo this back. Within the digital group there will be, or maybe there are DevOps entities. There's somebody there that is more central but not security-dedicated that focuses on developer empowerment. There's the security, the central security entity that reasonably has the same concerns regardless of whether it's on new or old infrastructure. If it's a vulnerability, it needs to be handled. But then for this new world, this DevOps team needs to take on, or is taking on some more of this responsibility in coordination with the security team. Did I hear that correctly?

[0:18:14] Brian Sodano: Yes. That's about right. It's a little bit more split up than that, and I don't need to get into the details of our organisation that likes to shift around as things do.

But there's definitely needs from, like I said, from that first response perspective and from a global, is this going to be a problem from a customer perspective that we need to really be concerned about? Essentially, rolling up to our CISO versus the roles that we have to help enable the functionality that we're driving and we're pushing.

It is a little bit of a self-elected, self-nominated. “We have to do this. We don't have choice.” As soon as we keep expanding this channel.

[0:18:53] Guy Podjarny: Well, you made a decision to embrace the technical platforms, or you made the technology choices. Given the fact they're different than past technology choices, you have to assume some responsibilities.

[0:19:07] Brian Sodano: It's like, when we have that freedom, we have to pay that price a little bit, right?

[0:19:10] Guy Podjarny: Yes. It goes hand-in-hand. So, you're doing. I think this process you describe is fascinating and it’s probably similar to many other digital transformation initiatives. What would you say are a couple of your key learnings here? Things that if you look back at the last year or two, you would have done differently, or after 70 durations, you hit the mark. What tips do you have to somebody else going through this same journey to spare them a mistake or two?

[0:19:40] Brian Sodano: One of the things we had to figure out was how to get the developers to care about this. We didn't have dedicated security folks. We have some people that care about it more than others but we had started a guild concept internally. It went how you would imagine it went, there was a lot of people that were like, “I really like UIs.” And there was a lot of people that were like, “I like some services and I like back-end stuff.” Then we had, “Let's do a testing guild, a security guild,” and there was a few people there. That's typically how it goes, and those are two areas that I really care about because they're super important and usually underrepresented, essentially. Not misrepresented, but –

[0:20:18] Guy Podjarny: Little bit more invisible.

[0:20:19] Brian Sodano: Yes. A little bit more subdued in terms of their role. The tricky part was trying to figure out how to get them to really understand just as much as they might be concerned with the way their code is presented, the kinds of libraries they're making, incessantly caring about nitty-gritty things like glinting rules in code and everything like that. Can you get them to care about security just as easily? One of the things was looking at the kinds of tools that we could use that, A, were super easy to integrate into their everyday processes, so API driven.

The second thing was using tools that were also easy to read and understand what they meant. That meant if there was something that was scanning or something that was helping them with the security process, there wasn't a lot of noise. They weren't just sitting there saying, “That's great. This tool just told me I have 2,000 things wrong with my stuff. I don't even care about this anymore.”

[0:21:14] Guy Podjarny: A much better signal-to-noise ratio.

[0:21:16] Brian Sodano: Correct. So, we looked across and then we looked at different tooling to do that. We also had tried to incorporate all of these tools into DevOps pipelines automatically. We were using a split mode between say a Jenkins and some other Atlassian tools like Bamboo and some other tools that exist inside there. We try to coalesce around some, but how do we then make that so that they're not really thinking about it so much?

It's super easy to say, “Okay. This is a quick change and I understand this.” The second part was also getting our product owners to buy in, and this was super important too. A lot of them are focused on making great changes for the customers. They have certain metrics they want to get to with customer satisfaction, making sure that folks like this, and we had to angle that in. We're continuously doing that and saying, “Also, a secure website is super important for you and for your customers. Have them have that peace of mind to make sure that it seems like we know what we're doing, and that they're capable of providing that safer environment with any incident or stuff like that too.”

So, we need to really step back and focus a lot on that, and quite frankly a lot of what we are going to be doing the rest of this year and in the next years is a heavy focus on working with our product owners, in addition to our security organisation, on educating what is it that we're trying to do? What is it that we want to go? And understanding the kinds of roles that everyone needs to play in helping support this transition, because it's an everybody thing.

To your point, we don't really have a dedicated person. We don't really even have dedicated QA or testing folks anymore. It's something that we're shying away from and we're saying, “This is everybody's responsibility as part of the dev thing. You're responsible for dev and DevOps. You're responsible for testing QA as it goes. You're responsible for security as it goes.” And trying to spread that all out with certain champions to help push certain things.

[0:23:03] Guy Podjarny: Across those, yes. But I think probably what I like the most about what you're describing is how you're basically treating security the same way you are treating all the other aspects. There's a UI guild, and there's also a security guild, or a testing guild, to even talk about product and getting into the backlog. I think what you're describing is actually the epitome of making security just a natural aspect of quality, of just, “This is what good software looks like.” It has those components in, which I assume is not an easy challenge, but it feels like once accomplished, it's just more ingrained into the fabric of how software is developed in the new stack.

[0:23:45] Brian Sodano: You said it correctly. All of this is a software quality play. Not for a means to an end. Not just because we want to sit here and chew on building correct software. What's the old adage? There's always the old joke that it's a bunch of DevOps-y folks that just love to tool around and get their most perfect Kubernetes cluster sitting there and running in perfect harmony.

It’s not what we're trying to do. We're trying to do very, what I believe, and I think what a lot of the folks in the industry are thinking, just as in the DevOps idea. If you want to take this to DevSecOps, this is where this is going. This is part of your job. It's part of your every day. There's a lot of noise and choices that certain individuals, say from a leadership perspective, from my angle, as well as in harmony with the security organisation that can help filter out and say, “Okay. There's some basics that you have to cover, and there's some things that we're expecting out of this.” But other than that, just keep building towards these things.

We're starting to introduce the idea essentially KPI or, better yet, more like OKR-driven requirements for security as well as performance and testing.

[0:24:52] Guy Podjarny: That's fascinating. What are the OKRs? Sorry for interrupting you there for a second, but what are a sample of OKRs that you had around security initiatives? Just the metrics, not necessarily the thresholds.

[0:25:03] Brian Sodano: Yes, they're a little bit of both. It depends. A lot of them would be tangible upon potential outcomes that we're looking for. I believe I heard earlier today in a discussion the idea of rewarding teams that might have a zero vulnerability in certain aspects like that too. It's being driven that way. It's the idea that in building these continuously evolving new software choices we're going to be rewarding folks just as we're meeting OKRs for getting certain other percentages to the website, or certain other stuff like that.

If we can hit these some degree of threshold, or some degree of code security quality, some sort of maintenance level. Like, we didn't introduce the new vulnerabilities, we made conscious choices to not use certain libraries that helped a whole bunch of different things by not doing that. We're now baking that into plans as we're thinking of the next year and giving those same OKRs to our product owners alongside with a customer-centric ones so that it's all equalised.

[0:26:05] Guy Podjarny: Rationalising the same – the next to the business value metrics, because this is business value it's just you have to measure it as a leading indicator. That's in general one of my areas of passion, just exploring, hence my butting in there on those. It's just finding security metrics, and it sounds like in this case you're saying, “I'm picking more of the accomplishment of the activity that I'm doing. I'm not trying to get into some nebulous, "how secure am I?" type measurement. It's more about how I've set out to not have known vulnerabilities in my system. Have I achieved that or not?”

[0:26:41] Brian Sodano: We want to set guidelines towards the excellence levels we want to achieve as an organisation, and that's security, and that's a level of testing that we have, and that's site performance which is super huge. That completely and very directly impacts our customers. All of those get intertwined but we don't want to necessarily be super overly prescriptive on how. We do want to narrow down into some guidelines. So, there's a middle ground that we're trying to come to where we can put a little bit of blinders on and say, “It's not a completely open field. You can't just do whatever you want and use 50,000 different security tools or testing tools, or even web frameworks for that matter.” We're going to centralise around this, more or less, and we're going to go over here.

I'd like to point out too, if there's any developers that are listening to this, the Airbnb model. They have certain standards that they use and certain libraries that they use. I don't know anybody at Airbnb. But I have to imagine that internally, there are plenty of other teams that explore other avenues and ways to do it. It's not like everybody uses this universally. It changes over time. That's the model we're taking. Let's pick like an 80% to 90% common denominator about where to go. Say, “Yes. Go that way.” Go do this and then say, “Figure it out.” We know we have a bunch of smart developers, really great engineers, and they're constantly coming up with awesome stuff.

We're just trying to make sure that they're measured and incentivised for doing the kinds of security practices in the same way as they are for that very direct customer-centric type of idea. Like, “I made something visually appealing, I made a workflow that works really awesome. I had a dysfunctionality that never existed before that talked to some of our systems and made the customer's life that much easier.” This should be alongside with all that stuff.

[0:28:20] Guy Podjarny: Yes. It makes a lot of sense, and I find it to be very much future-looking. Basically, just trying to understand around the destination. You talk about outcomes of the different aspects of software. Outcome of, “Am I performant, am I secure?” But to an extent, if you think about these things, as the outcomes of the organisation, if you manage to achieve an organisation that measures itself this way, I think that's a good destination.

There's a whole bunch of other things we can dig into over here, but I think we're coming a little bit to the end of the time. Before I let you go, I like to ask every guest coming on the show. If you have one piece of advice or one tip, maybe a pet peeve, something people should stop doing or one tip of something to start doing to level up their security foo. What would that one bit of advice be?

[0:29:08] Brian Sodano: There's a lot of change going on in the industry right now, in the security industry. Like I said before, there's a lot of players in the market and there's a lot of tools. I think to be fair, there's also almost a lot of noise just in the market itself. I think as a developer, it's a little confusing. My advice would be to educate yourself on the basics. There's plenty of resources. You can go around to almost any. You can go to Snyk's website, and you can go to WhiteSource’s website, Contrast's website. Everybody has a blog and they all do a very good job of trying to describe and understand the kinds of ways that security is handled and ways to segment it.

It doesn't take a lot of time to understand the differences between source code analysis and static application testing, security dynamic. I found a new acronym when I was looking this up the other day, it wasn't DAST, it was MAST which somebody referred to as manual application security testing. That’s free. But understanding that most of that world, especially from a developer standpoint, is very accessible to them. The SaaS, the SKA, the IaaS and even the RASP worlds are very much within the reach. DAST is a little bit different story. I think you're still going to need a bunch of interesting security professionals coming up with ways in which you can hack into –

[0:30:35] Guy Podjarny: Successfully scan.

[0:30:35] Brian Sodano: Yes, everybody's sites and constantly be churning that out. I think I heard you say recently, “There's not going to be any shortage of jobs for security professionals anytime, ever.”

[0:30:45] Guy Podjarny: It's the sad reality of security.

[0:30:48] Brian Sodano: I'm sure there's only to be more job opportunities in the near future as everything moves more online and we do more things via our phones and our computers and our watches. For all I know, we're anticipating that's going to be a thing probably in the next couple of years. When I worked in IoT, I never believed that voice stuff would be real five years ago, and now I have an Alexa in almost every room in my house. So, I get it. I think it's just super easy to educate yourself on this stuff. I think most developers just don't think it's their job.

Whereas, I think many of them now are in the mode of, “I do testing. I do ops. I understand my environment and I get into the cloud.” I think there's a next evolution that comes to security as part of that. It rounds out a lot of or most of what's going to become a very developer-centric new way of working over the next decade or two. You're only going to see more developers popping up.

[0:31:45] Guy Podjarny: Yes. That would be a good skill and a good talent to have. Sound advice. Brian, thanks a lot for coming on the show and sharing all this info. Thanks everybody for tuning in, and I hope you join us for the next one.

[OUTRO]

[0:31:58] Guy Podjarny: That's all we have time for today. If you'd like to come on as a guest on this show, or get involved in this community, find us at thesecuredeveloper.com, or on Twitter, @thesecuredev. Visit heavybit.com to find additional episodes, full transcriptions, and other great podcasts. See you next time.

Up next

Optimizing Team Communication With Sara Dunnack

Episode 41

Optimizing Team Communication With Sara Dunnack

View episode
Combatting Security Burnout With Stu Hirst

Episode 43

Combatting Security Burnout With Stu Hirst

View episode
Year In Review With Guy Podjarny And Simon Maple

Episode 44

Year In Review With Guy Podjarny And Simon Maple

View episode
Running Security For A Security Company With Michael Hanley

Episode 45

Running Security For A Security Company With Michael Hanley

View episode