Every mature security program eventually produces a number. A percentage of controls implemented, a maturity level, a risk rating that trends the right way each quarter. Executives like the number because it fits on a slide, and auditors like it because it maps to a framework. I've spent a good part of my career producing those numbers, and I'll defend them: they are how a large organization proves to itself that the basics are actually done, at scale, across teams that will never meet.
But I've watched enough incidents to know an uncomfortable thing. The score and the breach rarely live in the same place.
A control rubric is a list. Is encryption enabled here. Is MFA enforced there. Is this dependency patched, that bucket private, this access reviewed. Each row is a real question with a real answer, and a program that answers all of them honestly is far safer than one that doesn't. None of what follows is an argument against doing that work.
The limit is structural. A list measures the parts in isolation. It has a row for the database and a row for the service and a row for the identity provider. It does not have a row for the way those three things behave together at 2 a.m. under a request nobody designed for. The rubric sees the nodes. The attacker sees the edges.
A rubric measures the parts. An attack travels the connections between them - and the connections are what no one owns.
Real intrusions are usually not a failed control. They're a chain of things that were each, individually, fine. A low-severity service with a legitimate token. A trust relationship that made sense when it was created. A default that was reasonable in isolation. Each link passes its row on the checklist. The path through them was never a row at all, because no one wrote a rubric for the specific, improbable order in which they connect.
That's why the attacker's advantage is asymmetric. Defense has to make the aggregate look good - a high score across thousands of items. An attacker only has to find the one sequence the aggregate didn't model. Averages hide outliers, and the outlier is exactly where they live.
Building security in from the start is the highest-leverage thing a program can do. A secure default protects everyone downstream who never reads the guideline, and it's the closest we get to fixing a class of problems instead of an instance. I've built those defaults and I'd build them again.
But secure-by-design still designs for the system you can see. It hardens the components and the interfaces you drew on the diagram. The connective tissue - the emergent behavior of many correct components composed in a way the diagram never quite captured - is not something you can stamp at design time, because it doesn't exist until the parts are running together in production, under real load, with real credentials, next to systems built by other teams to other assumptions.
You don't throw out the score. You stop mistaking it for safety - and you spend real effort in the places it can't reach.
Measure paths, not just parts. The most useful security exercise I know is not another control audit; it's tracing how an attacker would actually move - from a foothold, through the trust relationships, to something that matters. Attack-path analysis finds the edges a checklist can't have a row for. Do it against the running system, not the diagram.
Assign the seams an owner. Most organizations have clear owners for components and no owner for the space between them. The identity team owns identity; the platform team owns the platform; nobody owns what happens when a platform workload assumes an over-broad identity role that was granted for a reason everyone has since forgotten. Name an owner for the connective fabric, or it stays everyone's problem, which means no one's.
Run continuously, not quarterly. The system changes every day; the rubric is scored every quarter. That gap is where drift lives. The closer detection, review, and correction get to the speed of change, the smaller the window in which an unmodeled path can sit open unnoticed.
The score still matters. It tells you the parts were built and measured, which is not nothing - it's most of the work, and it's the part that scales. Just don't confuse a clean scorecard with an absence of paths through the terrain. The comfort is real. So is the ground the comfort doesn't cover, and that's usually where the breach lives.