How do you make security a first-class citizen of the software development process? According to an industry report, “many information security engineers don’t understand software development—and most software developers don’t understand security. Developers and their managers are focused on delivering features and meeting time-to-market expectations, rather than on making sure that software is secure.” Harshil Parikh, CEO and Co-Founder Tromzo, shares best practices for reducing the disconnect between software development and information security engineers. One such practice is the establishing and automation of security guardrails for application development.

To access and download the entire podcast summary with discussion highlights --

https://www.dchatte.com/episode-26-reducing-the-disconnect-between-security-and-development-teams/

Connect with Host Dr. Dave Chatterjee and Subscribe to the Podcast

Please subscribe to the podcast so you don't miss any new episodes! And please leave the show a rating if you like what you hear. New episodes release every two weeks.

Connect with Dr. Chatterjee on these platforms:

LinkedIn: https://www.linkedin.com/in/dchatte/

Website: https://dchatte.com/

Cybersecurity Readiness Book: https://www.amazon.com/Cybersecurity-Readiness-Holistic-High-Performance-Approach/dp/1071837338

Welcome to the Cybersecurity Readiness Podcast

Series with Dr. Dave Chatterjee. Dr. Chatterjee is the author of

Cybersecurity Readiness, A Holistic and High-Performance

Approach. He has been studying cybersecurity for over a decade,

authored and edited scholarly papers, delivered talks,

conducted webinars, consulted with companies, and served on a

cybersecurity SWAT team with Chief Information Security

officers. Dr. Chatterjee is an Associate Professor of

Management Information Systems at the Terry College of

Business, the University of Georgia and Visiting Professor

at Duke University's Pratt School of Engineering.

Hello, everyone. I'm delighted to

welcome you to this episode of the Cybersecurity Readiness

Podcast Series. Today, I have the pleasure of talking with

Harshil Parikh, CEO and Co-Founder of Tromzo. Tromzo

empowers developers and security teams to collaboratively and

effortlessly build secure software. Harshil welcome. As we

discussed during our planning meeting, our theme for our

discussion today will revolve around reducing the disconnect

between security and development teams, obviously, you're an

expert in the area. And I'll let you introduce yourself. Talk a

little bit about your background, and then we can

proceed with the discussion.

Fantastic. Thank you, Dave, it is my absolute

pleasure to be a guest on this podcast. Just to give a little

bit of background to the audience especially, I've spent

quite a bit of time in the space of cybersecurity, done a lot of

things, started my career as a network security engineer back

in the day when firewalls were a big thing. And then eventually,

most recently, I was the head of security of a company, B2B tech

company. So, as a part of some of the previous roles I've built

and scaled security operations programs, software security

programs, compliance functions, things like that. So, gotten my

hands dirty in quite a few things. And as a part of that

journey, we've seen a lot of common themes and issues come up

again and again. So got tired of a few of them and decided to

solve them by starting a company. And here we are.

Fantastic. Fantastic. In fact, if you allow

me, I'd like to share with listeners an excerpt from an

industry report. And I think that sets the context for our

discussion quite well. The report says "many information

security engineers don't understand software development,

and most software developers don't understand security.

Developers and their managers are focused on delivering

features, and meeting time-to-market expectations,

rather than on making sure that the software is secure. So your

thoughts, your reactions,

I would empathic emphatically agree with that. At

the end of the day, we all are hired to do our specific roles.

And this is the world of specialization, right? Like, if

you hire a security engineer, you hire that person to be a

really, really good security engineer. Absolutely. In the

challenge with the current world of software development or

software security or you know, security operations, incident

response, what have you is that it's a very complex field. To be

a good software developer, you need to be good at a lot of

different things. Security is one of them. To be a good

security engineer, you have to be good at a lot of different

things, be very updated, be very fresh, technically keep up with

a very, very dynamic world, there is not enough time to be

the best security engineer and the best software developer as

well at the same time. It's not possible, which is obvious,

right? Now, what we see in the world is software developers are

very busy. They deal with very complex technical architectures.

And they know a little bit about security, maybe, but they're not

the best at it. Right? And same thing, so yeah, I mean, I 100%

agree, software developers should be and rightly so,

they're good at software development, not everything

else. And the same holds for security.

Absolutely. So given your experience in the

field, we have already mentioned why there is a disconnect in the

sense that if I am a specialist in security, and you're a

specialist in software development, I understand my

work very well, you understand yours. And, I'm incentivized by

ensuring the product is highly secure. You are incentivized by

making sure the product has all the functionalities, and it gets

to market on time. So our incentive systems are often not

aligned. That's one of the things that I think is a

challenge or it causes the disconnect. What do you feel?

Yeah,

I mean, that's, that's a good insight, right? I

mean, they at the end of the day, we are all humans and as

humans, we would focus on getting our things done quickly,

efficiently with a higher quality, like if you're proud of

your work. So if as a developer, you are focused and incentivized

by your leadership on just churning out features as fast as

you can. So that's what the developer would do. If you're

incentivizing the developers on building fast feature features

fast, but at a high quality, and you're measuring them on that.

And that's what they would do, which is push code rapidly, but

also potentially build at a higher quality because they know

they're being measured against that. The unfortunate reality of

our current world is, most engineering leadership does not

measure developers or does not incentivize developers on

building high quality code that is also secure, to a reasonable

extent, right? I doubt if most companies are in the business of

building the most secure software ever. That's just not

the reality of the world. So the idea is, how do you find that

balance of being agile, being fast, but also being able to

incorporate security to a reasonable extent that works for

the business? So I think you're right, that incentivization

structure doesn't exist today. In cases where it does exist,

for example, whether they are required by regulation or

required by law, you do end up seeing that outcome, which is

developers do follow certain security practices, because they

are forced to do so. So it all goes back to what are the top

level objectives? What are the incentives towards geared

towards? And that's the outcome that we would see.

True, very true. Now, what are you seeing

out there in companies? You mentioned about finding the

right balance. Yeah. How are companies, I'm just curious to

know how companies are finding the right balance, what

practices what structures are in place to achieve the dual goal

of quality software that is also very secure? Yeah,

I think the one theme that we've seen more

frequently occurring nowadays. over the past few years is, is

that there's a little bit more buy-in from the development

leadership or the engineering leadership to actually give

security it's due course, right? So earlier, are in a lot of

cases, even today, security was being positioned as the

responsibility of this one team that sits in the corner of the

building, and they do everything security, and everybody else

does their own things. Now the change that we've been seeing,

and this is partially also because security has become a

Board level topic has become an Executive discussion topic, so

companies are being held accountable for breaches there,

there is much more attention towards it. So the leadership of

the company, the executive leadership of the company, they

start focusing on cybersecurity practices, readiness, risk,

posture, and things like that. So there is a little bit more

acceptance in the engineering world where the CTO, VP, Engg,

Director of Engineering, what have you, those technical

leadership people, they have started to, to ask about it I

guess, it's not very, very common just yet, we still see a

lot of friction. But there has been some adoption that, hey,

security is everyone's responsibility. Let's work on it

jointly together. We've seen that come up more frequently

than before.

Okay, that's very encouraging to hear.

In fact, when I was authoring my book, Cybersecurity Readiness: A

Holistic and High-Performance Approach, my research led to the

identification of 17 success factors, a couple of them

centered around creating a We-Are-In-It-Together culture

centered around cross functional participation. Essentially, the

key messages were that we have to get everyone involved towards

creating a high performance information security culture.

From the standpoint of the developers and the security

folks what that meant, are they also aligned? Are they together?

What is an organization doing structurally, so they are not in

a collision path, but they are working cohesively as one

integrated team, working towards a common goal. What that prompts

me to think is to achieve that organizations will have to make

suitable adjustments to their structure, how they build

software, and I believe that's been addressed in the

methodologies that are being pushed forward these days. And

of course, that has to be coupled, supported by good

incentive systems. Right. And once again, you are the expert

in this area. So I look forward to your insights as to what

exactly is going on? Why is it that these teams have to be

separate? Why can't they be fused and work as one team

towards the delivery of a particular product? Just curious

to know

Yeah, that has been a question for so long

within this space, right? Like everyone within the the software

security space, we all expect that why can't just developers

know how to write secure code, right? Like, why do we have to

do anything? We can focus on more complex, sophisticated

problems and developers take care of the basic hygiene stuff

that they just should. But I mean, unfortunately, that's just

not the reality. Right? I mean, I think even basic security

practices, which seem basic to security people, sometimes are

not followed by the developers, a lot of times it is about

education and awareness. It's not, it's not always that the

developers who want to take the wrong decision or don't want to

address security issues. Most of the times, they actually do want

to, but they just don't know how to or even if they want to, and

they know how to, building secure software is sometimes

much more difficult several times more difficult as compared

to just getting it done without securities. And now, you have

given the decision making authority of whether to spend

more time and energy building something in a secure way, or

just get done with with the feature that they need to build,

right. So if if I was a developer, a junior developer,

for example, yeah, we probably would be obvious to me like, I

would just get done with my things, if security was so much

more difficult. So I think it goes back to is security easy

enough. And obviously, this is a very broad statement with

security being easy as is a very nebulous statement too. But at

the end of the day, what we are seeing now in a lot of the

modern security teams as they make secure path, the easier

path, right? So from a developer's perspective,

building something with security or without security is almost

the same. To give you an example, if I'm writing a new

application, I need to store secrets. If I store my secret in

code, obviously, it's bad, I shouldn't do it. But if I had no

other resource available, it would be incredibly hard for me

as a developer to go figure out a secrets management system and

then set it up and start using it before I could do that simple

job of getting my service deployed. But if secrets

management system was already made available by the security

team, so now for me, as a developer, whether I store

secret in code is the same level of difficulty, or easiness, as

compared to using a secret management system that's already

available, obviously, I would choose in a lot of cases, I

would choose the more secure choice. So I think it's a

combination of several things, which is developers are not

really aware of the decisions they should be making security

is not always easy for them. They're not incentivized to take

the right decision. They're not incentivized to make the secure

decision. So this is what makes it really complex. Right? Our

world is nowhere close to being automated by bots, because it is

Yeah, absolutely. And, you know, as

complex.

you're talking, I'm thinking about the number of patch

releases, and, you know, patch management being such a

challenge for organizations. And I wish we were in a world where

the software development was more secure, or was more robust.

So you don't have to have that many patch releases. I don't

know how you would react to that. But that's kind of my

thinking of this issue at a high level. Moving along, share with

the listeners some best practices for reducing the

disconnect, what would be certain things that folks could

do in their organization within their sphere and scope of

influence?

That's a good question. One of the things that

I've seen work really well, in a lot of cases is very make as

security professionals when we make security, very crystal

clear, and very binary. So if, for example, on one extreme, if

we go to a Dev team and hand them a PDF report, or a

spreadsheet with 1000s, and 1000s of vulnerabilities and

say, Hey, developer, go do something about this, right?

That is not a good productive conversation, because they have

no idea which ones is important, obviously, they don't have the

resources to fix all of them. So on the other hand, if you go to

the development team and say, hey, look, these are the, you

know, 12,356 issues that we found. But I know most of these

are not really relevant. How about if we fix 100 of them in

the first 30 days? And then we addressed the next batch of 200,

in the next quarter, and then so on and so forth. Let's manage

our risk collaboratively, I'll help you figure out which ones

are the most important bugs, what is the high priority for

you? And you tell me whether is this even possible or not

possible? Right. So I think one angle to this is we should do

our due diligence on the data and we should help make their

jobs a little bit easier by providing them ways on how they

can actually achieve something. But on the other hand, what we

also see a lot of times is even if you go take that, you know,

take that list of 12,600 issues down to 100 issues they still

will say no thank you Right, this could happen. Now in that

case, a lot of times what happens is then the security

teams get left with the accountability of it. Because if

something goes bad, then all fingers go point to the security

team saying you guys didn't do anything or you, you gals didn't

do anything. But in that to address that, then we have to,

we have to fix the accountability of things. Right?

So it is not the responsibility of the security team to

remediate risks, because in most cases, they cannot, right. It's

the engineering team or the developers who need to remediate

the risk. So if developers or Dev teams are saying, no, they

cannot, then we basically assign the risk to them. Right. So now

it's their decision. So what that calls for is a more data

driven structure of how you manage security, more

accountability, and there has to be a top down buy-in, of who's

responsible for what, the security team is responsible for

understanding the risk, identifying the risk, and

highlighting it to the right people. But if the people who

own the underlying risk, which is the folks that are managing

and building that infrastructure, or software or

the systems, if they don't want to fix it, then it's really, we

have to just hold them accountable for it. It's not

like we can go and patch the things that they own and manage,

that's just not going to happen. So making security easy for

them, making it easy for the Dev teams to actually go and

remediate things that are really important and matter to them,

but at the same time holding them accountable for their own

decisions. I think it's it's a two-way things that really help

us get out of this ditch. And the other day, we were talking

about this example, like look, we all know that we should all

brush our teeth a couple of times a day, floss our teeth and

maintain general dental hygiene. And the dentists are there to

give us guidance on how to do it easily. And when something goes

bad, they'll come in and fix it. But if I don't brush my teeth

every day, or floss my teeth every day, it's not the dentist

responsibility, right? It's it should be my responsibility. So

that's how I view the role of, you know, security, where

security teams are sort of those experts where they can tell

people like Hey, guys, look, this is important, we need to

fix this. But at the end of the day, it's your call, and we'll

we should hold you accountable for it.

You know, I couldn't agree with you more.

You're essentially speaking my language in many ways, because

I've been harping about the top management setting the tone, the

top management, recognizing what's the right approach to

institutionalizing security in the organization. So therefore,

it goes without saying, to me, it's a no brainer that unless

there is shared accountability, shared responsibility, top down

support, unless the performance evaluation system is suitably

modified, unless work structures are suitably redefined. So the

security team and the development team don't work

separately or don't work in isolation that they work as one

cohesive team, unless these measures are taken in a

deliberate manner. And you mentioned about metrics, it's

very important to at least keep track of a couple of metrics

that taps not only into the quality of the product, but also

it's like a stage by stage tracking of how well is security

being infused into the product at the appropriate stages in the

solutions development lifecycle. We're all familiar with the

Agile development methodology. I think that's the right way to do

it. Like you go back and forth. You constantly get feedback. And

the way I see it is this is a great opportunity where the

security team, the software team are working together in an agile

approach where they're constantly reviewing each

other's work, and trying to make the corrections before it

becomes a major problem. Like you talked about receiving a PDF

with thousand some issues, and I'm looking at it and saying, so

from where do I start? So a lot of things needs to be done

differently. But there's a huge need for it. And this brings

back memories of the disconnect between the technology people

and the business people, which was the focus of discussions for

a long time since the late 90s. That how do you reduce the

disconnect between business and IT? I find the same problem

reemerging in the form of the security people and the

development people. So it's the same problem, just a different

context. The challenges are very similar, but it's always good to

get thoughts and insights and feedback from subject matter

experts such as yourself. Once again, going back to our

discussion. when we were thinking about what all we

should be addressing something that came up were the best

practices for building and scale a modern application security

program. So, what are those best practices? And what do you mean

by a modern application security program?

Yeah. So I think, for far too long, we've

operated application security as software security in general as

a fundamentally different phase from development, right. So

developers would do their job. And then software security or

AppSec people would come in, perform these tests and

assessments and file a bunch of tickets, and then assign it to

developers and get done with it right and hoping that they would

go and fix it. I hope there's they're still filing tickets as

compared to giving them a PDF report with 1000 nations, right.

So that is a very step by step approach, which is probably good

fit for a waterfall model of development. However, the world

has moved on since or at least it's in the process of moving

on. Now. If you have a discrete step off, like, hey, developers,

once you're done coding, then we'll do all the assessment,

that step usually doesn't come because development nowadays,

it's more of an iterative process, right? There's very

rapid releases, rapid development, rapid deployments.

And it's micro feature by feature there is microservices

architectures. There's no more monolithic applications, and the

rapid delivery of software makes it imperative that security get

involved in it in a continuous manner. Because if development

is continuous, deployment is continuous, then security should

also be continuous. But it's unfortunately not today. So how

do you how do you make security continuous? How do you make

security a first class citizen of software development process?

I think that's what I really mean by modern application

security program where application security is much

more native to software development in general. And, you

know, we've talked about the security in SDLC, we've got

maturity models, like BSIMM and OpenSAMM. And we've talked about

shift left for a very, very, very long time. Unfortunately, a

lot of the shift left conversation has constrained

itself to running scans and scanning and running a bunch of

tools and performing assessments. Obviously, it's

much more than that, right? I mean, software security is a lot

of things, vulnerability scanning, being one of them. So

building a security program that is agile, that is fast, that

works at the same speed as the DevOps teams or development

teams that are using DevOps processes. I think that's what I

mean by modern application security program. And the

fundamental shift in this is, as AppSec people, we have to

understand how DevOps actually works. What is source control

system? What is a CI CD system? How do they both connect, how

does deployment happen? All of those things need to be

understood really, really well. And then we can build certain

practices into the SDLC. The one big change is what I mentioned

earlier, which is now there is no more a single discrete step,

where developers would stop and say, Hey, security come in and

do the assessment. Like that doesn't happen. You can do an

assessment, but that doesn't mean that developers will stop

building code. So what that means is, before you're even

able to finish an assessment and give a report back to

developers, they have already moved on to other things, and

they're likely not going to come back and address the debt that

you just found out. So one of the key decision, or the key

shift in how you build apps like that works really well is is

what we call a security guardrails right? So it's

security guardrails, or some people call it paved roads or

whatever that is, but what it actually means is a set of

controls, a set of secure defaults that developers should

follow, right? So now the assumption here is if developers

are free to build and deploy services and write code the way

they want, security teams don't have the time to stop them and

do an assessment and go and ask them to go back and fix it. So

security takes a proactive approach and says, you can do

whatever you want, as long as you are working within this

boundary. You can define those parameters and then say, hey,

you can only use container images or host images from this

internal registry like this is the approved blessed image, only

use that. You can only use secrets if you're using a

secrets management system. Or you can only use these

cryptographic standards, or you can only use these cipher

strengths, right. So security teams define those security

primitives, which then get applied at developers lifecycle.

So when developers are writing code, those checks and balances,

they just happen by itself by automatically. So that's what I

mean by security guardrails. And that's the type of thing which

is automating security controls and expectations into the

developers workflow. That's what helps people scale AppSec really

quickly and prevent a lot of the vulnerabilities from coming in

or prevent risk from manifesting itself in production.

I think that's a great approach because

the extent to which you can leverage the power of automation

to allow development to progress at its normal pace, and yet

achieve the goals of security, so you are achieving both the

goals of security and a timely delivery of software. To achieve

those dual goals, you need the power of automation. And that's

good to hear that there are automation platforms that are

being developed and touted that organizations can avail of to

make life a little easier. Right? I'd like to touch upon

another thing that we talked about the other day. And that's

about empowering the AppSec teams so they can focus their

time on more high-level strategic work. I found this

very interesting. Yeah, what exactly what were you alluding

to here?

Yeah. So I'll give you an example. So I talked

to a lot of AppSec engineers almost every week. And my

intention behind those conversations is just to learn

how do they do their job, right. And the idea is for me to

understand that deeply so I can make their life easier. What we

discovered is a lot of these AppSec teams, their primary job

is to run assessments, run scanning tools, and let's just

face it, you know, scanning systems exist in every single

AppSec team, they produce a lot of findings, but not all of it

is useful. So a lot of the AppSec engineers, there's just

doing busy work, taking findings from different scanning systems,

understanding what it actually means, triaging it, prioritizing

it, filing JIRA tickets, tracking it bringing people on

emails, or slack or Microsoft Teams, or what have you,

following up on it, all of it is ditch digging work, right? It's

very manual work, it's, it's the work that is actually not

security work, right as filing tickets and following up with

people, a lot of security engineers actually ended up

doing that, because they are focusing on you know,

vulnerability management or using the scanners to do

something. Those are the things that should be and can be

automated, and at Tromzo we've spent a lot of time automating

those manual processes. So then the security engineers can

actually focus on doing some security engineering work, which

is focused on more higher order strategic problems. So let's,

let's figure out the complex security holes that might exist

or the complex bugs that you just have seen being discussed.

And is your organization affected by that. So spending

more time in real security work as compared to filing tickets

and following up with people and sending emails and sending

reports and stuff like that, like that should be automated.

So that's what I really meant. And there are systems and tools

available to automate that manual work. It's just hasn't

taken a wide adoption within the industry. Just

Fantastic! Harshil, it's been such a

pleasure talking with you. I think you shared some very

interesting insights for our listeners. But I'd like to give

you the opportunity to put it all together and wrap it up for

us. So what are your final thoughts?

Yeah, so it's always difficult to wrap

interesting conversation into a final sentence. But look, the

reality is, we are all as software security people, as

security people, we are faced with this major transformation

that is happening within the technology space in our

companies, with more adoption of cloud, with faster development

cycles and releases, there is no choice for security other than

automation, like we just have to automate things. Otherwise, we

will not be able to keep up we are already not able to keep up

with it. And automation has to be smart automation. And every

single AppSec team or every single security team is

struggling with almost the same types of problems, not 100%

same, but it's very similar. So we don't have to reinvent the

wheel. So we have to think about these problems in terms of how

do we scale our security organization. It's not like we

are going to magically create hundreds of 1000s of security

professionals all of a sudden, so we are already facing a

talent shortage. How do we solve that talent shortage problem?

How do we scale ourselves? And the answer is automation.

I love it. So let me add my two cents to

that. So essentially, if I could summarize what we talked about,

at a high level, I'd approach it using the lens of people,

process, and technology. You already touched upon how

technology can be leveraged to automate certain tasks that

don't deserve too much human time. So humans can focus on

something more valuable, more strategic. But we also talked

about from a process standpoint, how important it is to ensure

that the security teams, the app development teams, are working

in alignment, are working cohesively, are working together

hand in hand, whereby they are not in conflict, and that

process has to be supported by an appropriate incentive system

in place. So the performance evaluation system must be

suitably modified with the blessings of top management, and

finally, people, people still are the most important part of

the equation. I couldn't agree with you more that we absolutely

need technology to help us with security. But still, there's the

people who still make everything run, they are the ones who are

building the technology who are using it. So to enhance their

level of awareness, to provide them the right training, to make

sure they are at the leading edge of things, that's a

constant pursuit of any forward thinking organization. So I hope

discussions such as this inform, influence, inspire management to

take the necessary steps or they might find validation in what

they're already doing. And so I'd like to thank you and your

peers for all the great work that you do in the software

development and security community to keep us as safe as

possible. It's been a real pleasure, Harshil. Thanks again

for joining me for a chat.

The pleasure is all mine Dr. Dave Chatterjee,

thank you so much for having me here.

A special thanks to Harshil Parikh for his

time and insights. If you like what you heard, please leave the

podcast a rating and share it with your network. Also,

subscribe to the show, so you don't miss any new episodes.

Thank you for listening, and I'll see you in the next

episode.

The information contained in this podcast is for

general guidance only. The discussants assume no

responsibility or liability for any errors or omissions in the

content of this podcast. The information contained in this

podcast is provided on an as-is basis with no guarantee of

completeness, accuracy, usefulness, or timeliness. The

opinions and recommendations expressed in this podcast are

those of the discussants and not of any organization.