In the Marines we called it mission creep.
You deploy with an objective, rules of engagement, and a fixed set of resources. Then somebody up the chain decides the mission should also cover this other thing. Same people. Same gear. Same clock. Nobody says no, because saying no sounds like you are not up to it. So you spread out, and thin, and the gaps that open up are not on anyone's slide deck.
That is the part that stays with me. The failure never announced itself when the scope changed. It announced itself later, somewhere nobody was looking.
Software does exactly the same thing, and I have watched it happen on projects I was responsible for.
The pattern
A project starts clean. Defined objective, a real scope, security requirements someone actually thought about. Then: "while we're in there, can we also add..."
One feature. Then another. Nobody re-opens the threat model, because re-opening the threat model is not a ticket anyone gets credit for closing.
Six months on you have a system with parts nobody fully understands, authentication that got bolted on somewhere in month three, and an attack surface that grew four times over while the security budget stayed flat.
None of that was a decision. That is what makes it dangerous. Every individual step was reasonable.
What actually goes wrong
Security stops being designed and starts being retrofitted. When auth is not in the plan, features get built assuming login shows up later. Then it does show up, and it has to accommodate everything already built around its absence. You do not weld armor onto a vehicle after it has been shot at. You build the mission around the protection you have.
Shortcuts become permanent. Hardcoded credentials that were "just for testing." Certificate validation switched off to unblock someone on a Friday. A permissive CORS policy nobody revisited. I have never once seen a team come back and fix these on their own. They are found by an attacker, or by an auditor, or by nobody at all until it matters.
Nobody can draw the system anymore. This is the one that scares me most, because it is measurable. Ask your team to draw the whole thing on a whiteboard. If three people draw three different pictures, you have an attack surface nobody owns: a forgotten admin endpoint, an integration that quietly carries more trust than anyone intended, a dependency installed for a spike two years ago that is still in the build.
Testing gets left at the old scope. The test plan was written for the original system. The features tripled. That untested integration point is not a quality problem. It is where the vulnerability lives.
The part project managers own
I want to be careful here, because this usually gets framed as engineers being sloppy. In my experience it is more often that nobody gave anyone room to say no.
If you own scope, you own risk. Every feature added is attack surface added, and if the time and the security budget do not move with the scope, you did not add a feature. You added exposure and hid the cost.
The most useful thing a PM can do is make the trade visible. Not "can we fit this in," but "what does this cost us to secure, and are we paying it." Sometimes the honest answer is that you cannot afford to build it, because you cannot afford to test it.
And when an engineer tells you something is not secure, that is not obstruction. That is the cheapest warning you will ever get.
What I actually do now
Not a framework. Four habits.
I write the threat model before the first line of code, and I treat it as a living document rather than a deliverable. Every scope change gets one question asked out loud: what does this change about who can reach what? If the architecture cannot answer that safely, there are only two options, refactor and pay for it, or decline the feature. There is no third option where you add it anyway and hope.
I keep a security backlog that is visible to everyone, including the people who set the deadlines. Everything cut for speed goes on it. If that list only ever grows, that is not a backlog. That is an incident with a delay on it.
And I re-draw the architecture on a regular cadence, by hand, from memory. Not because the diagram matters. Because finding out I cannot draw it is the earliest possible warning.
Discipline is the whole thing
Mission discipline in the field is not about being rigid. It is about knowing what you can actually sustain with what you have, and being willing to say so before you are stretched past it.
Scope discipline is the same skill in a different uniform.
An attacker does not care about your launch date. They do not need a sophisticated exploit if you left them a forgotten admin panel from a feature request in Q2. They will find the seam you stopped tracking, and they will be patient about it.
You can plan for security now, or you can explain the breach later. Both cost time. Only one of them is on your schedule.