Year In Review With Guy Podjarny And Simon Maple

“Guy Podjarny: The only way to scale is to build security into the surroundings of developers. I heard far more positive attitudes this year to how auditors are engaging in conversation. Security is this invisible thing. It doesn't have a natural feedback cycle. It doesn't hurt until it hurts really bad. We need a model as an industry that people can replicate, and I think that has not yet been created. But if there was really one thing we can do, it's to figure out how do we measure security, and because you can't optimise what you can't measure.”

[INTRODUCTION]

[0:00:34] 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 programme dedicated to helping startups take their developer products to market. For more information, visit heavybit.com.

[INTERVIEW]

[0:01:07] Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer. I'm Guy Podjarny. Today, we're actually going to do something a little bit different, where hopefully, not to your chagrin, I'm going to be the guest over here. What we're going to do is we're going to look back at just this year's episodes. We've had so many of them. And try to just reshare some of the themes and learnings that we've had from it. To help us do that, I actually have with me Simon Maple from Snyk here to actually host the show and be the interviewer here. Thanks, Simon, for coming on.

[0:01:38] Simon Maple: My pleasure. It is a true pleasure to be on The Secure Developer. I'm looking forward to asking you some searching questions about The Secure Developer in 2019. Yeah, let's go through a couple of stats of what's been happening in 2019. We've had 20 episodes over the year. This is the 21st episode this year. We have had so far, 697 minutes of content with 21 guests over the year. Pretty interesting stats.

[0:02:05] Guy Podjarny: Yeah. No, it's amazing how time flies forward. Definitely, the most we've done in a single year by a good margin here.

[0:02:12] Simon Maple: Let's talk about, of the 697 minutes, which was your favourite minute? No, I won't ask you that.

[0:02:18] Guy Podjarny: We'll get very detailed there.

[0:02:19] Simon Maple: Yeah, let's get very detailed. Yeah. But let's talk about, I mean there's obviously, with 21 separate guests, I'm sure we were talking about lots of different topics, but there's going to be some similar messages in this. Why don't we start with a question about what some of the recurring messages across the episodes were this year?

[0:02:36] Guy Podjarny: Well, there are definitely many different insights as we went through it. Digging into some recurring things, definitely, maybe I like to ask a lot of the guests how they got into security. One interesting maybe observation is maybe the lack of a theme here, which is there are very different answers to that question. There are many different paths to security. More recent episode, we had Andy Ellis talk about how pretty much you got assigned to security when he was in the military and he pretty much was told. Presumably asked, but in practice, not really, to do some work with security. That led him to his first job at Akamai. I don't think it's quite 20, but it's shy of 20 years later, he's the CISO there and doing an amazing job at a massive company.

We had Tanya Janca talking about how she was organising tech talks and had a lot of talks about security that was interesting and then got lured into it. A lot of people coming from software engineering jobs. We have, I think, Kate at the Guardian and Sarah at Envision and various others talked about how they got into it. That was interesting, like many different paths into security. I guess, related when I spoke to Tanya, she does a lot of great work trying to get more people to get into security and does these mentoring Mondays on Twitter and just try to increase, or push for more of that diversity in security and different paths. That's one really interesting observation.

Back into more themes. I think there might be a little bit of a selection bias, but the whole notion of security and dev collaboration has been a frequent topic. I think one key observation is, we talk a lot about how we need developers to embrace security, but really what came up a lot this year was the other side of the fence, which is how do security teams need to change to foster such collaboration.

You could see this in past years as well, but I think it was really, really strong this year. There was a lot of DevOps related references. Duncan who ran security at Auth0 talked about that, talked about how his own team operates like a DevOps team, own what they build and operate it and run it. There was a lot of a more a broad view from Justin Somaini, who talks a lot about the skill set that the different teams need to have, the security teams need to have, maybe going from more of a sys admin type background into more of a software engineering, or maybe from a project management to more software engineering.

You see things around team structures. A lot of teams report to CTO and engineering organisations. Sometimes even comment how that's different. Actually, sneaking a little bit further back, and I think in 2018, we had an episode with the CISO of Slack. Jeff was commenting on how it was actually a big deal to make them be a part of the engineering organisation. This was echoed back in various episodes today.

Definitely a lot of examples on how security teams had changed. The list goes on. Kate at the Guardian. She definitely said, it is a lot of work building and writing software for the dev teams. Maybe one of the best teams to give an example for is Segment. We had Eric Ellett there talk about embedding. I think, I actually exposed some cover there just before he was rolling out an embed programme more officially, but around how his team embeds itself into development teams to help them build software and leave there as well. The segment team talked about walking a mile in a developer's code to do this.

All of these really talk a lot about empathy and around how the security teams need to structure and change themselves to be able to collaborate better with dev. Even that, above and beyond their own structure and their theme, there was also a lot of conversation around how they should adopt this partnership mindset. This definitely came up a lot in Peter from Smartsheet. He talks about partnership a lot and a lot of those types of quotes. Talking about how working with the dev teams, they shouldn't be saying no. They should be talking about, how do we get to a yes. Mohan at Prudential was talking about this. Definitely a very strong recurring theme is how the security teams themselves need to change to fit this collaboration.

[0:06:47] Simon Maple: With this collaboration and this partnership between developers and security, obviously it's a two-way street and both need to change. From a historical point of view, is it fair to say that developers adopting agile processes, adopting dev ops processes? Would you say, it would be potentially easier for them to take on security than it would be for security teams to change themselves? Because maybe more traditionally, there haven't been as many changes in the org structure of a security team versus a development team.

[0:07:14] Guy Podjarny: Yeah. I think the development teams that changed their experiencing is very much around digital transformation. I guess, that's also been a key theme here, especially when you look to the enterprise. I think there are different, almost these two cohorts of companies that came on as guests this year. There's the cloud-native more born in a cloud, newer, less baggage type companies, from Auth0 to Segment to Smartsheet. Then you have a lot of enterprises.

When you look at in the enterprise side, that's really where development teams are changing how they develop software and change their org structure under that mantle of digital transformation. And there, there was a lot about how do they approach security and how should I change. We had some key episodes on that topic, but we had Justin Somaini, who if you've heard his episode, he's an ex-men of Box and Yahoo and Semantic and various. He's had very rich experience. He actually had this great quote there. He talked about how security is never going to be as agile as the lines of businesses. You have to think about how does a distributed, or integrated security model would work, right? Because it's the only way to handle the day-to-day.

That was more of a comment on how the security teams need to change, but it's due to a change in how development is being done. Similarly, we had James Kaplan from McKinsey, and he actually wrote this great article that triggered the podcast episode, talking about how, I think called it cyber security is the linchpin of digital transformation, and how that should modify how you approach security. How if you don't do that, then really, your options are either slowing things down, which nobody wants to do shipping and secure software, which clearly is not an ideal. Or the third option, which we aspire to, which is embedding security in. That's definitely a dev team change.

We got a bit of a taste of that from the opposite side. We had Brian at Liberty Mutual was really a great example of that, talking about he is on the dev side, and he talks about how, he's basically ahead of the security team. They're embracing modern technology and they just know so much more about it than the security teams, because they're living it. Sometimes they need to bring them along for the journey. I think a little bit earlier in the journey was Mohan from Prudential. He talks about how they're building that programme, how they're building that DevSecOps programme.

I guess, going back to Andy a little bit at Akamai, it's interesting. He talks about the intrinsic security thing has actually been built early. He almost didn't know better when he started, because it was his first job. He built security to be core and a part of the responsibility of the ops teams and of the dev teams. The change that they're undergoing is more about making things more agile. They're already doing well to have teams own that responsibility. Now doing that as the dev teams become more agile and move faster, they do have to change how do they deal with security internally. His team, his security team is helping them scale up.

[0:10:21] Simon Maple: When we see these changes in both security teams and development teams, where would you say the inertia exists, the greatest inertia exists? Because obviously, people naturally want to continue doing what they're doing in day-to-day, day-to-day lives. In all of our episodes, the guests from – that we choose are obviously already doing security far, far better than many other teams and organisations that exist. Where would you say, generally, would be the inertia in other organisations, which some of the guests that we're talking to have already succeeded?

[0:10:52] Guy Podjarny: Probably, the change that justifies a change is really around dev ops, and it's around indeed that. You can call it digital transformation. It can talk DevOps. DevOps does two things. One is as DevOps gets embraced more and more in these companies, then the needs to do something, things just change. You have to adapt. You have to fix it. The other thing is that DevOps gives us this model. There were a ton of references to how DevOps is a model throughout the show.

We had Sara at InVision talk about how they actually call their – they have a team called DevSecOps, which is more of a cloud security InfraSec type team. They actually call those people security SREs. There was definitely references on the dev side on how, hey, just like how we operate it. We also need to secure it. Probably, the momentum comes from DevOps, as well as the role model. It both gets us going and it shows us the way to it.

[0:11:49] Simon Maple: I guess, we've talked a lot about maybe more from an AppSec point of view. If we think a little bit more about from a container point of view, is this very similar when it comes to things like ownership and when it comes to the model that is required within an organization, or are we really looking at different stakeholders there?

[0:12:05] Guy Podjarny: Yeah. I think, if there's anything we can say from these conversations there, or from this episode this year is that container security ownership is messy. It is very unclear. On one side, we see, I'd say the more common pattern amidst guests, we think about Stu Hirst from Just Eat, or you think about Duncan at Auth0. You definitely see a lot of methodologies that are more VM-like, so to think about containers as the evolution of the VM. Simon Bennett from Bitnami talked a lot about the golden image and how do we handle it.

That approach really runs a little bit into a wall when it comes to the fact that the Docker file sits in a repo and that patching a container requires running a build. I think nobody's really quite comfortable. It's been the most natural thing to put container security and just patching this new breed of VMs in the cloud security and the team that previously patched the VMs. It also seems pretty clear that it's not the destination, and today, we're in flux. We're in that twilight zone today. Yeah, that's definitely shown very brightly through the many conversations.

[0:13:13] Simon Maple: Awesome. First of all, I must say, actually, the name-dropping level of this podcast so far has been set to expert in this episode. It is actually a testament to the calibre of the guests that we have.

[0:13:24] Guy Podjarny: Absolutely. Each of them, there are soundbites, there’s quotes, there’s these insights. I enjoy. Really, for me, this is for my own benefit, my own selfish interest, I learned so much from every one of these episodes.

[0:13:36] Simon Maple: Excellent. With the conversations that we've had with all of these podcast guests, let's take a step back and think maybe of the things that development teams, or security teams are doing well and what they need to improve. Let's think about, perhaps, what people have shown to be doing well in 2019 and maybe want to improve going forward into 2020.

[0:13:56] Guy Podjarny: Sure. There's definitely been a lot of improvements. We're talking about 2019, but I sense a bunch of these things and how good practices are being done and how that deferred over the three or so years of the podcast, right, nearly four years. What are we doing well? Definitely, great emphasis on automation. I think this really shown brightly throughout the episodes, go from Simon Bennett, indeed, talking about Bitnami and golden images to Tanya Janca was talking about security unit tests and how they're fast and accurate. That also came up with Omer from Soluto earlier in the year, talking about zero. There's been pretty much everybody's talking about how do you automate more.

I liked Peter's phrasing. Peter from Smartsheet talked about how automation gives you leverage from technology and just thinks about this as an element of scale. It really came up in the notion of scale, or speed. Emphasis on automation, I think, is appropriate. I think we're doing well. Nobody's really quite happy yet, their level of automation, but the attention to automation is good.

[0:14:59] Simon Maple: This is something I see day-to-day when I talk to customers. It's automation and speed is absolutely key. When we're talking about pipelines, it's not just about how can we add something into a pipeline without manual intervention, but how can we do it in a way to keep developers happy by keeping these pipelines to 10 minutes, 15 minutes, whatever? Something super quick that doesn't require a half day, or a day's turnaround in order to push something across to production.

[0:15:25] Guy Podjarny: Yeah, absolutely. It's a change, because a lot of security solutions don't necessarily have it. I guess, that's the other bit that I would say is improving is, it's also a change in the skill set. Definitely have heard much more this year that people are hiring, that security teams are hiring into their teams with an emphasis on software engineering abilities with hiring coders, hiring people that can programme. A lot of it comes back to that automation bit. Some of that is empathy, but a lot of it is because they see themselves as more service providers, as building tools, and they need to hire people who can build it. Definitely, can clearly see the change in the hiring profile.

Justin had a lot of great soundbites there in his insights, but he talked about how teams should move from governance via advisor to governance via product delivery. I know, Peter talked a lot about skills. Definitely, skills are evolving. I think we're doing that well, and it's still a path. With that, I think that skill set is again for building, but it's also for empathy. I'd say, the other thing that we're building an appreciation for is this importance of intrinsic security. It's almost this acceptance that the only way to scale is to build security into the surroundings of developers.

Various conversations about how you have to have to build security and integrate very elegantly into the tools that developers already use, how do you need to pull developers in and have them be a part of evaluating security tools? They need to be a core constituent, otherwise, it doesn't work. That approach, or that learning isn't just the learning on the security side that they should involve dev, but also dev learning how they do it. Again, a liberty mutual there with Brian and that digital transformation project that they're running is a good example.

Jeff McAffer, who was at Microsoft at the time, talked about he was running their open-source programme in security. It wasn't security’s, like that wasn't his job, but definitely was a lot of his attention as we build that.

[0:17:28] Simon Maple: It comes down to ownership as well, right? From a developer point of view, the approval, the committing to using these tools, if the developer doesn't have the skin in the game of that initial adoption, then they're never going to own it, really.

[0:17:42] Guy Podjarny: Yeah, very much. It’s the, sort of it takes two to tango type approach. There's no, you can't get collaboration when only one side wants to do it. Both parties have to come to the table. I guess, one thing that as an industry, I guess we're doing a little bit better on this year, which I thought was very encouraging, is the approach of auditors and compliance people. I heard far more positive attitude this year to how auditors are engaging in conversation about newer practices that impart developers.

There's a certain amount of risk-taking there. An auditor looking to see if you're compliant for PCI, or for a variety of others, they need to accept that that is a good way, or an acceptable way to address one risk, or the other. I harken back to one of the early episodes with Shaun Gordon from New Relic. He was paving the path to being able to get SOC 2 certified when you're enabling teams and you're not a draconian naysayer. He had to educate a bunch of auditors. I think I told him then that we all owe him a beer for that, and I think he should really be quite drunk by now, just seeing the change that happens. Just one of the recent ones where Duncan at Auth0 talked a lot about how this is a healthy conversation with the auditors. Those are the things we're doing well, I think so far.

[0:19:02] Simon Maple: Sounds like, we can go for a beer ourselves, and it sounds like, we're in a pretty good state ourselves.

[0:19:06] Guy Podjarny: Yeah. I think we still have a little bit of our work cut out for us.

[0:19:09] Simon Maple: There always is, isn't there? Yeah.

[0:19:11] Guy Podjarny: Yeah. I think for the areas that we need to improve clearly, first of all, like all of these things that we mention right now are evolved, but they're not done, so we need to do those. I'd say, one part good, part bad was the whole conversation about security champions programme. It came up so much during the sessions. It came up from trainer perspective, with Jim Manico talking about security champions and how that's a key element. Omer at Soluto, or Asurion. Asurion as a whole have these security mavens programmes that he's a part of. Tanya Janca, I think, semi-started that way.

Definitely a lot of conversation about champions and a lot of fondness to it, but very little structure. As an industry, we don't really know what makes a working security champions programme. I think we have a long ways to go to just understand it. Even within a company the conversation with Omer at the beginning of the year, a lot of it comes down to individual initiative and it's not that clear, how do you encourage, how do you motivate those champions? How do you empower them to do the work?

[0:20:13] Simon Maple: I absolutely love the work that Asurion did actually with the security mavens. I think, it's really important by educating developers and I think they use their security team to educate their own developers as well somewhat. It's less of a them and us model, when it was soon as you have such detailed security knowledge within the development team. I was talking to Mark, one of the folks at Asurion as well, and he was mentioning to me about how much once they got that model in, that champion programme in, how much more the security and developers talked, not just through the security maven, to the security team, but just in general across teams, the interaction was far greater.

[0:20:50] Guy Podjarny: Yeah, yeah. I think they're great and everybody acknowledges that they're a great path to better connect the two teams, the development side and security side, and also to scale the security teams, because they're not full-time security people, but there are people that carry a partial security responsibility, but there are many more of them than they are in dev. I do think that nobody really has a winning formula and nobody really has a model that should be replicated, or a structure. I think we should go forward and just evolve that as an industry.

[0:21:20] Simon Maple: Why do you think that is? Because it seems like, okay, it may differ a little bit from company to company and team to team, but the idea of pulling knowledge and information from security teams into development teams, it seems, I don't want to say maybe a little bit ignorantly that it's a simple thing to do, but it's the idea of having security champions in development teams, why is that not something that can be easily replicated?

[0:21:47] Guy Podjarny: Yeah. I think a lot of it is really around expectations of what is to be accomplished and what's the division of ownership. You see this with even with that maven's programme, or I had conversations with Autodesk, or outside the podcast around their security champions programme and everybody looking to roll it out. It's not entirely clear. They know they want the security champions to amplify, but if it's not entirely clear what the security champion does, then it's hard for the development teams around to know when to approach that person and it's hard for the security teams to know what to expect that person to have been done. It's hard for that person's management to know how much time to allocate to them.

Really, what it ends up being is it ends up being, which is very useful, a community, so security champions collaborate with one another and they learn. It ends up being a sensor. So, a person inside a dev team hears more about what's happening in that dev team and when there's a security related, like there's a consideration about security, they raise that flag, so that's valuable as well. It ends up being like an empathy vehicle, because if there's a healthier conversation between the security team and the slightly smaller cohort of champions then they're able to collaborate more effectively.

But it's just hard to know how. It creates almost more of a community, but it doesn't create a programme. It's not clear that you can say, well, the security champion will do security reviews. It's not clear that the security champion would get involved in security tooling. Some of them do. Omer at Soluto does a ton of actual concrete build security into the pipeline work. But he's not the norm. It's more because he is very passionate and takes initiative, versus having the programme structure it.

I think, the fact we're embracing it is a positive thing and everybody's – I've really heard no negativity around it. But the notion of how do you replicate it. Not everybody can be a leader. We need a model as an industry that people can replicate and I think that has not yet been created.

[0:23:46] Simon Maple: Is this problem somewhat compounded when we think about container security, whereby the ownership of that sometimes exists in various different teams depending on which org, or company you're talking to at the time?

[0:23:56] Guy Podjarny: Yeah, yeah. Container security is indeed, and as we referenced before, definitely an area for improvement around that type of ownership. That one introduces another couple of teams to the mix, which is the DevOps teams, who oftentimes container security falls not necessarily to the writers of the software, but to the maintainers of the infrastructure. Sometimes there's a dedicated cloud security, or infrastructure security, or various names for this team. Definitely, yet another aspect of security that kicks in.

It's really, I would definitely say that if security champions is one, container security ownership is another manifestation of ownership challenges and definitely another area to improve. That maybe underlying all of those, one of the areas that I would most love to see us improve is measuring security. It actually didn't come up as much in the podcast episodes, because nobody really had great insights to share almost on it. I would very often, in the quick prep that we do ahead of episodes, ask people about measuring security. It's just so clear that measuring security is a beast and nobody really feels like they've tamed it.

Security is this invisible thing. It doesn't have a natural feedback cycle and it doesn't hurt until it hurts really bad. Measuring security ends up measuring activities, measuring what are not optimal leading indicators to how secure you are, like putting an SLA into the – knowing how many vulnerabilities do you have, or putting an SLA to how quickly you remediate them, or just assessing whether security controls are in place. You're measuring things that are very much to the side. Nobody's really convinced that they are the best measure of how secure they are.

I get the sense that we're going to get to the end of 2020 and we're not actually going to have a full-on solution to how do we measure security. But if there was really one thing we can do to truly move the needle is to figure out how do we measure security and because you can't optimise what you can't measure, right? We have to get that barometer. That's definitely an area that we need some serious improvement on.

[0:25:58] Simon Maple: Let's continue with the thoughts of what's going to happen in 2020. Let's talk about with the guests that you talked to throughout the episodes, what are their biggest, what are their specific challenges that they're going to have in security in their organisations?

[0:26:14] Guy Podjarny: I think one very obvious one is just one of scale. A lot of references to security hygiene at scale as we move to the world of cloud. Anywhere from talking about Jeff McAfford at Microsoft, talking about Microsoft scale and how they had to build things in-house just to be able to track which libraries and which components they were using, given the scale of Microsoft and then adapt, how do they scale handling vulnerabilities of open-source components as part of the development process within Microsoft, and how hard that problem is to do it at the volume of work they do.

Jason Chan described the same problem that they tackled it in a much more decentralised way of more empowering developers to do it and building tools to help those developers know what they're doing. Really, security hygiene at scale, doing basic things, like indeed, keeping your dependencies patched and vulnerability-free, which isn't – you can do it very easily for one library. You can do it pretty easily for 10 libraries. Doing it for 10,000 libraries gets pretty darn hard. That's definitely the recurring theme.

We've seen also, like we had Liran on the show talking about the state of open-source security, and he shared some alarming stats about that, talking about the 88% increase in app library vulnerabilities. We're finding more security issues and we're not really addressing them, right? We had the top 10 Docker images that have a bunch of dependencies in them, the top 10 having at least 30 vulnerabilities each. We're talking about how also, the scene itself is getting increasingly complex. It's not about the 10 libraries that you pulled into your app. It's really, the vast majority is four and five vulnerabilities that get discovered is in an indirect dependencies. Not in the 10 libraries you used, but rather, in the 500 libraries that they in turn pulled in.

[0:28:07] Simon Maple: It was 78%, in fact, in indirect libraries. Did these numbers, did they shock you? Did they surprise you? Or were they really a reaffirmation of what you already believed?

[0:28:16] Guy Podjarny: Well, I think I don't think this is news. I think it's just, we're seeing it happen in scale. Clouds technology and open source and a variety of these technology adoptions and containers are now starting to get rolled out at scale. We're now experiencing the explosion. There's an order of magnitude more containers than there were VMs, right? That in turn, was an order of magnitude more than physical machines. More volume implies more risk.

It's not really terribly new problem. It's just a new manifestation. When we think about wrangling servers and how patching your servers is a really big problem, and then when these were data centre machines. There's definitely just another order of magnitude. It doesn't really surprise me. It also manifests in the cloud security side. You definitely see Duncan in Auth0 talked about how they have 150 accounts. I think Stu at Just Eat talked about 100 AWS accounts. It's not natural. It's not obvious for you to think that a company would have more than one AWS account, right? Or two or three. Why they have a 100. It's really that empowerment, the different teams that can operate and can run at a fast pace and agility and not ask for permissions implies you get fragmentation.

Now the challenge, really the name of the game is around how do you help embrace that agility and that speed without breaking? You have Netflix launched a Repokid as a tool. You empower the teams over there. There's a whole set of tools and technologies and approaches that happen, but some people revert into that centralised, can they still contain that agility, while versus others that are trying to more embrace the chaos and just empower the teams to run it? I don't see that problem diminishing in 2020. I think that continues to be everybody mentions those as one of their biggest challenge.

I think the second big challenge, which is very related, I was referring to centralised versus decentralised is cultural change, especially for companies that move it. Look, embracing good tech, or new tech is hard enough in terms of the time that is needed, but replacing people's attitudes, and sometimes people themselves and people's skillset is really, really hard. This definitely came up a lot, especially when we touched on the enterprise.

I mentioned some of this before, but some of this is indeed in that skillset change in a one slightly ominous prediction, if you will. Was in Justin Somaini saying that he thinks about a third, maybe half of security team staff will rotate. I don't think he gave an exact timeframe there, but when you think about that, that's a fairly alarming stat for many security people. A lot of it is that shift into – it's a result of the culture change, a result of what is the role of the security team within the company and therefore, what are the skills that you need within the security team.

Again, we heard, you see the magnitude of the programme that Mohan at Prudential is trying to roll out and how he touches every different aspect of the organisation. You also see this, like James from McKinsey was talking and he really gives a deep overview of how companies should be embracing that change and how do they justify it to the business, because these are expensive propositions. Really, alongside technologically, it's really about security hygiene at scale. But right alongside, it is this culture shift, this change.

We have great role models in the modern companies and these cloud-native companies in Envision, in Segment, in One Medical. But for enterprises, it's still very much a work in progress. I'd say, those are the primary, like this security hygiene at scale on one side and the culture change, plus that skill set shift are probably the biggest challenges that the security industry and security teams face in 2020.

[0:32:15] Simon Maple: With so many amazing guests that we've had on The Secure Developer over the last year and in fact, as you mentioned in the last few, in terms of what you've learned from our guests, what would you say the most important things are and maybe fit some of the things that you've sometimes thought, well, maybe we can do that in our org, as well as, well, others can consider making changes in their own organisations?

[0:32:36] Guy Podjarny: Yeah, there were, oh, so many episodes that I felt like, left to my own devices. I can go on for an hour or two more. My probably two biggest insights are related and they're really around that change in the scope of the application and how it relates to cloud. Maybe thinking first about that cloud piece, a lot of conversations around the difference between AppSec, or sometimes it's referred to as product security and cloud security. This relates to that container security ownership mess, but really, it's around this cloud as a whole. I asked Stu, for instance, in a recent episode, asked him, okay, what is the difference, or why are containers not owned by cloud security, which is his neck of the woods, versus not product security are not there.

He was saying, “Well, I think it's the start of a journey. They probably should eventually land over there.” Today they work in cloud sec and they're different. I asked Sarah at Envision around they have this, this great model where the AppSec teams are aligned to dev teams, and they collaborate really well over there. But they have a separate team they call DevSecOps and they refer to people that are security SREs. After a while, how are those different than, do they work with dev as well? Yeah, they do work in dev.

It sounds like, there's a lot of well-minded individuals in these companies. Auth0 is another example. It works, but I feel that delineation surprised me a little bit. I guess, I came at it from a slightly more dev-minded view. I thought, like a lot of these aspects of cloud, of the application of containers, they're just an evolution of the app. Therefore, clearly, they should be a part of AppSec, or definitely a part of product sec, if that's how you define it.

In many ways, these cloud security bits are an evolution of infrastructure security. They're more an evolution of maybe the sys admins and what you've done to patch your servers, indeed. That's one aspect that I've learned is just that there's a very interesting line. I think there's more to explore over there between cloud security and its various names and AppSec and where should they stay different and where should they be the same. I definitely have learned that that is not that given.

Then related to that is maybe this growing realisation, which has never been said explicitly about the growing scope of the application and how really to an extent, it's because when we say app, we don't always mean the same thing. That the application has really changed in nature. Sometimes you think about app and you think about code in libraries. Oftentimes, in a modern world, you think about an app, you think about so much more, about the containers, about the network layer, about so many things.

Definitely, I think it was Jason at Netflix, Jason Chan who talked about how there's really this line between infrastructure and the network goes away with cloud, because now with the infrastructure, the network has just embedded in. I think there's basically another line, another layer there that is into the app itself, the line between the infrastructure and the app does not go away.

I think that's probably my most meta perspective. I think on a practical, how should you approach security? I love some of the guidance that I got around focusing on the threats. I was surprised and I think in hindsight, surprised for the better, just the frequency that even when we talk about developers and security, the answer oftentimes reverted, or went back to talking about threat models. Peter at Smartsheet talked about how threat models create sometimes this Pavlovian response from teams. Therefore, he sometimes avoids the term. But really, you can call it security design review. It's still a threat model.

Really, what you want to do, and that was the recurring theme is you want to understand what are the attackers doing, so that you can tune your activities, versus over-investing in an area that doesn't matter and staying exposed on an area that does. That element and how embedding that into your developer security collaboration, and maybe tying back to that security hygiene at scale, how important a role it plays there, was definitely, definitely a great insight for me.

[0:36:55] Simon Maple: From a listener point of view, I guess, there's going to be a lot of people out there working in security teams, working in developer teams, a high-level discussion. But when it comes to the actual day-to-day roles, what can they take away? What actionable things can they do to actually start implementing some of these ideas?

[0:37:12] Guy Podjarny: Yeah, for sure. I think there were a ton of concrete tips, just very explicit like, do this, don't do that type element. I also like to ask that question at the end of every episode. Ask people what's your one pet peeve, or one piece of advice? I love how different guests take it in very different directions. Some key ones that I liked, definitely a lot, a great practice is around celebrating success and how that's key for developer adoption. Just basic human properties is you have to – you can just reprimand people for doing something wrong. You also have to celebrate it when they do it right.

This came up throughout the years. But I think some really good tips. We had Siren Hofvander talking about making cakes for nothing, for basically, for nothing happening. Just making those. She's definitely big on the on the positive reinforcement. Zach at One Medical, which I think I'm actually slipping a little bit into the previous year, talked about who did driven security and how they give those. That came up earlier as well with T-shirts, even all the way back to Optimizely, which I think might be my first episode on the show.

The segment team gives stickers at the end of – these unique stickers that you only get if you've passed security training. Definitely positive security celebrating people that do it well, anywhere from stickers and hoodies, to just giving exposure and recognition to someone who does something well, that was a great tip.

[0:38:33] Simon Maple: The swag-driven development model.

[0:38:34] Guy Podjarny: It is. It works.

[0:38:35] Simon Maple: I like it.

[0:38:36] Guy Podjarny: We're all just humans. There was a lot of focus on scaling security basics before you move on to the next shiny thing. I refer to that a little bit before, but security hygiene at scale. I think for a concrete tip is put aside the advanced persistent threat and the funky new attack vector and just invest in automation and in how do you scale activities. There were some concrete things, like try to reuse tools from the ops side of the fence to apply them to security, make sure that security is embedded elegantly into your development environments, so you're not asking developers to log on to yet another portal and work over there.

Org-wise, concrete advice about aligning security teams to dev teams. I most liked Envision’s model, where they literally take, like you think a lot of companies do these finance teams, or HR teams have this HR partner to these different business units. Envision embrace something similar for security and their AppSec teams are basically aligned. Every AppSec engineer has a set of development teams that they support, which I really liked. The team still works as a team, but their primary affinity almost is into these dev teams that they work. Therefore, they can embed. They can be a part of that.

Then, I guess, last is something that I've totally embedded into my vocabulary is this notion of the paved road. This, I think the first time I heard it was from Jason Chan at Netflix, but it definitely came out more later on. This is the idea that one way to manage, or to balance agility of the different teams with some consistency and methodology across the company is to create a paved road to say, here's a set of practices, tools that we the security team support and we make it super easy for you to use that paved road. Just stay on the paved road and life is going to be easier.

If you want to go off-road and you want to go on the dirt, then you can, but it's going to be harder. You need to take on a bit more responsibility. You need to do more of the work yourself, because we haven't paved it for you. I really, really liked that approach, and I think that's a concrete approach that then people can do is even just sit down and define what is the paved road, as opposed to just this nihilist, you can do anything. There are no rules. We'll just match you development team, or the draconian, no, you do it our way, or the highway-type approach. I thought it was a really good middle.

[0:41:00] Simon Maple: Great. Let's look forward again to 2020. Perhaps, offer the classic dinner guest, your ideal dinner guest style question for Emil, who would you be your ideal guests and perhaps topics of some of your 2020 episodes going forward?

[0:41:16] Guy Podjarny: It's hard to point to a specific guest. I have a, I think, a great topic that I have in mind. I think a guest is, there are many people I want to talk to. I'm fortunate enough that actually, a few of those are already scheduled. From a topic perspective, the one that interests me the most is indeed, this notion of unravelling cloud security. It feels so messy. Where on one hand, it's a very clear and immediate need to wrangle these 100-plus AWS accounts, to we see all the security breaches that happen by super capable security teams, because they missed some file, one file.

Definitely super important, but I feel like, it's not clear where it's headed. It's not clear whether, first of all, terminology is a mess. You talk about SecOps teams and you see on one hand, you see the same name SecOps is a team that handles detection and response. Just Eat in Stu Hirst's world. In Auth0, that very same name is actually more of an SRE, more of an engineering team that builds platform, and there's a separate detection and response team, right? Or in Envision, that same team is called DevSecOps, and Smartsheet calls it infrastructure security. Are these things the same? Are they different? Where should they be headed? This whole aspect of the infrastructure that moves into the scope of the app, what is the future of securing this app-led infrastructure?

[0:42:40] Simon Maple: Do you think they will converge to a common home across the different companies? Or do you think it's okay for them to just exist in different parts of the organisation based on the company?

[0:42:48] Guy Podjarny: Yeah. I mean, I think the short answer is I don't know. But I feel like, there is going to be an aspect of what is currently CloudSec that needs to move into AppSec, because it becomes such an intrinsic part of the application that how you deal with it – once again, AppSec is a supporting organisation for dev. They do a lot of responsibility themselves, but they can only scale through development. DevOps is a supporting organisation for dev, once again. The same notion, they build a bunch of stuff themselves and they do a lot of the work. But to scale, they need to get the dev teams to build operable software.

Cloud security is a little bit weird, because it's a supporting organisation to two supporting organisations almost, right? They help DevOps on one side, they help AppSec on the other. Then they help dev as well. It's not entirely clear where that's headed. Of course, they have their own responsibilities and direct ownership. That's more the infra-security side. I feel just the definition of it needs to shift. There are portions of it that needs to move to AppSec and become just a part of the product, a portion of it that needs to be embedded into your APM platforms, into your infrastructure monitoring platforms that actually move to DevOps.

We see a lot of this. We see a lot of platform teams owning security aspects. Definitely, we see it in Snyk’s world. Then there's probably still a missing piece there which is indeed, wrangling the infrastructure security, what used to be the data centre security, or the server security. I don't know what that looks like. Does that just get embedded into DevOps? Does it live long term? Yeah, I don't know. Selfishly, one of the reasons I want this topic to be dug into is because I want to end 2020 with a with a more crisp answer.

[0:44:23] Simon Maple: Excellent. Guy, to finish off, one of the questions, I'm going to spring this on you now, one of the questions that you said you ask on pretty much every guest at the end of every episode is what your pet peeve would be, or what advice you would give to your listeners. I ask you Guy Podjarny. Here, given that we've got you as our captive guest now, what is your one pet peeve, or piece of advice that you would give to listeners?

[0:44:47] Guy Podjarny: I think my primary piece of advice would be to focus on the future, not the past. I think, all too often, when you look at a security problem, or security solutions, people judge it based on current reality and what they have previously seen, versus taking a moment and say, where do I want to be in two years’ time? What do I think the world would look like in two years’ time? Then the security solution you implement needs, or whether it's org hires, or it's a tool that you purchase, or it's a methodology, or process that you're doing in your organisation, no matter what it is, it clearly, needs to serve today's needs, otherwise, it's no good.

It needs to be a solution that helps you get to that destination, versus one that holds you back. Otherwise, security is always going to be behind. The only way to get ahead is to implement solutions that think about where is it that you're headed in. Oftentimes, your company will have a path. You just need to know it. What is the path? What is the technology landscape? You can figure out, you can take your best guess about what's the market landscape and the adversary landscape, and just make that your first question and then present and only then, past. If you don't do that, then every year, you're going to need to reorg and rehire and retool everything you do.

[0:46:15] Simon Maple: Wonderful. Guy, it's been an absolute pleasure, I guess, being invited onto this podcast and asking you some wonderful questions. Thank you very much.

[0:46:25] Guy Podjarny: Thanks, Simon, for being a great interviewer here, and we'll see. Maybe I'll pull you in, just sort of help.

[0:46:32] Simon Maple: Oh, no, no. Not again.

[0:46:32] Guy Podjarny: A bunch of those. Thanks everybody for tuning in to it. I think this is a good time to talk a little bit about more structural changes that we're doing it. We had an amazing year here in The Secure Developed Podcast, we've had more episodes than ever really. We pulled in, if you've noticed outside, we've pulled in over the course of 2019, we've pulled in The Secure Developer into a part of MyDevSecOps as a broader community.

What we're going to do in 2020 is move it off where the podcast has hosted today, which is Heavybit and onto the MyDevSecOps platform. Heavybit, which you've probably heard many times at the opening to this podcast, is a great programme that Snyk is a part of, that really helps developer tools build up and shine and have great assets in them. They've graciously been hosting and helping us make this podcast happen over the past few years. We're still very involved, we're engaged with them as we engage in more and more community activity and just broaden the scope of security education and collaboration, we foster here under MyDevSecOps, we felt like the right home for this to be right alongside those. You can expect the podcast to move to MyDevSecOps.

We're also relating the podcast to a lot of the activities we're doing online and in DevSecCon, which is a great conference that we also help accelerate and amplify here at Snyk. What we're going to do is we actually recorded some DevSecCon episodes, some special episodes that maybe use some of the great content that we have on stage at DevSecCon, as well as some great conversations we've had with speakers from that event. You can expect that coming in 2020.

Then in general, just have cadence, or keep up the cadence. Sam has joined us. You don't know her, but behind the scenes, Sam Hepburn has been driving a lot of this growth in cadence and in amplifying and equality of content over here. Thanks, Sam, for being a part of it. With her help and the community team here, we will build up that – keep up the cadence, have an episode at least every two weeks, so by the end of 2020, we actually have even more episodes than the records that we've broken this year.

That's it. That's a wrap for 2019. Hope you enjoy the show. Thanks everybody for tuning in to this episode and for the shows this year. I hope you have a great break and I hope to see you both in the new year and in the next episodes.

[END OF INTERVIEW]

[0:49:04] Guy Podjarny: That's all we have time for today. If you'd like to come on as a guest on the 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.