A Year In Review With Simon Maple

[00:00:37] ANNOUNCER: Hi. You’re listening to The Secure Developer. It’s part of the DevSecCon community, a platform for developers, operators and security people to share their views and practices on DevSecOps, dev and sec collaboration, cloud security and more. Check out devseccon.com to join the community and find other great resources.

This podcast is sponsored by Snyk. Snyk’s a developer security platform helps developers build secure applications without slowing down, fixing vulnerabilities in code, open source containers, and infrastructure as code. To learn more visit snyk.io/tsd. On today’s episode, Guy Podjarny, Founder of Snyk is joined once again by colleague, and field CTO, Simon Maple. Simon takes the role of host in this episode and chats to Guy about key 2021 podcast themes. Topics include hiring people with development experience into security teams, and how empathy both ways, makes a huge difference to collaboration, as well as the need to adapt security education to be more accessible to developers.

They discuss the growth of DevSecOps activities in government departments, and some of the latest observations around how cloud security work is being handled by different teams today. Looking forward to 2022, some of the key topics to discuss include supply chain security, measuring security, which is still an unsolved problem, and the future into cloud security as we see the dynamics changing in the organization. We'd also like to go deeper into the more highly regulated industries, including potential regulation changes, and how they might affect us.

Scaling DevSecOps across large organizations is another interesting topic, as well as continuing to do more in diversifying the community. We hope you enjoy that conversation, and don't forget to leave us a review on iTunes if you enjoyed today's episode.

[INTERVIEW]

[00:02:45] Simon Maple: Hello, everyone, and welcome to The Secure Developer podcast. This is a yearend episode and we're going to look back on 2021. My voice you may recognize as the yearend episode recorder, I'm here with a more familiar voice, Guy Po. Guy, how's it going?

[00:03:02] Guy Podjarny: It's going well. Thanks, Simon. Thanks for taking this one up.

[00:03:06] Simon Maple: Absolutely. Yeah. So why don't we do some intro? I'm Simon Maple, field CTO here at Snyk and joining me, the man, Guy Po, Guy Podjarny. So, Guy, why don't you tell us a little bit about yourself, in case anyone doesn't recognize your voice.

[00:03:20] Guy Podjarny: It's funny, every now and then you sort of think about the fact that you don't want to take it for granted that people know what you're up to. So, if you happen to not know, I am the Founder and President at Snyk and really, president is not an overly descriptive title. In practice, I try to think about what's ahead and helps steer us a little bit and some of the strategy and kind of next directions at Snyk as we grow, which has been a fairly steep growth curve over the course of really, like a bunch of years, but definitely this last year as well.

[00:03:51] Simon Maple: Yeah, absolutely. And for those of you not familiar with the year-end format, this is where I ask Guy a number of questions, looking back on the episodes that were recorded and showed in 2021. During the year, we did 22 episodes with 23 guests. So, a great number of people, of experts, in different various companies and organizations that we were able to speak to.

So, Guy, let's jump straight in. And really, first of all, this is a similar question that I asked last time, and it'll be interesting to see if the answer has changed here. We're really looking at some of the recurring themes, recurring messages that people were were talking about during the episodes across 2021. What were they and how did they differ from the previous year?

[00:04:32] Guy Podjarny: It's a good question. I find one of the things I like about the sort of end of your episode is that allows me to go back and re-listen to some of the episodes from the beginning or sort of look at them. Again, reminded of some of the great insights that we got from folks, and it does feel between pandemic and sort of Snyk space, like an era, like an old sort of many, many, many years ago, in a galaxy far, far away when you just sort of go back to January or February.

I think the messages were really, a lot of them were along sort of similar lines as in 2020. But a little bit less pandemic shock and more just sort of reality, and a little bit more maturity, a little bit more about the next stage. I think, if I try to sort of summarize them a little bit, probably the top theme that was very consistent and evolved from the year before where it was more of a novelty was the notion of hiring developers into your security team, or hiring people with software engineering skills, really heard a lot of that over the course of this year.

I guess, wrote it at the X very recently, Rinki, Twitter CISO, dev, really it says security at Figma, really many others stated that they would prefer to hire engineering skills over security skills if they had to choose. In general, we’re aligned that it is, on one hand, they feel like it's easier to teach engineers security than to teach security people engineering, but also because they feel like that gives them better empathy and kind of better ability to interact with the engineering teams.

That was definitely something that was more of a thought in 2020 and really became, I think, increasingly the norm at least that meets my somewhat selection bias that influenced guests over here, which I guess relates to a second and very similar related theme, which was this need for security to adapt to development. I think we, generally, especially when I think back to the beginning of Snyk six years ago, or the beginning of this podcast that a year or two later, a lot of the concern was around security people trying to force their practices, getting developers to do as security does. I think the realization came out loud and clear this year that people are looking to do the other way around. They're saying, “Okay, let's see what development is doing and think about how do we adapt our security practices to still be secure, to still, we have security in but adapted to development.”

You heard a lot of different versions of this, Amanda, at Cisco talks a lot about empathy, and really kind of dug into how it's important and how you can build it up. And Nick at Pearson, really emphasized that as well, talk about how, aligning to the engineering teams there, and to their practices is very key. Dev at Figma, he really went as far as saying that I love that sort of phrase, that when he goes and asks for a developer to do something, that “I need you to handle this aspect of security”, he goes as far as starting with an apology saying, “Hey, I'm sorry. I'm going to need to have you to – there’s this security need, I haven't figured out how to spare you the need to do it yet. So, I'm going to need to ask you to make sure that you, whatever, sanitize inputs or whatever it is that concern.”

For some people that feels almost a bit extreme, but I liked how it is embodied. The concept in and, in general, Dev had a lot of great tips about bonding, between dev and security, especially in the sort of remote working surrounding through working together on incidents and other collaborations. So, I felt like those two were probably at the top. Does that make sense?

[00:08:16] Simon Maple: Yeah, absolutely. I actually think they're really actually going hand in hand because I feel like hiring developers into your security team – actually, first of all, with a talent shortage that has been very, very widely reported around, people struggling to find people with security aspirations to join their team. Having a larger pool to hire from particularly in developers really goes a long way to—I would say—helping the hiring groups there.

But I would also say, yeah, the empathy; it's one thing to try and teach empathy in this sense of teaching security folks, you need to be able to understand what the development teams are going through their perspective, et cetera. But it's one of those things that's just built in when you hire a developer, right? Because it's just a developer, someone with development experience talking to someone with development experience, and you don't actually need to train something like that. It's more something that is just built-in and understood from the security team. So, I think that's a really valuable thing, which is very useful from the engagements.

[00:09:12] Guy Podjarny: Yeah, yeah, I agree. I think, sadly, the scarcity of developers is starting to kind of get right up there with the scarcity of security people, but it's still probably like you've got a better shot at hiring that way. I think the counter or the other thing that I saw was on the flip side, and this is definitely a little bit of a selection bias. But it's not so much the counter but rather a complimentary side of it, is that at the beginning of the year, especially, but really, throughout the year, managed to get a bunch of guests that are working on developer tools, and came to talk about security. It was partially intentional, but it was also the result of just a lot of interest and activity that happens within the dev tooling world when it comes to embedding security in.

I think that's the other thing that really changed this year. This acknowledgment by dev tools of the development, sort of ecosystem and community that security isn't a thing that's off to the side, but rather that every developer tool has some amount of responsibility to build security into their workflows. So, you had Justin Cormack who is Docker CTO talk about helping developers be secure by default, and do we run or do we fail Docker builds and scans at the beginning, and the addition of Docker scan, to flag those.

We had James Turnbull talk about DevOps type metrics like service level objectives or SLOs, and others, and how do you apply them to security? How do you think about security observability? So really saying, okay, how do we take the DevOps practice and apply it to security. And there was this super insightful episode with Liz Rice, and she was describing eBPF, which is a great kind of underpinning technology that's coming around in the DevOps world. But you know, talked about how we can level up security.

So, I think it's working on both sides, which I guess has to happen for success. Security is adapting to development practices. But development tools and development leaders are really, kind of embracing security and thinking about security responsibility. If I veer a little bit off the people route, I guess, not too far off and I'd have to think about tech, there was definitely a lot more mention of security education in this year's episodes and guests. There are actually like three episodes that were almost entirely about it. We had Joshua from UHG UnitedHealth Group, describe how they do practices, that sort of education practices. Actually, this super cool and fun way to do it if you haven't listened to the episode, it describes these quests for security education, things like that, very recommended to listen to it.

Jett from Nike talked about how we had to adapt their security education practice, from classrooms to the remote work, and he did things like an intern podcast, where he brought external guests to it, and which sounded super, super useful. We had David Wheeler, from the open source security foundation, the open source asset, for in general, who works at the Linux Foundation, talk about kind of an ecosystem education, and how do we bring that into schools and into software development practices.

So, there are a lot of emphasis that came around this. Only one of those three episodes was actually teed up to be education. So, a lot of them there was just about the impetus of it, but also lots and lots of mentions about the importance of security education, and equipping developers in the right fashion, with the information they need, all the way through the ecosystem, which was super interesting.

[00:12:39] Simon Maple: Yeah. I think that awareness among development teams around the importance of security and how to do secure development well, is something which is just becoming a greater and greater thing that organizations want. But it's still one of those things, without that empathy, it's very, very hard to do well, like a lot of security programs, and fairly broad programs that are given to organizations or development teams. They're very often just way off in terms of the relevance, in terms of what the development team actually want. It actually becomes an overhead. So, it's a big challenge, in terms of getting the development teams, the style of knowledge that they actually want for it to actually be useful to them, and for them to want to listen to that education.

[00:13:22] Guy Podjarny: Yeah, absolutely. And it's about caring that they actually learned from the process. So not just thinking, “Hey, I have this checkbox that I have to check around giving developers security education”, I'll do something, it doesn't really matter if it's effective or loved or not, it just satisfies the compliance requirement, versus actually engaging and saying, “Well, how do I invest creativity and time and resources in finding the right way to have them truly understand, truly learn, truly embed?” And there's still definitely a gap around being able to measure the impact of that. That's definitely still a gap, but the importance of it has clearly gone up and it's been mentioned in many, many, by many, many guests.

I guess the last recurring theme, I'd say, doesn't really point to one episode or the other. But more overall, is this notion of security hygiene at scale. You talk to people about what worries them, to the guests, but what worries them, talk about where the emphasis are, what their priorities are, and a lot of them are just about being able to lock your doors and your windows at scale at the pace that we are working at today in modern development and cloud development. So, it wasn't really about some fancy nation states managing to break down your door, it was much more indeed just about getting the basics right. We've seen examples of that. We've seen all sorts of breaches this year, supply chain security is probably a topic of its own, we should probably get back to that a little bit. I think that's going to grow in this coming year, but we've seen various attacks there.

And we're sort of finishing the here with the massive, logged for J vulnerability, called log for Shell, which is really, it's all about how quickly are you able to respond to a severe vulnerability in a component they're using? Do you know where you're using it? Are you able to quickly roll out the fix? Those are basics. They're not fancy capabilities. But being able to do them at scale and at speed is very hard. I'd say almost all of the programs and drives that have been mentioned and prioritize by the guests this year, have been focused on that concept of getting the core done right, at scale.

[00:15:45] Simon Maple: Yeah, and I think it actually lends itself to other topics that you've mentioned already with the concepts of building security into dev tools with the concepts of security education and awareness among development teams as to how that security hygiene actually grows in an organization. I think mentioning log for j, the log for Shell exploits and attacks that are happening now, it's very interesting to see the differences on Twitter, or rather, the different experiences different developers are having on Twitter, based on how their security hygiene is. Some are headless trying to understand what this even means to them where issues exist. Others that already have good tooling, good education, are much much care about it, understanding straightaway, where issues exist. And you know, more often than not, it's kind of like business as usual approach in order to fix those rather than experiencing these kinds of attacks and these kinds of expert vulnerabilities for the first time. It's very interesting to see those differences.

[00:16:45] Guy Podjarny: Yeah, for sure. I kind of try my best to not to make this commercial sort of sneaky stuff. But if I look at some data, what we've seen at Snyk is we've seen this big surge of people adding projects to them. So, I think what it also has done is, specifically the log for Shell breaches or not breached. But vulnerability is that it added some urgency, even people that were on a good path, it reminded them that you need to have all of your – you need to have visibility for all of your projects. You can’t just gradually shift it, which is one of the key differences between developer and security. I think dev tools, they're local, you build an application, if it's using amazing technology in order to build it, then it will be larger than that technology will get adopted elsewhere. While security, there's a certain need for breadth, there's a certain need for coverage.

So, we're seeing that. But either way, like I think that theme, that need for security hygiene, and building that into the practices is also encouraging because it means you don't need developers to be super fancy blockers and know kung-fu to be able to block the attackers. They just need to know how to do the basics and need to think about that make day to day. So, that was definitely an overarching theme.

[00:17:59] Simon Maple: Yeah, absolutely. And as you mentioned, at the time of recording, this is news coming as we – day by day as things happen. So, it'll be interesting to see how this plays out over the coming days and weeks.

Going back to the podcast over 2021, one of the wonderful things about podcasts is you get some amazing guests from lots of different organizations that are really, really pushing the way security is done and showing others how it can be done through their best practices, et cetera. Personally, what are some of the most important things that you have learned from some of the guests that we've had over the previous year?

[00:18:33] Guy Podjarny: I learned a ton. I’m so spoiled with this podcast. I get the opportunity to reach out to smart people, and then bring them on to the show and ask them the questions that I find interesting.

[00:18:47] Simon Maple: That's a question in itself, Guy. Did you do it to teach others? Or did you do it just selfishly, because you want to talk to these amazing people?

[00:18:51] Guy Podjarny: I like to think it serves both purposes, but I definitely learned a lot from them. I don't think there's an episode that I came out of that I didn't feel like I learned some great perspective. Sometimes it's a perspective, sometimes it's a phrase, sometimes it's a technique, sometimes it's a brand-new topic, you know, that also happens. So, I definitely learned a ton. The top one that jumps to mind is the Codecov episode, mostly because it was just a unique experience. So, if you haven't listened to it, we had the code called founders come on the show, Jared and Eli, CEO and CTO of the company, sort of the leaders of it.

They described the experience and the whole set of steps that happened as part of the Codecov breach which was a pretty – one of the more sort of serious and more publicized supply chain attacks and breaches that happened this year. So, I thought it was super insightful because they just let us in into the feeling of what it was in the moment when you suddenly find doubt that these grave things happened and you need to deal with. How do you know what to do? How do you kind of overcome the maybe overwhelming sense, at the time of gravity, of how severe this is? How do you keep thinking about your users versus thinking about covering yourself in the process?

So, generally, I'm super grateful for them for coming on the show, and I found it super, super insightful. I think it's a very valuable episode to listen to. If nothing else, it would equip you a little bit better if you, unfortunately, find yourself in a situation like it. So, that was the top one that jumps to mind. I guess similarly isolated, or contained was, from a technology learning perspective, was the episode with Liz Rice on eBPF, which, frankly, is just fascinating technology. So, you can think of it as something as impactful as containers into the network. And so, eBPF is something you should learn about. Liz definitely educated me, and hopefully will be listeners about it at the time. So that was very useful.

I guess a bit more in sort of summary learnings. So, things that I've just sort of seen, repeatedly emphasized and have grown to appreciate, and build my understanding of, there are other topics. So, definitely saw how much governments are adopting DevSecOps as well. And how some of the parallels, when we think about power teams and such work there. So, I had two primary guests, from government organizations come in ahead, Robert Wood, or Rob, who works at CMS, which is deals with health care services in the US, and had Nicolas Chaillan, who was the chief software officer at the US Air Force.

Both of them really talked about how they work with these other groups that are very independent. And that actually brings to for all sorts of DevOps related practices, because you have to work in a platform mind mindset. And each of them had a little bit of a different flavor of risk aversion that they had to deal with. For Rob, it was more around accountability, it's more about, getting the different groups within CMS to not just think about how I'm going to do the minimum and deliver the software, but rather take on the responsibility for securing what they're building, and then equip them with sort of the right measures and sort of approaches to make them successful at it. And so, some groups were more power than others, which is very similar. It's like a group level, but it's very similar to working with developers.

For Nicolas, a lot of the challenge that he spoke about the most was probably more around demonstrating impact. So, this is not a surrounding in which you have commercial success. It's more about project success. So, what are the measures? What are the metrics that you measure the success of a DevOps or DevSecOps program? Because he was pushing DevOps and agility as well. What are the measures there that actually would mobilize people to action? So, he talked about productivity metrics and efficiency, which are measures that those organizations measure themselves. Those were really interesting, because governments are, I still think that they're not at the forefront, for the most part in terms of DevSecOps. But it was interesting to see how the same principles do come to the fore.

[00:23:33] Simon Maple: And is that largely because of things like regulations and compliance and things like that? Or do you feel like there's another reason as to why they're sometimes a little bit later in adopting some of these newer principles?

[00:23:44] Guy Podjarny: I think there was a whole set of reasons. But I think if you look at the problems that are being measured, one, for example, is the upside is more clear, is less clear than the downside. When you think about a business success, if you're doing the right thing, if the business runs fast, then you are financially successful, you sell more in the government, if you run fast, and all that you need to get satisfied by the projects and their individual impacts. The reason that overall metric, typically. While the downside, if you don't deliver, it actually has a lot of noise and a lot of attention being put onto it. So, that's one aspect of it.

The other is, I think, just the individual level, recognition, and understanding of – I think a lot of the people working in those organizations and governments are actually very mission-driven, and being able to relate their individual accomplishments to actually driving this type of change. And the, I mean, risk tolerance, shall we say those surroundings are not well known for risk tolerance. I think when you talk about the air force or the DOD, there's also the additional concern of the fact that they deal with extremely sensitive topics, which again, reduces or creates more risk aversion.

I think those are the key themes. I mentioned a few sort of quick ones that also kind of repeated through it. I find I evolved my view around what is the right location for a CISO in the organization. I think I started the year thinking that really shouldn't be moving CISOs to report into the engineering organization. And I think through the year, there have been many contraventions as well. Jeff Belknap talked about his own change when he was on the show before as CISO at Slack. He talked about how it was very impactful to have them moved to the CISO organization. Now that he's at LinkedIn, and he came on the show, again, he says, he thinks that it's really much more about wherever you are, what's important is your boss' interest in security and influencing in the organization. But otherwise, it's not that significant.

Rohit talked about how – because it was a Collective Health and now he's at Yext, how the right place was different in the two of them. Dev from Figma talks about Dropbox and his experience over there versus his work now at Figma, and how different practices or different organizational structures were correct. He had actually a different emphasis, even before I talked about Jeff's comment, Dev’s view was that the key thing is to ensure that your highest performers are working on the most important problems. Was more talking about less where the org is, and more, how do you structure your own org, which was really, really good.

So, I think those are very important. And for me, it was an evolution of my thinking. What I have seen, and I don't know if this is a learning as much as just reformation, is that the lines are blurring between cloud security, app, security engineering, you really saw this all over the place. Nobody has a clear-cut line, for that is sometimes you see security responsibility in-app, in different teams within it. So, those three areas of AppSec, CloudSec and security engineering, and even product security as in building security features, they blur all the time.

Ashish, from Page Up talks about CloudSec and AppSec, mixing up DJ from Village MD, doesn't even have a security title, as he did previously. But he still owns security, but the non-security and DevOps, a lot of things are really blurring over there. So, I think organizational fluidity is higher. For me, I learned to appreciate where you are in the org and exactly how you structure it is maybe less important than what I thought at the beginning of the year, as long as you have the right emphasis and that you're focused on the right way to engage with the rest of the org.

[00:27:46] Simon Maple: I think there's a lot we can learn there, which I think high-level concepts in a way how teams are structured, how organizations work together. In terms of, if individual groups wanted to make changes, and actually do it themselves without needing to restructure an org or anything like that, what are some of the takeaways and learnings maybe concrete tips or methodologies that you thought people can actually take away from an episode and implement in their own organization quickly?

[00:28:16] Guy Podjarny: I love the tips. I love when someone comes on the show and says, “Well, this is how I've done it”. I try to remember to try and tease it out of them because they surely have some. There were many that I liked this year. I definitely mentioned it before. So, she was approached to gamification, around security education was really cool. So, model in which you, it's almost like a role-playing game for security education, where you actually have levels and you take on quests, and it sounded really, really fun and very much worth considering.

I guess a couple from recent episodes. So, Rohit mentioned, I put them on the spot a bit to say what's your favorite hiring question, interview question, allowed us then to share in his question, which is he asked people to threat model a topic, which I love because it's such an open-ended question where you can see where do people take it and you ask them to threat model some problems, some scenario, and then you see where they take it and what where they put the emphasis. So, I really like that.

I guess similarly from various an episode is Tim Crother’s distinction between controls and guardrails. I could have put that in the learnings really. But, you know, he kind of used the two terms and he basically highlighted how controls are more about, thou shalt not pass and they're more around, you know, limiting. And the terminology around control is I'm going to constrain you, I'm not going to allow you to do something. While guardrails, they convey a positive statement. They say I'm helping you, and guardrails, they sound more supportive than controlled, so I thought that was really good.

I keep coming back to the episode with Dev just because he had a lot of these great sound bites in his episode. So, when we talked about working or creating bonds between teams, in a remote working surrounding, between the development team and the security team, he really emphasized how working on incidents together, not just security incidents, even just uptime incidents, really kind of made people gel and work well together. So, that was really interesting and brought up the notion of should AppSec teams actually be part of the on-call rotation, working, especially when you have multiple people on an on-call rotation just to work together and you create these bonds, which was a great tip, especially for remote work surrounding.

And then I guess the last one I'll mention is Ashish from Page Up had this really great, sneaky, but fun way to uncover which developers care about security, where I think early maybe even one of the first things he did when he join Page Up was to run this internal capture the flag competition option. People could opt in to join a capture the flag competition, and that flushed out the developers that cared about security just sort of naturally by virtue of who came into, to join in.

So, that kind of gave me gave him this set of allies to work with which I really liked. And Nitzan Blouin from Spotify, she was on the show last year and she had a similar when she was building up her AppSec program, she surveyed everybody to get their feedback about what they think was interested in or not. And part of the advantage of her surveying the different people was to see who brings up, who is engaged, who provides a lot of opinions. And those were her allies to come in. So, both of those I thought were really, really nice, too. So, there's lots and lots of tips. You’re going to have to listen to a lot of those, but those are probably the top ones that come to mind.

[00:32:03] Simon Maple: Absolutely. And I really love the capture the flag style way of also educating and creating great awareness among development teams, around security and the way exploits can happen and things like that. So, it's another great way of really raising that awareness.

[00:32:19] Guy Podjarny: It's worth it if you're not aware of it, and you're listening to it, raising the capture the flag competition is actually not as hard as you think. Today, there are all sorts of platforms and things like that, that you can do it. So, don't be deterred by it or don't be too frightened of it. If you're trying to run one of those to sort of see who in the team is engaged in security, you can get one up reasonably easily.

[00:32:38] Simon Maple: So, Guy, we’re coming up to the end of the year, and as is normal for organizations, a lot of the time people do performance reviews, right? So, Guy, we're going to do a live performance review for you on – no, we're not going to do that. But let's do a performance review almost for the dev team. So, the two questions, of course, that we would typically ask is, what are dev teams currently doing well, and has that been shown this year? And also, what are dev team still needing to improve?

[00:33:04] Guy Podjarny: That's a hard thing, right? Because everything, nothing is black and white, really. We're improving in some front and not. So, I've mentioned a few of these things, I think in the recurring themes and things that I saw come up a lot. So, when I think about what we're doing well, I definitely think the whole meshing together of development and security is on a really positive trajectory. This notion of hiring security people with engineering skills that I mentioned before, I think is valuable, the emphasis on empathy.

And even more, and I want to emphasize this notion of development, being willing to take security on. Simon, I think, in the episode, where you shared some of these sorts of state of cloud-native AppSec reports with us, there was some hard data that shows that developers are engaged in security. And you can correct me if I'm misquoting here, but what I really liked was mentioning how twice as many, in terms of ratios, developers thought that developers should own security versus security people.

So, basically, security people are more reluctant to let go, maybe or needs to be more willing to let go because developers are actually more ready to embrace it. So, I think that's a great improvement. And similarly, the dev tooling ecosystem that emphasize it. I think, clearly, this podcast is a great learning vehicle for me, but through Synk, and just the working in the industry, you see this well past all of those. You see them well pass to the podcast guests, as you see these themes. So, I really do think that the dam is sort of been broken, this notion of developers don't care about security developers will never pick up security. I think we're past that or we're pretty much well on our way to be best at and it's more of a how – so that’s I'd say the primary thing that's going well, but it's the most important thing because things derive out of that.

[00:35:09] Simon Maple: I always, you know, when I hear people say developers don't care about security, it always bugs me though. Because you taught developers and developers do care about their applications. Of course, you'll get extremes where some developers just don't care about it, they're doing a 9 to 5, they're there for the paycheck. In my opinion, devs are proud about what they create and they do have pride in their work and pride in their professionalism. So, when I hear developers not wanting to take security on, it's typically for other reasons, rather than, you know, a developer not wanting to their application or not caring about their application being secure. It's typically other barriers that exist in the way perhaps, the existing tooling that they're using isn't friendly. Perhaps they don't have the right education, to understand what the necessary fix is.

So, yeah, I absolutely agree that the dam has been broken, and that developers are not just acknowledging that they want to take security on, but wants to work with the security teams more and more. And certainly, over this year, I've never seen developers more engaged in these kinds of activities and just engaged in general with security organizations in the past.

[00:36:19] Guy Podjarny: Yeah, absolutely. I think this almost inevitably leads to the second part where I do think we need to improve, which is the implementation of it. And I'd say the two primary gaps are measurement and clarity. So, measurement, I keep asking this question, especially when I feel like I got sharp answers, from a guest, asking, how do you measure security? Nobody really says, “Oh, I've got this nailed. I know precisely how to do it.”

There's actually a really cool episode coming shortly at the beginning of the year, with Garrett Held from Carta, which I would suggest you tune in who has a really, really interesting measuring risk type approach. But either way, it's a challenge, though. So, when you think about the DevOps industry, we've standardized on these sorts of SLOs and SLAs and SLIs and practice around them and understanding of uptime. We just need to level up over there. We've seen some tips and tricks around it. Dev, again, from Figma had this notion of having pairing metrics, that one goes up, one goes down, like how many bug bounty reports, you want to get more bug bounty reports. But then you want to measure that against the percentage of valid reports, where you want to make sure that they're balanced against one another.

Amanda at Cisco took more, she was heavy on the empathy and stakeholder mentality. And so, she took more of a qualitative approach where she surveys her stakeholders to say, “Hey, are we doing well? How do you think we've improved the measures that over time?” Daniel Bryant and James Turnbull, who are both coming from DevOps world more than security, took more of an ELT is like accessibility, observability, testability type comments and talks about that, which reminds me of Lisa’s episode a year prior, talking about secure ability.

So, there are progress, there are thoughts in this space, but I think we need to crack measurement and understand whether we're doing better or worse. And then related to that is I think there's lack of clarity around the split between security and dev. And at this point, it's less confrontational and more setting up collaboration. I think the security world is evolving to resemble more how ops has evolved and become more of a platform to help developers succeed.

But I think in ops, we have a better handle today on where those lines are, there's also a gray area. And I think we need to level up over there in security to just understand what is it that we expect security teams to provide, and what is it that we expect developers to provide, and what is in the middle, which is legit. There's going to be some in the middle, and how are we going to tackle that on? So, I think those practices are what we'll see evolve.

[00:39:04] Simon Maple: Yeah, very, very interesting. So, I think, those in going into 2022, I think there's going to be interesting ones that will see improvement around. What other security challenges do you feel our guests, I guess, that are going to be talking to you around what they're going to experience in 2022 in their organizations?

[00:39:23] Guy Podjarny: So, measure of security is one. I mean, I think I just spoke to it. I'm not sure there's a ton more that I will apply to it. But fundamentally, as we decentralized security, we need better taxonomy, better tools to be able to collectively know whether we are doing well or poorly, whether we are improving or worsening. So, I think this measurement element is improvement and fundamentally, we need to take it up a notch as well. There's not just the measurement of your SLAs for fixing known vulnerabilities is are unrelated code activity to risk, fundamentally security teams should be working in risk measures about how do I protect the organization. But you want to relate that to the technical work.

So, I think that's going to be a challenge that's going to come up a lot this year, and even sometimes going as far as business impact. When you think, again, about DevOps and how we've evolved that area, it went from measurement of uptime to measurement of business success due to agility. I think measurement is definitely there.

The next one, which might be the first one, frankly, in terms of importance is supply chain security. Look this year, we actually except for the code called episode, we haven't talked about that as much in the podcast. We've had the code called episode, we've had Nicolas on the Air Force, talk about dependencies of dependencies and how everything is over there. But as an industry, this has definitely been the year that surfaced the concerns and the woes of supply chain security. The fact that we are dependent on one another, SolarWinds is probably the biggest example of that code called next to it. Now, even log for Shell is an example of it, which is we're building towers, and we're building on the shoulders of giants and communities and other in the community. And we created this web of dependencies between services, between components between individuals. We have to get handle of that.

So, there's a lot of work going on there right now. There was the executive order from Biden driving a lot of activity because federal agencies and the government will be requiring more sort of software bill of materials with long reports and long quality for any software that they purchase. We see the openness – I'm on the board of the open source security foundation, I think is a premier member there. And there's a great collaboration between all sorts of companies working together to help us because this is very much something where we need to come together as a community to define what are the standards with which we define what good looks like, and how do we communicate in ways that different tools different. Because there's no single solution that would solve supply chain security end to end, so how do we collaborate well?

There's a lot of emphasis over here. I do suspect we're going to see some breaches, or some additional sort of big-scale vulnerabilities. I’m sure those will continue. But I think mostly, I think this year, you'll see a lot of security programs that need to tackle this. So, I'm going to try and help all of us learn by trying to get guests to share those and we'll definitely touch on that.

And then I guess, the third one, I'd say, is cloud security. I mentioned this around the blurring lines, but it's tricky. When you come into it, most companies take on cloud security as an evolution of IT security. They think about their VMs in the data center, how they move to the cloud and other security and that way. So, they are organizationally set up that way. They are culturally thinking about it this way, like tools that are equipped to tackle that way. Increasingly, there's kind of clear acknowledgement that cloud is software, cloud is turning IT into software, and it requires software security-related tools. And I think that's rocking the boat, and people need to figure out how to tackle it, how to think about cloud security in infrastructures code terms, how to think about container security as an evolution of the app, not the VM. And so, I'll see a lot of – that is already happening already, like more and more of the guests, although they originally came from AppSec are dealing with those types of concerns. And I think we'll see a lot more of that this coming year.

[00:43:45] Simon Maple: Yeah, it’s interesting that it also goes to some of the bloodlines that you're mentioning about how teams organize themselves as well, which is a part of that, I guess, as well. So, going into 2022, then guests and topics that you want to talk about, what is on your kind of like hit list for getting different individuals into the podcast?

[00:44:04] Guy Podjarny: Yeah. I want to learn about so many things. The ones that I mentioned right now are the things that I think we should, as a community learn about. So, supply chain security, cloud security, measurement, so I'm going to do my best to bring guests that have opinions and perspectives on those areas. Personally, I'm really interested in the potential regulation changes that might happen. So, in my kind of question about, what do you think would change the most in the next five years, two guests, Geoff Belknap from LinkedIn and Tim Crothers from Mandiant have both mentioned regulations.

Jeff talked about how, when you think about the generally accepted accounting principles, the GAAP practices that CFOs are subjected to today, those did not exist, I think before Enron and the corruptions and similar type corruption elements there, and that drove the CFO regulations and he expects and I think that's really interesting that the same will happen to security regulations as well. And so that we'll see with the amount of breaches, we'll see companies being an even public markets expecting sort of security practices to be communicated and standardized.

Tim had maybe more pessimistic approaches like, look, fundamentally, we're kind of failing as an industry. Every year, we're spending more money and getting more breaches in the security space. So again, sort of things, regulators are not just going to allow that to continue as is, they're going to demand companies, regulators, and public markets kind of sharing the same view. So, I find that really interesting. So, I'm going to seek out and if people are listening to this and have thoughts to share on this space, I'd love to hear those. I think that's interesting.

I definitely want to talk about DevSecOps at large scale. So, when I think about the community maturing, we're also seeing large banks, we're seeing large governments, as we spoke before, talk about successfully operating DevSecOps and decentralizing security in an organization of that magnitude. So, I'm going to try and weave into that. And yeah, and I guess kind of the last and maybe most important topic over here is, I'd love to dig more into diversity. I think we're doing a very pretty miserable job at it as a community. I think security community has improved, I think as it embraces some DevOps style and culture, not just tooling and practices. It is becoming more inclusive. But we have to break the dam there. It's hard, like when there's so much talent shortage, it's so hard to hire, it's hard to also emphasize diversity, as part of that it's yet another very hard lift.

I know we deal with it all the time at Snyk, but I think you have to keep trying. And so, what they love to do is every now and then, a guest shares some great practices about how they've tackled it. Last year we had Tad to talk about security, the day of security and the work they've done there. We had Tonya mentioned a bunch of things. This year, Rinki, had a great point around in the growing the pool, not just sort of stealing security, diverse security candidates from different companies, moving them from one spot to the other, but how do we grow the pool.

But I feel like this year, I didn't have the role. So, it's like Newton had some great ideas. Also last year, 2020, but I feel like this year, I didn't have enough examples of some good tips on how to make our community more inclusive, have more diversity in it. And so, I would definitely be looking for people that have good techniques to share, good approaches to share, about how can we get this right.

[00:47:51] Simon Maple: Absolutely, a great mission. Guy, I'm going to sign off here with my last question, which is actually a question that you've asked many guests, pretty much all guests, over the last almost year, which is the crystal ball question. So, you always ask that tricky question, saying if you had a crystal ball, what would the world look like in five years in terms of, I guess, roles and activities and challenges and those kinds of things to our guests? Well, Guy, we're not going to let you get off scot-free here. We're going to ask that same question to you. What do you think that our environment, our world is going to look like, I guess, in the security world? What’s going to look like in five years’ time?

[00:48:24] Guy Podjarny: A taste of my own medicine is never that hard. It's not an easy question. I think the fact that it's open-ended is the reason I ask it, because people take it in many, many different directions.

[00:48:35] Simon Maple: Because you've heard so many answers, we need a completely unique answer from you.

[00:48:39] Guy Podjarny: I was about to say that I like I do agree with a lot of the comments that have been made around AI and around the developer engagement. There have been a lot of great answers to this. I think there are many changes, but I think one that hasn't been raised is going back to thinking about the application as a whole. So, as a single entity that has a lot of moving parts. I think what's been happening in the industry is that we've been, in a way, because of the split into independent teams, and because of all these kinds of API enabled interactions between them, we've gotten better at sort of automating and identifying also security, all sorts of security mistakes in each one of these pieces, in each one of these components, whether they are different services or a specific library. And I think those are important, but they're overwhelming.

So, I'm kind of imagining, I think there's going to be a bit of a wave where we're kind of approaching a certain breaking point, which is just impossible to deal and fix all of these different local vulnerabilities and we have to think in global terms. We have to think in – when I think about my application as a whole, when I think about my supply chain as a whole, how do I tackle that? How do I identify the security flaws that matter most? And so, to an extent, what I think will happen in five years is that we will be in a place in which we have more of a taxonomy and a tooling set that talks about security at a slightly higher resolution or lower resolution, a little bit less fine-grained, but that is effective and that is connected to the line and codes of those technical practices. And I think we have to do that, because otherwise, it would just get very messy. But I'm seeing all sorts of good indications and I think there will be positive progress there.

[00:50:27] Simon Maple: Yeah, really positive ways for developers to have real impact with their security changes, and remediations, and things like that, to make sure that that's really having an impact. So, guy, we're pretty much there for the end of this episode, and I guess there for the end of the all episodes of 2021. Why don't you sign off for this episode and for 2021?

[00:50:50] Guy Podjarny: First of all, I just want to say a huge thank you. I mean, I'm grateful for all these great guests that come on the show and share their learnings and my picky questions there, and trying to learn from them. I'm very much thankful to all the older listeners. Thank you all for being part of this community, for helping spread the knowledge. I'm seeing the further twists and mentions, and I think that's awesome. We want to level up together as a community. I appreciate. I know there's a lot of great content out there and I appreciate you sort of tuning into this one. I hope you keep finding it useful.

The one ask that I have, you might think that podcasts are these like digital native type entities and that we're able to see what people that liked or didn't like very easily so we can learn from it and know what else you want us to be doing or how to correct better serve, all of us great listeners, it's not. Podcasts are actually like fairly archaic in terms of that being said that we get, which makes us even more dependent on just your inputs to say what did you like? What did you not like? What did you stop listening? Which guests would you like to see? What are your topics for ’22 or themes on it? What guests you'd love to see on?

So, those or any other commentary, we'd love to hear from you. You can send notes to tsd@snyk.io, or the full-fledge thesecuredeveloper@snykio. Or you can just tweet or DM either myself @GuyPod or us @TheSecureDev. We really would love to hear from you. There's a million topics we can dig into and we'd love to kind of make the most of your time as we go into the new year.

So, thanks again. I hope you enjoyed all the opinions and the views that we got to share here over the course of the year, that you have an amazing break if you're managing to get one over the end of your celebrations. I'm looking forward to be back with a brand-new array of smart guests in the new year.

[END OF INTERVIEW]

[00:52:48] ANNOUNCER: Thanks for listening to The Secure Developer. That's all we have time for today. To find additional episodes and full transcriptions, visit thesecuredeveloper.com. If you'd like to be a guest on the show, or get involved in the community, find us on Twitter at @DevSecCon. Don't forget to leave us a review on iTunes if you enjoyed today's episode.

Bye for now.

[END]