Work Hours
Monday to Friday: 10.00 - 19.00
Most security incidents do not begin with a sophisticated attack. They begin with something ordinary. A credential committed three years ago. A staging environment that no one decommissioned. An endpoint that used to belong to a team that no longer exists. The exposure was always there. It just stopped being looked at.
When a team is small, the surface is small enough to hold in your head. The same engineer who wrote the deploy script also remembers the test bucket used to debug a webhook in 2022. Knowledge and ownership live in the same place. As the team grows, that breaks. New people inherit systems whose history they did not see. People who leave take context with them that was never written down. The surface keeps expanding. The mental map does not.
What the hidden surface actually looks like
It is rarely exotic. The same patterns repeat across teams of every size.
Credentials in old commits. A developer pastes an API key into a config file, notices the mistake, removes it, and commits the fix. The key is still in the history. Rotating it solves the problem. Deleting the file does not. Years later, the repo is open-sourced, or an engineer’s laptop is breached, or a vendor reads through history during an integration. The key is still there, intact, untouched by any of the controls layered on top of it.
Abandoned environments. A team stands up a staging cluster for a launch. The launch happens. The cluster keeps running because no one is sure who owns the shutdown. A year later, it is still reachable, still running an old build, still trusted by the rest of the network because that was the original design.
Public endpoints with no current owner. A subdomain points to a service that was migrated. The service moved. The DNS record did not. A new tenant takes the IP. Now, an attacker has a hostname your customers trust pointing at infrastructure your team no longer controls.
Forgotten internal tools. An admin dashboard built for a quick problem in year one. It still works. It still has wide privileges. The person who built it now leads a different team.
None of these requires sophistication. They require time. They require the team to have stopped paying attention to a thing that is still there.
Residual infrastructure rarely disappears cleanly.
The reason this happens is structural
When something breaks in production, ownership is usually clear within minutes: a service has an on-call rotation, a runbook, a Slack channel. When something simply exists, ownership decays quietly. There is no alert. Nothing fires. The thing keeps doing what it was originally set up to do, long after the people who set it up have moved on.
As a result, a quiet drift opens up between what your team thinks is in scope and what is actually exposed. Scaling teams tend to accumulate this drift faster than they prune it because growth introduces new systems faster than it retires old ones. Every reorganisation, every acquisition, every “let’s just try this for the quarter” leaves a small residue.
This is why most exposure is usually an ownership problem before it becomes a tooling problem. You can run every scanner on the market against a surface you have already forgotten about. It will scan only the part you remembered to point it at.
Starting with ownership, not tools
Before reaching for anything new, the more useful exercise is to ask: for each domain you own, each repository, each environment, each public endpoint, who would notice if it were behaving strangely tomorrow?
If the answer is no one, you have found a piece of the hidden surface. The fix is not a scan. The fix is a decision. Keep it and assign it, or take it down.
Once that question has an answer, scanning becomes useful because there is now someone for the findings to go to. Findings without an owner sit in dashboards. Findings with an owner become work. Controls only protect things the team still remembers are there. That was really the point behind last month’s piece on layered control.
A second principle helps: treat history as part of the surface. Most teams scan their current state and stop there. But commit history, old container images, retired environments, and archived buckets are all still reachable. They are still part of what an attacker sees.
The OWASP Top 10 has covered injection and broken access control for a decade. What changes year on year is how teams’ own past keeps becoming their present problem. The GitGuardian state of secrets reporting consistently finds that most leaked credentials discovered in any given year were committed in earlier ones. Most teams discover the exposure long after it became reachable.
Where to start checking
Two narrow places help.
Commit history is the first. Humans cannot reliably search every branch and every author across years of a repository. Teams need a way to search historical exposure beyond what manual review can realistically support. What matters is that history stops being invisible.
The public-facing surface is the second. Web Security Auditor fills the equivalent role here. It is a way to see what is actually reachable from the outside and compare it to what your team thinks is reachable. The gap between those two is usually where the surprises live.
Neither replaces the question of who owns what they reveal.
What changes when teams treat this seriously
The teams who handle this well do not have fewer findings. They have findings that get closed. They have inventories that match reality. They keep a rhythm where things that exist either have owners or get retired, and where history is treated as something you still have to defend.
The National Cyber Security Centre guidance on managing external attack surface makes the same point in a more institutional voice. The surface you do not know about is the one that hurts you. This is usually where our security and compliance work begins.
Finding the surface is usually easier than deciding who still owns it.