Back

PLG and security leaders: going with the flow

PLG is here to stay.

More and more cloud-apps are adopting a product-led growth (PLG) strategy as a way to help grow and retain their customer base. Think: Slack, Trello, and Calendly. 

In practice, PLG means getting rid of any friction points for signing up and trying a product (e.g. offering free or “freemium” versions), and placing a premium on a smooth and enjoyable user experience. The theory goes that once you’ve actually used a product, people are more likely to purchase it. Another hallmark of the strategy is leveraging evangelists—users who love a product and spread the word about it. This tactic works particularly well for SaaS products, because people need to share information (and therefore use the same apps) to collaborate effectively in the workplace.

There’s no doubt that PLG is here to stay. But what does it mean for security teams suddenly managing a sprawling perimeter defined by bottom-up end user adoption that bypasses the traditional security review process?

“How can security teams suddenly manage a sprawling perimeter defined by bottom-up end user adoption that bypasses the traditional security review process?”

Meteoric rise

It’s been around for a while, but PLG really took off in the past few years. Choosing and purchasing enterprise software used to be the exclusive domain of centralized IT departments, with third-party risk assessment built into the process. Now, with more and more digital infrastructure moving to the cloud, the decision-making power has shifted closer to the actual end user, effectively short-circuiting these old security protocols.

Combine that with the pandemic-borne shift to remote work, and a more widespread acceptance of the fact that business units and even individual employees know what they need to get their work done effectively, and you have the perfect breeding ground for a rise in PLG popularity.

Looming security crisis

But the increased productivity and innovation enabled by these 3rd party apps comes at a price.

Recent 3rd-party integration attacks at OktaMailchimp, and Github show the dangers of an increasingly interconnected cloud ecosystem – when vulnerable connections between apps and core systems go under-monitored. 

So, while the freedom to choose and install 3rd-party apps is great for employees, it can be a nightmare for IT and security, who are stakeholders in the security, cost containment, and governance for a company’s sensitive data and systems. To do their jobs most effectively, IT leaders need to know what tools are being installed, how they’re configured, and what data is flowing through them. This can be hard when most of your workforce is remote and can install whatever they want, whenever they want to.

To further complicate things, access to the apps themselves can be secured by things like multi-factor authentication and VPN’s, but the connections between these apps and critical on-prem systems may remain vulnerable and unprotected, These connections (along with any plug-ins, add-ons, and extensions that may exist), represent a growing attack surface that organizations are saddled with defending.

Balancing autonomy and security

Given all these risks, it might be tempting for security leaders to lock things down and wrest back control of the acquisition process. Unfortunately, at this point that wouldn’t even be possible without taking away tools that people already rely on. And, even if it could be done, it would stifle innovation and slow things down. 

Instead of locking things down, organizations need a security apparatus that works with, not against, this rising tide of PLG apps. For this to work, security leaders need visibility into all interconnected systems, and this information needs to update dynamically as things change. They need threat detection, in other words, they need to know which apps and which connections between apps and enterprise systems are at risk at any given time, and what they can do to remediate those vulnerabilities.

Full visibility and automated threat detection are highly effective at preventing breaches, but there are some low-tech measures that organizations can take as well. Training employees to vet and install apps responsibly, conducting regular cloud security audits, and decommissioning apps that are no longer being used are some good approaches.

With these kinds of measures and capabilities in place, security leaders will be able to keep data exposure  between systems and the long-tail of PLG-apps safe from breaches and attacks, without hindering the productivity and innovation unleashed by the PLG era.

Learn more about how Astrix can help your enterprise accelerate cloud adoption fearlessly with integration access management built for the era of hyperconnectivity.

Request a demo

See how Astrix can help you take
control of your third-party integrations.



This will close in 0 seconds

Contact us



This will close in 0 seconds

The Ultimate Guide to Securing App-to-App Integrations

How to discover and remediate over-privileged, unnecessary, and malicious integrations to your most critical systems.

This will close in 0 seconds

Risk #3: Compliance violations
  • What it is: An act that compromises an organization’s ability to comply with relevant governmental, legal, or industry frameworks – for example, data privacy regulations (like GDPR) or security and governance (like SOC 2).
  • Recent example: Ticketmaster received a $1.6 million fine for GDPR violations after hackers exploited vulnerabilities in the code of a third-party chat app vendor on its checkout page, exposing customers’ personal and payment data.
  • Why third-party integrations increase the risk: Any third-party application involved in data processing is part of an enterprise’s regulatory purview – meaning that the organization is ultimately responsible (often financially and legally) for its handling of sensitive data.
Risk #2: Direct malicious access
  • What it is: Malicious actors seek direct access to core platforms by tricking users into providing consent (via OAuth permissions rather than explicit credential phishing) or by taking advantage of leaked API keys, certificates, webhooks urls, etc.
  • Recent example: Microsoft recently warned of a phishing attack in which Office 365 users received emails intended to trick them into granting OAuth permissions to a fake app.
  • Why third-party integrations increase the risk: With third-party applications increasingly integrated to core platforms, access tokens enable malicious actors access to data and operations on organization critical systems.
Risk #1: Supply chain attacks
  • What it is: A third-party app integrated to a trustworthy central platform may “leak” sensitive data into a less secure environment. Malicious actors abuse security vulnerabilities associated with a legitimate (but less secure) third-party application – and exploit its privileged access to sensitive information (like credentials or data).
  • Recent example: Hackers compromised the software development tool Codecov to gain access to – and rapidly copy and export to an attacker-controlled server – sensitive secrets,credentials and IP associated with software accounts at thousands of clients.
  • Why third-party integrations increase the risk: More and more third-party applications hold the “keys to the kingdom”: the most privileged credentials in the enterprise. Any third party application that can be compromised opens up the possibility of unauthorized intrusion (and data extraction, ransoming, and more) by malicious actors.