Ep. #44, Year in Review with Guy Podjarny

Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer.

I'm Guy Podjarny and today we're actually going to do something a little bit different, hopefully not to your chagrin, where I'm going to be the guest over here.

What we're going to do is we're going to look back at this year's episodes, because we had so many of them, and try to re-share 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.

Simon Maple: My pleasure. It is a true pleasure to be on The Secure Developer, and I'm looking forward to asking you some searching questions about The Secure Developer in 2019.

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, and we have had so far 697 minutes of content with 21 guests over the year.

So, pretty interesting stats.

Guy: It's amazing how time flies forward. Definitely the most we've done in a single year by a good margin here.

Simon: Let's talk about, of the 697 minutes, which was your favorite? No, I won't ask you that.

Guy: We'll get very detailed here.

Simon: Yeah, let's get very detailed. But let's talk about how 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 there, so why don't we start with a question about what some of the recurring messages across the episodes were this year?

Guy: There are definitely many different insights as we went through it.

So digging into some recurring things, I definitely like to ask a lot of the guests how they got into security.

One interesting observation is maybe the lack of a theme here, which is that there are very different answers to that question.

There are many different paths to security.

In a more recent episode, we had Andy Ellis talk about how pretty much he 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 and that led him to his first job at Akamai.

I don't think it's quite 20, but it's just shy of 20 years later and he's the CISO there and doing an amazing job at a massive company.

We had Tanya Janka talking about how she was organizing 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 Kate at The Guardian and Sarah at InVision, and various others talked about how they got into it.

So that was interesting, like many different paths into security.

Related to that, when I spoke to Tanya, she does a lot of great work trying to get more people to get into security, and she does these mentoring Mondays on Twitter.

Just trying to increase or push for more of that diversity in security, and different paths.

So that's one really interesting observation, but 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 to 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 strong this year.

There was a lot of DevOps related references, like Duncan who runs security at AuthZero talked about that.

He talked about how his own team operates like a DevOps team, they own what they build and operate it and run it.

There was a lot of a more broad view from Justin Somaini, who talks a lot about the skill set that the different teams need to have, that security teams need to have.

Maybe going from more of a sysadmin type background into more of software engineering, or maybe from project management to more software engineering.

You see things around team structures, so a lot of teams report to CTO and engineering organizations, and sometimes even comment how that's different.

Actually, sneaking a little bit further back, I think in 2018 we had an episode with the CISO of Slack, and Jeff was commenting on how it was actually a big deal to make them be a part of the engineering organization.

This was echoed back in various episodes today, so definitely a lot of examples on how security teams have changed. The list goes on.

Kate at The Guardian, she definitely does 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, it was just before he was rolling out an embed program more officially, but around how his team embeds itself into development teams to help them build software.

Leif there as well, in 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 the 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 talks about partnership a lot and a lot of those types of quotes, and 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, so definitely a very strong recurring theme is how the security teams themselves need to change to fit this collaboration.

Simon: 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 are adopting more agile processes, or adopting DevOps 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 hasn't been as many changes in the org structure of a security team, versus a development team.

Guy: I think that development teams, the change they're experiencing is very much around digital transformation.

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 and less baggage type companies.

From AuthZero to Segment to SmartSheet.

Then you have a lot of enterprises, so when you look 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.

There was a lot about "How did 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 ex Box and Yahoo! and Symantec, and he's had very rich experience.

He talks, and he actually had this great quote there.

He talked about how security is never going to be as agile as the lines of businesses, so you have to think about "How does a distributed or integrated security model would work?"

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 episodes, talking about how I think he called it "Cybersecurity 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 insecure software, which clearly is not an ideal. Or the third option which you aspire to, which is embedding security.

That's definitely a dev team change, and we've got a bit of a taste of that from the opposite side.

We had Brian at Liberty Mutual who was really a great example of that, talking about he is on the dev side.

He talks about how he's basically a head of the security team, so 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, and I think a little bit earlier in the journey was Mohan from Prudential.

He talks about how they're building that program, how they're building that DevSecOps program.

Going back to Andy a little bit at Akamai, it's interesting.

He talks about how the intrinsic security thing has actually been built early, he almost didn't know better when it started because it was his first job.

When he built security to be core and a part of the responsibility of the ops teams and of the dev teams, but the change that they're undergoing is more about making things more agile.

They're already doing well to have teams own that responsibility, but now doing that as the dev team has 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.

Simon: And when we see these changes in both security teams and development teams, where would you say the greatest inertia exists?

Because obviously people naturally want to continue doing what they're doing in day to day lives.

In all of our episodes, the guests from that we choose are obviously already doing security far better than many other teams and organizations that exist.

Where would you say generally would be the inertia in other organizations, which some of the guests that that we're talking to have already succeeded?

Guy: Probably the change that justifies a change is really around DevOps, and it's around indeed that.

You can call it "Digital transformation," you can talk it to DevOps. But DevOps does two things, one is as DevOps gets embraced more and more in these companies, then there needs to do something.

Things just change, and now you have to adapt. You have to fix it.

But the other thing is that DevOps gives us this model, and there were a ton of references to how DevOps is a model throughout the show.

We had Sarah at InVision talk about how they actually call their-- They have a team called Dev SecOps, which is more like a cloud security infrasec type team.

They actually call those people security SREs, there was definitely references on the dev side on how just like how we operate it, we also need to secure it.

So 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.

Simon: 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?

Guy: If there's anything we can say from these conversations or from the episodes this year, is that container security ownership is messy.

It is very unclear. On one side, I'd say the more common pattern amidst guests is we think about Stu Hirst from JUST EAT, or you think about Duncan at AuthZero.

You definitely see a lot of methodologies that are more VM-like, so the thing about containers is the evolution of the VM.

Simon Bennett from Bitnami talked a lot about the golden image and how do we handle it, but 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, the team that previously patched the VMs.

But it also seems pretty clear that it's not the destination, and today we're in flux. We're in that twilight zone today, so that's definitely come.

They've shown very brightly through the many conversations.

Simon: First of all, I must say actually, the namedropping level of this podcast so far has been set to expert in this episode.

But it does -- It's actually a testament to the caliber of the guests that we have.

Guy: Absolutely. In each of them there is sound bytes, there's quotes, there's these insights. I enjoy it.

Really, for me this is for my own benefit, my own selfish interest. I learn so much from every one of these episodes.

Simon: Excellent. With the conversations that we've had with all of these podcast guests, let's take a step back and think 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?

Guy: Sure. There's definitely been a lot of improvements, and I've had--

We're talking about 2019, but I sense a bunch of these things and how good practices are being done and how that differed over the three or so years of the podcast, nearly four years.

So, what are we doing well? Definitely a great emphasis on automation.

I think this really shone brightly throughout the episodes, to go from Simon Bennett indeed talking about Bitnami and golden images to Tanya Janka's talking about security unit tests and how they're fast and accurate.

That also came up with Tomer from Saluto a little earlier in the year. Duncan at AuthZero, 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, so emphasis on automation I think is appropriate.

I think we're doing well, and nobody's really quite happy at their level of automation but the attention to automation is good.

Simon: This is something I see day to day when I talk to customers, it's that 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.

Guy: Yeah, absolutely. It's a change because a lot of security solutions don't necessarily have it, and I guess that's the other bit that I would say is improving.

It's also a change in the skill set, so I definitely have heard much more this year that people are hiring and that security teams are hiring into their teams with an emphasis on software engineering abilities, with hiring coders and hiring people that can program.

A lot of it is coming back to that automation bit, like 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.

So, definitely can clearly see the change in the hiring profile.

I love how Justin had a lot of great sound bytes there, in his insights, but he talked about how teams should move from governance via advisory to governance via product delivery.

Peter talked a lot about skills, and definitely skills are evolving.

I think we're doing that well and it's still a path, and 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 build security and integrate very elegantly into the tools the 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 core constituents, 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, Liberty Mutual there with Brian and that digital transformation project that they're running is a good example.

Jeff MacArthur, who was at Microsoft at the time, talked about how he was running their open-source program, and security wasn't security, like that wasn't his job.

But it definitely was a lot of his attention as we built that.

Simon: And it equally comes down to ownership as well, from a developer point of view, the approval or 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.

Guy: Yeah, very much. It's the "It takes two to tango" type of approach.

You can't get collaboration when only one side wants to do it, so both parties have to come to the table.

One thing that as an industry 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 empower developers.

There is 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 is a good way or an acceptable way to address one risk or the other.

I hearken back to one of the early episodes with Sean Gordon from New Relic, and 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, and I think I told him then that we all owe him a beer for that.

I think he should really be quite drunk by now, just seeing the change that happens, just one of the recent ones with Duncan at AuthZero who talked a lot about how this is a healthy conversation with the auditors.

So, those are the things we're doing well so far.

Simon: It sounds like we can go for a beer ourselves, it sounds like we're in a pretty good state ourselves.

Guy: I think we still have a little bit of our work cut out for us.

Simon: There always is, isn't there?

Guy: I think for the areas that we need to improve, clearly--

First of all of these things that we mentioned 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 the security champions program, 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, Tomer at Soluto, or Asurion.

Asurion as a whole have these security mavens program that he's a part of, and Tanya Janka 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 program.

I think we have a long ways to go to understand it, even within a company.

The conversation with Tomer 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?"

Simon: I absolutely love the work that Asurion did, actually, with the security mavens.

I think it's really important, by educating developers I think they use their security team to educate their own developers as well, somewhat.

It's less of a "Them and us" model, as 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 program in, how much more the security developers talked.

Not just through the security maven to the security team, but just in general across teams. The interaction was far greater.

Guy: I think they are 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 they are people that carry a partial security responsibility.

There are many more of them than there are in dev, but I do think that nobody really has a winning formula and nobody really has a model that should be replicated or structured.

I think we should go forward and just evolve that, as an industry.

Simon: Why do you think that is?

Because it seems like it may differ a little bit from company to company and team to team, but the idea of pooling 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 the idea of having security champions in development teams, why is that not something that can be easily replicated?

Guy: I think a lot of it is really around expectations of what is to be accomplished and what's the division of ownership, so you see this with--

Even with that mavens program, or I had conversations with Autodesk outside the podcast around their security champions program, 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.

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.

What it ends up being is it ends up being, which is very useful, a community.

Security champions collaborate with one another and they learn, and 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 consideration about security, they raise that flag. So that's valuable as well.

It ends up being 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 hard to know-- It creates more of a community, but it doesn't create a program.

It's not clear that you can say "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, like Tomer 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 vs. having the program structure it.

I think the fact we're embracing it is a positive thing, and 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. I think that has not yet been created.

Simon: 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?

Guy: Yeah. Container security is indeed, 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 is a dedicated cloud security, or infrastructure security, or various names for this team.

Definitely yet another aspect of security that kicks in.

I would definitely say, if security champions is one, container security ownership is another manifestation of ownership challenges and definitely another area to improve.

Then may be , 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 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, so 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 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?"

Because you can't optimize what you can't measure. We have to get that barometer.

That's definitely an area that that we need some serious improvement on.

Simon: 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 were their specific challenges that they're going to have in security in their organizations?

Guy: 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 McAffer at Microsoft talking about Microsoft's scale and how they had to build things in-house just to be able to track which libraries and which components they're using.

Given the scale of Microsoft, 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?"

The volume of work they do, Jason Chan described the same problem but they tackled it in a much more decentralized way.

More empowering developers to do it and building tools to help those developers know what they're doing, but really, security hygiene at scale, doing basic things like 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, but doing it for 10,000 libraries gets pretty darn hard.

That's definitely the recurring theme, and we've seen also, 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.

So we're finding more security issues and we're not really addressing them.

We had the top 10 Docker images that have a bunch of dependencies in them, the top 10 having at least 30 vulnerabilities each, and 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, four and five vulnerabilities that get discovered is in indirect dependencies.

Not in the 10 libraries you used, but rather in the 500 libraries that they in turn pulled in.

Simon: It was 78%, in fact, in indirect libraries. Did these numbers, did they shock you or did they surprise you?

Or were they really a reaffirmation of what you already believed?

Guy: I don't think this is news, I think it's just that we're seeing it happen in scale.

So cloud 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 is an order of magnitude more containers than there were VMs.

That, in turn, was an order of magnitude more than physical machines.

More volume implies more risk, and it's not really a 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 even when these were datacenter machines.

There's definitely just another order of magnitude, so it doesn't really surprise me.

It also manifests in the cloud security side, so you definitely see Duncan at AuthZero talk about how they have 150 accounts.

I think Stu at JUST EAT talked about 100 AWS accounts, and it's not natural.

It's not obvious for you to think that a company would have more than one AWS account, or two or three, or if they have 100.

But 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 who launched Repo Kid as a tool, and 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 centralized "Can I still contain that agility?"

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 who mentions those as one of their biggest challenge.

I think the second big challenge, which is very related, I was referring to centralized versus decentralized 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 or people's skillset is really hard.

So 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.

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 it'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, the result of "What is the role of the security team within the company?"

Therefore, "What are the skills that you need within the security team?" Again, we heard--

You see the magnitude of the program that Mohan at Prudential is trying to roll out and how it touches every different aspect of the organization.

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, but 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, InVision and Segment and One Medical.

But for enterprises, it's still very much a work in progress.

I'd say those are the primary, like it's security hygiene at scale on one side and the culture change plus that skillset shift are probably the biggest challenges that the security industry and security teams face in 2020.

Simon: With so many amazing guests that we've had on The Secure Developer over the last year, and in fact as you've mentioned, the last few.

In terms of what you've learned from our guests, what would you say the most important things are?

And maybe some of the things that you sometimes thought, "Maybe we can do that in our org as well as what others can consider making changes in their own organizations?"

Guy: Yeah, there were so many episodes that I felt like, if I was left to my own devices I can go on for an hour or two more.

Probably my two biggest insights are related, and they're really around that change in the scope of the application and how it relates to cloud.

So 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, and 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, I asked him "OK, look. 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 they not there?"

And he was saying, "I think it's the start of a journey and they probably should eventually land over there.

But today, they work in cloud sec and they're different, I asked Sarah at InVision around--

They have 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 called DevSecOps and they refer to people there as security SREs.

I asked her, "How are those different than--? Did they work with dev as well? And it's like, "Yeah. They do work in dev."

It sounds like there's a lot of well minded individuals in these companies, AuthZero is another example.

So, it works, but I feel like that delineation surprised me a little bit.

I guess I came at it from a slightly more dev minded view and I thought a lot of these aspects of cloud or of the application of containers, they're just an evolution of the app and therefore clearly they should be a part of AppSec or definitely part of product sec if that's how you define it.

But in many ways, these cloud security bits are an evolution of infrastructure security. They're more an evolution of maybe the sysadmins and what you've done to patch your servers indeed.

That's one aspect that I've learned, is just that there is a very interesting line and I think there's more to explore over there between cloud security and its various names, and AppSec.

Where should they stay different, and where should they be the same?

But I definitely have learned that is not that given, so related to that is maybe this growing realization 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, and that the application has really changed in nature.

Sometimes you think about "App" and you think about code and libraries, but oftentimes in a modern world you think about an app and you think about so much more.

About the containers, about the network layer, about so many things.

So definitely, I like I think it was Jason at Netflix, Jason Chan talked about how there's really this line between infrastructure and the network that goes away with cloud, because now with the infrastructure, the network is just embedded in.

I think there is basically another line, another layer there that is into the app itself.

The line between the infrastructure and the app, does that go away? I think that's probably my most meta perspective, and I think on a practical "How should you approach security?"

I loved some of the guidance that I got around focusing on the threats.

I was surprised, and I think in hindsight I was 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, and 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 overinvesting in an area that doesn't matter and staying exposed on an area that does.

So, that element and how embedding that into your developer security collaboration and maybe tying back to that security agent at scale, how important a role he plays there was definitely great insight for me.

Simon: From a listener point of view, I guess there's going to be a lot of people out there working in security teams, working developer teams.

I love all the high level discussions, but when it comes to the actual day to day roles what can they take away and what actionable things can they do to actually start implementing some of these ideas?

Guy: 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 allowed a great practice around celebrating success and how that's key for a developer adoption. Just basic human properties, you have to--

You can't 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 are that we had Siren Hofvander talking about making cakes for nothing, for basically for nothing happening, just making those or 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, we talked about hoodie-driven security and how they give those, that came up earlier as well with T-shirts, even all the way back to "Optimize,"which I think might be my first episode of the show.

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

Simon: The swag driven development model. I like it.

Guy: It is, and it works. We're all just humans.

There was a lot of focus on scaling security basics before you move on to the next shiny thing, so I referred to that a little bit before, about security hygiene at scale, but I think for a concrete tip is to put aside the advanced persistent threat and the funky new attack vector and just invest in automation.

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's embedded elegantly into your development environments.

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 InVision's model where they literally take--

You think a lot of companies do these finance teams or HR teams have this HR partner to these different business units, so InVision, and embrace something similar for security in 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 teams that they work, and therefore they can embed and they can be a part of that.

Then last is something that I've totally embedded into my vocabulary, is this notion of the paved road. I think the first time I heard it was from Jason Chan at Netflix, but it definitely came up more later on.

This is the idea that one way to manage 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 and tools that we, the security team, support. 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 and 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."

So I really liked that approach, and I think that's a concrete approach that people can do.

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 to a development team," or the draconian "No. You do it our way or the highway," type approach.

I thought it was a really good middle.

Simon: Great. Let's look forward again to 2020, and perhaps the classic dinner guest.

Your ideal dinner guest style question for a meal, who would be your ideal guests and perhaps topics of some of your 2020 episodes, going forward?

Guy: It's hard to point to a specific guest, I have 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 I actually have a few of those already scheduled.

From a topic perspective, the one that interests me the most is indeed this notion of unraveling cloud security.

It feels so messy, where on one hand it's a very clear and immediate need to wrangle these 100+ AWS accounts, to we see all the security breaches that happened by super capable security teams, because they missed some file or one file.

So, it's 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, and JUST EAT in Stu Hirst's world and in AuthZero that very same name is actually more of an SRE, more of an engineering team that builds platform and there is a separate detection and response team.

Or at InVision, that same team is called DevSecOps and SmartSheet calls it infrastructure security.

So, 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?

Simon: 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 organization? Based in the cloud?

Guy: 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 cloud sec 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 organization for dev.

They do a lot of responsibility themselves, but they can only scale through development and DevOps is a supporting organization 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 the operable software.

So cloud security is a little bit weird, because it's a supporting organization to supporting organization, almost.

They help DevOps on one side, they help AppSec on the other, and then they kind of help dev as well.

It's not entirely clear where that's headed, and of course they have their own responsibilities and direct ownership.

That's more of the infra security side, so I feel just the definition of it needs to shift.

There are portions of it that needs to move to AppSec and just become part of the product, a portion of it that needs to be embedded into your APM platforms, into your infrastructure monitoring platforms, and 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 center 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? 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.

Simon: 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?"

So I ask you, Guy Podjarny, given that we've got you as our captive guest now, what is your one pet peeve or piece of advice that you'd give to listeners?

Guy: 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 vs. taking a moment and saying, "Where do I want to be in two years time? What do I think the world would look like in two years time?"

And then the security solution you implement needs to--

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 organization, no matter what it is it clearly needs to serve today's needs.

Otherwise, it's no good. But it needs to be a solution that helps you get to that destination, vs. 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?"

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.

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 re-org and rehire and retool everything you do.

Simon: Wonderful , Guy. It's been an absolute pleasure being invited onto this podcast and asking you the some wonderful questions. Thank you very much.

Guy: Thanks Simon, for being a great interviewer here. We'll see, maybe I'll pull you in to help.

Simon: No, not again.

Guy: Thanks everybody, for turning into it. I think this is a good time to talk a little bit about more structural changes that we're doing.

We had an amazing year here in The Secure Developer 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 my DevSecOps as a broader community.

What we're going to do in 2020 is move it off where the podcast is hosted today, which is Heavybit, and onto the my DevSecOps platform.

So Heavybit, which you've probably heard many times at the opening to this podcast, is a great program 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 that we foster here under my DevSecOps.

We felt like the right home for this was to be right alongside those, so you can expect the podcast to move to my DevSecOps.

We're also relating the podcast to a lot of the activities we're doing online and in DevSec Con, 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 DevSec Con episodes, some special episodes that maybe use some of the great content that we have on stage at DevSec Con, as well as some great conversations we've had with speakers from that event.

You can expect that coming in 2020, and then in general just have cadence or keep up the cadence.

Sam has joined us. You don't you don't know her, but behind the scenes Sam Hepburn has been driving a lot of this growth in cadence and in amplifying an inequality of constant here.

So thanks, Sam, for being a part of it.

With her help and the community team here, we will build up and 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.

So, that's it. That's a wrap for 2019. Hope you enjoyed the show.

Thanks everybody, for tuning into 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 episode.