Daniel sent us this one — he's asking how a private individual or a small business owner can respectfully ask a cloud service vendor about their security practices, and what technical red flags they should actually look for. The big one he flags is security by obscurity in unauthenticated storage buckets — this idea that a vendor thinks your data is safe just because the URL is hard to guess. There's a real tension here between what a non-technical person can realistically ask and what actually keeps data secure. Where do we even start?
Before we dig into the technical indicators, I want to talk about the asking part — because most small business owners feel completely outgunned walking into this conversation. And they're not wrong. The asymmetry is real. A vendor says "yes, we encrypt your data at rest," and that sounds reassuring. But it's meaningless if the storage bucket is publicly readable.
The encryption is working hard while the door's wide open. It's like locking your filing cabinet and then leaving it on the sidewalk.
And the research backs this up. Tenable's 2025 Cloud Security Risk Report found that 9% of publicly accessible cloud storage buckets contain restricted data. That's nearly one in ten. And CybelAngel's analysis from just this January found that more than half of all buckets they analyzed contained sensitive or personally identifiable information. We're not talking about theoretical risks here.
The first thing Daniel's asking is how to even open this conversation without sounding accusatory or — and I think this is key — without revealing that you don't know what you're talking about and getting handed a reassuring non-answer.
The answer, interestingly, is structure. There are industry-standard frameworks that exist specifically for this. The Cloud Security Alliance has something called the Consensus Assessments Initiative Questionnaire — the C. — and the Shared Assessments Program has the Standardized Information Gathering questionnaire, or S. These are designed for enterprise vendor risk management, but a small business can adapt them down to maybe twenty to fifty questions, depending on how critical the vendor is.
Twenty to fifty questions still sounds like a lot for someone running a five-person shop.
It does, but you don't need all of them. The key domains — and this comes from Anchor Cyber Security's S. checklist from last June — are really seven buckets. Vendor background and stability. Data handling and storage — that's your encryption at rest, encryption in transit, where the data lives geographically. Security practices — are they enforcing multi-factor authentication, are they doing vulnerability scanning and penetration testing. Compliance and privacy — do they have a Data Processing Agreement, are they handling G. properly if that applies. Incident response and breach notification timelines. Business continuity and disaster recovery. And subprocessors — who else are they sharing your data with?
That subprocessor one is sneaky. You can vet the vendor and then find out they're handing everything off to some third party you've never heard of.
That's explicitly a red flag in the Anchor Cyber Security guidance. If a vendor is vague about subprocessors or won't give you a clear list, that should prompt escalation or walking away.
Walk me through the actual conversation. I'm a small business owner. I've signed up for some cloud accounting platform or customer management tool. I send them an email. What do I actually say?
The most effective opener is disarmingly simple. You say something like, "We're reviewing our vendor security practices as part of our internal due diligence — can you point me to your security documentation or trust page?" That's it. You're not interrogating them. You're framing it as your own process. And their response tells you a lot right there.
A vendor with a mature security program will have a publicly accessible trust page, a security white paper, maybe a SOC Two Type Two report available under N. They'll respond within a day or two with clear links and an offer to answer follow-ups. A vendor that gets evasive, takes two weeks, sends you a paragraph of vague reassurances — that's your red flag right there, before you've even asked a technical question.
This is where I think the "respectful" part of Daniel's question matters. You're not demanding a full security audit as a small customer. You're asking what they already have. If they have nothing, that's useful information. If they have a lot and they're transparent about it, that's also useful.
Now, once you're in that conversation, you want to move beyond yes-or-no questions. "Do you encrypt data at rest" is a yes-or-no. The better question is, "Can you describe your encryption key management practices, and who has access to the keys?" Or instead of "Do you have access controls," you ask, "Can you walk me through how you ensure that only authenticated users can access customer data?" The second question catches the bucket problem. The first one doesn't.
Let's talk about that bucket problem directly, because this is the core technical red flag Daniel's asking about. Security by obscurity in unauthenticated storage. What does that actually look like in practice?
Imagine a vendor stores your uploaded documents in an Amazon S Three bucket, or an Azure Blob Storage container, or a Google Cloud Storage bucket. The correct way to do this is to require authentication — every request for a file has to come with credentials that prove you're allowed to access it. The wrong way is to leave the bucket publicly accessible and just hope nobody finds the U.
is something like — I'm making this up — ess three dot amazonaws dot com slash customer dash uploads dash seven three eight two nine?
That's exactly the kind of thing. The vendor thinks, well, nobody could possibly guess that string. And they're wrong. There are open-source tools — S Three Scanner, BucketLoot, Slurp — that systematically scan for open buckets across all the major cloud providers. No credentials needed. You just point the tool at a target and it finds exposed buckets.
It's not just targeted attacks. There are services that index this stuff.
GrayhatWarfare indexes publicly accessible S Three buckets and lets anyone search by filename for about twenty-five dollars a month. CybelAngel's January report highlighted this specifically. And here's the thing that should keep vendors up at night — even buckets that don't allow directory listing can be brute-forced. If the bucket is private but has predictable filenames — backup dot zip, credentials dot jason, index dot html — attackers can just guess. GrayhatWarfare found that about ten percent of supposedly private buckets have an exposed index dot html that acts as a breadcrumb.
The obscurity isn't just weak protection — it's practically no protection. And we're seeing the scale of this now.
The numbers are staggering. According to Cybernews reporting cited by S. World, over six hundred sixty thousand misconfigured buckets across major cloud providers are leaking an estimated two hundred billion files. Two hundred billion. And cloud-conscious intrusions jumped thirty-seven percent year over year in 2025.
The average detection time for these configuration issues exceeds one hundred eighty days, according to CybelAngel. So a bucket gets misconfigured in January, and nobody notices until July. That's half a year of your data sitting exposed.
There's another dimension here that I think is underappreciated — abandoned buckets. Researchers from watchTowr published work on this that The Record covered. Leftover buckets from old projects or test environments stay online and accessible indefinitely. Sometimes they're still receiving millions of requests. And attackers can actually hijack these abandoned buckets for malware delivery. The vendor moved on, but the infrastructure didn't.
You've got actively misconfigured buckets, you've got abandoned buckets, and then you've got what Microsoft calls "blob hunting" — which is a named threat vector now. What's that?
Blob hunting specifically targets Azure Blob Storage containers that allow unauthenticated public access. Attackers guess container U. s and exfiltrate data. Microsoft Defender for Cloud explicitly flags unusual unauthenticated reads on typically private accounts as a signal of potential compromise. This isn't a fringe thing — it's in Microsoft's official threat detection documentation.
If I'm that small business owner and I'm trying to assess a vendor, what specific question do I ask to surface whether they're relying on security by obscurity?
You ask, "Do you enforce authentication on every request to access customer data, and can you describe how that enforcement works?" If they hesitate, if they say something about "our U. s are complex," if they mention that files are "unlisted" but not authenticated — that's your smoking gun.
"Unlisted" is a great word to watch for. It sounds technical. It means nothing.
It means "we're hoping nobody looks." And the tools to look are getting better every month.
Let's talk about the certification question, because I think there's a trap here. A lot of small business owners hear "we're SOC Two compliant" or "we have ISO twenty-seven thousand one certification" and they stop asking questions. Is that enough?
It's not, and this is one of the most important things to understand. A SOC Two Type Two report or an ISO twenty-seven thousand one certificate is valuable — I don't want to dismiss it. SOC Two Type Two is particularly useful because it covers operating effectiveness over time, not just a point-in-time design review. ISO twenty-seven thousand one is broader and internationally recognized. If a vendor has both, that's a genuinely strong signal.
There's a but.
These are point-in-time audits. A vendor could pass their SOC Two audit in March, and in April a developer spins up a test bucket with real customer data and leaves it public. The certification doesn't catch that. The gap between compliance and actual security is where a lot of breaches happen.
This connects to something Google Cloud reported. Their threat horizons report for the first half of this year — so the first half of 2026 — found that weak or absent credentials accounted for forty-seven point one percent of observed cloud security incidents. That's nearly half. Misconfigurations specifically were twenty-nine point four percent. And Gartner projects that ninety-nine percent of cloud security failures through this year will be the customer's fault — meaning the cloud user, not the provider.
Which brings us to the shared responsibility trap. , Azure, Google Cloud — they've all shifted toward secure-by-default settings in recent years. But legacy configurations persist, and human error hasn't gone anywhere. The cloud provider might be perfectly secure. The vendor's use of the cloud might not be. And your contract is with the vendor, not with A.
The question isn't just "are you certified." It's "how do you continuously monitor your cloud configuration, and can you demonstrate that?
This is where tools like UpGuard's security ratings come in. Gartner has predicted that cybersecurity ratings will become as important as credit ratings for business relationships. The idea is you get an independent, real-time assessment of a vendor's external security posture. It catches risks that emerge between assessment cycles. A questionnaire captures a snapshot. Continuous monitoring catches the bucket that got opened last Tuesday.
For a small business, though, subscribing to a security ratings service might be overkill. What's the lightweight version?
The lightweight version is asking the vendor directly: "Do you have continuous cloud security posture management in place? How do you detect misconfigurations in real time?" A vendor who can answer that coherently is probably doing the right things. A vendor who looks confused probably isn't.
If you want to go a step further, you can ask for their most recent penetration test summary. Not the full report — that might be sensitive — but a summary of findings and remediation. A vendor that's never pen-tested their application is a vendor that's not taking security seriously.
There's a related point that I think gets overlooked. Bug bounty programs. If a vendor has a public bug bounty program — through HackerOne or Bugcrowd or even just a security at company dot com email address — that's a green flag. It means they're inviting scrutiny. They're not hiding behind obscurity.
The opposite of security by obscurity is security by transparency. You want the vendor who says, "Here's how we handle your data, here's who has access, here's our incident response plan, and please tell us if you find something wrong.
That transparency should extend to breach notification. The Anchor Cyber Security checklist specifically flags unclear breach notification plans as a red flag. You want to know, in writing, how quickly they'll tell you if something goes wrong. Forty-eight hours? If they won't commit to a timeline, walk away.
Let's pull this together into something practical. If I'm a small business owner and I've got a cloud vendor I'm evaluating, what's my actual playbook?
Step one — send the respectful email. "We're doing our vendor security review. Can you point me to your security documentation?" See how they respond. Step two — once you have documentation, look for specific evidence. A SOC Two Type Two report, an ISO twenty-seven thousand one certificate, a penetration test summary, a Data Processing Agreement. Step three — ask the authentication question. "Do you enforce authentication on every request to access customer data?" Step four — ask about continuous monitoring. "How do you detect cloud misconfigurations in real time?" Step five — ask about breach notification. "What's your commitment on notifying customers if there's a breach?
If at any point they're vague, evasive, or start talking about how their U. s are really complicated — that's your answer.
That's your answer. And here's the thing — none of these questions are aggressive. None of them require deep technical expertise to ask. You're not auditing their infrastructure. You're asking them to describe their own practices. A vendor with good practices will be happy to answer. A vendor without them will resist.
The cost of not asking? CybelAngel found that the average enterprise has over three thousand misconfigured cloud assets at any given time. That's the enterprise number — but the small business vendors are often worse, because they have fewer resources dedicated to security. The asymmetry cuts both ways. Small vendors are more likely to have gaps, and small customers are less likely to ask about them.
There's one more angle I want to touch on. Daniel mentioned "security by obscurity in unauthenticated storage buckets" specifically in his prompt. I think it's worth being really concrete about what that looks like from the attacker's perspective, because it helps understand why it's such a critical red flag.
Walk me through it.
An attacker wants to find exposed data. They fire up a tool like S Three Scanner. They configure it to scan a range of I. addresses or a specific domain. The tool sends requests to potential bucket U. s — it's trying variations of names, common keywords, anything that might match. When it finds a bucket that responds with a directory listing, jackpot — they can see every file. When it finds a bucket that doesn't allow listing but also doesn't require authentication, they switch to brute force. They try common filenames. Backup dot zip. Database dot sql. Config dot yaml. Credentials dot jason. And because humans are predictable, these filenames work often enough to be worth the effort.
This is all automated. Nobody's sitting there typing U. s one at a time.
A single attacker can scan thousands of buckets in an hour. And once they find something interesting, they can exfiltrate the data in minutes. The victim never knows, because there's no authentication log to check — nobody was supposed to be authenticating in the first place.
The obscurity isn't a lock. It's not even a closed door. It's a curtain, and there are machines systematically pulling back every curtain they can find.
And the tools keep improving. GrayhatWarfare now indexes these things and makes them searchable. You can literally search by filename across millions of exposed buckets for a modest monthly fee. That's not nation-state-level capability. That's available to anyone with a credit card.
Which brings us back to the core advice. If you're a small business or an individual entrusting data to a cloud vendor, you don't need to become a security expert. You need to ask the right questions, and you need to recognize when the answers aren't good enough. "We encrypt everything" isn't good enough if the bucket is public. "We're SOC Two certified" isn't good enough if they opened a test bucket last week. s are complex" is never, ever good enough.
I'll add — document everything. If a vendor tells you in writing that they enforce authentication on all customer data requests, and then there's a breach because they didn't, that email matters. It won't prevent the breach, but it establishes that you did your due diligence and they misrepresented their security posture.
There's a practical point there too. Some vendors will be more careful with their written answers than their verbal ones. Asking in writing is itself a form of pressure.
And it creates a record. For a small business, that record can be the difference between "we had no idea" and "we asked, and here's what they told us.
Daniel's question — how to ask respectfully, and what to look for — I think the answer is that respect and rigor aren't in tension here. The respectful approach is the structured one. You're not accusing them of anything. You're saying, "We take our data seriously, and we want to work with vendors who do the same." A good vendor will respect that. A bad vendor will reveal themselves.
Now: Hilbert's daily fun fact.
Wait, I'm doing it this time. And now: Hilbert's daily fun fact. The collective noun for a group of porcupines is a prickle.
What can listeners actually do with all this? Let's make it concrete. First, if you're evaluating a new vendor right now, send that email today. "We're reviewing our vendor security — can you point me to your security documentation?" It's one sentence. You'll learn something from the response no matter what.
Second, if you're already using cloud services, check what you can find publicly. Search for the vendor's name plus "security" or "trust center." See if they have a published SOC Two report or security white paper. The absence of public documentation isn't necessarily a dealbreaker, but it's worth asking about.
Third, when you're reviewing a vendor's security claims, look past the buzzwords. "Enterprise-grade encryption" means nothing without key management details. "Secure infrastructure" means nothing without authentication enforcement. Ask the follow-up question.
Fourth, if you're a small vendor yourself — and some of our listeners probably are — audit your own cloud storage configuration. Check whether any of your buckets are publicly accessible. Check whether authentication is enforced on every request. The tools to do this are built into A. , Azure, and Google Cloud consoles now. It's an afternoon of work that could prevent a catastrophic breach.
Fifth, build this into your vendor review process going forward. Before you sign up for any service that will handle customer data, employee data, financial data — ask the five questions. Security documentation, authentication enforcement, continuous monitoring, breach notification, subprocessors. Make it routine. It takes fifteen minutes and it signals to vendors that their customers care about this stuff.
One forward-looking thought. We're seeing a shift in the industry toward secure-by-default cloud configurations, and the major providers are making it harder to accidentally expose data. But the attack surface is also growing — more services, more buckets, more configurations to manage. The gap between "the cloud is secure" and "your particular use of the cloud is secure" is where the risk lives. And that gap isn't closing on its own.
Thanks to our producer Hilbert Flumingtop for keeping this show running, and to Daniel for the prompt. This has been My Weird Prompts. If you want more episodes like this one, head to myweirdprompts dot com.
We'll be back with a new one soon.
