Hacking Security is a monthly podcast on emerging trends in application security. In Episode 4, secure development expert Meera Rao discusses DevSecOps.
Hacking Security is a monthly podcast on emerging trends in application security development hosted by Steve Giguere, lead EMEA engineer at Synopsys.
Episode 4 features Meera Rao, senior principal consultant and director of the secure development practice at Synopsys. She has over 20 years of experience in software development organizations in a variety of roles, including architect, lead developer, project manager, and security architect. Steve and Meera discuss the relationship between CI/CD, DevOps, and DevSecOps, how to get started in DevSecOps, why everyone in information security ought to learn how to code securely, how to get more women in technology, and more. Listen here or read the transcript below.
Welcome to the Hacking Security podcast. Hacking Security is a podcast for emerging trends in application security development. I am your host, Steve Giguere, and full disclosure: This podcast series is sponsored by the Synopsys Software Integrity Group.
And welcome once again to Hacking Security. In this particular episode—this’ll be our first interview episode, actually—we’ve got one of the industry-recognized gurus in DevSecOps. How did we get that Sec in there? How did the wonderful marriage, the happy couple that is Dev and Ops that we’ve been celebrating over the past few years with changes in culture, changes in agility, changes in velocity, the introduction of high-speed CI/CD pipelines—lots of good things have come out of the DevOps movement. And now we’re trying to break that up. Are we? We’re trying to turn it into a threesome.
DevSecOps is more than just a simple or automated integration of security into DevOps. And I think I didn’t quite understand the depth, the breadth, and the magnitude of what’s required when we’re talking about getting a DevSecOps culture in place. But thankfully, I’ve been lucky enough to have an expert. And that expert is Meera Rao.
In our conversation that’s coming up, Meera opened my eyes to what DevSecOps really was. Now I thought I know. But it wasn’t quite as enlightened as it is now. And I hope you find the interview equally enlightening, if not at least helping to solidify the direction you’re trying to go if you’re trying to create a DevSecOps culture in your development world. I could introduce her, but I think we do a fine job during the interview. So without any further discussion, here we go.
This interview has been edited for clarity.
Steve: OK, I’ll do a mock intro.
Meera: OK, sure.
Steve: All right, this will be Hacking Security Episode 4, I think. But this will be the first ever interview one. In fact, you’re the first ever interviewee on Hacking Security. It’s quite an honor, isn’t it?
Meera: Yes, it is.
Steve: Yeah. So I’m with Meera Rao, CI/CD guru, DevSecOps champion, and women-in-technology evangelist, perhaps.
Steve: Does that work?
Meera: It does definitely work.
Steve: I just made that up.
Meera: Yes, I am that title.
Meera: I would gladly take the title.
Steve: OK, here we go. That was a pretty good intro. I did OK.
Meera: Oh, really? That’s good.
Steve: I called you a women-in-technology evangelist. You just came back from a conference, correct?
Meera: I just came back from the European Women in Technology Conference.
Steve: Where you were doing a talk?
Meera: Yes, I was talking about how to grow together through mentorship.
Steve: Oh, cool.
Steve: Yeah, I think I’ve seen it or I’ve seen you talking about it on LinkedIn.
Steve: Excellent. Where I want to focus today, though, is on DevSecOps, because people don’t say that enough.
Steve: I think we need to talk more about it.
Steve: I want to get your take on its evolution and its future. Does that make sense?
Meera: Yes, it does.
Steve: In preparation for this interview, I went outside, and I asked a whole bunch of our colleagues these questions about, where did it come from? Is it real? Is it a concept or a culture? Because we call DevOps a culture. Would that be fair?
Meera: It is fair because…
Steve: You’re looking like there’s a “but.”
Meera: No, the reason I say that is a lot of people don’t really realize what DevSecOps is.
Steve: That’s why we’re doing this.
Meera: Yes. They assume that when they’re doing continuous integration (which is CI), continuous delivery or deployment (which is CD squared, I call it, but you can call it CD), they’ll be doing CI and CD, and they assume that they are doing DevSecOps.
Steve: But there’s no Sec.
Meera: There might be security. They might have automated static analysis or dynamic analysis or software composition analysis. But that doesn’t make it DevSecOps.
Meera: There’s a fundamental difference. CI/CD is all about automation. Whereas DevSecOps, the way I define it, is about people, process, technology, and then all of them coming together in a continuous fashion. You have continuous communication, you have continuous collaboration, you have continuous feedback from the field. And then you have on top of this continuous integration, delivery, as well as continuous deployment.
Meera: For me, when organizations or clients talk about both of them interchangeably, “CI/CD is DevSecOps,” I’m like, “No, it’s not.” Because when we talk about DevSecOps, what we do within Synopsys is also try to bring in all the processes that you have in your organization, in the pipeline. We try to bring the people into the pipeline.
What do I mean when I say we bring the people into the pipeline? One of the things is, say, suppose you check in your code, you run a static analysis scan, and it finds certain issues. You immediately want to know, who was the one who checked in the code? Not that you don’t want to give them the bonus.
Steve: Yeah, yeah.
Meera: This is the bonus season, right? December. But then you want to make sure that you give them the training that they need in order to not make this mistake the next time they check in the code. You want to bring in all three aspects together in your CI/CD pipeline. That is where there is a fundamental difference between CI/CD and DevSecOps.
Steve: So we should call CI/CD an enabler for DevSecOps.
Meera: Yes. Automation is required. You can still be doing DevSecOps without CI/CD, because you’re trying to bring your development team, your operations team, and security team together to work together. You might not want to do continuous integration or delivery.
Steve: So you could have low-velocity DevSecOps.
Meera: Yeah. Then the three teams are working together as one team. But if you really want to increase your velocity to production, you want to find all the issues early in your SDLC, then I think CI and CD are definitely going to help you.
Steve: Yeah, just automation generally. I’ve never heard of low-velocity DevSecOps before. I don’t think that’s going to catch on. Yeah, OK.
Steve: So do you think, then, based on what you just said—I wasn’t going to ask this, but now you’re creating questions in my mind—do you think there’s confusion about your definition of DevSecOps because of DevOps? Because that word is known and people see that as “We’re developers. We have pride in being DevOps. We want ‘DevOps’ on our business card. We want to go to DevOps conferences. We want stickers on our laptops that represent DevOps tools that we can be associated with.” There’s a culture. That’s what we’ve called it.
Steve: So when you say DevSecOps, people are expecting that same movement or some way to transition from DevOps to DevSecOps with the same enthusiasm.
Meera: Yeah. That enthusiasm you want in 2018 and going forward in 2019 is still not there in the DevOps community. Because any time you bring in security, one of the challenges that you have is it reduces your velocity. Anytime you run a static analysis tool or a dynamic analysis tool, if your velocity was you were deploying every 10 minutes, now, this tool that you bring in is going to take four hours to run the scan. It reduces your velocity. So rather than using security as an enabler, they think that security is hindering them to go to production.
Meera: That is where we try to educate them and say, “There’s no one size fits all.” It’s not that you just bring in a tool, include it in your pipeline, and say, “I’m going to do DevSecOps.” There are many, many ways of including security in your DevOps processes. That’s where I think we need to educate organizations and companies on how you need to bring in security. I think that’s when DevSecOps also will be a cool thing, just like DevOps.
Steve: OK, good. Because then developers who have the knowledge will stand out.
Meera: Yes, exactly.
Steve: Then that understanding, I think, what you said about adding security to the DevOps process or culture decreases velocity, but that is a…
Steve: It’s a false economy. Because it’s a sacrifice in speed, but they don’t realize that there’s a long-term gain in terms of how much their time to market will increase because they’re not fixing stupid bugs. I’ve been in conversations with developers about this before. And it doesn’t take much of a conversation where they flip from rolling their eyes about adding security to explaining that. They go, “Yeah.” Because their mind automatically goes to how many bugs they fixed that week. You can just say, “Well, then we’ll have to fix all those bugs.” They’re like, “Yeah, I can see.” I’ve worked with teams where they’re spending 50% of their time fixing defects.
Meera: The other big issue I see is the quality defects that the organization sees, they don’t put the same importance on security defects. Suppose they’re using Jira for their quality defects. These security defects are stored somewhere in an Excel spreadsheet or in a PDF, Word document. How do you have any governance in your pipeline when you don’t even know what defects you have for security? You have to give the same importance that you give your quality defects to your security defects. If all of them go through the same defect tracking, then…
Steve: That’d be a wonderful world.
Meera: The pipeline has a better way to understand, “OK, I have a critical finding. I have 30 days to fix it.” If that threshold is crossed, then the pipeline knows, “OK, 30 days exceeded. I need to notify someone.” All this governance, risk management, defect management needs to happen the same way that it happens for your quality defects. And that’s not what’s happening right now.
Steve: I think a lot of situations I see, I’m impressed that they’ve even got quality defects at that level.
Steve: You kind of touched on the aggregation of both. It could be quality, it could be security, it could be issues, let’s say issue management and centralized location. To me, that sounds like—I think before we started, I mentioned the word “unicorn”—a very difficult-to-achieve thing. And that brings me back to integrating security into DevOps. One of the bigger complaints is that the tools just aren’t designed for that world. My question is then, why have we not designed… I could say “we,” because we have tools, but every tool.
Meera: I think the tools are designed for that. But then I think we are not educating our clients properly on how to use those tools in a CI/CD environment. The biggest mistake most organizations make is they bring in the tool, they just automate the tool—you have scripts for automation—and then just run the scans. That’s not going to work. Anytime you want to bring in any tool, whether it is SAST, DAST, software composition analysis, IAST—we have tools for all these at Synopsys—you need to have an onboarding process even before you automate that.
What do I mean by that? When I say “onboarding,” you need to have onboarded the application, triaged all the results, marked all the ones that you don’t care about. Then, once you have that, you know, “OK, I have 10 findings which are true positives. Everything else, either they are false positives or I don’t care about them.” Then you automate that in your pipeline.
Steve: They have to want that, though.
Meera: That’s how we do it, right? When we go to clients, we want to make sure that you onboard your application and then you bring it into your pipeline.
Meera: The next big mistake that I see organizations make is they have one set of rules. Everyone likes OWASP. Whether it’s a web application, a thick client, a mobile application, you just run OWASP Top 10. It’s not going to work.
You need to customize the rules for the application and for the language. The OWASP Top 10 is different for…say you’re doing Java. If it is a Java web application, it’s different. If you’re using REST services, there is no OWASP Top 10. You need to make sure that you configure the rules based off of what language it is, what type of application it is, what technology it’s using. And then you automate it in your pipeline.
Even then, you need to look at, what kind of defects do you want to automate defect tracking for? We usually tell clients, don’t automate all the defects that the tool finds. Start with critical findings. Even within critical findings, maybe start with SQL injection the very first month. Because if you automate all the defects, you’re going to annoy your developers. You want their buy-in. So the very first month, say, “We’re only going to automate SQL injection.”
Meera: Make sure that you weed out all the SQL injection the first month. Then, the next month, start with cross-site scripting. I think that is where you need to bring in your development team, your operations team, your security team to work together to make sure that you are enabling your developers.
Steve: I see. I guess we are talking about it’s a recipe, this best practice, and it’s a phased…
Steve: A phased introduction of friction, so you’re not just ripping the Band-Aid off. They get used to the idea of part of security being automated. They get better at that one, and you can expand the automation. They get better. Eventually, they never see more than a trickle of security in their feedback loop. Then they can see it’s fine.
Steve: The next question is, how do organizations find out about these recipes? Because it feels like there’s immaturity just in, I guess, CISOs who are trying to implement these processes, or software security groups, or whatever the organizations have. They’re clearly not doing this, because I almost never see this in practice. The typical practice I see—and far from the best—is they design the pipeline first with no security. They ramp the developers up to full velocity. And then they start looking for security.
Meera: We are OK with that approach. We are OK. A lot of our clients, many places we go, they have a CI/CD pipeline. We are OK with that. They say, “OK, we have Jenkins. We have Maven. We use GitLab. We use these projects. We have Java, .NET, C, C++.” We are OK with that. As long as you have a pipeline, you are doing continuous delivery, you deploy to Tomcat, you are lucky. Yes, that’s very good. Now, let’s bring in all the security tools.
Steve: What I see is, yeah, that. But they tend to work out what the tool they need is without outside assistance. Then they’ll even maybe try and DIY the implementation of that into the environment. Almost instantly, the concept of DevSecOps becomes negative. You could have 1,000 developers, and you blew your one shot to make that happen in your organization. And now what could have been a six-month program is going to be a five-year one.
Meera: We start with helping them build a pilot program. That pilot will be the poster so they can showcase to their entire organization, “This is what we did.” When we go in there, we say, “OK, let’s look at what you have right now. What tools do you have? What languages are you using? What technologies are you using?” If they have already tools, whether it’s Synopsys tools, commercial tools, or open source tools, we don’t care. We want to help you build this pipeline. You have a CI/CD pipeline, but then when I talk to my clients, I tell them, “We’ll help you build a DevSecOps pipeline, which is intelligent, which is dynamic. Because your pipeline right now is static. It doesn’t know anything.”
If you have a SAST tool, no matter what the developer checked in, it keeps on running the SAST tool. If you have DAST integrated in your pipeline, no matter what you change, it keeps on running the DAST tool. That’s why you have this friction, with your development team saying, “You brought in all these tools, and then my pipeline increased from 20 or 30 minutes to four or five hours.”
So when we go in, when we do the pilot, we want to make sure that we look at the type of application that you have. What is the pipeline? What do you want to do? What kind of risk management do you have in place? What is the application risk? We bring in all these considerations into the pipeline.
Meera: Then we decide, what do you want to run inline in the pipeline? And what activities do you want to run out-of-band? Because a lot of times you want to run these activities inline, and many times there are code changes for which none of the tools can do anything. Say you changed a cryptography API, which is a major change. The tool might say, “Oh, you’re using MD5.” That’s all. It doesn’t know what you are using MD5 for. That’s when we want to make sure that we trigger an out-of-band manual code review or an architectural risk analysis.
Say your attack surface changed. The pipeline doesn’t know that you added a new framework or you added a new technology. We want to make sure that we take into consideration all of what we call a bill of materials—not with respect to software composition analysis, but the changes that are going into the pipeline—and trigger activities based off that.
The pipeline is not static. It is dynamic. It has built-in intelligence where it knows, “What do I need to do next?” Then it also knows when I ran the scan yesterday, I had five SQL injection issues. When I run the pipeline today with SAST, I have 50. Oh, there’s something wrong. I need to pause, or break the build, or let the product manager know. “Do you want to look at this? You decide. Do you want to proceed?” We are fine with that. But when you say, “I want to proceed,” we want to make sure that we gather that communication for auditing purposes.
There are a lot of continuous activities going on within the pipeline that we try to build in. When we talk about a pipeline, when I talk to my clients, I say, “We don’t just build a CI/CD pipeline. It’s a truly DevSecOps pipeline, which includes all the processes that you have in your organization.” Again, all those things, there has to be a way for me to create those dashboards. You have to have risk management somewhere. You have to have a defect management tool somewhere. If you don’t have those, then we cannot help you build this intelligent pipeline.
Steve: Yeah, you won’t have any visibility.
Meera: Yeah. We want to make sure that when we talk about all these activities, we work with organizations to say, “It’s not simple CI/CD.” This becomes the poster child for other business units or other product teams in the organization. They can showcase, “Hey, this is what Meera and her team did.” Then we maybe do a two-day workshop or help them build templates so that they can scale and continuing using whatever we build for other product teams in their organization.
Steve: Do you think that this gets hindered by budgetary constraints a lot? If I went into the four tribes scenario, you’ve got your CISO at the top who understands that security is an enabler. They’re going to have the budget, and they would come to you, and you’d get to do this.
As soon as you start to go below that, your technology enthusiast will probably DIY it and maybe not talk to you about it. Then you’d just come in afterwards and look at the disaster.
As you get down, you might be fortunate enough to have the conversation at the right time. And then they’ll say, “Oh, but our budget only allows us to buy a SAST tool. That’s why we called you. We only have enough money for that.”
How do you handle the situation? I think if people are listening to this and they just heard your description of what DevSecOps looks like, which was great, they’re probably thinking, “Oh, I wish I had that.” But they know already that their budget is probably not going to cover that.
Meera: No, I think we have seen that. In many places, they only have budget for a commercial tool, for either SAST or DAST. That is where we have told them, “Why not restart with an open source tool? We’ll show you how it works.”
Then, the pipeline that we build, we call it a blueprint or a reference architecture. Today you might have an open source tool. Tomorrow you might decide “I want to buy Coverity.” Then you can flip that switch and use Coverity. Today you might have an open source DAST tool, and tomorrow you might decide, “I want to purchase a commercial tool.” You should be able to switch easily.
Meera: Again, there will be some changes, because each tool has its own command line interface. So there will be some minor changes. But the majority of the stuff that you do for defect management, metrics, risk management, breaking the build, and gathering and consolidating all the results will still be the same.
Steve: Right, so they’ll have a template for success. They can slowly upgrade and probably use it to justify the budget next time.
Steve: Because they can see the holes in their DevSecOps dream.
Meera: Yeah. Many times we also have worked with clients where they use an open source tool in their pipeline. Then when it exceeds a certain threshold, they already have a commercial tool, which usually takes hours to run because they do in-depth scanning. We say run open source tools in your pipeline. And then when they cross a certain threshold, try to run these commercial tools as an out-of-band activity. You’re still using the same metrics dashboard, defect tracking, and risk management, but now you have additional assurance that, “OK, I ran these.”
This is also where we help a lot of clients run managed services from within Synopsys. Maybe you’re running your tools in the pipeline, but you need additional assurance for some major changes that you accomplished. Then you want a manual code review or a manual penetration test or manual dynamic assessment. So you can trigger those activities out-of-band in the pipeline.
Steve: OK. You mentioned “out-of-band.” A lot of people, their security is entirely out-of-band right now. They’re beginning to automate, and they want to automate. That means as a developer, I’m used to security being out-of-band. And I’m used to it just being something that’s being done to me all the time. How do we fix that? Other than being granted access within organizations because we’re invited to be a part of that, how do we get a message out to the modern-day developer that security isn’t like that? It doesn’t have to be like that. There’s a better way. Is that something we can start in universities to change the way we teach development to have security built in?
Meera: I think it has to start from universities, or maybe even from high school.
Steve: What am I talking about, right? I have a nephew who’s four who’s writing Python.
Meera: Yeah, I have a niece who learned how to do PHP and Python, and then she was also doing Java. Why not teach from there?
Steve: Yeah, teach security.
Meera: Because at that age, I think they already have all the tools and technologies in hand. They already have heard about, “Oh, OK. I had posted all this on Instagram. Something happened. Something got hacked. This is what happened with Facebook.” They have already heard about all these security issues.
Steve: Being hacked at school.
Meera: So why not teach them from high school? If not high school, then yes, in undergrad. They definitely have to learn about security. Just like how we taught them how to write “public static void main” when they learned Java. Why not teach how to mitigate SQL injection properly? I think that should start from there.
Meera: The next thing I also want to see—I’m not sure if I will see that in 2019 or even in 2020—I would like to see that every person who is part of information security or application security really knows how to write code.
Steve: Well, yeah.
Meera: Because that’s not happening.
Steve: We have a ways to go for that one.
Meera: I was a developer. So I see the other side. I was a developer for 20 years before I came into this field. So when I talk to them, I understand their pain. But then people who are in information security or the SSG or whatever you may call it, they don’t know how to write code. That’s a huge challenge. Because you are telling your developers, “Hey, there’s a SQL injection.” But the fix you are asking them to do, you’re giving a canned report from a tool. And now, you know, everyone uses a lot of open source frameworks. They might be using Spring JDBC, they might be using Hibernate. They might be using iBATIS. You cannot give a canned report saying, “Hey, go fix this.”
So I think it’s very important for the SSG to be knowledgeable about how to write code and then how to actually fix the issues that they find.
Steve: Yes, have some empathy for the developer, the development community.
Steve: It is interesting. There’s a lot of CISO reports where you go and ask people a lot of questions and report the findings on their opinions on software security. But I would like to see the breakdowns separate, “These are CISOs who were former developers, these are the ones who weren’t,” and see.
Meera: I think it’s very low. Even when we were part of Cigital, I think we had maybe five or six people who actually had done development.
Steve: I feel like I’ve clarified myself on DevSecOps. I mentioned before we even started this, I was asking security professionals to define DevSecOps for me. I asked six people, and I got six answers. They’re now going to have to listen to this to get the education, because they knew why I was asking them, which is really cool.
I’m asking now for a prediction. I think anyone listening to this has probably a pretty good picture of what DevSecOps, CI/CD integration looks like, and understands that someday it will be culturally positive. And people will be proud to go into the DevSecOps convention, and they’ll want security stickers to show how good they are at writing secure code. And we’ll have an education system that doesn’t teach coding and security separately, which is still a thing. Because I have to keep up, I have to go on the advanced Python course, but then I have to go on the secure Python programming course afterward, and they’re still separate. The course for Python I did, I’m doing it, going, “This has got problems.” So I’d love to see the DevSecOps philosophy incorporated into education. That would be great.
Steve: How much time will it be in our lives before we get to something where… Is it the generation that’s coming now? Are we going to have to wait for the four-year-old nieces and nephews to grow up and then we can look back and go, “Ah, finally”?
Meera: I don’t think this generation is going to look like that.
Steve: All right, wow.
Meera: Yeah. The next generation maybe, because we still haven’t started that. Every one of those changes takes time. So maybe 2030. I think it’s going to take at least another 10, 11 years for us to get to that phase where can say, “Yes, every person who is graduating knows how to write secure code.”
Steve: It seems ridiculous that we don’t. That should be the idea.
Meera: But it’s not.
Steve: We put a seat belt on. It’s ridiculous if you don’t. That’s what we have to get to.
Meera: We have a lot of those. Even in the medical industry, we have a lot of those. Once you cross 30, you need to undergo all these tests.
Steve: It’s built in.
Meera: Yeah, it’s built in, but not here.
Steve: You brush your teeth.
Meera: Yeah. But not here.
Meera: So I think it has to change, and we are the ones who should change this, talk about this. And that’s exactly what I do everywhere I go. Whether in the blogs I write or at the conferences where I speak, that’s what I say: Security is not just a job for the SSG or information security. It’s everyone’s job. Because yes, in this profession, we don’t get to save lives. But we are saving lives in an indirect manner.
Meera: Right? Because people’s money gets stolen, their credentials get stolen.
Steve: Sometimes literally medical devices.
Meera: Yeah, medical devices, pacemakers. Your cars. You’re driving in your car, you have…
Steve: Autonomous vehicles.
Meera: Video cameras in your house monitoring your kids, and that gets hacked. We aren’t saving lives literally in the sense that medical doctors do. But in another sense, we are actually saving lives. I think as long as people realize that, this is a cool profession. We should talk to kids in middle school, high school, and get them to understand how important it is to write secure code.
Steve: This transitions nicely to the conference you were just at, Women in Technology. I noticed that the last few AppSec conferences that I’ve been to, the female population is noticeably different. It used to be just men pretty much.
Steve: By no possible stretch is there any equity there really, but it’s noticeable. Is it getting better but needs to be much, much better?
Meera: Oh, yeah. It’s getting better because there are a lot of women like me who speak out. I see that in my own organization. Even yesterday, when we were in this group, I was the only woman. I looked around: “Oh, my God. There’s no one else.” These were all the leadership people who were in the room. I was like, “This is so sad. It’s just me.”
Especially at European Women in Technology, that’s why I didn’t focus on talking about DevSecOps or CI/CD or security in general. I wanted to talk about how I came all the way from a small town in India, all the way to the U.S., and then working in this amazing company, how mentorship actually helped me.
I want to mentor a lot of men, as well as women, to get to the field. Because everyone assumes when we talk about DevSecOps, CI/CD, that it’s a very challenging profession. We need to travel a lot. No. There are a lot of women on my team. Yeah, they need to travel maybe once or twice or thrice a year, but not every month.
Meera: There are a lot of opportunities as long as you know how to program, how to do some automation. You don’t need to know security to be part of a DevSecOps team. Yeah, you need to know a little bit of security, but you can learn, just like how I learned. When I joined the company, I didn’t know anything about security. So I want to inspire other women. I know I inspire a lot of women within my organization, within my community.
Steve: And men.
Meera: And men. Yeah, a lot of men have got upset over that. “Hey, Meera. Why do you say that? You inspire us as well.” I want to make sure I tell them that this is the coolest field. Like I said earlier, we literally save lives by being in this profession. We also help companies release products at an increasingly high velocity by helping them build all the automation. And then we also help the development team. I think I really want women to listen to this podcast and say, “Oh, if Meera can do it, then I can do it.”
Steve: Yeah, you’re a role model, an inspirational role model.
Meera: I would like to say I would love to be a mentor. Because a role model is someone you see but you don’t get to talk to. When I watched the presidential elections, especially in 2004, Obama was my role model. I never got to talk to him. Hillary Clinton was my role model. (For speaking. I never wanted to get into politics). Mother Teresa was my role model for the passion that she had for people. You never get to talk to them.
So I would like to be a mentor to everyone. They can reach out to me on LinkedIn, Twitter, Facebook. I am available to them. They can talk to me. That’s why I say…
Steve: Accessible role model.
Meera: Yes. Maybe. I think, yeah, that is what I want: to inspire a lot of women, as well as men, to get into this field and then see how amazing this industry is.
Steve: It’s full of opportunities. It’s immature. It’s ground floor still.
Meera: It’s very satisfying. Yeah, in all ways. A lot of people get into specific careers for money. And this is the field if you want to earn money.
Steve: It does OK.
Meera: Right? A lot of people want to travel, and this is the field if you really want to travel. Many who are listening know that I grumble a lot because I travel a lot.
Steve: Sometimes you accidentally go to France.
Meera: Yes, you go to Amsterdam, you go to France. You take a few hours and go look around the city. Many times you get to take your family on all these travels. There are a lot of benefits in being part of this journey.
Steve: Can I ask a question which may be controversial then? If I were listening to this and I wanted to get into it as a woman, there are a lot of industries where women are not that welcome. It’s an old boys club. You could have powered through that to be the inspirational mentor you are now. But we don’t know what you went through to be that. Would you say that it is a welcoming industry, that there’s not something to be afraid of?
Meera: It is. When I joined—because it’s almost 11 years now since I joined the security industry—it was not that welcoming. But my company was. There were challenges even for me because I didn’t know about security. So when I went and sat with a group of men and I had no clue what to say, what not to say, I think it was hard work. It was passion. It was that aim to excel in this field and show everyone that no, I can do it.
A lot of people think, when they look at all the awards, the interviews that I have, “Oh, Meera is very lucky.” I say, “There was no luck in this.”
Steve: It’s hard work.
Meera: This was hard work. But when you do that hard work, at some point, you reach that destination wherein you can influence a lot of other people. So it is not easy, but you have to do hard work in any other field in order to excel.
So I think it is a welcoming field now. A lot of companies want to bring in women. When I say they want to bring women into this industry, I don’t mean they just go somewhere and find a woman and bring her in. But if you have that knowledge, if you have that experience, then you are welcome. If women listening to this have those skills, we are ready to hire them.
Steve: Oh, yeah. We always need people. Everybody needs people in cyber security.
Meera: Yes, and we need people in DevSecOps. So if they are interested to work with me…
Steve: We’ll put your details in the show notes. Wherever this podcast will be, go check out the show notes in your app, and you can get information.
Steve: All right. I’m already recording this, so this is sort of the end of the credits section where I ask you, if you have a key cyber security influencer in your life that you think would be good on this podcast, who are they and what’s their subject of expertise that we might talk about?
Meera: I would recommend you to talk to Andrew Glover. He is the delivery manager for Netflix. I worked with him before my tenure at Cigital, at Stelligent. He’s an amazing person. I learned a lot from Andrew. We invited him to speak at Synopsys. I think doing a podcast with him about DevOps and what Netflix does for security would be awesome.
Steve: I’d love to know that.
Meera: Yes, Andrew Glover from Netflix.
Steve: OK, I’m nervous already thinking about talking to him. Thanks.
OK, that was our interview with Meera Rao. And wow, what an interview it was. It went into all sort of directions: defining what DevSecOps is, what it should be, with all sorts of advice on how to get started for anyone, really, who is looking to secure their DevOps environment. We even got a little bit at the end where we talked about her evangelism for women in technology and women in security and how great a career move security can be. If you’re looking into that, then yeah, do check the show notes. We’re going to get her Twitter handle and her various other contact information in there. Once more, big thanks to Meera, a fantastic person with a great attitude and an incredible role model for anyone in the industry.
OK, this has been Hacking Security. I’m your host, Steve Giguere. Thanks for listening, and we’ll see you next time.