Most security conversations happen at the code review stage: is input validated, are dependencies patched, does this endpoint leak anything it shouldn't. Those questions matter. But by the time a pull request exists, the most consequential security decision may already be locked in — because it was made in a product requirements document, weeks or months before anyone wrote a line of code.
A team can implement a specification flawlessly and still ship something insecure, if the specification itself was built on a security assumption that stopped being true years ago. Security isn't only a coding problem. Sometimes the vulnerability was designed in on purpose, by people who had no idea they were introducing one.
Take a familiar example: "users must answer security questions to recover their account." An engineering team can build this feature to a genuinely high standard — encrypt the stored answers, rate-limit recovery attempts, log every recovery event, monitor for abuse, protect the API surface end to end. Every one of those controls can pass review and testing. None of it touches the actual question: is the recovery mechanism itself sound? If the "secret" an attacker needs is something they can find in ten minutes of searching, no amount of implementation quality changes the answer.
This isn't hypothetical or dated. NIST's Digital Identity Guidelines — the federal standard that much of the industry treats as a baseline — explicitly prohibit knowledge-based authentication as a recovery or verification mechanism. The reasoning is direct: answers to questions like "what was your first pet's name" or "what city were you born in" are disproportionately available through social media, public records, and the enormous volume of data already sitting in breach dumps. One analysis of the standard's evolution put it plainly: searching a person's name alongside a hometown or school on public sources now surfaces answers to the majority of a typical security-question set — before an attacker has done anything more sophisticated than a search engine query. The problem was never how the answer is stored. It's whether the answer was ever a real secret.
This is where the usual security workflow quietly breaks down. Product defines the requirement, engineering builds it, QA verifies the behavior matches spec, security reviews the implementation, and the feature ships. Every person in that chain can do their job correctly. If the requirement itself encoded an outdated security model, the weakness survives the entire process untouched — because nobody in that pipeline was actually positioned to question whether the feature should exist in its current form. Code review answers "is this implementation safe?" It doesn't answer "is this feature design still considered safe?" — and by the time code review happens, that second question usually isn't on the table anymore.
This is precisely why security guidance can't be treated as something engineering consults during implementation and product teams never see. NIST's guidance on knowledge-based authentication didn't change quietly — it was a documented, public reversal, the kind of update that a security-aware product process should catch automatically, the same way a dependency scanner catches a deprecated package. But a product requirements document written five years ago doesn't get a CVE alert when the security assumptions underneath it expire. Someone has to go looking, and that someone increasingly needs to sit upstream of engineering, not downstream of it.
CISA's Secure by Design pledge — signed by dozens of major software manufacturers — frames this exact shift as an industry-wide priority: security should be treated as a core business requirement embedded during the design phase, not a technical feature bolted on afterward or verified only at the review stage. The pledge's own framing is worth taking literally: products should arrive secure by default, with the expensive, hard-to-reverse decisions about authentication, defaults, and data handling made correctly before a single feature ships — because retrofitting security into a shipped product is a fundamentally different (and more expensive) problem than designing it in from the requirement forward.
Security recommendations aren't static, because the conditions they respond to aren't static. Attackers develop new techniques. Data that used to be private becomes searchable. Platforms add authentication capabilities that didn't exist five years ago — passkeys, hardware security keys, and authenticator apps are all comparatively recent, and standards bodies have moved decisively in their direction while moving decisively away from the mechanisms they replace. A requirement that was defensible when it was written can become the weakest part of a system purely by standing still while the threat landscape and the available tooling both moved on. Treating a requirements document as a one-time artifact, reviewed once at creation and never revisited, guarantees that this drift accumulates silently until an incident forces the conversation nobody scheduled.
The most effective security intervention in a case like this often isn't a pull request at all. It's a product decision: replacing "answer three security questions" with a genuinely strong recovery mechanism — verified email or device-based recovery, an authenticator app, a hardware key — rather than trying to shore up a fundamentally weak mechanism with better encryption and more logging around it. A perfectly implemented version of the wrong design is still the wrong design. Organizations that pour effort into securing the implementation layer while leaving the underlying product decision untouched are optimizing the part of the problem that was never actually broken.
Product teams already treat usability, performance, and scalability as first-class questions asked during design, not bolted on after a feature ships. Security deserves the same standing, asked with the same two-sided framing: not just "can users complete this workflow," but "can attackers abuse this workflow" — asked by the people writing the requirement, not deferred entirely to whoever reviews the code six weeks later. The strongest security teams don't only review implementations. They review the assumptions requirements are built on, and they're willing to ask whether a given approach is still the right one given current guidance, not just whether it was defensible when it was first written down.
A secure implementation cannot compensate for an insecure product decision. That's not a criticism of engineering — a team building exactly what was specified, to a high technical standard, can still inherit a vulnerability that existed before their first commit. The most expensive security failures are rarely caused by careless code. They're caused by building the wrong thing correctly, at scale, for years, because the assumption behind the requirement was never revisited after the world it was written in had already changed.
Password Security Was Never About Complexity — It's About Exposure
Complexity rules check whether a password looks hard to guess. Attackers running credential stuffing don't care how a password is shaped — only whether it's already sitting in a breach dataset.
Multiple Wrongs Do Not Make a Right: Challenging Industry Patterns in Banking Software
"Other banks do it this way" answers is this common, not is this the right control. Two onboarding requirements worth interrogating on their own merits, not on precedent.