Breaking Silos in Platform Security, Trust & Safety, and Risk – Mona Salvi (Sr. Director, HubSpot)


In this SaaSTrana podcast, Mona Salvi (Senior Director – Product Security, HubSpot) talks to Venky about building a unified org structure and North Star metrics to drive security-related initiatives in a cohesive working environment.  

She also shares how to manage three pillars – platform security + trust & safety + payments fraud together under a single leadership umbrella.  

Key highlights from the discussion :
  • About Mona Salvi and HubSpot 
  • Developing the mindset of intrinsic vs. extrinsic security 
  • Driving secure product experiences along with focusing on core business
  • The pillars of platform security + trust and safety + payments fraud
  • Breaking the silos between the risk officer and the security officer
  • Developing applications at speed without impacting the security
  • Building security champions within the organizations
  • Building North Star metrics for security teams - Security
  • an enabler for customers to pick the right vendor of choice
  • Protecting from threats caused by OpenAI and LLM tools (The facts on utilizing security co-pilots)


I joined HubSpot about a year and a half ago. I’m currently the senior director of Product Security, Fraud, and Risk at HubSpot. Before that, I was at Intuit and did some stints in IT enterprise security, leading various initiatives related to multi-factor authentication, SSO, privileged access management, DLP, insider threat, etc.

And then, I moved on to trust and safety, which was in a different group at Intuit. The primary function there was content moderation, abuse, fraud detection, prevention, and making sure that the customer success agents at Intuit, who deal with very highly sensitive data related to TurboTax, QuickBooks, etc., are not falling victim to social engineering attacks or phishing fraud attacks and so on. It was about building an AI-powered security incident event management platform and protecting users’ accounts, payments, whatever you will, from any abuse and maintaining the integrity of our TurboTax and QuickBooks software.

Before Intuit, I joined VeriSign, overseeing the identity and authentication business unit. Everything related to PKI managed services, MFA, and offering those managed services not only in the enterprise segment but also on the Internet of Things.

And then before that, in different companies like Blue Cross Blue Shield, Bank of America, and Verizon, I played various other roles as a software engineer, data analyst, and so on.

As part of scaling and building the product security function in HubSpot, one of my primary charters here is to build product security early on and bring in the intrinsic versus extrinsic security mindset.

It started by overseeing the product security and platform security for the HubSpot function. And then, over time, it has grown into owning trust and safety. Everything related to ensuring content moderation and integrity. Failing to address issues related to bad actors abusing the HubSpot platform could risk the HubSpot brand and reputation and violate an acceptable use policy.

We want to ensure our customers understand the acceptable use policy, so our trust and safety teams come in. Their goals involve rules-based detection, alerting, and ensuring that they have all the right tools and capabilities to either be proactive or, even if it were reactive, ensuring that they do so in the right manner to protect them from falling victim to the same.

And then the third vertical that I have is the e-commerce fraud. Everything related to the payments ecosystem, and we apply a set right risk framework, enables the commerce product teams to make the right decisions as they will move quickly and drive more adoption. Here, we enable the mindset of security and risk as an enabler to growth versus being perceived as friction.

I would call those three verticals Platform security, Trust and safety, and Payment fraud.

I also have a horizontal that spans across all these three verticals. That’s our risk function. In terms of identifying our North Star and measures of success and making sure we are making the right decisions in terms of prioritization, we need to have a good, solid, and robust risk strategy.

In my risk function, we are again applying the principles of identifying risks and quantifying, assessing, and prioritizing those risks, which enables us to make the right solutions only for the critical and high risks. And make sure we are always continuously working and narrowing those risks and gaps in the HubSpot platform and continuously protecting our customers’ accounts in the HubSpot brand.

I’m witnessing this slow shift that’s finally at speed and becoming essential for businesses because the goal is to be more proactive. We all know about the risk management framework. We’ve all talked about growth versus risk conversations. But this is shifting in that fraud leaders must realize that their area shouldn’t be treated as separate line items to drive more adoption overall and bring more growth like the business product. Because overseeing the overall P&L of the product ultimately involves the various disciplines, whether it be business, IT, or security. They all serve the same purpose: protecting our customers and businesses. And we are seeing that more and more organizations are developing that mindset of convergence versus silo.You cannot solve or go ahead and grow the business sustainably without viewing risk, security, and fraud as an enabler. This means you have all this rich data related to behaviours, patterns, and signals. If there are siloed functions, how do you go ahead and apply those insights to businesses in the forefront? How do you enable them to allow the customers to protect their identities and the organization’s own fraud posture?

I’ve seen a couple of companies already starting to do this. I’ve seen risk and security officers are separate in some very large organizations.

There are always benefits, areas, and opportunities. When you have a risk function and have identified and quantified the risks, sometimes it can conflict, but you start having growth versus risk conversations. We’re all here for our shared mission goals, & the whole concept is bringing that mindset that we are all in this together and bringing sustainable growth. To bring sustainable growth, the following risks have to be mitigated.

Sometimes, I think having the product, solution, and risk strategies under a single leadership may have pros and cons:

  • When do you prioritize?
  • When is the right time to go ahead and do so?

But again, you need to start having security champions built in within the security organization to start educating them, training them, having the right curriculum, bringing them into this shared mission, and driving forward with speed. If it’s going in the right direction and then, as there are areas and opportunities, you learn from them and continue to evolve.

The answer is not about scaling or adding more security heads to the organization. But it again comes back to our mindset as to

  • Who would I partner with?
  • Who are the stakeholders?
  • How can we change the mindset?
  • How can we have a well-defined software development lifecycle process?
  • How can we have proactive security in the CI/CD pipelines?

And this is a conversation just to be had within the business units, within the functional groups. But I’m also hearing about this in boardrooms, where we discuss SDLC; we understand the options. We are trying to understand how well it is adopted, not just by the board members but as a culture that would shift the organizations. It is also about taking it forward and going ahead and implementing it in the same way in the development communities.

With security, there are checklists and many more changes. How do we enable them to move faster without having room for slowing down? Dev teams are saying they need more automation.

Bring that mindset and have the right checklists, let’s say OWASP 10, that go ahead and call out injection or cross-site scripting or sensitive data exposure, which could be inadvertent or malicious, but making sure that all the code goes through those checks before it launches any features and production.

Continue to innovate at that mindset without again adding more heads within the security organization, but rather by enabling the rest of the business units to join this journey and making things easier by implementing the automation with partners.

I’ve seen that security teams continue to get pulled in and enable the developers to go ahead and ensure the security of that code. Sometimes, the security leaders have to go ahead and push for that paradigm shift. As we talked about automation, we are enabling the developers with the right tools and services.

We continue to see a pull-and-push model. You would rather have the developers come to the security teams to ensure they follow the best practices versus pushing yourself as a security leader in that conversation.

At some point in time in the future, it becomes a well-oiled, well-functioning process, where security through automation enables the developers to continue to build with speed, with various integrations that could be different security cultures, hygiene, best practices, etc., and all these that need to be implemented.

How do you implement it while making these culture shifts? By applying the hygiene and best practices and bringing third parties in to launch that automation.

I recommend adding more security by finding a role model team in the organization, latching on to them, and driving that culture.

Drive culture or bring security champions within the developer community to drive the change. Security champion is now becoming an industry-standard term that needs an evangelist, a champion within that business unit who goes through the training and the curriculum.

And then, with that role, they go ahead. Once they prove successful, the rest of the teams start coming in.

Enable the champions to hold their respective dev teams more accountable, probably with KPIs and metrics like scorecards to measure success. And are they calling those recommendations to measure our North Star metrics?

How do you go about measuring that? Let’s say no incidents happen because of vulnerabilities that could otherwise have been caught or the adoption of these services. With that, the security champions enabling the adoption of automation services to embed security early in the lifecycle could be a metric.

Enable them with the right education, train them appropriately, and then discuss various risk criteria like defining high risk versus medium versus low risk and enabling the right amount of sanity testing, unit testing before the code gets checked into production, or even counting vulnerabilities.

These are various measures of success that I call out as ways to change the culture, change the mindset, and embed security within the business units rather than just relying on a security organization to ensure platform security.

This model truly succeeds as an organization and grows in scale; you have to start spreading and instilling that security mindset across all product groups and business units.

There are a lot of benefits that automation and bots and co-pilots can bring in. But now it’s like, who cops the cop? So now, what signals do you really put in place to ensure they are not introducing or missing out on any vulnerabilities?
In today’s age, more and more customers are increasingly aware of their tools and the systems they use to do their jobs while also questioning their sales or trying to understand how the organizations protect their data and their identities.It’s coincidentally yesterday, I got a text message from Bank of America about the potential fraud alert to my debit account. As a security professional, I would go one step further and ensure I don’t click on the link, etc. But I also verified everything to see if it looked okay. I wouldn’t stop calling the right number to understand how my account was affected or what looked suspicious.

Not-so-security-savvy customers, regardless of age, demographics, etc., are interested in knowing and understanding that their data is safe. Our TurboTax customers, QuickBooks, and HubSpot CRM customers have routinely been interested in understanding how we protect their data and what we can develop as core features that they can benefit from in understanding their organization’s security posture.

Whether it’s security admins who are trying to understand how the spread of risk is in their organization or if it is the end users that are being enabled to scale and grow better without having to worry about data and account protection are all the various use cases that more and more customers are becoming aware of and savvy about.

Security is now a differentiator to enabling and promoting customers and picking the right vendor. These come from customer research and user research, where customers are interested in

  • How well do we secure our platform?
  • How is data protected in the platform?
  • How and who can access the end-user data?

These questions drive us to make our jobs easier again and launch security as that tailwind or differentiator into the landscape.

It’s all about how we can be more proactive versus reactive. That’s what our security practitioners have always believed in. Like myself, many security practitioners call out the risks that open AI and LLMs bring to various organizations.

For example, it becomes much easier in CRM to spin up content. It also educates cyber criminals on how to spin up campaigns that do not look like phishing anymore because earlier, it was easier to point out grammatical errors and language. All of that just got made much easier. It’s like an education or training tool for attackers to develop better phishing or good-looking campaigns.

How you can get ahead in this space is an open question. But some of the philosophies are areas that I would like to solve, or at least organizations should be thinking of solving.

Earlier in January of this year, NIST launched an open AI RMF. It was a risk management framework, as with every cybersecurity or fraud risk, which follows this framework of just identifying risks, whether in code or product features.

Follow the principle of identifying and assessing the risks based on probability and likelihood or impact.

Quantify and prioritize them. Similarly, we can leverage that NIST RMF Framework and start measuring in the Open AI and LLM landscape.

  • What are the kinds of risks this model can bring?
  • How can we go ahead and measure and prioritize without being perceived?

At the core of the NIST or other frameworks, these are the four best practices that govern:

  • Bringing that risk management culture, let’s ensure it is and continues to stay intrinsic. It continues to be perceived not as friction but perceived as an enabler.
  • The second one is mapping. So how do you recognize the context of that content and assess or map those risks, whichever crown assets, infrastructure assets, or product features you want to protect and are most critical?
  • How do you measure it? We talked about North Star metrics, so how well are these best practices adopted?
  • Again, assessing and analyzing for continuous monitoring and then managing.

How do you’ve gone ahead and governed, mapped, and measured? How do you go ahead and prioritize this?

There’s a lot of theory to this now to advance AI responsibly. It is not a very draconian view of all the security risks that open AI and LLMs bring. The reality gained leadership support.

How can you champion ethical users of data with best practices, with training, and with awareness? Suppose the organization wants to leverage ChatGPT and Open AI. In that case, we can improve the training of AI and also apply that SSDLC process in this concept of implementing and putting anything in ChatGPT.

When you can’t measure, that situation keeps you up at night. You know that there is a risk. And if you can’t measure that, you don’t know where to prioritize.

And based on that, then I think the challenge is up here. At least, those are best practices. It’s just about getting the right championship from the leaders in the organization, and it’s not going to be an overnight job.

My guidance to anybody, whether it be an engineer or anybody else who wants to grow in the field of security, is to combine business acumen, a strong technical background, and great communication skills. You can have one or the other, but that wouldn’t set you up for success if you’re not able to communicate the risks to the business or if you’re not able to understand the customer-back mindset.

What’s in it for the customer, whether that customer is an insider, internal customer, let’s say you’re selling for the operations teams, or what’s in it for the customer, which is the end user, how they’re protecting their data and the risks associated.

If you can’t communicate that, if you don’t keep the customer in the center of it all and just have multiple years of technical experience, engineering, and technical depth, then it might just get too difficult to map all these three, which are needed for becoming a great leader in security.