Derek Weeks on the 2020 DevSecOps Community Survey Results

Show Notes

• 00:00 Shane: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. I'm sitting down virtually with Derek Weeks. Derek, welcome. Thanks for taking the time to talk to us today.
• 00:17 Derek: Thanks, Shane. Great to be here. Looking forward to the chat.
• 00:20 Shane: Now you are the vice president of Sonatype.  Do you want to maybe tell us a little bit about yourself and your background?
• 00:28 What got you to where you are today, and who's Sonatype?
• 00:32 Derek: So as you mentioned, I'm vice president of Sonatype. I've spent the last couple of decades in enterprise software businesses.  As a kid, I grew up in Silicon Valley, so I've always been fascinated with technology and how things work and innovation. So I strapped myself to a bunch of innovative companies along the way, and throughout my career, and seven years ago landed at  Sonatype and I help with a number of different things around the business in terms of advising on DevOps practices, doing DevOps market research, leading a lot of our community efforts out there and broad community efforts with the open source community, the DevOps community and the application security community, or where those converge into DevSecOps doing a lot of work there.
• 01:19 So it's been a great journey along the way. I've met a lot of really cool people and love to share the knowledge that I've gathered about that.
• 01:27 Shane: So, DevSecOps, isn't this just another buzzword?
• 01:30 Derek: Yes, it is. That's all it is. It's a fad. This too shall pass.
• 01:37 The name isn't really important. You know, if you're doing DevOps right, DevSecOps is a part of it. 
• 01:43 For some people and some organizations, culturally, you know, the dev teams and ops teams were easy to get together, QA was easy to merge in, but security was in another building,  part of another business unit, a tax bolt-on organization and sometimes development didn't even know who those people were.
• 02:04 So I think it's a reflection, sometimes of the culture and organizational structures, where security is a different tribe and different part of the organization, where there's a desire to bring it in or build it in. And I think that's a lot of where it comes from, but I think security seems to be one of the last major legs of the stool to come in and support DevOps practices.
• 02:30 And it's funny, cause a lot of the earlier people in the DevOps movement, like Gene Kim actually came from a security background. So while he's strongly preached DevOps and been one of the early leaders in the movement, if you go back eight years, he was preaching about DevSecOps or really DevOps and security merging together and why that was so important. And only in the last, I don't know, two years, have we had the DevSecOps moniker really come out more strongly as a term. But like I said, the term doesn't matter, it's the practices behind it that really do.
• 03:06 Shane: This is the culture podcast. What do those practices imply about culture?
• 03:11 Derek: In terms of the security culture, there's a couple of things that come into play organizationally. Part of that is we just ran our seventh annual DevSecOps community survey. One of the questions we ask in the survey was how are you informed of application or info security issues?
• 03:32 And you think about some people as they imagine DevOps is like, if we're doing DevOps right, security is built into our practices. We don't need a security team to do this or a security organization to support us;  we've built it in, we've automated it,  everything's there.
• 03:51 And the reality of what we're seeing in the survey is pretty interesting, and we've seen this a couple of years in a row now, is when we look at mature versus immature DevOps practices, the mature practices have more security tools and they're more integrated into these environments. Also, those groups are more informed. The more mature groups are more informed by security tooling issues that come up, but also in the more mature organizations, security teams also play a bigger role in more mature DevOps organizations than they do in the immature ones.
• 04:27 And part of that tells me is the work and the collaboration that needs to be done to bring tribes together is really happening. That it's not a culture of exclusiveness, DevOps is going to take this,  we don't need security's help; it's DevOps is going to take this on. We need security's help. We know who they are, we've built them into our practices, into our training, into our secure coding training into our information loops and fast feedback loops that we're trying to build. So we're trying to establish closer ties with these groups culturally than otherwise. And I think there's this impression around DevOps or DevSecOps for people that aren't that far into it, that they actually want to be more exclusive than inclusive when it comes to security.
• 05:22 I can build security  in, I can shift security left, , as far left as possible, and if I do that, right, I don't need a security team bolted on as a taxes at the end of my development life cycle. And I think we're seeing just the opposite of that happen. DevSecOps is a more inclusive culture where DevOps and security tribes are coming together.
• 05:43 And we see empirical evidence of that in the survey results.
• 05:47 Shane: You use this term maturity and maturity and DevOps. And we talk about maturity a lot in information technology. What is a mature DevSecOps team/organization look like.
• 05:59 Derek: It's interesting because I think there are a number of different things that tie into this and some would argue that we shouldn't care about maturity in DevOps overall.  DevOps is about producing the kinds of outcomes that you want faster. And if you can do that, then it doesn't matter. There's no maturity model that you're trying to get to level two or level three or level four. But in the survey, we find this as an interesting way of measuring people's perceptions and the behaviors of things.
• 06:27 So one: in the survey we asked people to self-identify their maturity level, would you consider your practices immature average, very mature, very mature in pockets, very mature across the whole organization?
• 06:40 You tell us what your perception of maturity is, but then we'll also look at that maturity against different attributes.
• 06:49 We have a question on what security tools are you using? And I think we have nine or 10 different tool types or categories listed in the survey and we'll see how different people answer these questions, but then we'll ask, well, how integrated are these tools into your development life cycles or your DevOps pipelines?
• 07:10 And when you start to look at levels of maturity, different types of tooling used and other training and other attributes, you start to see this dichotomy really play out where the mature teams are you using tools, but they're much more integrated. The mature teams are doing training, but they're offering more training.
• 07:30 And this year we talked about job satisfaction and happiness of the developers and everything. The mature teams had a higher percentage of happier developers within their organizations than the immature ones. So we don't come out in the report or the survey with a specific definition of mature versus immature. But we just see practices tied to the higher performing organizations, do these kinds of things.
• 07:59 So personally, I would equate it with higher levels of maturity or higher performing organizations with better outcomes. Happier employees, more training, better job satisfaction, better tooling and integration, better collaboration with other teams across the environment, more empirical evidence of your results than opinionated outcomes and so forth.
• 08:23 Shane: One of the figures I see in the survey, happy developers are 3.6 times more likely to pay attention to security.
• 08:31 Derek: Yes. Interesting.
• 08:33 So this is a DevSecOps community survey and we had 5,000 people take the survey; for years now in the survey while security is part of this security folks are only about 6% of the overall population of the survey.
• 08:48 Substantially more than half are DevOps, developers, IT architects, IT managers, operations folks.  Really you have to think DevOps and not security in terms of the answers that we're seeing in the survey. But we ask people, do you spend time or is security a top concern within your organization? Do you have time to spend on it within the organizations?
• 09:13 And we're seeing this interesting dynamic that when we ask about job satisfaction, how satisfied are you with your job? Do you like your employer? Would you recommend your employers a place to work? Do you have the tools necessary to get your job done? Are you able to get the work done assigned to you?
• 09:31 All of these things play into satisfaction, but then we kind of take those attributes of the people that were really satisfied versus very unsatisfied. And we've matched it with different questions throughout the survey. And this is where you see people that say security is important and I follow the security practices within my organization and I consider it a priority, were much higher in the happier category than the unhappy category.  . It's dramatic when you think about what is the outcome of managing a team of people? If your people aren't happy, they're not following the rules. And if they're not following the rules and security being a type of rule or something you want to govern within your organization in terms of building quality and building security and having happier people ties to better outcomes when it comes to security.
• 10:23 You know, it's not something that we ask, are you happy and therefore, do you follow the rules? It was tying different attributes or questions in the survey together to see those results come out. But the patterns were dramatic, as you said, 3.6 times more likely to follow security or prioritize it.
• 10:40 Shane: How do we make security real and not theater?
• 10:44 Derek: There are a lot of different ways to approach that. One is probably the most important one overall, especially for developers and DevOps pros is education. What are secure coding practices? Are we training our people on what to look for? A lot of developers out there that I talked to and that we've surveyed throughout the years have said, look, I have a job to do.
• 11:10 I'm working on sprints. I'm delivering functionality. I have a deadline. I have to meet those deadlines. I'm compensated on meeting these deadlines and delivering these features to market and security is not always the top priority there.  Year after year in the survey, for four years in a row, we've had a question of how do you consider or prioritize security and consistently every year it's 47 or 48% say, I know security is important, but I don't have time to spend on it.
• 11:42 So that says, yes, I know I'm hearing about it, but you know, I don't have any time to spend on this. 
• 11:49 In order to make it real and not theater. One is. Let's train people on what to look for. Let's not have security being this bolt on tax at the end of the development life cycle, but something that I understand and make it easier for me.
• 12:05 So a great example of this. I was in Washington, DC presenting at a local OWASP meetup,  the open web application security project, and I'm presenting on my given subject and one of the guys in the audience says, I just got an alert from GiTHub that my code has a security vulnerability in it. He's a developer using a developer tool, being informed by his development tool, that there is a security issue in this.
• 12:34 The security team isn't necessarily involved in any of that: where the alert came from the tool that the developer was using, how they were informed. They're developing code. They're committing that code, pushing it up to their repo and the repo is telling them, maybe it's default settings or maybe through an integration tool that they have, that there is an issue with it.
• 12:58 Effectively what that is doing, that is the reality more than the theater of security and making it practical for people,  is it's almost the equivalent of myself as a writer or you, you know, in the writing that you do or anyone else as you're writing, there's spell check and grammar check going on instantly and Word or Google docs or whatever that's saying, Hey, Derek, you spelled this word wrong, again probably,  it's underlined, here's the correct spelling or here are different options of different words that look similar to that thing that you misspelledor that we didn't recognize. 
• 13:31 When developers can get that same kind of information in the tools that they're using to build applications that makes it easy, that reduces the friction of that process, then it becomes more real and less theater.
• 13:46 So there's part of it that, as I said, starts with education, we have to train people on what to look for as they code to develop more securely. We have to get them information that makes sense, that is actionable.
• 14:00 A lot of traditional security tools, when I talked to the security vendors, they're developing security tools for security professionals, to tell a security professional there's something bad in this code. And then I'm like, okay, well, that's cool, you've identified something bad in code now, what do you do? And they're like, well, we inform development to go and fix it. I'm like, how do you help developers fix that? And they were like, Oh, that's not our problem, the developer has to figure that out.
• 14:27 And to make it less theater because like, Oh, you have a problem. Go and fix it. Versus the reality, do you have a problem? Here's where it is here. Options on how to fix that or guidance on what it means in your code. Why is your code vulnerable? Then you can take action.
• 14:45 I think that's more of where DevSecOps becomes less theater, more reality, more practical. The feedback loops are tight and you have more action being taken.
• 14:55 Shane: Friction, where does friction come in?  You started talking about some points there that sound like they remove it, but what are some of the things that we can do from a practical perspective to remove some of that friction,  to make this just natural, as easy as seeing the squiggly red underline when you're typing?
• 15:15 Derek: Well, the interesting thing, when we put this survey together this year, We asked this question about where do you see friction within your environment? Because part of DevOps practices are trying to remove the bottlenecks, trying to remove the friction in the organization,
• 15:34 And we asked, where is this seen?  Is it seen in other developers? Is it seen in  management? Is it seen and the executive staff? Is it seen in security?  And the interesting findings that came from this were in, when we looked at happy developers versus unhappy developers in the survey, the unhappy developer set was, there was a huge portion, I think almost 50%, of the unhappy developers said management is the point of friction within this environment.
• 16:10 In the happy developer set one of the highest-ranking, if not the highest ranking person, was fellow developers. And I think that's actually a good thing that says, look, we're trying to develop this code, we're trying to innovate and do something new and bring out a new feature and I'm talking with you, Shane and we're debating on which is the best way to approach this feature. . And there may be conflict or friction there, but it's a healthy kind of friction with my peer because I'm a happy guy and I like what's going on.
• 16:42 The unhappy guys, when you look at management as  the friction point, one is, it was pretty surprising that if you have a low performing organization, and you're a manager and you're like, why are my low performing? Why isn't my team doing what I need them to do? Why aren't we working together? You try and point your finger at other places or other things within the culture, but you might actually have to point the finger at yourself  it might be you.
• 17:12 You're not providing the training. You're not providing the tools to help me get my work done. . You're saying I can't go and work with that security team over there because they're just a different part of the business. We can't bring more automated platforms in here cause we don't work that way, we haven't worked that way here for 15 years that I've been here.
• 17:34 You might be the point of friction. And I think it was really interesting from a kind of perception standpoint of how do you look at friction in the organization? And maybe you have to look inward.
• 17:45 Shane: Security breaches. What are some of the things that you're seeing in the analysis of the security breaches questions that you had in the report?
• 17:55 Derek: This was a really interesting one from a culture perspective. I'll say we saw similar results last year, so I can see patterns repeating themselves. There's one question where we ask, have you had an open source related breach in the previous 12 months and overall 21% of the people in the survey said we've seen an opensource related breach in the last 12 months.
• 18:19 When we looked at the immature DevOps practices in this 19% said we've seen a breach. So it's a lower than the average.
• 18:28 When we looked at the most mature kinds of DevOps  practices, through various attributes in the survey,  28% of those organizations said they experienced a breach.
• 18:39 Logically you would think if you're better at DevOps if you're better at DevSecOps and a higher performing and more mature, you should see fewer breaches, not more breaches. So I have my assumptions for why that is, but I went out on Twitter to my followers and I said, I have an idea of why this is happening, but I want to ask you. Why would there be more breaches recognized in the mature DevOps shops versus the immature DevOps shops? And the tribes came out, the culture started appearing within this community.
• 19:15 So there was one tribe of people that I know personally and their backgrounds and they're application security people. And they were saying development meant high velocity, very mature dev ops shops. They're moving way too fast. They will throw anything over the wall. They're just trying to get value out the door fast. They don't care about what they're building in. It's a mess over there. And I'm sitting here as an AppSec person needing to clean up the mess afterwards, kind of thing.
• 19:43 The DevOps background people and tribe said. Of course mature DevOps organizations are seeing more breaches. They have a culture of inclusion, they have a culture of don't blame the messenger. They have practices that say we're monitoring and aware of everything within our environment. The way our culture is shaped. Is reflected in that number. We're more aware of the breaches. We're more open to talking about the breaches. We're learning from our failures. We're not blaming the messengers. And they were like, I'm totally okay with that number. Now, the immature people are probably being breached just as much as we are, they just don't know of it. .
• 20:27 And it was really interesting to see that dynamic. And I commented on this in the survey report, but that dynamic come out of the different tribes and that kind of cultural aspects of it that you think, Oh my gosh, we're being breached more, maybe we shouldn't be as mature at DevOps as we want to be. But the  DevOps people, the most mature ones, the thought leaders that I work with in this space were completely comfortable with that kind of number. And not looking at it as offended, like you're saying DevOps is bad and better DevOps is even worse for security.
• 21:01 They were very accepting of that. So from a cultural dynamic, yes. That's super interesting.
• 21:07 Shane: Intriguing stuff. You have a few fun facts in the survey. I'd like to explore them, but also I'd like to think about what does that mean about the culture that your organization has, being able to put it in there  and what came up from that point of view?
• 21:23 Derek: Yes. So the survey that we do each year is a long survey. It probably takes a good solid 15 minutes, if not more to complete. We have nearly 40 questions in it. So every once in a while throughout the survey, we throw in some fun questions. Like what's your favourite pizza topping pineapple pepperoni, anchovies, as we were talking off air - 12% of people like pineapple, neither of us are those people. They do exist out there and there's like one in 10 people in the room is a pineapple lover on pizza. I mean favourite topping, not just like, what topping would you put on a pizza favourite topping, you know, 12% being pineapple, but it makes the survey a little easier to get through.
• 22:10 I think the best question that we put in here ,that I still find hilarious, is we ask people who's your favourite mercenary? And there was only one choice, it was Deadpool, and as you can imagine, a hundred percent of the people that took the survey selected Deadpool as there a favourite mercenary, which is just part of the fun of going through, and then we also ask about Star Trek versus star Wars, or I really don't care.
• 22:37 We also had choices like, are you still paying attention? And then we just see like, okay, people were active and not just, it's a long survey I'm just going to answer a, for every question throughout the survey, but I have to think, and you just can't get overly academic in these things without being able to throw some fun into it.
• 22:57 So anyone out there hosting surveys, especially long ones, take a little hint there on best survey practices to throw in a fun question or two.
• 23:06 Shane: One of the things that you're also known for is All Day DevOps, the 40,000 person remote conference. We're sitting in isolation on opposite sides of the world because of COVID-19. This remote stuff is new for many, but it's not that new for you?
• 23:26 Derek: 23:26 Yeah. So back in 2016, so five years ago, now my colleague Mark Miller and I were at a DevOps conference, probably been to 25 DevOps conferences in the year leading up to that. And I was meeting a lot of the same people at these conferences were all speaking at these conferences, we're talking in the hallways together and I'd meet people from, you know, Lloyd's of London or eBay or JP Morgan or whatever company. And there would be like one, maybe two, three people from that organization. And I'd say, well, how many people are in your DevOps practice? And they'd say, oh, 600, three thousand,  six thousand, whatever the number was, but certainly not all of them were at these conferences and DevOps was growing in momentum and Mark and I said, I think we could build a conference for everyone else. How do we take the same content from our friends in the community, pull something together that makes sense and make it totally accessible because a lot of people want this knowledge will benefit from it, and trip reports back after a conference, aren't the same kind of thing.
• 24:38 So in order to make this kind of thing accessible, we put it online. So anyone with an internet connection could access it. We made it free. So you didn't have to pay to show up. And if you had 3000 people in your organization, all 3000 could come and participate and it wouldn't cost anything.
• 24:58 We also put in a rule from the very beginning, no vendor pitches, part of the learning experiences in DevOps, and this community is great because loads of people want to share information and share knowledge. And it's important part of the innovation industries and IT industries. But we wanted to make sure you weren't showing up to hear pitches because that would be a boring conference.
• 25:22 As you said, last year, we had 40,000 people participate in this conference that we've made free for everyone. They can access the different tracks online. We run it also 24 hours. So no matter if you live in New Zealand, or India or Germany or New Mexico, you have access to this conference because we're on air for 24 straight hours across these five tracks that we have.
• 25:47 But a couple of different things that we did that made a big difference in  the kind of culture of the community that we put together is. One, you're just not showing up and listening to presentations.
• 26:00 We have a Slack community that we use for conversations. But when we started this conference, people said, uh, it's totally gonna fail because there's no hallway track,,  and the big value out of this as after the sessions, me and my colleagues leave and we talk about that session or we meet other people from the conference and we talk about and share information. So from day one, we set up a Slack workspace for the conference. All of the speakers who present at the conference jump into Slack after their presentation is finished and answer questions about it.
• 26:31 And we weren't sure if it was going to work or not. It ended up working in spades. But people wanted to share information. It was not only just, hey, here are my slides from that presentation. It was, you showed some code there. Is that available? Oh yes. It's right here on GitHub. You can take the code, download it yourself.
• 26:49 Use it in your organization. You mentioned that research. Where is that? Oh, let me point to that. In fact, I know Bob who actually did that research. He's here on Slack too. Let me pull him into a channel and we can chat. So the hallway track interactiveness of this conference made a big difference.
• 27:07 The other thing that we did from a culture perspective to build this successful growing conference and community was from the very beginning we were inclusive of anyone can come no matter where you are, it's free, it's online. What have you, but when you said, when you go to a conference, especially if you're from a big company, you don't attend alone, you have a colleague or two, and you talk about what you're learning at that conference with them.
• 27:33 So we tell people, register yourself and then register your team. And we see loads of organizations that are bringing multiple people to the conference, and we encourage something called viewing parties for the conference. We encourage people reserve a conference room in your office, on your floor, reserve the auditorium, whatever, invite everyone to this.
• 27:57 So if I'm presenting at the conference or James Wicket or anyone else from our community of 150 speakers is presenting, you watch as a team. You're like, wow, that was interesting, are we doing that? Should we do that? Let's talk about that as a team and as part of the culture of learning is it's not an individual learning opportunity, but a group learning activity.
• 28:22 We had 180 viewing parties around the world for the conference last year.  So these are kind of satellite conferences, if you will, anywhere from five colleagues sitting together to State Farm had I think 900 or a thousand people in a huge auditorium room, all watching and learning together. So they didn't have any travel costs. They just showed up to their centralized location and their offices, but it shows you even in this pandemic world that we're facing now, that learning doesn't stop innovation doesn't stop, there are opportunities to come together.
• 28:58 And even when you and I are seeing probably countless invitations to "our conference is not physical is now virtual come together". In order to really make this successful, you kind of have to , set it up in a way that like me and six of my colleagues are attending this conference, watching this content together, learning together as we would at other places and instilling that in your learning culture I think is important because otherwise you've gathered knowledge, I've gathered knowledge from a different place. We do all the time, but it doesn't ease the collaboration, friction that working from home sometimes introduces. Some of the cool things that we've done with the conference, we do by the way, have a whole cultural transformations track within the conference itself.
• 29:46 And another part of the conference, I'll just mention just around that is that inclusive nature of ideas. That when we started the conference, we did not have that cultural transformation strategy and cultural transformation is a big part of DevOps.
• 30:01 And I'm sitting at dinner with a friend of mine and he says, you know what you don't have is a cultural transformation track. And then I said, Summit, we could have one, if you run it,  so if you'll help us, we can have this at the conference. And he said, okay, I'm in. And he's been running it for the last four years and stays up with us all 24 hours in our office to run the conference.
• 30:24 But that kind of inclusiveness culture is a big part of growing a happy community, growing, you know, a happy organization that we have around the conference. So it's been a fun journey and we have some more cool things on the way this year, November 12th, 2020, we'll be online again for 24 hours. And all of the sessions from all of the previous years are all online, they're all free. We have over 400 now. I think, I don't know what the exact number is, but we have a lot of sessions from many years of doing this.
• 30:55 Shane: 30:55 Derek. Thanks very much for taking the time to talk to us today. If people want to get hold of the survey and, or continue the conversation, where do they find you?
• 31:03 Derek: 31:03 They could go to sonatype.com or just to go to Google or whatever search engine and type in 2020 DevSecOps community survey and I'm sure come up the top of the search engine results. You can find me on LinkedIn. I'm just Derick E Weeks is the place to find me there.
• 31:20 I'm on Twitter @weekstweets. I'm very active on Twitter. So definitely reach out there and connect. And I'm happy. You know, if you find me on Twitter DM me, or find me on LinkedIn and just send me a link and say, Hey, I heard about that survey and your conversation can you  send me a copy of it, and I'll just attach it there in a direct message for you.
• 31:39 Shane: Thank you so much.
• 31:40 Derek: Thanks. Shane, it's been a pleasure.

Mentioned

• Sonatype
• 2020 DevSecOps Community Survey
• All Day DevOps
• Derek on LinkedIn and Twitter