I've written all year about checking your own code for exposed keys yourself. Worth noting that some hosting platforms have quietly built their own layer of protection for exactly this, and it's useful to understand what that layer actually covers before assuming it's handling the whole problem for you.
What this kind of platform-level scanning actually does
Vercel, for instance, has GitHub-integrated secret scanning that can automatically revoke exposed API credentials tied to its own platform when they're detected in a repository. By its own account, this kind of pre-deployment scanning has blocked well over 100,000 insecure deployments in total, including a large batch in a single month last year. That's a meaningful, real backstop operating quietly in the background for a lot of projects deployed through platforms with this kind of feature.
Why this is genuinely useful, and also easy to over-trust
A scan like this catches a specific, valuable category: credentials tied to the platform's own services, in a format the scanner recognizes, committed somewhere the scan actually looks. That's real coverage, and it's exactly the kind of automatic, no-effort-required protection that actually moves the needle, the same pattern I've praised in Lovable's and Bolt's publish-time scans.
It's also worth being precise about the edges of that coverage. A platform-level scan focused on its own service's credentials has no particular reason to catch a key for an unrelated third-party service, a payment processor, an email provider, an AI model API, unless it's specifically built to recognize that pattern too. And a scan looking at what gets deployed doesn't necessarily catch a key that ended up in your frontend bundle, shipped correctly through the deployment process, syntactically valid, just sitting somewhere the browser can read it, which is a different failure mode from a raw secret being caught in transit.
What's actually worth doing regardless of what your platform catches automatically
- Check what your specific hosting platform's scanning actually covers. Read the documentation rather than assuming a general reputation for being secure means every category of leak is caught.
- Continue running your own checks: searching your repo and your deployed frontend bundle for anything that looks like a key, the practice I've recommended since January.
- Treat any platform-level catch as a helpful backstop, not a reason to skip your own review. It's one more layer, not a replacement for the layers you control directly.
- Remember that a scan catching a raw leaked secret and a key intentionally, correctly placed somewhere insecure, like frontend code, are different problems, and platform scanning is much more reliably built for the first one.
This is a genuinely good trend, more of the infrastructure builders rely on quietly catching a real category of mistake automatically. It's still one layer among several, and understanding exactly what it covers is more useful than assuming a well-known platform means the whole problem is handled somewhere you don't have to think about.