Harshil Parikh -- Deep Environmental and Organizational Context in Application Security

Harshil Parikh is a seasoned security leader with experience building security and compliance functions from the ground up. He notably built the security and compliance team at Medallia from scratch and led it through several transitions. He is also a conference speaker, and, most recently, he co-founded Tromzo. Harshil shares insights about AppSec, running a startup, selling effectively, and provides justification for his mantra, "Context is king."

Harshil underscores the importance of understanding context in security, emphasizing that it's the bedrock for making informed decisions. He also brings to light the significance of data-driven metrics in application security.

Harshil champions the cause of enhancing the developer experience in application security. He posits that security professionals should be more than just watchdogs; they should be enablers, aiding developers in making the right security decisions. This involves equipping developers with the necessary tools and knowledge and providing them with the relevant context to understand the bigger picture. Harshil's insights into the trend of developer autonomy, especially in modern companies, are particularly enlightening. He discusses how developers today often take ownership beyond just coding, emphasizing the need for security guardrails to guide them.

Rounding off the episode, Harshil touches upon the challenges of scaling application security programs in organizations. His main message resonates powerfully: the role of security professionals extends beyond mere problem detection. It's about risk management, improving developer experiences, and navigating the complex labyrinths of organizational hierarchies. This episode is a treasure trove of insights for anyone keen on understanding the nuances of application security in today's dynamic tech landscape.

Recommended Reading:
The Metrics Manifesto by Richard Seiersen. https://www.wiley.com/en-us/The+Metrics+Manifesto%3A+Confronting+Security+with+Data-p-9781119515418

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @AppSecPodcast
➜LinkedIn: The Application Security Podcast
➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast

Thanks for Listening!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Transcript

Chris Romeo: 0:00

Harshil Parikh is a seasoned security leader with experience building security and compliance functions from the ground up, and most recently built the security and compliance team at Medallia from scratch. Scaled the team globally, achieved compliance, SOC 2 ISO FedRAMP, went through an IPO, And secured seven mergers and acquisitions. Additionally, he's been a speaker at RSA Conference, AppSec USA, and CSX Europe. Harshil joins us to discuss developer first security, developer autonomy and guardrails, and challenges scaling AppSec programs. We hope you enjoy this conversation with Harshil Parikh.​Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I am the CEO of Kerr Ventures and also joined by my co host Robert Hurlbut. Hey Robert.

Robert Hurlbut: 1:29

Hey, Chris. Yeah, Robert Hurlbut. I'm a Principal Application Security Architect and Threat Modeling Lead at Aquia and really glad to be here and to talk to our guest today.

Chris Romeo: 1:42

And you are broadcasting from the Great American Plains, if I'm not. If

Robert Hurlbut: 1:47

I am. Yeah, I've, I've, I've been traveling a bit the last few weeks. And so, yeah, I'm in the Plains States, Midwest. Yes.

Chris Romeo: 1:56

Yeah, that's good. That's, that's, uh, it's a good challenge or good, uh, difference from the good old east coast where you usually hang out, uh, up there in the northern part. So where all the snow comes from, which most people like me, we run away from and go to the warm places, but that's, that's just me and just my take. So, all right, we are joined today by Harshil. We're going to jump right in, Harshil. We're going to throw you right into the deep end, because I don't believe in warming up guests or anything or giving them softball questions. Like, what's your security origin story? How'd you get into AppSec ultimately? Maybe security before that? Like, what was your trajectory? What did it look like?

Harshil Parikh: 2:35

Yeah, it's a good question. Hello, everyone. Nice to, by the way, thanks for having me here, Chris, Robert. Um, I started my security career in the Great Plains, one of those Great Plains states. I actually went to school in Kansas City. But my interest in security started way before then, even when I was in high school, I guess, you know, it's, um, I used to go to the local library and read about, uh, read Kevin Mitnick's books back in the day. Uh, unfortunately, he just passed away, I think, a few weeks ago. But he was kind of, he made cyber security exciting for me at that time. Like I wanted to get into that, but at that time, you know, we didn't have any majors you could take in cyber security. Now you do, but at that time, I went to Kansas City, majored in networking. It was kind of close to security, I guess, that you could study. So, my first gig, my first job, real security job, was in Kansas City. And, uh, I was racking and stacking firewalls before, before cloud was a thing, right? So, um, uh, that's how I started my journey in security. With a lot of, uh, data center related things, firewalls, and then proxies and SSL VPNs when that was a new thing back in the day. Eventually, I, um, you know, went into a lot of pentesting as well, application security pentesting. Although most of the pentesting was still network pentesting at that time. Uh, then, uh, my journey eventually took me to more of, uh, Business side of security, so I did advisory services with one of the big four consulting firms within security itself. So building and scaling security programs for other larger companies. And at some point I realized that you know what, I've done enough consulting and enough telling people what to do, writing a document and giving a report. I gotta do it myself, so I started my corporate journey. Became a CISO eventually at a company called Medallia, a B2B tech company in the West Coast. And then saw the same problems occur again and again. So said, okay, as an industry, we have to solve this problem. So I took the, uh, you know, I jumped into the deep end and started a company, Tromzo, after spending several years as a security practitioner myself.

Robert Hurlbut: 4:47

So let's dive in a little bit to some of the work that you've done as a startup founder and in particular in the security space. I think you've experienced some challenges and rewards of building a company from the ground up, but can you share some of the most valuable lessons that you've learned and how they have shaped your approach to entrepreneurship?

Harshil Parikh: 5:10

Yeah, you know, it's, um, it's interesting that all of the learnings that That, you know, I've had in my co founder as well, and as a security practitioner, you would think that, you know, there are these very obvious problems. If you solve these problems, then you have a good working product that solves problem and hence a good business, right? But the challenge that Almost every founder goes through and, uh, and if you flip the switch, on the other hand, if you become a vendor, if you're a CISO, you're being reached out, or if you're a security person, you're being contacted by so many product companies, so many vendors trying to sell you stuff that most people just tune out, right? So it's, um, It's not just about solving a problem, but it's also about who do you solve the problem for? How do you communicate that problem solution? Is your problem even important to the people that you're reaching out to? So all of those questions are very foundational to company building and to building a business. Like you have to, You have to figure out how to sell your product. It's not just having a great product doesn't actually work by itself. It's a foundation, it's table stakes. Your product should actually solve a problem. But, um, how do you get in front of the right people? How do you enable the business to actually grow? All of those things are, uh, are very foundational to a successful company, successful business. So, for me, you know, coming from a security background as a CISO, you know, you would expect that, hey, if something solves my problem, it should be a solid business. But at the same time, you gotta figure out how to reach out to those right people. So a lot of those learnings for me personally are, how do you make that message simple, effective, and how do you get it in front of the right people, right? Like that's the, that's the biggest challenge that most security founders have these days.

Chris Romeo: 6:56

What's your approach to get in front of the right people? As a new startup founder, because I know we've got a lot of people listening who probably on the other side, they're on the other side of the equation. They're the ones being reached out to. But from your perspective, what's what's been successful for you?

Harshil Parikh: 7:13

Yeah, so what has worked for us is, is look, we got to be very transparent. If you try to be an outward salesperson, people pick that up very quickly and it turns people off, right? Like, don't try to sell your stuff. Just try to solve a problem, right? And Maybe that's not a problem for everyone that you're trying to reach out to at that point, but at some point it will become a problem. And if you just come out as a genuine, authentic person who's trying to solve a problem with a good differentiated solution, they'll remember you, right? They'll reach out to you when it becomes a problem. Even if I put myself In my previous roles, when I was trying to build my security org from the ground up, the problems that I was trying to solve in the first year were very different than the problems that I was trying to solve in the third and the fourth year of my security program maturity. So if you're trying to, you know, uh, get your solution in the door at a company today, they may not be feeling that problem at that point, but at some point they will, right? So just be authentic. Be, uh, don't try to sell stuff by creating FUD. Uh, don't try to, you know, give free iPods if you take a meeting. All of that stuff, maybe it works in some cases, but, um, if you're a genuine, authentic person, if you have a good solution that actually works, talk about that. Talk about how you have a different approach of solving that same problem. And, uh, and people will, you know, will remember it.

Chris Romeo: 8:41

Yeah, I think one of the advantages or see even secret advantage or unfair advantages they say in the startup world is being a, a member of the community. Which is kind of, it's where, how you got to being a startup person and it's founding a company. I did the same thing. Like I was in the community and then I started a company. And so I was able to reach out to people and people realized. Hey, you're going to provide value. You're sharing content. You're sharing things that don't just promote what you're trying to do as a company. You're still being a strong community member. We did an interview with Tony Quadros, uh, just a couple of weeks ago from Contrast who really helped us to understand what goes into being a good security, uh, account executive. And he said some of those same things you did. It's about, you know, it's about being transparent, it's about being real, it's about being, you know, part of the community, part of being a part of what's happening in AppSec. And so, I think that's just a really powerful way to approach it, and I really liked your answer as well. You know, just being transparent about who you are and solving somebody's problem versus... People that still try to use those classic sales techniques of, let's just annoy the prospect until they maybe take a meeting with us. Like that doesn't work in this day and age. It's just not, it's not, it's not something that people are interested in.

Harshil Parikh: 10:09

Right. Yeah. I mean, if you're, if you're genuinely helping people, they remember you, they recognize you. Right. And that effectively that becomes your brand, uh, in the industry. And we're all, uh, in this industry longer than individual companies itself. Right. So, so I like to think about my relationship with people within this industry as that's something that spans over several decades and not just a

Chris Romeo: 10:34

It's a long, it's definitely a long term thing and that's, that's a good reminder. And even people that are working jobs in AppSec, you're likely, your career is going to extend beyond single companies. Go through three, four, five, six companies, maybe in your time. And so that, that industry reputation is, is a very important thing for you, because this is a small industry. Like AppSec is very tiny. We could sit here and we could make a list of all the people that, um, two of, two out of the three of us know. And it's, it's a small community, like people know, um, know each other and, and know kind of what's going on there. So let's, let's transition and talk about developer first AppSec. So I know you've written some about this, Harshil, but it kind of caught my attention because I just happened to be looking at Gartner's hype cycle for 2023. And they have this new category that they're calling devX or developer experience, this area where tooling is helping the developers to be more successful and it's more ingrained in what they're doing and trying to take down friction. So I'm curious from your perspective in the world of AppSec. What is that? What is DevX developer experience or developer first AppSec? What does that look like in your world? I

Harshil Parikh: 11:55

Yeah. So, so let me, let me talk about my personal experience and why I care about this. Uh, when I was a pen tester, when I was doing security assessments as a consultant, you know, we would, we would go into companies and say, hey, here are all these things that you should fix. They would, we would come back six months or a year down the line and They still wouldn't have fixed most of it, right? And as a consultant, you would think, why are you guys not fixing it, right? It's obvious, like, these are things that you should, but you don't. So, the other half of that picture is, it's actually really, really hard. It's really difficult to get people to do things. And as security people, Our job is to really highlight those risks, identify those risks, communicate and help the other teams fix those things. But you're not the ones actually fixing those things. We're not the ones mitigating those risks, in most cases. So, so when I went to the other side of actually running and building security programs myself, I saw that it's not just about, you know, finding problems, finding problems, it's, it's actually really difficult as well, like we hire some of the best talented people to, to find those issues and risk, but then it's equally hard to convince people to actually spend time and do things. And it's not because they don't want the dev teams or cloud teams. They don't actually want to fix it. They do. But the thing is, they don't understand how important it is, or they've got other priorities as well that are equally important, if not more important than security. So if you, if I think about myself as a software developer, just trying to ship a product. You know, a developer is, is judged, or the performance review is based on, you know, how many features you write, or what quality of the features are, and high quality of feature actually includes performance, scale, reliability, security, all of those things, right? So, security is one element. of the broader spectrum of what a developer's job is. So making that easier for developers, so they can actually make the right choices, do the right things for security, it's actually pretty important. And that's why developer experience or developer first security is really, really important. So you can't stop at creating this PDF report with hundreds of findings and expecting somebody to fix it, or creating... Hundreds of Jira tickets and expecting somebody to just go and fix. There's a lot of organizational nuance that goes behind. How do you actually drive remediation of the risks that you identify? And at the end of the day, the people who are going to drive the remediation, they are developers. So if you make it easy for developers to fix and remediate those risks, that's going to be the single most impactful thing in, uh, in mitigation, right? So, so that's why developer experience is important. Developer first AppSec is actually really, really important. If you care about remediation, if you care about only flagging issues and stopping at that point, then you don't have to really worry about DevEx.

Chris Romeo: 14:46

mean, you don't really have to worry about having a good program either though, right? Like, at that point. I'll take it a step further. I've reached the point, Harshil, where I can just say pretty much anything that comes to the top of my mind. So, but yeah, I mean, that's, that's the case. Like, those are the security programs that are going to be compliance focused, checklist based, and They aren't going to move the needle from improving application security, which is really what we should be trying to do.

Harshil Parikh: 15:14

Yeah, yeah, and it's, um, it's, it's software security, application security, however you call it, right? It's the security of the application or security of the software that is being written. And who's writing those things? It's, it's the developers, right? So you're, in a way, helping the developers build secure software, build secure applications or cloud infrastructure or what have you. So if you're helping them, you should care about their experience, right? So you should care about developer experience.

Robert Hurlbut: 15:44

You've also, uh, Harshil, written about, uh, developer autonomy and security guardrails. So what is developer autonomy and what is its importance to, and in the AppSec program?

Harshil Parikh: 15:59

Right? Yeah, you know, it's um, it's a, so the trend that we've seen in several modern companies who are using more cloud native or microservices architectures or DevOps pipelines, or however you want to call it, modern way of building software, is that developers actually take ownership of more than just writing code. Right? Back in the day, 10 years ago, 15 years ago, you would have developers who would write code, ship it over to a QA team who would do all the testing, ship it over to another release management team who would eventually figure out how to do this deployment, do this release. Developers responsibility was fairly limited, but now if you think about what dev teams are doing, modern dev teams are doing, they are Not just writing code, they're also writing their own tests. They're running their own CI pipelines. They're also doing their own deployments. They also understand how it should be deployed in cloud or what have you. So they own more and more of the. The dev to ops stack, you can call it DevOps or, uh, you know, whatever you call it, but at the end of the day, developers have more and more responsibility towards things. So, um, since they have the autonomy to not just write code, but also test it, deploy it, operate it, maintain it over a period of time, security should be a core part of it. Right? So how do you make. a part of developers responsibility. That's where the developer autonomy in this comes in. So really the transformation that we saw was, you know, 10 years ago, when you had QA teams who are running tests for developers, that has changed now to developers writing their own tests and the tests get automated within the CI pipelines. So in the same way, security guardrails are sort of not just testing, but also. Um, how do you enforce those controls? Like, how do you make sure developers are making the right choices? If they are the ones who are making all those decisions, how do you make sure they're making the right decisions? Through developer autonomy, through developer, uh, you know, security guardrails. How you implement it, whether it's an IDE control or CI control or CD control, what have you. That's all. It depends on the organization, what your environment looks like. But what it actually does is security guardrails really help you, uh, help the security team say, these are the set of controls or practices that I expect my dev teams to follow. And building those guardrails just makes it easier for developers to just make the right choices from the beginning, um, so you, so they know that, okay, I'm supposed to use this approved base image for building a container. Or I'm supposed to use... These set of approved CI CD systems that security has already vetted and said, okay, these are good to go or you know You have to use these crypto frameworks when you're writing anything related to crypto. So all of those are Controls that you could build in in your CI pipeline to proactively say hey developer You have a choice to make your life will be easier if you make this choice because security has already done this work As compared to us doing an assessment six months after you release your software and then filing a bug on it. So, uh, so letting the developers make their right choice, uh, through security guardrails or through controls that get implemented, uh, in a developer's workflow. That's really what it is at the end of the day. And it's not really... There's an ideal state that a lot of companies talk about in conferences and so on and so forth. Maybe it's not applicable to every single company, right? But there is reasonable levels of controls or checks and balances that you can put in. So, for example, in my previous companies, we started rolling out, this was several years ago, when we started rolling out container security scanning, and we found that there were hundreds of thousands of Critical issues, um, yeah, and that just had to be remediate, but one approach is you could start filing tickets and you could say, hey, go fix these things, right? But that was not going to scale. So, what we did is we said, okay, let's ignore these things for now. We're going to work with the platform team and build out 6 different container images that are. That will always be kept updated. We figured out who's going to own the maintenance of those things, who's going to keep it fresh and updated. We figured out from a process perspective, every single Jenkins pipeline, we would have a check that said, are you using an approved base image or not? Right? And then we socialize it from the ground up. It took. Six months. It took two quarters for us to do that. But when the adoption went above 75%, it automatically remediated hundreds of thousands of vulnerabilities. So it's not the traditional vulnerability management. It's more about how do you build a guardrail saying when developers have to make a choice of what container to build their image based on or what image to use. They choose the right one that is published by an approved team as compared to picking a random image from the internet.

Chris Romeo: 20:42

What particular pushback did you get on that? Like what, were there, there's got to be some group of people that are going to want to fight you on this idea of... This one of the six base images don't do what I need. So any examples of that pushback and then how you dealt with that?

Harshil Parikh: 21:02

yeah, so initially we started with one base image saying this is a sent to us or, uh, uh, one of those base images and everyone has to use this. Well, the pushback was that means if I'm using, uh, a particular, uh, a Redis instance, then I have to build Redis on your image as compared to just using a Redis image, uh, directly, which adds a lot of work, right? So, so some of those were very legitimate concerns, right? Like, you know, you don't want the developers to like now do a bunch of rebuilding and installing their things on a base image. So what we actually did was we expanded that scope saying, okay, now. We will take up some of that responsibility. The security team will, along with the platform team, and said, instead of one image, we'll have six, which covers majority of those platform specific technology components. So, uh, so we found out that, okay, Redis image being one of them, so we'll just deploy, we'll have an approved image that has Redis as a part of it. An approved image that has, uh, you know, GRE as a part of it. An approved image that's just basic, bland image that you don't need other things on top of it. So we expanded the scope of what we would maintain, what we would help with, what the platform team would help with. We helped them change the process of, if you're using this, Then you have to do this. If you're using that, then you have to do that. Right. Um, so that pushback was definitely there. And even then there will be some engineering work. There was some engineering work that. The dev teams had to do, and some of them didn't have the bandwidth or capacity to actually port their existing things to this new image that they were working on. At that point, we just had to work with the leadership, the engineering leadership, with the CTO, and we said, okay, uh, next quarter. We're going to allocate half an engineer for, you know, the first two months to make sure this portability thing is done. We put that as a quarterly objective, uh, and made sure resources was allocated for that. And, uh, we were aiming for 80%, you know, 80 percent is the 80 20 rule. Uh, but 20 percent got us the maximum coverage, but then the rest of it... Uh, it was, uh, it was really, really high impact. So, so at some point you just have to give in to some of these things. Some, some of those things you have to put off into a future quarter with committed resource allocations and things like that. So you really have to work at a strategic level, um, at different layers of the, of the leadership chain and just get things prioritized.

Robert Hurlbut: 23:29

Yeah, I was wondering about that in terms of guardrails. I mean, it could be, um, technical. It could be, um, you know, like I said, built into the IDE and so forth. So different ways. And so that's some good examples of, of guardrails. Um, what about, uh, scaling an AppSec program? What are some of the challenges, uh, that you face in scaling a program to keep up with modern development?

Harshil Parikh: 23:54

Yeah, yeah, you know, one of the big challenges that I've, uh, I've observed over the past several years is, um, is because of developer autonomy, because developers get to pick whatever stack that they want to build their code on. In any decent sized organizations, sometimes developers don't. Security teams then have to deal with, you know, all kinds of hybrid technical environments. So so you would have Java, Go, Python, Ruby, React, all kinds of things across AWS, GCP, on prem, containers, lambda functions, all kinds of different things, right? So then as a security team, You have to know a lot of different things. You have to be good at security of a lot of different things instead of a limited tech stack. Um, so scaling that function, like how do you hire for so many people who are good at so many things? Or do you hire many people who are good at few things? Um, so that becomes a challenge just from security team staffing and scaling perspective. Um, and then as, as the organization grows, as teams keep moving here and there, you know, the. The leadership changes, uh, applications keep changing. How do you even define what an application is when people keep moving? The microservices architecture is very fluid. Um, so just keeping track of what is actually important to the business and what is not, that becomes a major headache, right? So you got to know a variety of different technical architectures, tech stacks. You have to keep up with. Hundreds of different engineers doing different things all the time. So just security team understanding what's actually high risk, what are critical areas of the business, it becomes impossible for them to keep a track of it. A very realistic example is, you know, typically an AppSec or a product security person usually is, you know, one security engineer to about 200 developers, right? That's an average number. So when dev teams go and create new code repos, new pipelines and deploy new services, it Typically, they don't go to the security team and say, Hey, I just built a new service. Do I need to do anything about security? That almost never happens. So how does the security team even know that a new service was created and deployed in production? And is it even relevant from a risk perspective? What is risk? Did we even test it? So just keeping up with all of these changes becomes really, really difficult. And that's one of the reasons, you know, I started Tromzo because I felt That pain point myself where things were deployed into production and we didn't know and the customer eventually found out and that, that was like a big giant egg on our face because we spent so much time building this amazing security program, but we had no idea these things were existing in production. So that becomes a scaling challenge. How do you keep up with all the things that are happening and even know what you have? And if you don't know what you have, you can't really protect it.

Chris Romeo: 26:40

How does governance play in to that scaling problem that you just talked about? Because you have, like you said, many different tech stacks. Developers have autonomy. They're coming in, they're building what they want. Like our guardrails Part of the governance structure that give them that kind of hold them to a particular area or like what do you do? How do you, how do you, how do people deal with this problem? Cause I've spent a lot of time in startups in the last decade, but before that I was at Cisco where we had hundreds, if not thousands of products across 25,000 engineers and 50,000 people. And so we had, we had a scale problem, but it was, it was a scenario where people just kind of built on the tech stack they needed to build the product that they. And we just dealt with it as an internal security team. But like anything in your experience, Harshil, that speaks to governance approaches that we can take to, to try to smooth out this scaling problem.

Harshil Parikh: 27:50

Yeah, you know, this is, this is one of those areas where, um, uh, my opinion might be a little bit controversial here because I don't think security teams can enforce a governance process when there is no existing governance process within the engineering organization itself. So, for example, if startups, is that there is no generally adopted process or governance mechanism. Within the development itself, um, I'm not even talking about security, right? So if you don't have a consistent process that you're following, if you don't have any checks and balances from a deployment and development and deployment perspective, there's nothing for security to latch onto. But when companies grow to a certain size, they inherently have to build some of these systems. Just for, uh, performance, availability, quality, uh, related things, right? So, once those start, uh, getting established, security just has to be a core part of those existing processes, rather than building a separate governance process for, uh, you know, ensuring security of what is being built and deployed. In my experience, the best approach has been to latch on to an existing governance process and just make security a core part of everything else. So, for example, in one of our previous companies, when we tried to drive down risk from vulnerabilities, compliance controls, configuration issues, what have you, we tried to set up our own system where we would, you know, invite certain people and talk about the top key risks and what have you. That didn't really work really well. But when we had a new CTO who came in and said, okay, we're going to set up an engineering leadership meeting every week where every single director and VP from engineering will come in, they'll talk about the operational health of their service of their system. And they were talking about quality issues, bugs, customer issues, what have you. We made security just a part of it. And as soon as that happened, security started being treated as just any other important aspect, um, that's related to the health and quality of a service. So we started talking about Security issues or security vulnerabilities and risks at the same level as a customer facing issue as a, uh, as a quality issue. And it got, it started getting treatment just like any other, um, normal issue. So, so we had to fight less, significantly less and, uh, the whole system of as an organization, how do we deal, how do we deal with defects? Security became a part of that same process.

Chris Romeo: 30:29

So I know one of the areas that you're pretty passionate about these days is this idea of deep environmental and organizational context in AppSec. Introduce to us what you mean by that concept. And then, if possible, try to wrap it together into this idea of developer first, autonomy, guardrails, all these other things that we discussed.

Harshil Parikh: 30:53

Yeah, that's a, that's a great question. So, the, the reality today is dev teams, developer teams have so many things to deal with, right? I mean, we talked about this earlier. They have to. Not just write their code, they also have to test it, they have to deploy it, they have to operationally maintain it across many different tech stacks, many different environments. They're doing a lot of different things. So, um, in, in the context of security, we will always be finding way too many problems for developers and cloud teams to actually fix. So we have to convince them which ones are the top risk and why should they fix those things first. So, answering that question of why this security issue matters, why adopting a particular security control as a guardrail matters, or why remediating this particular security vulnerability really matters. That is really important for developers to, or even, uh, product management to prioritize security issues, right? So, for us to be effective security professionals, we have to be explain why certain things matters. And why is effectively the context, right? So the more context we give to the security or the dev teams, the easier justification they would have. So, for example, you could run SCA scans across your entire code repo and have hundreds of thousands of issues. But is everything worth even fixing? Probably not, right? So why not just look at, you know, issues in only the code repos that are actually deployed to production, as maybe internet facing services or in scope for compliance, and only the issues that have a fix available, or issues that have CVEs that have an active exploit. So, if you give all of those contacts saying, Hey, you have to update this dependency, Because there's a very well known exploit on the CVE and you're using this exploit, this dependency in an internet facing service that's processing customer data. It's very obvious for the developers like this is the highest priority issue to be fixed as compared to this other, you know, CVSS score 9. 8 rating issue. But it's an internal lunch menu app that, you know, it's probably not the same risk level. So how do you give that context at scale and make the developer's life easy so they can make those decisions? Without really having to talk to security people, without having to, you know, look at tickets and get into meetings and, uh, you know, get into Slack threads and discussions about why they should do something like it. I think that is, is really what will, um, improve the developer experience from a security perspective and also help us be more effective into mitigating the risks that really matter.

Chris Romeo: 33:35

All right, well, that was a good answer, and it's time for the lightning round. And I feel like I need some intro music for Roberts. It's, it's Roberts lightning round corner. That's what I'm calling it now. It's lightning round corner now for you.

Robert Hurlbut: 33:48

There we go. All right, Harjul. Uh, so, first question is, uh, what's your most controversial opinion on application security, and why do you hold that view? Okay,

Harshil Parikh: 33:59

Yeah, so one of the controversial things that I say that people don't like generally is that you don't always have to convince developers and plead them and, you know, always have to tell them. You can hold an opinionated approach and say, Hey, Here's how to do it in the interest of organizational risk, managing at risk. You, you can't take that stance every single time, but in the, in the context of, you know, building those, enforcing controls, building guardrails, you can enforce reasonable things. A lot, I see a lot of security people being scared of, you know, telling developers what to do or touching that CI pipeline or doing anything in it. You don't have to be so scared, you know, you have to be competent, right? Uh, and then you can enforce certain things to manage the organizational risk. That becomes controversial in some cases when people say, Oh no, you can't piss off developers, you know, you can't do this, you can't do that. Well, in some cases you just have to because at the end of the day, you own responsibility of managing the risk.

Robert Hurlbut: 35:00

yeah, makes sense.

Harshil Parikh: 35:02

Kind of contrary to your developer experience, right? In a way.

Robert Hurlbut: 35:06

Yeah. So, um, the next one we have is, uh, what would it say if you could display a single message on a billboard at the RSA or Black Hat conference?

Harshil Parikh: 35:18

Context is king.

Robert Hurlbut: 35:19

Context is king. Like that. That's great. And then, uh, finally, the last question is, uh, what's your top book recommendation for those who are interested in security, and why do you find it valuable?

Harshil Parikh: 35:33

Oh wow, I recently read, well recently meaning a few months ago, I read Richard Sarsen's book about security metrics. I think that's a phenomenal read. It goes into the depths of explaining what are the all kinds of different metrics and different KPIs that you can use. I think application security in general has not been run generally as a data driven function. Now, as a founder, you know, looking at sales and marketing and finance, every single function runs on data. And if I look back at application security, we don't do enough data driven decision making. So, which is why I find it very, very powerful to read that book by Richard Sarsen. It's an amazing book. I don't know exactly what the title is, but if you look up Richard Sarsen, he's written some amazing things on security metrics.

Chris Romeo: 36:20

Yeah, we'll, we'll find it. We'll put it in the show notes for our audience to, uh, to be able to access. So, Harshil, what's, uh, a key takeaway? They're a call to action for the audience here. Is there some homework you want to send them away with? Uh, do you want to give them just one last message? The floor is yours.

Harshil Parikh: 36:39

The, the, the one key takeaway that I would say is, um, the, the job of our, our security professionals, us being in an industry is obviously to help the organization manage the risk, but we're really helping the dev teams and the cloud teams make the right decisions. So how do you help them make the right decisions? And, you know, this goes back to making it easy for developers. By improving the developer experience, giving them context about why they should pay attention to certain things and being cognizant of the organizational decision making, right? So it's not just the developer who makes all the decisions. It's, it's product management, their management, their leadership at different levels of the hierarchy. So, uh, so holistically speaking, our job is to manage the risk, not just find problems and report, but how do you manage that risk is by improving developers experience, giving them context of why that matters and really navigating that organizational hierarchy.

Chris Romeo: 37:33

Harshil, thanks for being with us today, for sharing your insights, taking us through this, this journey through you know, developer autonomy, developer first security. Guardrails, and then leading us into this concept of context and how that fits together all there. So this has been very helpful to learn from your experiences. We thank you for sharing those with us, and we look forward to a future episode where we can continue the conversation.

Harshil Parikh: 38:03

Thanks for having me here. It's been, uh, it's been a pleasure.