TL;DR: Enterprise marketplaces vet apps at the point of entry. What happens after listing depends largely on the developer. AI coding tools are increasing the volume of apps entering these ecosystems while raising the baseline rate of security gaps in the code underneath them. The gaps aren't new. The scale is. And when something goes wrong, the data governance responsibility sits with you.
If this kind of platform governance thinking is useful, the newsletter is where I keep working through the risks that sit just outside the frame of most enterprise technology decisions. Subscribe if you'd rather ask the right questions before something goes wrong than after. Thank you :)
There’s an assumption of trust baked into every SaaS marketplace.
You open the AppExchange, the HubSpot App Marketplace, or the ServiceNow Store. You find something that solves a specific problem. You check the reviews, confirm the vendor looks legitimate, and decide to hit install. Somewhere in the back of your mind, the green tick from the platform does its job. It must be fine.
That assumption isn’t entirely wrong, but it’s probably not as complete as we’d like it to be. And with AI coding tools accelerating who can build marketplace apps and how fast they ship, it’s worth understanding what that trust is actually based on when we use these marketplaces.
How Marketplace Security Works in Practice
I’m not a security engineer, and I’m not going to pretend to be one. But when I started pulling on this thread, I went looking at what the major platforms actually publish about how their marketplace vetting works. The pattern is pretty consistent across all of them.
The most intensive scrutiny happens at the front door.
Salesforce’s AppExchange is widely cited as the most rigorous example. According to their own developer documentation, apps go through a formal review before listing. It’s a multi-week process involving both automated scanning and review by Salesforce’s product security team. Paid apps pay a fee to submit, and free apps can apply for waivers. If Apps fail the review, they get sent back. Salesforce has also updated the scope in recent years to cover AI-specific risks as more apps start using machine learning. That process is real, and by marketplace standards, it’s meaningful.
But their documentation also describes what happens after listing. For version updates, developers work through a self-attestation process. Essentially, they confirm that the changes they’re pushing don’t introduce new security issues. Salesforce conducts periodic re-reviews, but the frequency depends on risk factors, and no marketplace is manually auditing every minor code change across thousands of apps in real time. The maths simply doesn’t work at that scale.
Other platforms follow similar models, with variations. HubSpot’s marketplace requirements focus on certification, with security standards baked into that process and responsibility for ongoing code integrity sitting with the developer. Microsoft and ServiceNow both have formal vetting before an app goes live. What all of them have in common is that the review is most thorough at the point of entry, and what happens between reviews depends significantly on the developer.
To be fair, the platforms aren’t standing still. There’s a clear industry move toward continuous automated monitoring. Background tools flag unusual behaviour or unexpected changes between formal review cycles. They are trying to make meaningful improvements, but automated tools are better at catching threats they’ve seen before.
The Gap That’s Hard to Close
Security scanning tools, automated or otherwise, are effective at finding attack patterns that are already understood. Known vulnerabilities, exploits, or common mistakes.
What they typically struggle with are what researchers call business logic vulnerabilities. These aren’t broken in a traditional sense. They’re flaws that only surface under specific, untested conditions, when this particular app talks to that particular system in a way nobody anticipated.
From what security researchers describe, AI-generated code tends to produce two related but distinct problems depending on how it’s built.
When AI tools are used to extend or modify existing code, they sometimes remove security checks that are already in place. The model sees something preventing a function from running and treats it like a bug to fix. It doesn’t know why that check is there. So it finds a way around it. The error message disappears, the code looks clean, and a safeguard quietly gets removed.
Pure vibe coding, where an entire app or integration is built from scratch through prompts, introduces a different but related problem. AI models have learned from enormous amounts of code, including well-written, secure code. If you explicitly ask for security measures, you’ll often get them. But if you don’t ask, or if the prompt doesn’t surface the right context, security boundaries may not appear at all. The model isn’t deliberately leaving gaps. It’s generating what the prompt asked for. What the prompt didn’t ask for simply doesn’t get built.
This is the underlying issue in both scenarios. Security in AI-generated code tends to reflect what was asked rather than what’s needed. And most people building a quick integration to solve a business problem aren’t prompting for security architecture. They’re prompting for functionality.
The vibe coding problem compounds this further. When code looks polished and well-structured, the assumption is that the logic underneath is sound. That’s the false sense of confidence that makes these vulnerabilities hard to catch before something goes wrong.
Research from Veracode found 45% of AI-generated code contains security vulnerabilities. Separate benchmarking puts that range at 40 to 62%, depending on the tool and the programming language. The consistent finding across studies is the same: AI-generated code is better at looking secure than being secure. At least for now.
What Changes When the Barrier to Entry Drops
Third-party marketplace apps have always carried risk. A developer could go out of business and stop maintaining their app. A small vendor with limited resources could have vulnerabilities that took months to surface. These risks existed before AI coding tools.
What AI tools change is the volume and velocity.
The barrier to building a marketplace app just dropped significantly. A developer who previously needed months of work to reach listing-ready quality can now do it in weeks. The pool of potential developers, including people without formal engineering backgrounds, has expanded. And those apps can be updated quickly, with changes pushed via self-declaration between formal reviews as per some of the practices that seem to be followed today.
Wiz research found that 1 in 5 organisations using AI-built platforms had apps with serious security misconfigurations running in production. More apps entering marketplace ecosystems, built faster, by a wider pool of developers, with a higher probability of logic flaws in the underlying code. That’s the shift I’m calling out.
And there’s a complication worth naming. If marketplace security requirements stay too demanding or too expensive, the problem moves. Developers and business teams who can’t get a quick app listed through official channels find other ways: direct API connections, automation tools like Zapier or Make, integrations built by freelancers who bypass the review process entirely. A marketplace app with a green tick, even an imperfect one, is still statistically safer than a side-loaded integration that never went through any vetting at all.
I’m not writing this to scare you off marketplaces. They’re imperfect. But an imperfect process is probably still more secure than the workaround your business team builds with an unvetted third-party tool nobody in IT knows about.
The Real Incident That Grounds This
This isn’t theoretical. We have historical scenarios that played out that are worth noting.
In 2025, attackers compromised Salesforce environments at multiple organisations through a third-party Drift integration. Qualys was among the confirmed affected organisations, with customer data, contact details, and internal communications exposed. The integration had gone through a marketplace security process. That didn’t prevent the exposure.
The way in was through something called an OAuth token, essentially the digital key that lets a third-party app access your platform data on behalf of your users. These tokens are powerful precisely because they’re designed to work silently in the background. Once an attacker has one, they can access whatever the integration was authorised to reach without triggering login alerts or the multi-factor authentication most organisations rely on.
Who Ends Up Holding the Bag
Here’s where the accountability question gets uncomfortable. The platform can truthfully say: we reviewed the app, it met our standards at listing, we published our requirements, developers self-declared on updates. Their responsibility ends at the review framework.
The developer might be unreachable. Or operating as a small team with limited security resources. Or have shipped AI-generated code they didn’t fully audit or understand before listing.
But when your HR or Finance data gets exposed through an integration you installed from an enterprise marketplace, the one with the green tick, you’re the one explaining it to regulators. Your data protection obligations don’t have a clause for “the marketplace vendor attested it was safe”.
As I’ve previously said in other pieces, you chose the vendor, you approved the connection, and you installed the integration. The shared responsibility model places the data governance decision with you.
That’s not totally unreasonable either. Vendor selection is part of your risk position, so it’s worth being clear-eyed about it, because “we got it from the marketplace” can become a false comfort in an organisation’s governance process.
This is now starting to get the attention of the insurance industry. Cyber insurers are increasingly looking at how organisations manage their SaaS connections as a primary risk factor. There’s an early movement toward something called a “SaaS Bill of Materials”, essentially a documented inventory of every integration you’ve connected, what it has access to, and when it was last reviewed. Right now this is emerging as best practice.
What to Add to Your Vetting Process
None of this is an argument against using marketplace apps. They solve real problems, and the major platforms do meaningful vetting at the point of entry. A marketplace app is still a more controlled option than most alternatives.
But the model has gaps, and those gaps are likely to widen as AI-accelerated development increases the volume of apps entering these ecosystems. A few questions worth adding to your process:
When was this app last formally reviewed, not just self-declared? This difference matters. A self-declaration is the developer’s word. An independent review is someone else’s.
What does this connection actually need access to? Permissions are often set broader than the specific feature requires. If a recruitment integration is asking for access to your financial records, that’s worth questioning. The principle of only granting the minimum access needed to do the job applies here as much as anywhere.
What’s the vendor’s security posture beyond the listing? Do they have a published security policy? A process for disclosing and patching problems when they find them? A small developer who built their app using AI tools and hasn’t documented any security review is a different risk profile to an established software vendor with a dedicated team. For example, do they have independent security review certification?
What happens if this vendor disappears? Marketplace apps can be removed, deprecated, or abandoned. If a critical integration goes dark, what’s your plan?
The Question I’m Sitting With
I manage platforms where these decisions get made regularly. Installing a third-party app from a marketplace is part of the job. You can’t build every capability in-house, and these ecosystems exist precisely because they extend what the core platform does.
There’s a reasonable optimism here too. Some people argue that AI will eventually be the solution to this problem, that AI-powered security scanning will get fast enough and smart enough to review thousands of apps continuously, closing the gap that manual review cycles leave open. That’s plausible and it’s probably the direction things are heading.
But I find myself thinking about where we are right now. The gap between “passed the marketplace security review” and “safe to connect to your most sensitive enterprise data” was always there. What AI coding tools are doing is potentially widening it, by increasing the volume of apps in these ecosystems and raising the rate of “logic flaws” in the code within them.
The platforms are trying to do their part. The question is whether your governance process accounts for everything the platforms can’t see.
I’m genuinely curious how others are navigating this. Are you adding steps to your app vetting process? Has the rise of AI-built integrations changed how you think about third-party risk in your platform stack?
~ Pete G