May 26, 2023

Comprehending Security Culture with Ariel Shin

TLDR;

Finding right balance between Production Speed and Security is all about right Prioritization. It’s a shared responsibility between Security & other teams.
Security Team is an advisor where as Product & Engineering owns the implementation. So, building relationship with other Teams is highly important.
Empathy is one of the key skills for Security Teams. It helps with showing value to stakeholders when getting budget, resources, etc.

Transcript

Host: Hi, everyone. Welcome to another episode of Scale to Zero. I'm Purusottam, co-founder and CTO of Cloudanix.

For today's episode, we are focusing on DevSecOps and culture around it. To discuss on these topics, we have Ariel Shin with us. Ariel is a product security team lead at Twilio. She's rolling out and expanding self-service threat models for the Twilio organization. She started her career as a pen tester specializing in web and mobile security before moving into the product security space. She enjoys building relationship with developers through secure code reviews, threat modeling, security training, and vulnerability management exercises.

Ariel, it's wonderful to have you in the show. For our viewers who may not know you, do you want to briefly share about your journey?

Ariel: Yeah, thank you so much for having me. I started off as a penetration tester, as you said, did a variety of different types of pen tests, ranging from web apps to network pen tests. And then I moved into the application security space, primarily because some of the work I did as a pen tester felt very repetitive, especially with the annuity work. And I wanted to actually create change that I could visibly see and build those relationships with developers. So been part of the AppSec product security space now for a few years previously at One Medical and now I'm currently at the Twilio segment.

Host: Nice. So the way we do the recording is we have two sections. The first section focuses on security questions, and the second section is mostly about rating some of the security practices that we see used by organizations. So let's start with the security questions. So the first question that I have is, traditionally the DevOps practices are sort of designed or geared towards speeding up the production process, right? Like building and deployments.

Continuous integration and continuous deployments. When we implement sort of security, when we bring in security into it, it affects the speed of the DevOps, right? How quickly your code is getting deployed or there are more processes which are brought into it. So

When it comes to DevSecOps, what can organizations do to find the right balance between speed and security?

Ariel: I think the fastest code review is no code review at all. But the fastest doesn't mean it's the best written, it has the best performance, the best security, or even the best usability. And that balance is ultimately for developers to determine and prioritize. And as security individuals, we're advisors to an extent that tell them what they should prioritize. And there are many different motivational efforts we can get for developers to prioritize security.

You could potentially do nothing and hopefully they try to reconsider security. You could use the carrot method in which you reward users for doing the right thing or use a stick and you have negative consequences for doing the wrong thing. And so I think the method that I think works best and finding that right balance between speed and security is a maturity model and that scales depending on the size of the org and the readiness to integrate security best practices.

You can't have everything right away, but you can take the steps. You can measure, have measurable goals for individuals. And you're thinking at short-term and long-term the way you think about it's like training for a marathon. If you try to run 10 miles in one day, you're going to tie yourself out and you're not going to be able to do that again.

But if you are prioritizing kind of within your day, I'm going to train on the weekends, or I'm going to train every day after work, uh, you have a lot more measurable goals and. When you're training for a marathon, it's not the only thing that's going on in your life. You usually have a career, a family life, and a social life. So you're balancing all of those things the same way that you're balancing security amongst usability, performance, and building the feature itself.

So I think start with a maturity model, see where you're currently at and what your next goal is, and then you can continue to level up as your security org scales and grows.

Host: Okay, so that makes sense. I love your analogy of a marathon, right? Running a marathon on day one and then you're exhausted and you are not able to do it on day two anymore, right? You're not able to practice. So let's say you define the process.

What are the challenges faced when you are, when an organization applies steps and cops and how can they mitigate those challenges?

Ariel: I think just speaking very broadly, there will be many challenges and some that you may never have been able to predict. The one thing that you can lean on when there's so much unpredictability is your strong relationships. You wanna have negotiations between developers and yourself. And so it's starting to build those relationships, have those one-on-ones, especially when you're considering the SCLC, you may think about bringing a new tooling. I think it's extremely important to get developer buy-in. What do they think about that tool? Is it easy to onboard? Does it hinder their work? Get their input. And if they say they don't like the tool, start looking elsewhere or figure out what other problems may occur that may need to be solved first.

Host: Okay, so that makes sense. One of the key things that you highlighted is that building that relationship, right with the development team or the engineering team because at the end of the day security is to advise what needs to be done But the actual work is done by the engineering team So that that sort of touches on how the culture is defined in the organization, right? Because that's how you connect with other team members or you get get help from other team members as well And every company has a unique culture, right? If you think about it, like either it's an engineering-driven or sales driven or security driven.

Ariel: There are many strategies, especially considering that depending on the type of org that you're in, there are just different impacts that matter to the org. And so some strategies that may work very broadly is you can first lean on your power users. These are the folks that care about security without you even trying. They're the first ones to reach out to you when you started your first day at the job, the security team was just born and they are loving it and they're singing your praises when you haven't done too much. And so. Lead these users to get feedback all the time about what you're doing right, and what can go better. The second thing is to have empathy, listen to the folks, what are their current problems and how security fit and be generous with your time. Many people do have those competing concerns beyond just security. And so it's understanding what they're kind of, what's competing for their time and figure out where does security fit. And lastly, it's scaling that influence. You're not going to get anywhere with just doing one-on-ones, especially as your org continues to grow. You want to start to impact leadership, what leadership thinks about security. It's really just, it's building that culture with empathy and getting folks to understand the impacts of security, regardless of which stage or size your company is at.

Host: Okay, I definitely want to talk about empathy, but before I we go into that,

Are there any tools or frameworks that organizations can use to build that relationship or create and foster the culture in the organization?

Ariel: So not necessarily a tool or a framework, but the way I like to think about fostering a culture is you really have to understand who your audience is. And so, like you mentioned, if you're a sales-driven org, you have to adapt to what they're thinking about. Their impact is their bottom line, revenue is important. So if your company cares about saving money, explain how this vulnerability saves money. If you prove that a vulnerability exists, but you don't explain why it matters, they're not going to care. For them, it's just this floating vulnerability that doesn't affect them or doesn't really matter to them because to them it's a non-issue.

If a company cares about their brand image, you want to explain how that vulnerability affects their image. If the company really cares about engineering and engineering productivity, explain how vulnerability and the ensuing incident can ruin that productivity. So at the end of the day, like engineering and security is never going to be one-to-one. I think if it is, that might not be the best business you swear, security needs to always thinking about scale and not just… We need to be catching up with engineering because we're never gonna catch up with engineering.

And it's really changing the way we think about why security matters for the org that we're at. And it's working with our partners. It's not just saying security always comes first. I think at times people think that security may be somewhat of a zero sum game of you take, I lose. And it's not that, it's we're working together on that shared goal. And that's why going back to empathy, it really is important to create this culture of empathy.

so that we understand kind of what our peers and stakeholders are thinking. And we're thinking about our business's goals and not just let's secure everything 100% and ignore what customers want or what the business wants. We have to have that empathy, not only with developers, but with the business itself.

Host: Yeah, makes sense. I think I like the answer where you said, right? It depends on the incentive of the other stakeholders. It's not a one size fits all solution that you bring in a tool and you're all set, right? But rather it's about which team you are interacting with, what are their incentives, what language you use to tell them the challenges and how you get value out of it. That makes more sense that or that helps the organization more.

So, now let's talk about the empathy, right? So in like today, most of the organizations have challenges of prioritizing efficiency right over maybe interpersonal relationship or communication because at the end of the day businesses are there to make money or have a goal right and with the remote culture that happened because of COVID-19, that also in like sort of exacerbated the challenges as well.

One of the side effects is like lack of empathy, which you have been highlighting. Right. Can you help us understand why is this needed?

Ariel: I think we see the impacts of this lack of empathy where to us like people are this like flat screen. They're just people that we wanna get work out of. And it's really hard to understand what's going on. And I think with the pandemic, we all went through a lot of things where our kind of personal lives started to bleed into our work lives. Our productivity was low. People just, we stopped caring about things because it felt like the world was ending.

So, Why is it really important that I fix the security bug immediately when I feel like the world is ending or I have no idea what's going on? And that's why I think empathy is crucial. It provides us the necessary context to motivate individuals and do the right thing. A lot of times it's you'll turn on a security tooling and there'll be hundreds and thousands of bugs that come out.

But it's What does that matter to the developer in the shoes of a developer? Is it really important that they spend a hundred percent of their time fixing all of these bugs and never getting out of it? Or is it more important that we build this culture? We shift left and we prevent the vulnerabilities that could have occurred. The ones that do exist. We prioritize the ones that actually matter to the org. We see kind of plug and play these types of tooling that just tell us, okay, we can just report all these findings are false positive ratings. Pretty good.

But, We still have many, many classes of vulnerabilities. You have to provide context and understanding, or else it's just kind of a vulnerability that exists, not a vulnerability that matters and impacts the organ in a meaningful way.

Host: Right, makes sense. So it comes back to adding context or having the shift left thing that you highlighted that makes a lot of sense as well. Right. The sooner that you introduce security that in a way helps organization in not wasting time in a later stages of development cycles. So I have a follow up question.

Let's say there is a startup which started in the COVID time. How can they cultivate empathy in those difficult times?

Ariel: I think that sometimes it's just you need to have a human-to-human interaction. And at times when we hop on a Zoom meeting, we just think about work. So that means you can have some fun interactive way for people to get to know each other. I think that's important. When we were in the office, there were lots of opportunities for people to co-mingle.

I remember we used to have happy hours with engineering and security. So we weren't talking about security, but we were building those important relationships that helped us get to know one another and build that social capital. Because I think security is all about social capital, right? It's you have to build your social capital and spend it on what you think is right or what you think is important for the org. And so when it comes to building that, a lot of times building those relationships.

So I think for a smaller org, building those one-on-ones, right? It's building those relationships, helping out when you can. If someone has a question, but you're not the right person, either help them find who the right person is or find the solution for them even if that's not in your job title or not what your team does, providing that extra stuff, that extra like second of generosity goes a really long way in building your social capital. So be generous with your time, I think is very important. And then find ways so you can break some of those barriers that you find with being on a Zoom call, it's get to know each other as a human. You don't have to go straight into security. Security problems will exist today and they'll exist tomorrow and for years and decades to come. It's okay to be human and share some time together.

Host: Okay, that makes sense. So you highlighted like if you can do in person like happy hours or if you are doing remote maybe like zoom one-on-ones.

Are there any other frameworks or tools that you use to like build that relationship at Twilio let's say.

Ariel: Yeah. So I think there are many things where like if you're on an incident, having a retro and kind of discussing what went wrong and it's to be able to go back in time and see what are some things we can improve on. And that shows that you have a little bit of humility that what you did wasn't probably the best or could have always improved and you're always striving to improve upon yourself.

I think that having some of that humility helps build that empathy because you understand like not the best security rock star out there. There are a lot of things I could do better. There are a lot of ways that I can learn from the developers. There are a lot of ways I can learn from the engineering leaders that helps you build your empathy to understand, hey, there are more things I can do to help improve the org.

Host: Makes sense and I like the humility part right when you do retros because that's also done as part of engineering sometimes in retro conversations it gets a little challenging to share your message across but having that humility definitely helps and if you have built the relationship beforehand that also helps in those conversations. I see that that has a lot of value.

Ariel: Yeah, it's definitely like building that space for people to be open, right? It's a lot of times when you don't create that space or you don't allow people to make mistakes. Like one of my teammates was giving a talk on committing secrets on GitHub.

Like it happens to everyone. It's a hard problem to solve because it's so easy to commit those mistakes. So having that, like, I've been there. It's okay that you've went through this. It's don't let folks feel embarrassed about something that happens to everyone. It's build that space and give them that time to just express their opinions on things or express what went wrong and be generous again with your time.

Host: Yeah, make sense. That makes a lot of sense. The next question is one of my favorite is, often when it comes to security, right? It's seen as a roadblock to business growth because in today's world, everybody wants to move fast and deploy new features. But the moment we bring in security, it feels like, oh, we have to implement xyz before we can go to production. So in that case, like,

How can security teams work with other business units so that they can sort of help them understand that how this helps in increasing the revenue or improving the bottom line?

Ariel: Definitely. I think it comes to say that a decision will be made at one point that is based off of revenue and it compromises the security concern that you felt was extremely important and you feel like that the business is making the wrong decision. Some point in your career, there will be a decision that is made that you're like, what? Why aren't they prioritizing my security concern? That means you got to work on your influence again.

It's you never have full influence over a company because you want that negotiation. You always want there to be some tension between, hey, we wanna prioritize these issues against security.

It's really, it's building that social capital and extending it. So it's, if a company doesn't think that security doesn't affect their bottom line, you wanna start doing a bit more work. So let's say an incident occurs, your stock prices drop, your customers lose trust engineering productivity is halted, you want to kind of describe and explain those impacts to the org and measure it where you can.

And so, um, if an incident hasn't occurred at your company, you can also pull from other companies that may have been of your similar size or, um, we're faced by an issue that could potentially affect you as well and share those out. So you could create a security Slack channel that educates users kind of on the after-effects of an incident that may be kind of hit a little bit too close to home and it tells them this is what happens when you ignore security for too long.

We're not the only individuals facing these problems. And we're not the only individuals ignoring this problem. And so this is what happens if we go down this path for too long. A lot of times business leaders care about risk.

A lot of times it's that perceived risk. So it's depending on the leader. They're trying to think, how little can I spend on security before I start to see material impacts, while another leader can say, like,

I want to invest a lot in security. Security has all of this money. Those are two opposite ends of the spectrum where you kind of want to have them meet more towards the middle where they're making reasonable decisions on security. Should not be spending all of your budget on security. There are other things that are providing a lot more revenue. So it's always finding that right balance and building that trust and that influence in the org helps you go about doing that.

Host: Okay, so the two sort of takeaways from this is one is showing the value, direct or indirect value for the organization and again building the relationship beforehand so that you can use that to influence some of the stakeholders or your let's say upper management that hey here is the value and then they sort of help you in budget and getting headcounts so that you can incorporate the recommendations.Right. A follow up question to that is,

Do you have a set of metrics or KPIs that you use so that you can show how security maturity can help the bottom line?

Ariel: Yeah, definitely. So I think one thing you should always be doing is identifying the top risks for the company and tie those back to business impacts. How does that materially affect the company? If a breach were to occur or if a customer says, I would like this feature or this security requirement in place, tying that to the dollar amount. And so we've also done this at Twilio Segment where for every contract that we enabled for sales, either that be through the SOC 2 or the customer questionnaire.

We identified the dollar amount that we enabled. But I think that can sometimes be a double-edged sword where if you measure everything by dollar amounts, and so every security service that you offer, you offer a dollar amount, you might start to see some cost-cutting measures where you don't get to ultimately decide or on things that aren't immediately providing impact. So I say kind of do that a bit slowly and kind of within the context of your org, but there are ways to show like.

Security does bring in revenue. At the end of the day, I think security is an enabler and not a cost center. We need security because it ensures and builds customer trust. It helps us prevent all of those incidents that may affect our brand image and kind of lead if you're a publicly traded company, it may kind of lead to like dips in your stock price. So there are lots of benefits and there are ways that we can contextualize that that matters to leaders. I don't think everything is about dollar bills. Otherwise, I feel like no one would have any benefits, right? Because that's just an extra cost.

There are other ways that we contextualize and influence really helps determine that. And so while you can provide lots of metrics and dashboards, the relationships you build are just as important.

Host: Yeah, I guess I see a pattern in all of your answers. It's all about building the relationships and then the culture, right? How the culture is set or how you are interacting with others, use that, leverage that for not just prioritization, but for budgets and all other aspects of incorporating security. So when it comes to, let's say, as you highlighted earlier, right?

Security is more of an advisor and at the end of the day, it's the engineering team which needs to implement that So sometimes security teams teach some of the basic security basics to other team members as well, right? So that they can judge the threads what level it is. What is the depth of it and stuff like that? So I have two questions here

What are some of the effective ways that you have seen or you have used in Twilio to improve security awareness within the organization?

Ariel: So I think it's like a compliance requirement for many companies have like a broad security awareness training and that usually just kind of like, what is phishing? If you see a phishing attempt, report it. But then you also kind of see more specific security training for developers.

So I think when you're speaking to an extremely broad, obvious audience, the simpler the message is better, right? It's they, people don't really have the time. Sometimes they're just clicking through all the trainings. Where you can have impact is where you have smaller groups. And so in developer training, what we did at Twilio Segment was we had live trainings where we paired our think like an attacker training with an actual, like, here's the OWASP top 10 and then let's actually go and break the OWASP Jupshop app.

Then we pair that with a threat modeling training where we walk through a real threat model, we kind of give them the trainings over kind of three courses to figure out here's how you identify threats, here's how you break down the future.

Here's how you prioritize those threats and then remediate or mitigate. And so I think it's really, you have to cater your security training to your audience. So if it's extremely broad, you want a simpler message.

But if you do have the opportunity and the time and the resources for a smaller audience, such as your developers, and let's say it's kind of within like that 200 developers, you can spend a lot more time in thinking through what are their current problems. Instead of just talking about OWASP top 10,

I want to talk about what really matters to them. So what are our current issues? So if you have a bug bounty, pull into your bug bounty and see what your top concerns or your top vulnerabilities are, and cater to that, not just the broad OWASP top 10. And then when it comes to threat modeling, where are they at when it comes to threat modeling?

Do they have a good idea of what your framework or model is? If they do, you can create kind of more advanced levels of threat modeling and not just the basic, here's how you threat model.

So there are many, many ways and it's really adapting and context, it goes back to that and having that empathy really matters in giving high quality trainings that engage engineers.

Host: Yeah, makes a lot of sense. And one of the things that you mentioned here is that, of course, it depends on how much resources or budget you have. But if you have the opportunity, maybe go into specific use cases specific, like as you highlighted about the bug boundary thing. Maybe look at the top five issues, those are open and go into detail, so that it's not a very high level discussion, but rather you are going into very detailed so that engineers are able to relate to it and are able to understand very granular nuances of it as well. So one of the things that you earlier said is that while working with other team members, maybe find some power users and then start with them. But when it comes to security, it's all about accountability, right? Who is accountable to some of the security vulnerabilities?

How would you implement or improve the accountability of security in an organization?

Ariel: So you need a clear process. You need, it can't be security owns all of the risk. We have this process where we democratize vulnerability management. And so it's not for security to own the risk and it to be securities problem. This vulnerability is owned by security. It's, we all own this as an org.

This is kind of all of our problem. It's a shared problem. We're all working on it together. And to even get to that point of this is our problem. You do need a clear, standardized process where you have a single way for all individuals to interact with vulnerabilities.

They shouldn't have to know the difference between cloud security and incident response and product security. A lot of times when you think about security, it's just the security team. We fit under that umbrella. People aren't thinking specifically about, oh, this person's product security because they touched the product and application layer. They're really thinking, oh, this is a vulnerability or this is a security issue, goes to the security team.

And so it's really, really important to have a standardized and clear process that allows individuals to kind of interact with. And that second part is that ownership should be shared amongst everyone.

This is something where you would want to use your social capital and engaging engineering leaders to understand, hey, this is a vulnerability that your team owns. And if you'd like to push it off or if you'd like to not work on it, this kind of affects how your part of the org is securing the entire organization. That is your responsibility.

It's something that we have to work on together to influence them to prioritize that risk. But this isn't something they should go about alone. It's something that security is going to partner with them to influence, to take the right actions. But ultimately, it's their responsibility. It's their decision. And I think that kind of ensures accountability when you have a bit of that ownership.

Host: Okay, that makes a lot of sense. So again, it goes back to the relationships that you have built so that you can influence some of the prioritization because ultimately it comes down to prioritization, right? Which vulnerabilities are getting worked on. So if you have built that relationship, you can influence and then get those addressed. And that also makes other teams accountable to some of these security risks as well. Makes a lot of sense.

Ariel: Definitely like, yeah, there are like many things you can do with like dashboards, notifications and alerts. But what really powers the effectiveness of all of those tools is your relationship with the developers and the leaders. Uh, if you had no relationship and you had just automated your security team to fire off all of these alerts, give all these notifications and these beautiful dashboards, people could just ignore all of it.

What really motivates someone to work on it? You can always mute an email or mute a Slack notification or push it off a week or a month. What really motivates people to do it now is that they understand the importance of it and they're prioritizing it because they have this strong relationship with security.

Host: Yeah, absolutely. That's spot on. Totally agree with that. So that's a great way to end the security questions section.

Now let's go to the rating security practices section. So the way it works is I'll be sharing one practice, and you should rate them from 1 to 5. And you can add more context, like why you think it's a 1 or a 5, or in between.

Host: The first practice is training employees only during onboarding so that they can identify and respond to potential security threats because there is no need to do like continuous training or table top exercises.

Ariel: So I think this is kind of a two and a half and being it's on the scale of like one being the worst and five being the best. It's you at least have training. That's actually a great thing that your security team did in training all of your engineers. And I'm assuming this happens annually or during onboarding.

There's a process in place for you to count who's untrained, who's trained. There's a lot of management involved in that. So I think it's you're on the right path. I think there are more steps for you to mature, but like, Hey, at least you have training. Kudos to you.

You're on the right path.

Host: Okay, that makes sense. The second question is somewhat what we discussed earlier. Security processes are often seen as roadblocks to business growth, right? So when a developer or an engineer says that, hey, I want access to a cloud environment, just grant them unrestricted access so that they can just move fast because we don't want business growth to be affected in any way.

Ariel: So this one I give a two. So it's still kind of a little bit worse than training employees. The reason why I say that is, um, yes, it's not a great practice, not a great security practice. Uh, but the end of the day, this will start to affect the business. There will be customers that say, Hey, I'd like to see more controls in place. Um, I have no idea who's accessing my data. This isn't gray or you have no idea. An incident happens who access what or what caused it.

And so it'll start to become a business priority. But when you're a super small organization and your company is focused on business growth, you should be doing everything possible to enable that business growth.

If you have a clunky process that makes it really difficult to regain access or they have to wait a really long time or if someone goes on vacation, they can't enable access again. It's really, really hard. Implementing like just in time systems can be really expensive or take a really long time to implement. So it's okay.

Your business knows that it's a risk and you should outline it for them and give them a long-term roadmap. But at the end of the day, if you're at a small size and this is a current problem, help the business enable their growth and start to kind of give security considerations to them and say, later down the line, this can become an issue.

Here's what we can start doing now. Here are the baby steps we can take, or here's a roadmap for us to get to a point where this is a lot more mature. But I think it's okay to enable business growth at certain instances.

when you're at kind of a smaller size and business growth is extremely important to ensuring that your company continues to grow. So it's definitely not the worst, but it's something that you should consider based off context.

Host: I like how you structured it anyway, right? Like if it is a smaller organization, let's say a company of 10 people, maybe it's not a major issue, but as you grow, you need to have those process in place or you should not follow this practice rather when you grow. Okay.

Ariel: Yeah. And you'll be getting signals from customers who are inquiring about it constantly. And it's captured those customer signals ensure that the engineering leaders know this has become a top priority for many of our customers or we've lost X number of contracts because we have unrestricted access.

Those are the things that matter to the business. And so you're providing that important context.

Host: Yeah absolutely. The last question is whenever there is an incident it is a one time activity it never occurs again. So, there is no need to do a retrospective analysis after it is resolved.

Ariel: So I think this is the worst. I give this rating a one, because it's such a small thing to do a retro after an incident occurs. And this is something that permeates throughout your culture. If you say that we fix it once and we're done, there's nothing we could have done more. We're not even gonna think about it.

We're just gonna think about the next day, the next problem. Yesterday's problems are yesterday. So I think that really hurts your long-term strategy and your long-term culture, where you're just kind of...focused on these fixes within the moment and not, how does it affect our long-term strategy or how does it affect us long-term?

How does it affect our security engineers? How does it affect our engineers? You don't have answers to any of those questions. And I think retros are extremely important in understanding what went wrong, what went well, and what you could do better next time and take it with you. Become extremely actionable on your retros as.

Okay, here's how we're gonna improve upon it next time. And it builds this culture of like iterative improvements. It's not, we're perfect, we don't have any more to do. There's always more that we can be doing to improve. And so let's start thinking about what we could do better.

Host: And when you do the retro have the humility as part of it as well right as you highlighted.

Ariel: Exactly. Exactly. And it's, yeah, it's, it's always great to have other people like talk about their problems as well of what went wrong. It, it may creates this shared empathy of like, we both really struggled with this problem. It wasn't just me. Um, and here's what we can do to collaborate or do something different the next time.

Host: Yeah, Yeah, makes a lot of sense. Yeah, that's a great way to end the episode. Thank you so much, Ariel for joining with us and sharing your insights.

Ariel: Thank you so much for having me.

Host: Absolutely. And to our viewers, thanks for watching. Hope you have learned something new. If you have any questions around security, share those at skill20.com and we'll get those answered by an expert in the security space. See you in the next episode. Thank you!

Insights from Scale to Zero

Detect Your Cloud Misconfigurations

Reduce your risks by fixing your misconfigurations before they become a threat.