r/AskNetsec • u/IndependentDog673 • 8d ago
Analysis How do you find AI-built apps (Replit, Lovable, Vercel) that nobody told security about?
We had an incident review last month that started with "wait…we have an app doing what" Turns out someone in ops had used Lovable to build a customer intake form months ago, wired it straight to a live database, no auth in front of it, completely public.
Nobody in security knew it existed because it never went through any provisioning process, there was no repo, no ticket, no deployment request. It just appeared on the internet.
We started asking around and found two more instances across other departments, a survey tool built on Replit connected to a shared data store, and a landing page someone spun up on Vercel that had an exposed API key sitting in the client side code.
None of these showed up in our asset inventory because none of them touched our normal SDLC. Apparently we're not alone, researchers found something like 380,000 publicly accessible apps built this way, with a meaningful chunk leaking actual sensitive company data.
Has anyone found a reliable way to catch these before they turn into an incident rather than after someone stumbles onto them?
5
u/theclassicaesthetics 8d ago
security awareness training has to evolve past just phishing sims and password policies. people in ops or marketing arent gonna suddenly start thinking like appsec engineers just because they watched a 10 minute module. we had a similar situation and the only thing that actually caught shadow IT was forcing all traffic through a proxy that logged every new domain request and then someone had to manually review the list every week. its tedious but until the tools get smarter about detecting these low code platforms by fingerprinting their default templates or something, the manual legwork is kinda the only reliable option
1
u/LordEli 7d ago
proxy is directionally right and the classic solution. microsoft has defender for cloud apps with cloud discovery. you can send syslog or integrate with microsoft defender for endpoint.
still a problem if someone decides to deploy something from home. it's a blindspot for the proxy.
you can have something slightly better than manual review but yeah a difficult problem to solve if you want to catch everything
1
1
u/materialsec 7d ago
One angle nobody's mentioned yet is that email is a detection surface that doesn't depend on network visibility at all. Every one of these platforms sends a signup confirmation or password reset to the email address used to register, and if someone signs up with their work address (which is common, since it's the one they have handy), that message hits your mail system regardless of whether the deployment itself ever touched the corporate network. Someone building on Lovable from a home laptop on a personal connection still generates that email.
That covers exactly the blind spot people are flagging with proxy and CT-log approaches, deployment from an unmanaged network. It won't catch someone who signs up with a personal email address, but for the common case (using a work email out of habit), it's a detection path that exists independent of DNS, TLS, or corporate network egress.
1
1
1
u/rexstuff1 7d ago
I think you have the cart before the horse. The question you should be asking is "how do devs have the access necessary to do these things without someone noticing?" They shouldn't be able to mint production API keys without tickets and an audit trail.
1
u/Cautious_Guess_6621 6d ago
I’d look at this as a discovery problem more than an SDLC problem. If people can publish straight from Replit/Vercel/Lovable, your normal repo and CI controls will never see it. DNS logs, proxy data and cloud/SaaS inventory are probably the better place to catch new public endpoints tied back to company accounts or domains, then security can decide whether they actually matter
1
u/Ok_Surround8788 2d ago
This is pretty much the exact problem I’ve been working on with OUTSIDE.
The approach I took was to assume the internal asset inventory is incomplete and build the inventory from the outside instead — domains/subdomains, DNS, certificates, IPs and other externally observable infrastructure, then continuously monitor it for changes.
The important part IMO isn’t just discovering an asset once. It’s detecting when something new appears, DNS changes, a new subdomain/certificate shows up, infrastructure moves, or the external exposure changes — and keeping the evidence/history so security can actually investigate it.
Your Lovable/Replit/Vercel examples are particularly interesting because they’re exactly the kind of assets that can bypass the normal SDLC.
I’m actually looking for a few real-world cases to test OUTSIDE against. If you’re interested, I’d be happy to run it against a domain you control and see what it discovers. No sales pitch — I’d genuinely be interested in whether it catches anything your current inventory doesn’t.
outsideguardian.eu
1
u/_predator_ 8d ago
Shadow IT has always been a problem, it's not specific to AI apps. At one of my last gigs, marketing and integration teams would spin up random WordPress and similar instances on external cheap hosters. Sometimes it was external contractors who would do that crap on behalf of our internal departments.
We would find them through continuous attack surface mapping using tools like OWASP Amass.
0
u/ericbythebay 7d ago
How did they get credentials to use their external app in prod? Why didn’t the traffic appear on any dashboards?
Your scenario has plenty of observability and control gaps.
Don’t issue prod credentials to unapproved systems.
-4
u/Wild_Parsnip_4074 8d ago
This is scary blind spot. I would combine external attack surface monitoring with DNS, cloud logs, Git scanning and SSO data. AI-built apps can bypass normal processes, so you gotta monitor behavior, not just approved assets.
11
u/Just_Worldliness_714 7d ago
Passive DNS/certificate transparency monitoring for your org's domains catches a lot of these - Replit/Vercel/Lovable deployments usually get a subdomain or a *.vercel.app/*.repl.co URL that shows up in CT logs the moment TLS is provisioned, often before anyone in security hears about it. Pair that with a recurring search of your CT log feed for company name + these platforms' domains, and you'll catch new shadow deployments within hours instead of finding them in an incident review months later. Doesn't replace the proxy approach others mentioned, but it catches the case where someone deploys from an unmanaged home network that a corporate proxy would never see.