The later you find it, the more it costs — from x1 in requirements to a mean of about x250 once the system is in operations, which is why rework and bug-fixing can swallow up to half a project's effort.

* The multipliers on a log scale: the range per phase, with the mean joining them up. *

A defect found while the requirements are still being written costs one conversation. The same defect found in production has to be unwound from every decision that was built on top of it — the design that assumed it, the code that implemented it, the tests that certified it, the documentation that described it, and the live data already stored the wrong way. Each of those layers must be changed and re-verified, and each re-verification can itself go wrong. That compounding is what turns a linear delay into an exponential bill:

Money is only the measurable part of the damage. A late security defect can also trigger regulatory consequences — a supervisor can force you to shut the service down until it is fixed — and it can cost reputation, which no amount of money buys back quickly.

Tip: Turn the multiplier around and it becomes a budgeting argument: since reworking and bug-fixing may account for up to 50% of the total effort on a project, time spent nailing the requirements down early is not overhead competing with "real" work — it is the cheapest slot in the whole schedule to spend it in.

Go deeper:

• NIST Planning Report 02-3 — The Economic Impacts of Inadequate Infrastructure for Software Testing — the underlying research, with relative repair costs tabulated by the stage a defect is caught.
• Shift-left testing (Wikipedia) — the practice this curve is the argument for.

Not "zero vulnerabilities" but "no well-known vulnerabilities in the code" — reached by knowing the common vulnerability types, avoiding the well-known mistakes, and reusing proven countermeasures and patterns instead of inventing your own.

Perfect security is not an achievable goal for anyone — the defender has to cover every path while an attacker only needs one, and even the most heavily resourced organisations get breached. Setting "100% secure" as the target is therefore worse than useless: it is unmeasurable, so nobody can tell whether the project met it, and it invites the fatalistic conclusion that effort is pointless.

The workable target replaces perfect with no cheap wins for the attacker:

• Know the types of vulnerabilities. You cannot avoid a class of bug you have never heard of, so a baseline vocabulary of the common failure modes is the entry ticket.
• Avoid the well-known mistakes. The overwhelming majority of real-world compromises exploit long-documented, long-solved classes of flaw — not novel research.
• Use proven countermeasures and patterns. Established guidelines and library implementations have already survived the attacks a fresh hand-rolled solution is about to meet for the first time.

Two standing aims follow from that: projects should be "best-of-breed secure" — secure by the best standard the field currently knows, not merely "secure enough for now" — and all developers should be permanently security-aware, because a target that only one specialist carries is one holiday away from lapsing.

Tip: The realistic target is deliberately falsifiable. "Are there known vulnerability classes in our code?" is a question a review can actually answer; "are we secure?" is not.

Go deeper:

• OWASP Top Ten — the canonical list of the well-known vulnerability classes the target is defined against.
• CWE Top 25 Most Dangerous Software Weaknesses — the ranked catalogue of the mistakes that keep getting made anyway.