Somebody asked me a simple question a while back: are any of our databases reachable from the public internet?
I said I'd check. Then I sat there for a second realising I didn't actually know how to answer that quickly.
Not because the information is hidden. Because it's scattered across three cloud consoles that each describe exposure differently, and I'd have to go and assemble the answer by hand while the person who asked waited.
Exposure isn't one setting
That's the bit that makes this harder than it sounds.
A resource can be reachable from the internet because it has a public IP. Or because a security group allows inbound from 0.0.0.0/0. Or because a storage bucket has public read enabled at the object level while the bucket itself looks fine. Or because it sits behind a load balancer somebody pointed at the world six months ago.
Four different mechanisms, four different places to look. And that's inside one cloud.
Move across providers and the vocabulary changes too. AWS calls it a security group, Azure calls it a network security group, GCP calls it a firewall rule. Same idea, three different screens, three different filter syntaxes. You can't run one query and be done.
So the honest answer to "are we exposed" is usually "give me an afternoon", and afternoons are exactly what nobody has.
The numbers are worse than I expected
I went looking for how common this is, mostly to work out whether I should feel bad about not knowing.
Research published in March 2026 scanned across AWS, Google Cloud, Azure, DigitalOcean and Alibaba and found 19.6 billion files sitting in 535,480 publicly listable buckets. No login, no exploit. Just open.
The part that stuck with me is the timeline in these cases. A developer sets something public to unblock a test, means to revert it, and doesn't. Within about 72 hours, automated scanners have found and indexed it. The exposure isn't discovered for weeks.
So the window where you could have caught it cheaply is very short, and it closes while everyone is busy with something else.
Asking once, across everything
This is what I use Vörr for now, and it turned an afternoon into a question.
I can search infrastructure resources filtered by exposure, across every connected cloud, in one pass. Not per provider. Not per console. One request, normalised results.
exposure: public
provider: all
category: databaseChange category and the same question covers storage, compute, or load balancers. Drop it entirely and you get everything that's reachable, ranked and grouped, regardless of which cloud it happens to live in.
The reason that matters more than it looks: exposure questions are all-or-nothing. Checking two clouds out of three isn't 66% of an answer. It's not an answer at all, because the thing you missed is exactly the thing that's exposed. Being able to cover everything in one go is the difference between actually knowing and mostly knowing.
The four things I look for
Storage. Buckets and containers with public access. Most common, most likely to hold something sensitive, and the one people assume is already handled because they turned on a block-public-access setting once.
Databases. Managed database instances with a public endpoint. These are almost never intentional. They're usually the leftovers of a connectivity problem somebody solved quickly.
Admin interfaces. Dashboards, management ports, internal APIs sitting behind a security group that allows the world. Jenkins, Grafana, anything with a web UI that was only ever meant to be internal.
Old environments. This is the category I've come to check first. Test and staging resources outlive their purpose constantly, and nobody has ownership of them, so nobody reviews them. A staging database with production-shaped data in it is a real thing that happens.
Temporary is the dangerous word
The pattern behind nearly every one of these is the same, and it's not carelessness.
Someone needs to unblock work. They open something up, deliberately and reasonably, planning to close it after. Then the actual task takes over, the ticket gets closed, and the change stays. There's no alert for it because nothing broke. It works. That's the whole problem.
Which means the only thing that catches it is looking, on a schedule, whether or not you have a reason to.
What I actually do
I run the full sweep weekly. It takes about a minute now, which is the only reason it survives as a habit.
I run it again after any significant infrastructure change, because that's when the temporary rules get added.
And when something new shows up in the results, I try to find out who added it and why before removing it. Half the time there's a legitimate reason and it just needs documenting. The other half, somebody says "oh, that was for testing" and it comes straight down.
The question I couldn't answer that day now takes about as long as asking it. That's most of what I wanted.
Author note
Manjunaathaa, Associate DevOps Development Engineer at Frigga Cloud Labs.
I've noticed that the security work which actually gets done is the work that's quick. Anything that takes an afternoon becomes a thing you'll do next sprint, and next sprint has its own problems. So I've stopped looking for thorough processes and started looking for fast ones I'll genuinely repeat.
If your team runs exposure checks differently, especially anyone who's automated the follow-up rather than just the detection, I'd like to hear about it. LinkedIn.