Security is Everyone’s Lock – not just the guard at the gate
The Building We All Live In
Picture an apartment building. It has a security guard at the entrance, a lock on every apartment door, and inside some of those apartments — a safe bolted to the floor, locked with a combination only a few people know.
Three layers. All interdependent. None of them sufficient alone.
Now swap the building for your mobile app. The analogy holds — almost perfectly.
LAYER 1 · ORGANISATION
The security guard & boundary wall
The guard checks everyone who enters the building. They log arrivals and departures, keep the main doors locked after hours, and form the first perimeter everyone benefits from — regardless of which floor they’re on.
In your org, this is the platform security team: firewalls, WAF rules, network monitoring, SSO, and penetration testing. They protect every team, every system, every line of code behind that wall.
LAYER 2 · TEAM
Your apartment door & peephole
You still lock your own door. You check the peephole before opening it, because you know exactly who your visitors are — the guard downstairs does not.
Your team owns this layer: API authentication, role-based access controls, input validation, dependency audits, and code review gates. You have the closest context about what belongs inside your service and what doesn’t. Use it.
LAYER 3 · THE SAFE
The locked safe inside the apartment
Not everything inside the apartment is left on the kitchen table. The most sensitive things — documents, valuables, things that would cause real damage if lost — go in the safe. Only specific, trusted family members know the combination, and they’re expected to lock it again after use.
In software, this is your data layer: encrypted PII, secrets in a vault, API keys managed through a secrets manager, and sensitive operations gated behind strict authorisation checks. The safe doesn’t care that the building guard is reliable. It stays locked regardless.
The core insight: each layer assumes the one above it will sometimes fail. The safe doesn’t rely on the apartment door. The apartment door doesn’t rely on the guard. This is defence in depth — and it only works when every layer is maintained by someone who cares.
Extending the Analogy
The intercom system – THIRD-PARTY SDKS
A delivery person buzzes from downstairs. The guard let them into the lobby — but you still check the intercom before opening your door.
Every SDK or library you import has been “let into the building” by the ecosystem, but that doesn’t make it trustworthy inside your apartment. Vet your dependencies. Know what you’re importing, what permissions it requests, and when it was last updated.
The building notice board – SECURITY POLICY
Most buildings post rules in the lobby: don’t prop the fire door, don’t share your fob. Nobody enforces these 24/7 — but residents are expected to follow them because they understand why they exist.
Security policies, threat models, and secure coding standards work the same way. They’re only effective when engineers have internalised the reasoning, not just seen the checklist.
Your neighbours – OTHER TEAMS
If your neighbour props their door open every night, the whole floor is at risk.
A team with visible secrets or ignored Common Vulnerabilities and Exposures is a lateral movement opportunity. Security isn’t isolated to your service — a breach next door can easily become your incident. Care about what the teams around you are doing, and let them care about what you’re doing too.
The building inspector – SECURITY AUDITS
Once a year, a professional walks through with fresh eyes — finds the fire exit that’s been blocked, the lock that hasn’t been replaced.
Penetration testers and security audits serve this role. They’re not a sign that something is wrong; they’re a sign that you’re serious about finding out before someone else does.
Moving in and out – ACCESS LIFECYCLE
New tenants get keys — specific keys, not the master. When they leave, the locks get changed. Access provisioning and offboarding are exactly this.
Forgetting to revoke permissions when someone leaves the team is the equivalent of a former tenant still being able to walk into your apartment. It happens. It shouldn’t.
The master key – ADMIN CREDENTIALS
The superintendent holds a master key to every unit. It’s locked in a safe, signed out with a log, and never duplicated casually.
Production access, root credentials, and signing keys deserve exactly this treatment — minimal holders, full audit trails, and zero exceptions for convenience.
Security is a habit, not a handoff
The most dangerous assumption in any team is that security belongs to someone else — the platform team, the AppSec squad, the compliance officer. The guard downstairs is real and they’re doing their job well. But they cannot be in your apartment. They cannot see what you’re storing or who you’re letting in.
Every engineer — whether you’re writing your first feature or your thousandth — is a resident in this building. You lock your door. You know your visitors. You keep the safe shut.
The building is only as secure as the habits of the people who live in it.
