May 12, 2021

Software Security Gurus Episode #15: Astha Singhal

Welcome to episode 15 of the Software Security Gurus webcast.

In this episode, Matias chats to Astha Singhal, Director of AppSec at Netflix. They discuss Netflix's enviable culture of freedom and responsibility, and what this means for application security in her team. They also dive into the world of self-service, and the impact this can have on reducing cyber risk. Finally, Astha talks about her unique experience as the leader of Salesforce's AppSec security program.


A culture of freedom and responsibility: 01:13

Self-service and the "paved path": 03:54

A unique AppSec experience at Salesforce: 08:39


Listen to the podcast version:

Read the transcription:

Matias Madou:
Welcome to today's Software Security Gurus Webcast. With me today, Astha Singhal. Welcome Astha.

Astha Singhal:
Thank you Matias.

Matias Madou:
Of course. Astha, do you mind sharing a few words about yourself?

Astha Singhal:
Yeah, definitely. My name is Astha and I lead the Application Security Organization over at Netflix. I've been there about three years. And before that I used to run a part of Product Security at Salesforce, including their App Store security. And before that some consulting insecurity and yeah.

Matias Madou:
And heavily involved in the security community in general, where you are.

Astha Singhal:
Yeah, that's true. Definitely involved in the barrier security community as a part of DevSecOps and helping out with some OWASP stuff in the past and other local conferences and things like that.

Matias Madou:
Great. Great to give back. For today's webcast... I'll start if you don't mind, I have three topics in mind and hopefully they are near and dear to your heart. The first one is around Netflix and a lot of people try to develop code just like if they are at Netflix, because it's a well-known way of developing code. It's a very interesting way, but it all starts with the culture of Netflix. And actually I had a look at jobs.netflix.com/culture, and I found it very interesting. And one that really popped up was like the freedom to do stuff, but also the responsibility. With that culture and no control, how does that impact the security program that you're working on?

Astha Singhal:
Yeah, I would say that usually the two cultural values that impact our security program the most is freedom and responsibility and this culture of context, not control, right? For folks that are not aware freedom and responsibility really encourages this idea, that individual folks should have the freedom to do local decision-making, as it makes sense, as long as they're taking the responsibility for doing the right thing for Netflix. And actually it encourages a lot of ownership and accountability in how folks think about the work that they're doing. From a security standpoint, it actually does end up being really helpful because application developers are responsible for the security of the applications they're building and they think of it the same as availability as performance as functionality, right? It becomes like a part of their responsibility as application developers.

Astha Singhal:
The other pillar is context, not control, right? Even as managers, my job is not to tell my team what to do, or what to work on or how to work on it. My job is to really set strategy and help the team orient in uniform direction and folks to individually figure out, how do we achieve those goals and how do we get there? And this enables folks to be able to make the right decisions based on the context that they have. And when it comes to security, the way this works is we as the security team are responsible to share the context of the risk impact with application owners, with the engineers at the company. And really at the end of the day, everybody is driven by the same goal of what's the right thing for Netflix, right? So I'm not telling them what to do as the security team, I'm providing them the risk context and they will make the right decision based on the risk impact and based on everything else that they know about the business objectives that they're trying to achieve that I don't.

Matias Madou:
Okay. I think that that leads straight into actually my second topic, which is you're a big advocate for self-service and your ID, if I'm not mistaken, is to reduce the risk by following the paved path. I saw a couple of presentations where you talked about, "Hey, within Netflix you have to follow the paved path and then everything will be all right." On the one hand, there's not enough AppSec people and there's a lot of developers, so we have to do something to help the developers. What is for you self-service and what does it mean to follow a paved path?

Astha Singhal:
Yeah. When I think about our overall application security strategy, right? There is two pillars that really jump out as ways in which we scale our program. One is secure by default and the other security self-service, right? Secure by default, really ties to that idea of paved road. While we're saying that if that our paved road tools folks are using for build, for deploy, their runtime frameworks, that they're using the compute platform they're using. How can we make sure that most of the security things are taken care of as a part of those platforms? How do we work closely with those platform teams to make them secure by default? As an application developer, you're having to think about way less things when it comes to security. And then the other one is self-service because at the end of the day, it's unreasonable for us as security people to ask all developers to become security experts.


Astha Singhal:
Our job is to make the security context more readily available to them. In areas where secure by default is not an option or in areas where secure by default is not the right path for something, self-service comes into play to say, "Okay, as an application developer, can I see all the context on all of the things that I need to do to put my application in a secure state." Now that could be outdated dependencies, that could be security controls that are not present on an internet facing application. That could be really other things that are about, I don't know, like admin, a login for your application and how it's set up in our CICG tools. Making sure that they have all of that context in one space, and then they can consume that, take action, have the right information about the risk impact and then move on with their life to do the job that they're actually primarily here to do, which is create value for the business by writing software that they're the experts of.

Matias Madou:
I couldn't agree more. I think if you can bake in a lot of security functionality in the platform itself, that is great. Is it because of Netflix as a young company that you're able to do that, and there's not a lot of legacy code? Or what are the techniques to reach some state like that? Because a lot of people dream about what you've just mentioned, where you bake in a lot of security controls, but ultimately it all comes back to the developer and making sure that the developer can do the right thing. What is the secret ingredient over here?

Astha Singhal:
Yeah, I would say that there, it's really more about not just the fact that it's a young company, I guess that's a debatable at this point, right? I think it's more about having in the engineering organization, a culture of continuous improvement and changing things over time and making sure that we are modernizing tech stacks where it makes sense. But then also right, secure by default is not going to be the thing that solves everything for you all the time if that is say a set of applications that can't migrate to the secure by default solutions.

Astha Singhal:
That's where the self-service comes in, right? Where we can say, "Okay, you can't use the new framework that gives you these controls by default, but we see that these controls are missing. Can you do the additional work to implement that and then get your app to a secure state until you're actually going to be able to move to that to here by default platform." And this is where there is the complimenting of each other. And hopefully we'll end up in a world where more and more of the tech stack is on that modern platforms that give you those things by default. But then in the meantime, I think that is just sort of this balance between those two pillars.

Matias Madou:
Yeah. So you're saying well, if you have a dollar, you try to spend it the right way and right now it's finding the right balance. Not overspending in all of the platform, because quite often or sometimes it's a one-off where developers just need to know that one thing and it's going to be okay. And at the same time, not spending everything on just the developers and hoping that they can do everything right.

Astha Singhal:
Mm-hmm (affirmative).

Matias Madou:
Last topic in Salesforce, you mentioned Salesforce and when I went through your bio and what you've done at Salesforce, one thing caught my eye, which was, hey, you were leading at Salesforce, the app store security program, but your customer was a sales organization and not really a product in engineering organization. I think that's a very unusual experience I think, can you elaborate a little bit on your experience over there and how you handled that?

Astha Singhal:
Yeah. I think one of the things that really, it helps you do as security professionals. Outside of that one experience, my customer has always been product in engineering. I would say working for the business directly or having the business as my customer really helped solidify this idea that as security professionals, we're here to serve the business, right? And I think when you see that maybe in engineering being your customer, maybe it's at one step removed, but then having that direct relationship really reinforces that at the end of the day, or what we're trying to do is we're trying to generate revenue for the business by enabling these ice we used to be able to publish on the App Store. And then how do we make sure that our processes, our tools, our guidance, all of those things are set up in a way that we are making that possible in as seamless of a way while being responsible for customer security in the best way possible. I would say that it really roots you in the idea of, we as security are here to serve the business.

Matias Madou:
Yeah. Metrics is very important in that area where security it's quite often perceived as the blockers. And we count like, "Hey, how many vulnerabilities can we find? And how often can we stop the developers?" I would assume in Salesforce. That was very different.

Astha Singhal:
Yeah. I actually wouldn't say that that should be a goal for a security team anywhere. I actually don't think that that's the goal for the security team that I work on today, or the team I worked on before, right? The goal is really, we're here to enable engineering to put out secure software. And then how do we do it in a way that it's least disruptive? And then how do we enable the business to take appropriate risks while managing it for the company.

Matias Madou:
I couldn't agree more. Absolutely. But I would assume like 10 years ago, what I saw was AppSec teams were super thrilled that they found 10% more vulnerabilities the next month. And their end-goal was not, enable the business, help the business, but it was more like, hey, feel good for themselves. Can you share a couple of metrics that you're using today within Netflix? Where you say, "Hey, that is helping the end-goal and reaching shipping reliable coat."

Astha Singhal:
Yeah. Maybe we'll start at the vulnerabilities, right? I think the one thing that we do measure around vulnerabilities is really around things that we are finding and fixing through our dependency scanning work. Really you want to make sure, like how far down are we driving the campaigns for vulnerable dependency. That's definitely one of the things where we want to make sure that that technique is being effective for change management. When it comes to self-service really there, it's about how is the adoption of security services increasing across the ecosystem to be able to tie that back to risk reduction. When it comes to some of the partnership... Oh, sorry, go ahead.

Matias Madou:
Would you mind giving one example of self-service so to make it more tangible for the people?

Astha Singhal:
Yeah. Yeah. Yeah. For example, we have done a ton of work with our application gateway team to make that the secure authentication proxy. If apps are behind that authentication proxy, they get a ton of controls for free, right? Measuring adoption of that proxy especially for high-risk applications, right? We do some interesting work in the risk scoring space to say, "Okay. What is the type of data you're handling? Are you internet-facing or not? Are you built on a certain framework?" And all of that, using all of that. What is previous vulnerabilities against your app if you have seen? We come up with this idea for risk score. And then what we're trying to do is we're saying, "Okay, four things that are the top 10% from a risk score standpoint, how do we drive adoption and measure adoption of our authentication proxy?" Because we know that there'll be like all of these security controls that those apps will get for free once they are behind that authentication proxy.

Matias Madou:
That's good. That's very nice.

Astha Singhal:
I will say that on the partnership side, it's definitely still a bit qualitative because you can think about, I don't know, for example, the compute platform, right? For the compute platform, yes. We want to drive the strategy for how to make the compute platform more secure by default and the autos option is that, okay, as the ecosystem adopts the platform, a lot of security things go away, but I'm not quite sure what the way for us to measure that risk reduction will be. Same thing for say the data platform and saying, "Okay, this is the security and access solution that we worked on with the data platform team. Now we want anybody handling core Pi to be behind this solution."

Matias Madou:
Measuring security is super hard. Ultimately, if nothing happens, everything is fine, but if something happens... So it's super hard. But we're all trying. Maybe to finish off, I actually went through your Twitter account and it seems that you're into cooking. Well at least you seem to be into quarantine cooking. Is it still a thing quarantine cooking or was that a short-lived experiment?

Astha Singhal:
No, I actually love cooking, but then quarantine cooking was just a thing because I had a lot more time to be able to cook. That's definitely still going on. The thing that has petered off is like a lot of other people in quarantine, I got into bread making.

Matias Madou:
Oh, really?

Astha Singhal:
That was definitely short-lived because I was just like, "This is way too many carbs all the time." That has petered off fortunately, at this point.

Matias Madou:
The photos of the cookies that you shared looked fantastic. And next time in the US, I'll definitely bring you some Belgian chocolate so you can actually make cookies with the chocolate.

Astha Singhal:
I will take you up on that.

Matias Madou:
Sounds very good. Astha, I really appreciate the chat. It was a fantastic chat. Thank you to be a Software Security Guru on my webcast.

Astha Singhal:
Thank you for having me Matias. And thank you for calling me a Software Security Guru. I don't know if I agree with that, but...

Matias Madou:
You are.

Astha Singhal:
Thank you.

Matias Madou:
Now you are.

Never want to miss an episode? Get in touch and subscribe!