DevSpecOps: Developing a Better Software Delivery Model

Guy Podjarny: Hello everyone, welcome back to The Secure Developer. Today, we have a fun guest. It’s not often do I get to actually interview one of my colleagues here at Snyk. We have some awesome people here and we have with us Alyssa Miller who has been doing great work around DevSecOps and really has an interesting path and background to it. Welcome to the show Alyssa, thanks for coming on.

Alyssa Miller: Hey Guy, I appreciate it. Thanks for having me, it’s pretty exciting.

Guy: Alyssa, before we dig in, can you tell us a little bit about — what is it that you do here at Snyk as well as, how did you get into security? A little bit of your journey?

Alyssa: Sure, yeah. That gets to be a deep story. First of all, at Snyk, I’m an application security advocate and really what that means is — I’m out in the security community in particular, advocating for better practices in terms of security, really bringing awareness to some of the challenges around application security in particular. DevSecOps, certainly, but also just larger community related struggles, challenges, things that we deal with every day from a security perspective.

My path, like so many people in security, it was kind of not what you would expect and certainly not traditional. I mean, I’ve been a hacker all my life. 12 years old, I saved up a bunch of money with a paper route and ended up buying my first computer. We’re talking, I mean, this is late 80s, early 90s, not most people hack computers in their homes and here’s this 12 year old, buys herself a computer, teachers herself basic programming and asynchronous modem communications which led to me manipulating something in an old online service called Prodigy that some people might remember. I won’t admit any more than that but people do things that might be questionable nowadays. But I never really saw it as a career. In fact, I went to university as a premed major. I had fully anticipated, I was going to be a doctor and that was it and after three semesters of college level chemistry, I realized that was definitely not the clear path for me. I needed to pivot and discovered that they had a computer science degree. Okay, I already knew how to program, that should be pretty easy, right?

Chase that down and this was during the .com era now. .com is booming and companies were desperate for programmers and so while I was still in school, working on this degree program, I actually got my first job as a software developer for a large — what today, we would call them a FinTech firm. I did development for almost 10 years before someone from the security organization approached me and wanted to know if I would come over and be a pen tester.

I didn’t know anything about pen testing at that point but she knew I knew a number of different programming languages and I’d been developing in Microsoft technologies for the better part of 10 years. I made that transition and that kind of got me started and within a year or two, I was managing a team. That team ended up being responsible for the entire vulnerability management program across what was a 35,000 employee Fortune 500 company.

You know, from there, things kind of just take off and I got tired of seeing financial services, wanted to see the rest of the world. Made my way into consulting for quite a while, I worked for a couple of different consulting organizations. Really focused mostly on application security and at various levels, initially more at the application assessment level, slowly becoming more and more programmatic to the point where probably my last consulting role was really at a level of working on application security programs at the enterprise levels.

Now we’re sitting down with CISO’s security directors and so forth who are really trying to figure out, “How do I secure these 900, these thousands of applications maybe, in some cases, across my entire enterprise.” That was a lot of my career up until more recently, I took a little bit of a step back into more of a generalist role, working for a reseller.

Still kind of a consulting role but definitely a broader, again, working at that higher level of kind of the enterprise organization and security strategy but now covering the full gamut of, okay, how do we deal with cloud security, how do we deal with network security, how do we deal with application security, wireless though, across the board and ultimately, that led me to where I am today with Snyk.

Guy: Yeah, well, it definitely is quite a journey from hands-on kind of dev to you know, the big programming inside the company to consulting. A couple, there’s probably like a lot of learning and changes, you know, in each one of these different steps in the journey but one that I find closer to the theme we often discuss here is really this kind of tradition out and then back into app sec. and you know, these last few years, how would you say, how different are the two, right? You’re focusing on app sec., you’re growing this and then you’re’ expanding I guess kind of the scope of it. Is it like expanding within app sec.? Or are there some significant changes, you know, when you go from app sec. to other parts over the threat landscape?

Alyssa: Sure, yeah, there definitely is, in fact, actually, I would say it’s actually a very considerable difference when you get into that broader sense of just enterprise security program. First of all, first and foremost, you start to realize how many organizations out there don’t do any form of their own software development and so suddenly you’re seeing organizations who, for instance, the education space, a lot of these educational institutions, certainly here in the United States. We’re at a kindergarten through 12th grade level, they don’t have a lot of budget and they don’t typically have dedicated security personnel. They’re very immature in their processes and they’re just trying to scrape by and do the best they can with what they’ve got. They’re definitely not doing software development, they’re buying things off the shelf, they’re leveraging these days, a lot of cloud technology and in particular, from a GCP perspective and a G suite perspective, you get that exposure. But then even talking to these large enterprises, when you’re talking to these security executives, in a large enterprise you realize how small, for a lot of them, application security is in terms of their wider focus.

I ran into numerous organizations that were large, had a fair amount of software development they did and applications security almost didn’t even make it on their radar. Coming from roles where I was always really focused on application security, that was surprising to me,

it was a little eye opening to see just how much of a chasm there was there when you make that shift and then realize that — I will say, the organizations that do have strong app sec. programs tend to be the most mature.

Coming from a financial services background and in my consulting days, having worked with a lot of financial services organizations, they were very focused on application security because they’re doing a lot of their own software development and even in the supply chain, they’re having to be concerned with, “what does our software security program look like.” And so it becomes a more prominent portion of what they’re looking at, versus if you go to say, a large enterprise that’s in a utility space, delivering electricity and gas and things like that. They’re of course, far less worried about applications and far more worried about their networks and their devices.

Guy: You mention maturity but then there’s kind of maturity on the digital transformation, sort of continuum, if you will, or how much of a technology company it is. I think that’s a little bit easier to sort of to understand that if you have less application then you worry less about application and security.

For the organizations that do have software, do you think it is indeed a maturity element? Is it just that they’re sort of less appreciative of the threats or concerns that are there? Or is it a legitimate perspective on what are the primary risks to their business and then – how do you see it?

Alyssa: Yeah, a little bit of both honestly. You look at it from how they see application security. When software development isn’t really your primary thing, there is a certain level of reliance on the vendors that you’re buying software from. I mean everybody’s got software and we all need to be worrying about software security but a lot of organizations that are doing their own development maybe don’t have that deep perspective of all of the implications and threats that go into that space. They may do some due diligence, hopefully within their supply chain and as part of their procurement process, but when it comes to day-to-day, they’re really reliant on those vendors. It’s somewhat legitimate in that — okay, yeah, that’s probably not something that they need to focus on. And they can, if again, their security program within procurement is particularly well thought out and well structured, sure, you might be able to take that step back. But I do think that there’s also an overall maturing process by having to focus on application security as part of your program.

I think that helps mature other areas of your program because it gives a little bit of a different perspective on how you can approach things like invulnerability management and so forth. Where a lot of organizations who are only thinking about network and vendor security, vulnerability management to them is patching. That’s the end of the story. When you think about application security and software that you developed in particular, that conversation obviously becomes much bigger and you start to get deeper into the realms of “How do we negotiate with business units to remediate their vulnerabilities?” Because, a lot of times, there are conflicting priorities that can be more than just required versions of software or availability concerns.

There could be far greater issues there that they’re worried about and so developing those structures and those capabilities to negotiate out those remediations and make sure that they happen. I think that’s a maturity level that you get from dealing in an application security program that you don’t if application security just isn’t something that you have to focus on.

Guy: That makes a lot of sense. Taking then, that last step in the journey, moving back into app sec., you spent a few years outside the application security world. Coming back, did it feel different? Did you feel like there was evolution in space, did it feel like it’s pretty much the same?

Alyssa: No, it’s definitely not the same. For me, personally, it’s very different. Just having now gained a little bit of a new perspective on some of these things from getting back to more of an enterprise focus that I had way back when I was in FinTech. To what I did for a couple of years working for a reseller. There was that but you look at just the last couple of years — the absolute explosion of cloud native technologies. It’s amazing to me. I think about where we were three years ago when I was working for a company that was dedicated application security, that was all the consulting we did. It was it.

I think about what we were thinking at that time — and of the problems that we were focused on, to where we are now in terms of DevSecOps. DevSecOps, that whole concept, sure, DevOps have been around for a decade at this point but DevSecOps was still really immature just a few years ago. And now, we’re seeing this explosion of technologies and techniques around how we really drive security into the pipeline, things like containers, the way that Docker images have just exploded in terms of their widespread usage and just the sheer number of available images out there. I mean, I was literally just ‘heads down’ today in Docker Hub, digging through docker images and it’s absolutely amazing the growth that we’ve seen there. That’s become so much more common place and then we get into things with orchestration like Kubernetes and so forth. Everything there that is really driving just a whole new approach to how we think about and deploy and move forward and that’s changed so much just in the last two years.

Guy: Yeah, definitely. Kind of more has grown into the scope of this world. I think that’s actually a really good segue into another topic that I was keen to dig into, you mentioned DevSecOps and this sort of brethren. Buzzwords sort of a blessing and a curse, right? They mobilize a movement but it’s really hard to embody the complexity that most of these concepts have in a single short word like DevSecOps. I know one of your latest projects or sort of pushes was precisely in that area, was basically trying to define DevSecOps and put that down into a portal. Before we dive into the details, where can we find the DevSecOps hub?

Alyssa: It’s on the Snyk website, two easy ways to get there either you can go to snyk.io, visit the website and under the resources tab, you will see the DevSecOps hub listed there, or you can just simply go to snyk.io/DevSecOps and either will take you right into the hub.

Guy: Tell us a little bit about it, we’re going to take a little bit of a walk through this but you know, what is the DevSecOps portal?

Alyssa: Yeah, DevSecOps portal or I think we’ve actually called it the DevSecOps Hub at this point is really, it’s our way of reaching out and helping organizations who are still trying to digest, “What do we do to bring security more effectively and seamlessly into a DevOps pipeline?” Like I mentioned before, DevOps have been around for better than a decade now but security is still very much lagging behind and how do we bring ourselves into that space and what are the right strategies we should be following?

When we look at those DevSecOps hub, it was really our way to start to provide tangible, useful materials that organizations can leverage, whether they’re just beginning a journey into DevSecOps or they’re somewhere down that path but they’re really looking for how do we take that next step. “How are we going to level up from where we are today to having a greater capability?” Maybe it’s greater efficiency, a lot of times they’re just struggling with adoption or certain security practices into the pipeline.

The focus really of that hub is to elevate the view of DevSecOps as well because my impression — and I’ve certainly had these conversations with others who share this view — is we become a little too focused on technology solely when we think about DevSecOps. I’m amazed that we just had a little bit of a twitter thread going on this the other day about how often people, developers, and security alike will conflate the idea of DevOps and CICD. And they become so focused on this idea of continuous integration, continuous deployment, we need all the tooling and automation to make that happen that we forget that there is this whole culture that goes along with trying to be a DevSecOps shop. And

it’s this idea of shared responsibility across those different disciplines and really, across the entire business. For all aspects of software delivery, whether it’s the security of it, whether it’s the operational stability of it in the long run, whether it’s just the efficiency of delivering that software.

All of that is something that we all take a part in and we need to have those shared goals that we marched toward.

Guy: Definitely. Amen to that. I think it definitely has been a DevOps or ‘preaching kind of motion’ to remind everybody that DevOps is a culture change. Known first and foremost the technologies, the tools, all of those methodologies are really a means to that cultural change. When you think about that hub, I like the structure in it. We talk about the thesis of what is DevOps, you talk about as you sort of described the cultural change that embodies and we talked about this. And then it sort of splits it into this people-process-technology. That might be like a nice way to split this up a little bit. Let’s dig into one of those, what are the key people components that are needed for DevSecOps?

Alyssa: Yeah, the people process technology, any time you’re going to try to change a culture, first of all, that’s a very traditional approach that we’ve talked for as long as I’ve been in security even longer but yeah, that’s how you change a culture. When we think about the people, it’s okay, how do we look at how our people are aligned?

What are, first of all, just their goals from a formal perspective? What are we really expecting from them in terms of responsibility? DevSecOps can’t just be — “We’re putting it all on the developer’s shoulders now, they’re just going to do it all.” When we think about the people, how do we align those various disciplines and those specialties in a way that they really truly feel they all have that responsibility — that’s a multi-faceted thing that we need to approach so it’s how do we build empathy between those various roles and this idea of security champions, that’s something that’s been discussed. In fact, I believe now it’s actually even a requirement in the OASP sand model and so forth.

But bringing development, resources who have a security focus, or a tie to security together and distributing them across those development organizations but what about the other way as well? Why don’t we have development champions and security? Start to actually build that truly cross-functional flow where their jobs on a daily basis, their daily tests are intertwined. Our security specialist attending standups. Are they going to spring planning? How do we involve them? And then, on the flipside of that, of course, you do have that involvement of how do we get the development and ops teams involved in terms of when we’re making security decisions or we’re launching a security initiative? So that we know that we’re getting their perspectives on whether it’s tooling, whether it’s policy, whatever it is, we need that understanding cross-functionally to make this work.

Because, if any one of us is operating in a vacuum and making decisions or implementations on behalf of the other, that’s where we seed that friction. And then that friction is what causes this whole thing to fall apart and suddenly this idea of a common structure and shared responsibility around that software delivery starts to become siloed again.

Guy: I think definitely, great motions. You mentioned a bunch of these examples, I guess the portal aims to get concrete, right? It doesn’t just raise the questions, it actually offers some answers? What are some examples in this people space that are of concrete examples you can — people might want to apply at home if you will, or in their org.

Alyssa: Sure, so one of them is this idea of, “How do you structure your security champion’s program and what should that really look like?” We also delve into detail and methodology for how you set up some of that job. I don’t want to call it job-shadowing because it really isn’t and it is actually that day-to-day integration of these various roles working together — but start to establish more of that cross-functional tactical approach to just the daily task. So we do dive into both of those pretty deeply. There is a lengthy discussion and focus too on just things like training and ensuring that even at training, it is more than just, “Hey, we want to train developers in secure coding” — no. We walk through the development of it, a formal gamified training program and what that should look like, how you address that at different roles and different levels within the organization and bringing something that is a little more tangible and easy to ultimately adapt, for these resources that are ultimately involved in that pipeline and in whatever way that they are involved.

Guy: So, a lot of the specific practices that are captured. “How do you apply this, how do you do the change?”. Would you say — and we are still going to dig into the process of technology sides for example — but just to see this up, who would you say is the hub oriented at, who should be reading this? Is this for a security person, for a developer at the start or at the end of their journey?

Alyssa: It is a little wide range, right. I think certainly for our DevOps, we got DevOps engineers. Those are actually responsible for building out these programs or these pipelines within their organizations. DevOps architects for sure and then even the leadership that has that responsibility as well. So even moving up a few levels where you may have, whether it is development directors or someone in a security leadership position, we want those people working together on this. And so from an audience perspective, it is meant to touch on key topics in key areas that are going to be top of mind and concerns for those individuals where they may be seeing their struggles and really trying to address, “How do they start to work beyond those and leverage their peers in a way that they can bring more of these capabilities together?”

Guy: Cool and I guess the people-part probably, naturally, more senior people or people change as it requires a little bit more senior presence and application. Although many of the tips are very concrete and very practical. So shifting to part two of this trial, which is the process, what are some key process changes that need to happen to implement DevSecOps?

Alyssa: Yeah, so this is where really it is focused on the underpinnings of, “How do we structure our security practices, our development practices in a sense that we are now setting up things for visibility into the process we are looking at things like KPI’s and so forth, how are we actually going to measure success?” What does that look like both from the software delivery perspective but also our program itself? How are we really understanding that yes, we are getting better? We are seeing that idea of continuous improvement start to come to fruition as we continue to hopefully be exploring and maturing what it is that we are doing from a development delivery pipeline as we start to dig into that. It is really centered around driving repeatable processes that support the involvement of multiple areas of the organization, really starting to think beyond.

We call it DevSecOps, which implies developers operations and security, right? But how do you start to get the business involved in this? How do you ensure that this is something that, across the organization, there is ownership and everyone within that organization is really feeling that they’re a part of the success — that they have that responsibility for the success of this program of the company’s overall software delivery?

And so that comes from the bottom up, whether it’s bringing in business people as part of threat modeling exercises, or building beyond that and ensuring that we are doing the right level of reporting. So as we have defined these KPIs, KPIs are great but if no one is looking at them and no one is reviewing those and we are not constantly assessing that and moving forward, they’re meaningless.

Guy: It is so tempting to go through this, looking through the portal, which I am sure would evolve over time but like as it stands today, you talk about the paved road. You indeed talk about threat modeling and measurement, which of these topics is probably like an episode or half an episode on the runway talking about this. If you had to pick a couple, you already mentioned threat modeling and a few maybe, pick one more to highlight from the process changes, what is your next favorite?

Alyssa: I think just the idea around how we handle vulnerability management. We talk on the hub quite a bit about a couple of different approaches, specifically around what are we doing for software assessment and how it fit into this. Because, traditionally that has probably been one of the toughest areas for organizations that launch a DevOps model, is, we are so used to that pen test or that application assessment being that gate. That last thing that we do before production and it creates such a slow feedback-loop. And that really is one of those things that will break down a DevOps model or typically what happens is DevOps continues, you’re just not getting your assessments. They are working around that. And so really, looking at ideas for, “How do you make penetration testing part of those phases of the pipeline rather than gates between?” And then you know creative ways to do that.

Whether it’s red teaming, how do you leverage outside sources that have more creative solutions, even just where is bug bounty? Where does a bug bounty fit into all of this and how can you leverage that as another aspect of your overall security program, not just from discovery and vulnerabilities, but then ensuring on the backend that you have opened yourself up for a whole new flow of data. How are you going to leverage that information and ensure that that makes its way back into your backlog and comes back through again and that you are addressing those with proper priority and so forth?

Guy: Definitely, I am tempted to dig in but I think they all sound like very powerful practice. Would you say that most of these practices, or most of these process steps in this case, do they need to be an all or nothing? Would you think they can be advanced one by one or is there some critical math you have to do together?

Alyssa: I don’t think there is critical math. You definitely don’t want to boil the ocean, right? Much like we think about in terms of continuous improvement, the other CI that everyone forgets about, but really

continuous improvement is what our goal needs to be. We in the security world have said for years, we throw out weird sayings like ‘it’s not if you get hacked, it’s when’,

which the feeling behind that is right. The intention is there but let’s put that into something more productive — and that is, we know that to stand up and say we are a 100% secure and we are unhackable or whatever is really not a good idea because that would be a pretty dubious claim on anyone’s part. What we should be doing is constantly working to get better and then being able to measure and validate that we are getting better. So each day that we improve a little bit is another day where maybe that’s one less vulnerability that is exploitable within our environment or within our software.

And so, that just makes it that much more difficult, ultimately, for those attackers to find ways to exploit our software and so forth. Ao it’s got to be that continuous model because if you try to sell this as anything other in terms of gaining overall executive and board level support for these programs, it can be sold as something that has an end-date because you will not succeed. We know the technology landscape is constantly changing. Which means our response to the threats that we face is constantly changing and so all we can continue to do is try to get better and better each day.

When it comes to a DevOps or a DevSecOps model, we are looking to improve maturity. What level of maturity is meaningful for one organization versus another that is something that is very dynamic too. Each organization has their own risk tolerance, given their industries, what their business model is and we need to be aware of that too. So I would never be one to say, “Hey, these are all the steps you have to do. Until you do this, you’re not DevSecOps.” Well, that would be a pretty foolish statement on my part and that is a whole level of gatekeeping we just don’t need.

Guy: Indeed. Talk about shifting technologies that is a good lead into the third section that we have here, which is technology. So we talked about people change and culture. We talked about the processes. What is the technology component of DevSecOps? Where are we trying to cover here in the hub?

Alyssa: So obviously, we can’t ignore technology and the tooling either, right? I mean, as much as we become hyper-focused on it, sometimes I just can’t shut off to it either. It does have to be acknowledged and it is something we have to look at. And it is really, in terms of the Hub, painting a more solid roadmap of what are the technologies that need to be a part of your pipeline and how are they enabling developers? And how are they ultimately enabling your software delivery overall?

So we start with thinking about developers. Let’s make life easier for them and ensure that the technologies that we’re going to leverage meet their needs and aren’t creating additional friction or additional issues, hurdles, obstacles, things for them to overcome, and how do we implement them in a way — you brought up paved road before — that whole idea of, how do we make the secure, the way that’s the easiest for them to get to a deployment state.

You know it begins at the repository, or you can even say it begins before that. I would argue it even begins in the IDE. We can go further back even argue it again at the user-story when we start talking about how we are managing our backlogs. But wherever we want to begin, just focus on that. Making sure that we’ve got the right technologies that meet developers where they live. They’re the tools that fit into the models that developers are used to. As we expect developers to continue to push further right into our pipeline and into our deployments, how do we ensure that they’ve got the right tooling that they are willing to adopt? So that could be a tool centered around CICD. How are we automating these different phases within the pipeline? What are we doing to ensure that security is a part of each phase, whether it is automated, SCA and assessed happening at code commit times or at build times? Looking at getting the right tooling and implementing it in the right way.

And so, to that end, one of the things that we’ve done with this hub is really focus on calling out very specific technologies and providing some simple guidance, just simple checklists on some key security practices or implementation strategies for leveraging those things. If you are going to be going on that technology journey with a particular solution, having something tangible, whether you want to call it a checklist, or a cheat-cheat, or whatnot — but having those very specific granular tests or configurations and things that you need to validate about that solution is crucial for anybody. And so, we’ve got a couple of them now. We are building those out and we’ll continue to build them out. Again, as new technologies become available or grow in popularity, we want to make sure that the information that we have out there related to that is fresh as well.

Guy: Yeah and I think probably a non-obvious decision is that the technologies, when you look at the way they are sorted, they are not focused on, it is not technologies as in static analysis, SC and such, but rather they’re the DevOps or the developer’s context of technologies. They are CICD, they are the source code, they are orchestrations. So they are more oriented at the security application or how do you apply security, how do you build in security as you point out, right? To make it easy to make the right decision in each of these stages. I assume that is no coincidence. That is the perspective of how to address the technologies.

Alyssa: For sure. That is definitely not a coincidence and that’s exactly it. We in the security world really need to get out of this idea that we are going to build a bunch of tools and force them down developer’s throats and say, “This is what you are going to use and this is how it is going to be.” We do need, like I said, to meet them where they live and where they live is, they think in terms of IDE’s and repositories and build automation — and these are all the things that are meaningful to developers that, from a security perspective, we talk SAS, DAS, RAS all of these acronyms we have for the different tools and security tools that we have come up with but that doesn’t mean anything in terms of someone who’s ‘heads down’ day-to-day in the delivery pipeline. It is no accident that this is the perspective that we have chosen to take. Again, thinking even in terms of that empathy, how do I get security people thinking more in line with the other folks that they are ultimately charged with trying to help secure?

Guy: Yeah indeed. So I guess last but very much not least, I think this maybe my favorite section of this and also, it relates to this podcast. So I think I am a fan — we have a section called ‘Share the Journey’. Tell us a little bit about what goes on in that area, that part of the Hub?

Alyssa: Yeah and this is actually one of my favorite parts too, quite honestly. So what we’ve done with Share the Journey is taking all of this very wonderful material that we have put together. We want to show how this actually gets applied in a real world environment and what are some ideas and strategies that other people have been able to employ, what are the other lessons learned that they have encountered through their own journey in DevSecOps. And so, to that end, to facilitate that, we have taken a lot of the stories that have shared here on this podcast with a number of different guests and really looked at what are some of the unique challenges that they have overcome, what are some of the really novel or innovative strategies that they have leveraged? How have they employed some of the technologies and processes that we talk about throughout the hub to really succeed in maturing their own approach to DevSecOps — and highlight those. And almost a mini-case study —just telling a little bit of their story about what it is that they are able to accomplish, how they did it and just sharing some of the key highlights or the key insights that came from those stories that they shared.

Guy: Excellent and I think if you have enjoyed any of the past episodes of this podcast, which hopefully you have, you might find some of the content there, indeed, kind of starts with some of these conversations. We had the pleasure of talking to some pretty smart folks here and them sharing their journeys is helping us all learn and get better. So listen, we have a lot of smart folks listening to this episode who, hopefully, might be up for sharing their own journey or otherwise have opinions about how we can improve these best practices that we are sharing or tricks that they’ve learned. If they want to contribute their own content or insight, how do they get in contact with you to contribute?

Alyssa: Sure, so there are a few ways. One certainly is through our website. We’ve got just a simple contact form. They are more than welcome to leverage that or if they’d like to email us more directly, contact@synk.io would be a very easy way to get in touch with us. Additionally, through social media. We are very active with our Twitter account, @synksec. Definitely @ us. You can also @ me directly, if you want to give a mention to me or follow me on Twitter and reach out.

My DM’s are always open, my handle is @alyssam_infosec. So certainly happy to interact that way as well. And then finally through our website as well, you can get in touch with the MyDev SecOps Community. Some of our folks, myself included, are very active in that community as well and certainly that is a great place to share some ideas and thoughts and get more involved and potentially be able to share your own story as part of some of that information sharing that we do through the Hub.

Guy: Excellent. I hope there will be a whole burst of sharing going on here. We really would love to hear from you and then, as you might have noticed from that the intro to the podcast, this podcast is a part of MyDevSecOps and there are a whole bunch of ways to share content, to do public talks, to just engage on the Slack communities and others. So Alyssa, this has been great and I think as I pointed out, probably a lot of these different topics are full-on episode content on their own.

Before I let you go, I’d like to ask every guest that comes onto the show, if you have one bit of advice that you would like to give a team to level up their security-fu, what would that be?

Alyssa: The thing that I have been preaching, and I hate to use that term, but get rid of the fud more than anything else. It is unfortunate that we still — that that’s a thing — but the fear, the uncertainty, the doubt, and really focus on how what you are doing is going to help enable the business. So if we are talking about security initiatives, how is that tied to revenue generation or how is that going to create cost savings or open up a new business line if we are thinking from a dev or an ops perspective, those same things come into play. Okay yeah, we want to leverage a new container environment or a new cloud technology, wonderful but how do we sell that in terms of — this is what it brings to the business, this is how it is going to move us forward. Ultimately, in terms of whether it is reducing business risk or costs or it is opening up that new revenue channel for us those are the things that are, in the end, most meaningful. That is going to be your paved road to getting those initiatives approved.

Guy: Wow that is awesome. I love that, definitely get rid of that fear, start building. There is something positive with your attitude. This has been great Alyssa. Thanks a lot for coming onto the show.

Alyssa: Yeah thank you.

Guy: And thanks everybody for tuning in and I hope you check out the DevSecOps Hub at synk.io/devsecops and that you join us for the next episode.

[END OF INTERVIEW]