Improving Security Culture With Justin Somaini

"Justin Somaini: In my experience, you have really an opportunity to teach developers how to phish. And if you teach them well, what comes back to security is exponentially more than what you put into it. How do we get security part of the feedback cycle of the business? We're in this together. And so, you have to be in the thick of it day-to-day rolling up your sleeves and working with them. And so, that's the first thing about culture." 

[00:00:34] Guy Podjarny: Hi. I'm Guy Podjarny, CEO and Co-Founder of Snyk. And 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.

[INTERVIEW]

[00:01:08] Guy Podjarny: Welcome back to The Secure Developer. Happy to have you back with us. And today we have Justin Somaini. Justin has a very long and extensive history in security. Ranging from being the Chief Security Officer in a variety of interesting companies coming from Symantec, and Yahoo, and Box, and SAP. I'll let him sort of tell his story in a sec. But welcome to the show, Justin. 

[00:01:29] Justin Somaini: Thank you for having me. It's great to be here.

[00:01:32] Guy Podjarny: Justin, before we dig into the many interesting questions that we can debate here, tell us a little bit about how did you get here? Who you are a little bit? Some short version of that history.
[00:01:42] Justin Somaini: Yeah. I've been in security for 25 years and started out many, many moons ago at Price Waterhouse as a penetration tester. And during that process, realized that if I was ever going to be a great consultant, I might actually want to do the job at least once in my life. Got the amazing opportunity to come over to Charles Schwab to run security operations. And then realized that this whole fixing security was a lot more difficult than just consulting on it. And so, stick with it. 

And so, from there, went to VeriSign where I ran all security for five years. Went over to Symantec after that as their CISO. Then over to Yahoo as their CISO. To Box as a Chief Trust Officer. And then just recently left SAP as their global CSO. 

And then, of course, as we do in the Valley, we have a tendency to participate with VCs and security companies. I've been doing advisory roles and on advisory functions for VCs and security companies as well. I try to be very active in the industry that I love.

[00:02:51] Guy Podjarny: Yeah. That's excellent. Those things also keep you fresh a little bit. Right? I like to say, they help you learn in parallel. Not just sequentially.

It's quite a journey. Maybe we start a little bit with that sort of historical perspective. You've gotten from these different companies that are also different in different times. How would you say the security landscape has changed as you've been tackling maybe the same title across a decade or two? 

[00:03:13] Justin Somaini: Yeah, I think that we have gone through a lot of maturity. And a lot more is still yet to come. But over the past 25 years, when I started security was very much what I would call a very simple audit and compliance, "Hey, we have a firewall." You know what? Nobody can ever really execute anything on a webpage. Literally, that was a statement that was made to me way back in the day. Very sophomoric thoughts about security. Even though we had luminaries and security theory back in those days. 

But as we've matured and grown, I think that we've really grappled a deeper technical base of what's going on. Hence, application security and driving deeper into the nuances of coding, and  development, and how coding is really done in spite of the acceleration that software development has gone through over the past 15 to 20 years. But on part and parcel, from a network standpoint, and education standpoint, from an organizational standpoint, we've done those as well. 

Some of the things that I think that is well-matured but maybe a little bit later if we look at global law enforcement, I remember probably up until maybe 15 years ago, law enforcement was not deeply focused on the cyber problem. It was a bit of a joke in a lot of ways. I hate to say this. I have a lot of deep love and affinity for law enforcement globally that deals with this problem. But there were other challenges that they were looking at. That's a very different story today. 

When you look at the FBI, or Interpol, or Europol, or some of the other agencies around the globe, they have dramatically matured to kind of deal with the problem as that threat is increased. We've seen a lot of changes. But quite honestly, I think we're maybe in the first quarter of maturity in application security or in security as a whole. Not unlike they're still robbing banks. And that's been around for a while. And we look at other industries such as legal or finance that have been around for a very long time. And in spite of that, they're still maturing themselves at a slower pace, of course. I think we have a long way to go.

[00:05:32] Guy Podjarny: We’re still at the beginning. Some changes I think are obvious in the landscape as some tech has changed, like mobile devices or others. But what would you say are kind of the beacons of change? Or what are the key drivers of difference in today's world in security versus maybe a decade ago?

[00:05:54] Justin Somaini: Yeah. When I look at security, I have a tendency at a meta level that you're kind of referring to it. I take a step back and I think about there's a big difference between security theory and applied security. If we take security theory about how we attach confidentiality, integrity, and availability to data and its transactions, in a mainframe world, that's fairly simple. You apply it in the mainframe. It's a centralized model. You've got green screens that are basically just windows into that data and transactions. It's fairly easy to implement a CIA model to that. 
But what we saw with a transformation from mainframe to client-server, the world dramatically changed. And theory didn't change. But how it was applied did. Where that data was and where the transactions were now shifted to workstations, servers, multiple servers running those services, workstations, data being handled back and forth. We had an explosion of complexity simply because the data and transactions moved and we did not have the mechanisms to apply CIA to it. 

If we move forward from client server into client cloud, now those services are on the internet with a more insecure or hostile direct access environment shall we say. But really underneath the hoods, what you're seeing is an interconnection of those services as we look at Web 2.0 and some of these other API integrations that you have. So that transaction and data service model becomes even more complex. 

Now as we move even beyond that, what I would call multi-cloud and containerization, while the concept of the service doesn't necessarily change in a great degree in a container model, but what but what we do have is an exasperation on the operational side that we saw with virtualization. We have many containers with many data and transactions. And how we manage and govern them becomes even more complex and is being done in a multi-cloud space around the globe with a whole bunch of different things. 

And so, how we leverage technology to do things has a significant effect on how we apply CIA  to govern those things. And so, that's the basic concept of how I look at technical security to start with. And what you see is you're able to predict a lot of the challenges that we face if you keep an eye on what is the new technology that is going to be adopted eventually by businesses and organizations as they try to accelerate their growth and revenue. But containers came onto the market. And now it's flushing. And now everybody's trying to run and keep up. We can also do the prediction with serverless, a whole bunch of things that are just starting to take hold.

[00:08:52] Guy Podjarny: Yeah. I fully relate to that. I feel, for starters, there's many, many, many moving parts. And a lot of the sort of the safety of controlling the environment has gone away because now everything is kind of interconnected, and mobile, and on the internet. 

I guess maybe before we go to sort of the next challenge, I mean, what have you seen as kind of strategies, successful strategies, to help tackle that? It feels like definitely a big battle. What do people do? What have you done maybe that you've seen work to conceptually try and kind of adjust to this fragmentation? 

[00:09:23] Justin Somaini: Yeah. The security management model that I try to approach, I'm a big believer in a general statement the centralization of a security function. You can get some leverage. But getting to your point, you're never going to be as agile as the lines of businesses, or the development teams, or the functions in a centralized model. How do you have a distributed or integrated security model to be able to deal with the day-to-day handling of issues as they come up? 

And as a result of that, generally, what you have – and this is more pronounced in application security than it is with security operations. As we have shifted to an agile model, the velocity of change or releases has dramatically shifted, which has forced security to be able to handle this velocity, which is where they struggle to a great degree in AppSec. 

But one of the models is having embedded individuals in those line of businesses. But secondary to that is really finding ways to not only educate and empower the development teams. But, also, make it clear that because of the models and the decisions that they've taken, there's a significant accountability that they have in the security model as well. 
And this is where the first problem really comes in with basic security teams and developers is because they are two very different camps, mindsets, and beliefs. We've grown up in security in this operational model where I create a policy and a standard and somebody's just going to build it to that standard. That's what DBAs and system administrators do when they build servers. That is not how development works.

[00:11:12] Guy Podjarny: Definitely not today. 

[00:11:14] Justin Somaini: You have a problem and the developers are part of the process to engineer a solution. Most security people have never checked in code. They don't understand what a CI/CD pipeline is. If you talk about new technologies or new capabilities like mesh networks or containers to a great degree, it's just not really part of their normal ecosystem. 
The first step in any security buildout for AppSec is to really establish leadership or a partnership with the development leads. One, a general understanding and agreed upon problem set. Security coming to the table with proposed solutions but not a dictation on what the answer is. But a series of answers. So that the development leads or development teams can be part of that conversation. 

But being part of that conversation also means that they're now enrolled. That they're adopting. And that means you're going to have greater efficacy in integration and implementation of those, like static analysis tools and things like that.

[00:12:18] Guy Podjarny: Yeah. I love the – I guess kind of going even back to an early start of that answer, talking about embedding security knowledge within development. But it sounds – or it's security champions even or the like. But you're talking about also like just as equally important is almost the embedding of development knowledge within security. Sort of ensuring that people are at rest on it and having those shared conversations, I guess, when? 

In Agile, there is no, "Hey, there's some glorified design meeting that happened that security needs to be a part of." I mean, how in practice does that work? Do you sort of take developers and make them a part of the security team? Do you send your security people to sort of to learn how to code? How have you seen that work? 

[00:12:56] Justin Somaini: There's two what I would say parallel paths. One is how do you get just as much automation of security into that CI/CD process as possible with the developers, of course? Because they're the ones that are actually going to have to deal with the output. And so, if they're not part of this, it's not going to go well. 

[00:13:14] Guy Podjarny: Yeah.
[00:13:15] Justin Somaini: In my experience, you have really an opportunity to teach developers how to phish. And if you teach them well, what comes back to security is exponentially more than what you put into it. Let me explain. If I can teach a developer the basic concepts of security that we look for and how we look for them in general, they're able to shard  that into the myriad of different ways that things are actually developed, and implemeted, and coded, et cetera, to be able to come back into that process and actually give advice on better solutions. 

And so, education and training is really big. But it's very difficult to scale. You have labs. Hands-on experience is probably the best one to do. And so, you have those mechanisms. And it's a train-the-trainer model. I'm a big believer in that train one developer on the security and have them host a lab for 10 to 15. And, eventually, you got to go through that process. 

But on a day-to-day basis, I believe that having an individual that is born from the development community be identified in the security team as the security lead, for lack of a better word, or the security accountable individual for that LOB that effectively is part of those scrum meetings, that's part of that leads, that's doing the hand-to-hand discussions, and walking through, and working with the developers. Because I found that developers and the community that they have on a working relationship day-to-day is very powerful on being able to get their buy-in, get their proactive approach, and get their focus. Versus a gate check that they have to go through. I want people embedded as much as possible. And, usually, identifying those individuals having to be part is the best way to go.

[00:15:10] Guy Podjarny: Yeah. Yeah. What I love about that perspective as well is that it's very analogous or sort of very parallel to how DevOps operate. Right? You've got those sysadmins, ITs that were outside the team. Today, you look at what happened to those? As admins, they became DevOps automations, they became SREs. They're probably paid to double and they're embedded into the application while most of the activity, most of the sort of the ops activity is handled by the dev teams. But the proficiency is built within – I guess, depends on the org. But, in many times, within the org. Basically, let's apply the same for security and create securities equivalent of an SRE. 

[00:15:48] Justin Somaini: Yeah. I mean, it does have some problems though. And so, taking a step back and maybe not droning on this too much. But Agile has come in you know years ago but has had a lot of changes not just on how software is developed. That's very easy to kind of see. But the impact on the business, what we call digital transformation on how we digitize the entire supply chain and pull customers in, and suppliers in, and actually have those analytics dramatically change the products that are actually being delivered. Netflix is probably a great example of this. 

On the security side, it's had a significant impact as well that I think we're just now starting to realize but can take some insights from newer companies. And so, as waterfall to Agile started approach, we saw a higher velocity. What does security do? We need to get tools in. We need to do training. But at the output, we still have the same vulnerabilities or the classes of vulnerabilities. OWASP Top 10 I haven't really change that much, right? 

What do we do? Well, we're going to put in an SDK and give it to developers and give them standards. We're going to have third parties come in. And, yet, what we see is the same classes of vulnerability are still there. Cross-site scripting is still probably the biggest vulnerability. And everybody knows how to solve cross-site scripting. The question is why is it still there? 

What you have in businesses, you have this problem where developers are kind of caught between a rock and a hard place. They are on one side being paid and accountable for feature functionality of a service. And on the other side, you got security saying you need to be very clean in your code. You need to dedicate time to both. And it just doesn't work, which is why we have cross-site scripting issues, et cetera, because developers are going to go where their paycheck goes. Right? Feature functionality. 

What I see security doing is moving to solve this problem is moving what I would call from a governance and advisory type function to one of governance and product delivery. And the reason for that is let's take something like cryptography or data at rest encryption. Historically, you have two organizations in a security team, an enterprise security and an application security team, and they would go out saying you need to have a PKI environment. Here's your standard and build to solve that problem. 

What we see now to be Agile, to be the product security, the security teams are saying stop coding data at rest solutions. We will do it and provide you a service, an API service, to be able to leverage it. And that means the enterprise and AppSec team are combining into one team to be able to do the PKI, the APIs all the way up the stack to be a production service to the various applications. And that's a very different organizational and skill set model than we've ever seen before. And I think that's a significant change that we're going through right now.

[00:18:58] Guy Podjarny: Yeah. Makes a lot of sense. I guess you're tapping into some of the advantages. There's a lot of conversations about the advantages of DevOps from a security perspective. And the advantages of agility, probably the most well-touted one or most touted one is speed. Is the fact that you can patch faster. But you're sort of highlighting a different one, which is, well, if the system is more library-oriented, and microservice-oriented, and the likes, then I can interject or the security team can interject more elegantly by being a component of this system that is security conscious.

[00:19:31] Justin Somaini: Yeah. When you look at born in the cloud companies, security started with one developer solving a problem. And being in the Valley, of course, you talk to tons of them. And it's like one developer saying I need to create an identity and authentication mechanism for our service. Okay. Then how did it grow? Well, I needed to create a logging API. Then I needed to create a crypto. 

And then, eventually, we had customers saying we need to be certified. So we got some of those governance people. But it was born a very different model than what other companies that have been around a long time are going in reverse. And so, I think there's a lot of lessons in regards to why they have done it and the scalability that they have as a result. And I think it's an incredible opportunity.

[00:20:18] Guy Podjarny: Yeah. It makes a lot of sense. And, I guess, for that, you need to transform not just how you work. But, actually, the makeup and the skill set inside of your security teams to be able to provide these types of solutions.

[00:20:29] Justin Somaini: Yeah. I would say a security team's staff will rotate about a third, maybe a half from process management that we do today generally into developers. And as a result of that, they're developing internal tools as well to be used. But what does that do to the security workforce? I think that's a big impact that will be going on for 10, 15 years.

[00:20:55] Guy Podjarny: Yeah. On the flip side, I guess it might be an answer to the infamous security talent shortage that never really does get resolved. Not the developers are that plentiful. But slightly more sort of varied talent pool there.

[00:21:07] Justin Somaini: Yeah. We talk a lot about application security. But when we've spoken before, you were mentioning how application security extends more or will extend more maybe when you compare it to endpoint security that's an area that is not as mature as it should be compared to the risk. I guess what's your view on the AppSec industry if you will?

[00:21:28] Justin Somaini: Yeah. I think the AppSec industry is absolutely horrible. And the reason why I say that is not that good people haven't tried. But it's a very difficult problem to create a business. And so, for example, how many firewall vendors, endpoint solutions, et cetera, do we have out there? A lot. Go to RSA. How many of them are dealing with application security versus anything else? 

And, yet, when you look at the problems that we face as an industry, 90%, 95%, 98% perhaps are at the code level. This makes no sense whatsoever. The only reason why it makes sense is that it's so much easier to create a network control access point than it is to do a mature static analysis kind of model. And it's very, very difficult to do AppSec from a vendor standpoint. 

Because of that, what you see in organizations is that the solutions that a vendor can put in has no context to the application development service or business in which a company has. It makes it very, very difficult to create a one-size-fits-all, so to speak, solution when our environments are pretty different, especially for cloud services, let me put it that way. 

What happens is that the internal teams in that company need to take that on. Hence, the product delivery statement that I made about security teams. I wouldn't say all of them are doing that necessarily. But that's what should happen. But this is where why I say application security is pretty bad. 

On one side, we have a complexity, and a problem, and a difficult business model to create a vendor in this space to solve the problems. And on the other side, we've got developers that are paid for feature functionality and are not able to dedicate or even security teams to get the resources to do all the things that need to be done inside the application to solve the problem. 

The third problem I would say is, if we look at any of the other solutions that are out there to do WAF application firewalls and things along those lines, while it's an effort, it's what we would call a secondary control versus a primary control. The primary control must be in the application where it has context. It understands what that is. Versus being outside of it. 

I think that it's great that we create it initially into the market to get something there as a hold-off while we have a long-term solution on driving it inside the application. But, generally, companies haven't done this. So we're only left with a WAF that ultimately it causes problems sometimes. Right? 

[00:24:09] Guy Podjarny: Yeah. And I guess it's the same kind of notion that you started with talking about how it was easier to protect the main frame than all these moving parts. The application has a lot of moving parts. The network, there's one of it or there's five. It's just easier to sort of tackle. 

[00:24:22] Justin Somaini: I mean nothing for nothing. But how are you able to protect a modern-day application that is containerized, is multi-cloud, it's got connections up and down your supply chain, and developers are pushing releases at least once a day? 

[00:24:36] Guy Podjarny: Yeah. I guess maybe the good news is that there's an opportunity to try and crack that in terms of the need of the industry. But the complexity is very much there.

[00:24:45] Justin Somaini: Yes. 
[00:24:46] Guy Podjarny: Is it safe to add to that that there's a shift in people? I mean, I think I definitely talk a lot about that, which is one aspect of it is the complexity. But I guess I kind of wonder whether we are talking to the wrong people, right? Whether the solutions that are built – I've personally built a product called [inaudible 00:25:02] Developer Edition that had developer in the name. But that was pretty much it.

I mean, it was a really good product and it succeeded financially. But it really was an auditor's product kind of built into a developer environment. Do you see that happening? Do you think that's indeed like an important part of the solution? Or is that secondary? 

[00:25:19] Justin Somaini: If I understand your question correctly, it's how do we make sure security is acted upon by the various LLBs? In this case, the product team. Versus driving security to the networking or ops team, which can't really solve the problem. At least that problem on the application side. 

I think that that's absolutely the case. But that gets into a very different problem, which is how do you drive a culture of security into the executive management team? Second to that, how do you ensure that security is a business driver so that it is important to the executive management team, which also requires the security person to be business aware. 

What we generally have is security people and not to make it overly complex. But we need to be more participatory in the executive management team. And to do that, we need to at least have a modicum of understanding of what a business is. What is a funnel? What is marketing? What are conversion rates? What are sale cycles? And that's generally unknown. 

What that allows you to do is to use all the tools in your belt. Customer requirements demands. Competitive analysis of other competitors in the market from feature functionality standpoint. Solicitation on deal flows, and the sales cycle, and how you can shorten that. And bring that to the product managers and say, "With better security, we can increase net promoter score. We can shorten the sale cycle. We can actually possibly drive topline revenue if we have really lock solid security implemented and have a lean-forward approach on how we open the APIs to other partners, and networks, and all these other things. 

I believe in that model very significantly. It's what I did at Box actually as a Chief Trust Officer and driving that competitive differentiation on security. And it had a massive impact on the culture and what the developers really see as important because it's coming from the business. I mean, I consult with my clients a lot on that one topic. And it is very rarely. I've never heard really anybody really talk about it. And I feel very passionately about needing to drive that.

[00:27:41] Guy Podjarny: Yeah. Yeah. Agreed. And it's hard. I guess anything that requires an org-wide change is not something to be taken lightly. But you also hear a lot about that even in the world of marketing needing to adapt to Agile. It's almost like everything is adapting to this like DevOps Agile change. Because the whole business is becoming one big feedback cycle. And security needs to be part of that group as they adapt the business. Also, there's a certain cadence that is now not just based on feedback and users. 

I guess one of the key challenges is that security's feedback cycle is kind of bad. Right? It doesn't hurt until you're breached and then it hurts really bad. It's hard sometimes to sort of know if you're doing it right. 

[00:28:21] Justin Somaini: I really like the way you just put that, that feedback cycle. Honestly, I've never heard that. One, it makes a lot of sense. And it relates obviously to a whole bunch of things. Yeah, I think if I was going to phrase it a different – what I was saying a different way using your words, how do we get security part of the feedback cycle of the business? They are so focused on hearing about what Gartner is saying, what customers are saying, and what the competitors are doing. How do we pull, tease out the security-isms of those three and have it be part of life cycle so now they pay attention and drive it inside their orgs? 

[00:28:58] Guy Podjarny: Hallelujah. Now we need to actually get that done. Yeah. 

[00:28:59] Justin Somaini: Definitely. 

[00:29:00] Guy Podjarny: Actually, with that, there's one other bit that I want to make sure that we cover before we do it, and this is actually a decent segue, is to talk indeed about corporate cultures and security within those environments. You've seen big and small and also kind of over time, what would you say working with Symantec, Yahoo, Box, SAP, how does the corporate culture play into it? And maybe to try and kind of give it a practical sense, I mean, how did you need to adjust your approach to change what would work given that surrounding? 

[00:29:31] Justin Somaini: Yeah. Culture is an interesting thing. And there's no one – take any company, there's no one culture. But all of them have it. And so, when you look at security and your approach about implementing it, what you're really talking about is how can I move the needle for somebody else? How do I understand what their challenges are? What they're trying to do? And get them on board with a problem that we're trying to solve. And know their role into that. 

Culture is a massively important thing to not only break into that behaviour change, but also solidify security as a core value of that organization. And so, when you look at like a Yahoo being in Sunnyvale and one of the bastions of the internet back in the day and coming around, and at that particular time going in, it was – you had Facebook, you had Google especially coming in. And a lot of competition that they once dominated. And so, there was a bit of a turnaround within the company culture that needed to be aware. I had five CEOs within 12 months. Not a fun experience. 

To get to the developers, you had to understand the challenges that they were facing when they were going through their own transformation in the business. And how can you help solve some of their problems if you're asking them to help you solve some of theirs? It's the we're in together. How can we move forward? 

And I think that statement holds true in any other company. In Box, for a great example. You know what? We're starting out. We're a startup. We're breaking through. We're going to go IPO. We've got massive competition from Microsoft, and Dropbox, and the like. We have limited – massively limited resources and money and all those other wonderful things. We're in this together. And we need to fight. 

You can't have that we're in this together when you're doing a keynote and then walking away issuing a standard. That doesn't happen. And so, you have to be in the thick of it day-to-day. Listening, hearing, and working, and rolling up your sleeves and working with them. And so, that's the first thing about culture. 

The second thing is the development culture versus any other teams culture is very different. And most security people don't understand that as well. Where the developers, they’re the creatives of technology for lack of a better word. And so, they're very accustomed to being presented a problem and their task with figuring out how to solve it. Versus what we've historically done in security, which is security comes up with a policy and standard. I.E. what the answer is. And we give it to somebody else to just implement. That doesn't work very well in development communities. 

And so, what you need to do is you need to go in with not only a clear definition of what the problems are. But probably a couple of options on how to solve it and solicit the input advice and guidance of the development community on that ultimate answer. If you don't do that, they're going to reject it. It doesn't work. You don't understand the development process, the codes, the languages, all the other complexities that they deal with. 

And, honestly, at the end of the day, a business is either a product or a sales company. It's not a security company. You don't have the political power. You got to be in there. You got to win the hearts and minds. And to do that, you got to check your ego at the door. Because everybody else knows it. Everybody else knows you're not as smart as you think you are. And, generally, they're smarter than you in the development space.

[00:33:06] Guy Podjarny: Let's unpack there. I think we might need to do another episode. Because there's so much more to sort of even chat there. A lot of great insights here. Going from kind of starting comments about security needing to move from this governance and advisory to governance via product delivery. The need to build security expertise within Dev. Whether it's a security champion. Make that a part of the component. 

We talked a lot of about how you have to sort of figure out the security business value. And from there, to understand what's the value. How do you turn security into a business differentiator and get that into the feedback loop of the business? And, fundamentally, do all of that within the context of the culture and sort of understand what makes the surrounding tick, which I guess it sounds like the end goal is the same. It's still those same elements of like embedding into the fabric. But maybe the business drivers, and what's doable, and what's not. Sort of changes per the organization. Not easy tasks. But I think really, really useful perspectives to sort of run forward with.

[00:34:03] Justin Somaini: I really enjoy this. I ramble on for 10 minutes and you succinctly and accurately say, "Yeah. Okay. One sentence. This is what you're saying." I'm like, "That's fantastic." Thank you.

[00:34:13] Guy Podjarny: Communication matters. Before I let you go here, I like to ask every guest coming on the show, if you had one tip or one pet peeve you want to talk about to try and give to a team that's looking to level up their security calibre, to sort of do security better, what would that be? 

[00:34:30] Justin Somaini: Yeah. I love my industry. I love security. I feel that I'm possessive. It's my industry so to speak. We're all in this together. But within that environment, there's a lot of collaboration we share a lot within the security industry. We're open. We're accepting. And so, the one thing that I would say to a developer is just reach out and say I want to learn. I'd like to be a little bit better. You will be amazed to anybody. Myself, anybody on LinkedIn, anybody that you see. You will be amazed at the response of welcome and participation that you see to kind of level up education or anything that you might need.

[00:35:12] Guy Podjarny: That's a great tip. Seek out to learn and you shall find. 

[00:35:15] Justin Somaini: Yeah.

[00:35:16] Guy Podjarny: I guess that's also – you just teed this up. But I was just going to ask. If somebody has further comments, feedback, questions for you to ask on the Twitters or others, how can they find you? 
[00:35:26] Justin Somaini: Justin@somaini.net is my email address. I'm on LinkedIn. And my website's down. But I'll be building that up again. I don't really do Twitter. But I'm on LinkedIn a bit. 

[00:35:38] Guy Podjarny: That's good to know you're on a social network. Justin, this was a pleasure. Thanks for coming on the show.

[00:35:42] Justin Somaini: Thank you very much.

[00:35:43] Guy Podjarny: And thanks to everybody for tuning in. And I hope you join us for the next one.

[OUTRO]

[00:35:49] 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.