Research

4 min read

1,480+ cloud security findings in one startup: field notes

What this is: an honest breakdown of a single real engagement, anonymized at the client's request. This is one company, not a survey, so treat the numbers as a detailed example rather than an industry average. We are sharing it because the shape of what we found is common, even when the exact counts are not.

The headline numbers

In one end-to-end review of a venture-backed technology company's cloud environment, we surfaced:

  • 900+ findings in AWS

  • 580+ findings in GCP

  • 1 active intrusion, detected and contained during the work

  • 100% of endpoints brought under endpoint detection and response by the end

That is more than 1,480 cloud findings in a company that, by every outward measure, was doing fine: a fast-growing product, real customers, and a capable engineering team. What they did not have was a dedicated security hire. That is the point.

Why the numbers get this high

A count in the thousands sounds like negligence. It usually is not. It is drift. As a cloud environment grows, small shortcuts pile up faster than anyone reviews them, and the same handful of categories show up again and again: over-permissioned access, storage that is more open than intended, services exposed to the internet, secrets sitting in code or config, and logging that was never fully switched on. None of these is exotic. Together, across a real environment, they add up quickly.

The detail that was not a number

The most important thing we found was not on the list. During the review, we detected an intrusion that was already underway and contained it. A scanner would have added a line to a report. Finding an active attacker, understanding what they were doing, and shutting it down took people. That gap, between a list of possible issues and an attacker already inside, is the whole reason manual review exists.

The number worth celebrating: 100%

By the end of the engagement, every endpoint was under endpoint detection and response. Endpoint coverage is one of the few security metrics with a clean finish line: you are either watching all of your machines or you are not. Going from partial to full is a concrete, achievable win, and one of the highest-value moves a small team can make.

What a startup should take from this

  • A clean-looking company can still carry hundreds of exposures. The absence of an incident is not evidence of security.

  • Most of the risk sits in a few recurring categories, not clever attacks. Closing the common doors removes most of the exposure.

  • Tools find volume; people find the few things that matter. The contained intrusion here is the proof.

  • You do not need a full-time security team to close this gap. You need someone senior to look, prioritize, and fix.

How we counted

For transparency: one engagement, one company, anonymized at their request, with the sector withheld. We reviewed the AWS and GCP environments end to end, using automated tooling for coverage and manual review for prioritization and exploit paths. A finding is an issue worth investigating, ranked by real risk. It is not the same as a breach. It is something worth looking at before someone else does.

The takeaway

The headline is not that this company was unusually exposed. It is that it looked completely normal and still had more than 1,480 things worth fixing, plus an attacker already inside. If you are growing fast without a dedicated security hire, the honest assumption is that your environment looks similar. The good news is that most of it is closable, and you can find out where you stand in a single review.

Next step

Want to know what your own environment looks like? A free security review will show you where you stand today. Get a free security review.

Want this looked at for real?

Get a free security review and we will show you where you actually stand.