Example Only: The Most-Cited Number in Secure Design Was Never a Finding

In May 2002 the research institute RTI delivered a report to the National Institute of Standards and Technology called The Economic Impacts of Inadequate Infrastructure for Software Testing. In chapter five there is a small table, five columns wide, showing what it costs to repair a defect depending on when you catch it: 1X at requirements and architectural design, 5X at coding, 10X at system test, 15X at beta, and 30X after the product ships.

That table is the origin of the sentence “NIST found that bugs cost thirty times more to fix in production.” It is quoted in vendor decks, in conference keynotes, in secure-development training and in a great many articles like this one.

Here is the table’s full title, as printed in the report:

Table 5-1. Relative Cost to Repair Defects When Found at Different Stages of Software Development (Example Only)

The parenthesis is not an editor’s note. It is part of the title. The next table along, which extends the same ratios into a grid, is titled “Preliminary Estimates of Relative Cost Factors of Correcting Errors as a Function of Where Errors Are Introduced and Found (Example Only).” The report’s own narrative introduces the first table with the words “illustrates this with an example.” The numbers are an illustration drawn to make a point about the market for testing tools, in a study whose actual finding — a real one, and a large one — is that inadequate software testing infrastructure costs the US economy $59.5 billion a year, of which $22.2 billion could be recovered by feasible improvements.

Twenty-four years of citations, and the thing being cited says Example Only in its own name.

The study that does not exist

The second pillar of the argument is worse, because it is not a mislabelled illustration. It is a citation to which no underlying data has ever been produced.

Search for “IBM Systems Sciences Institute” and you will find a chart: 1x at design, 6.5x at implementation, 15x at testing, 100x in production. It is attributed to an IBM research study, usually without a date.

Laurent Bossavit, who has spent years auditing the empirical claims his own field repeats, followed the trail. It ends at a textbook. Roger Pressman’s Software Engineering: A Practitioner’s Approach states the ratios — “Assume that an error uncovered during design will cost 1.0 monetary unit to correct. Relative to this cost, the same error uncovered just before testing commences will cost 6.5 units; during testing, 15 units; and after release, between 60 and 100 units” — and cites them as [IBM81]. The reference reads, in full:

“Implementing Software Inspections,” course notes, IBM Systems Sciences Institute, IBM Corporation, 1981

Course notes. Not a study, not a paper, not a data set.

Bossavit then went looking for the Institute itself. He found it, and it is not what the citation implies. Quoting one of the few people demonstrably affiliated with it, Claude W. Burrill: “The Systems Science Institute is an educational organization and is a unit of IBM. We offer a variety of advanced courses for management and for professionals in the computer field.” It sat at 3550 Wilshire Boulevard in Los Angeles, began operating around 1967, and had stopped using that name by 1982, when it became the Information Systems Management Institute. It was a staff training programme. Bossavit’s conclusion is careful and damning: it is “inappropriate to cite the source of the ratios as ‘an IBM study’… in the total absence of any claim that the Institute was the primary source,” and “the original project data, if any exist, are not more recent than 1981, and probably older; and could be as old as 1967.”

The Register ran the finding on 22 July 2021 under a headline that has aged well: “Everyone cites that ‘bugs are 100x more expensive to fix in production’ research, but the study might not even exist.”

The one that is real, and the sentence its author added

There is a third source, and this one holds. Barry Boehm collected cost-to-fix data through the 1970s, published it in IEEE Transactions on Computers in December 1976, and drew the canonical curve in Software Engineering Economics in 1981 — the book’s version resting on data from large systems at IBM, TRW, GTE and Bell Labs. When anyone says “the research shows,” this is the research they mean, whether or not they know it.

In January 2001, Boehm and Victor Basili published a short piece in IEEE Computer called “Software Defect Reduction Top 10 List.” Item one reads:

Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.

And then, in the same item, the two paragraphs almost nobody quotes:

For this updated list, we have added the word “often” to reflect additional insights about this observation. One insight shows the cost-escalation factor for small, noncritical software systems to be more like 5:1 than 100:1. This ratio reveals that we can develop such systems more efficiently in a less formal, continuous prototype mode that still emphasizes getting things right early rather than late.

Another insight reveals that good architectural practices can significantly reduce the cost-escalation factor even for large critical systems. Such practices reduce the cost of most fixes by confining them to small, well-encapsulated modules.

In one column of a trade magazine, the man whose data produced the 100:1 figure inserted a hedge into his own claim, said the ratio is nearer 5:1 for small non-critical systems, and said good architecture flattens the curve even for the large critical ones. The industry kept the 100:1 and discarded all three qualifications.

So the standard economic case for involving security early rests on a mislabelled illustration, a phantom study, and a real finding whose author published the caveats twenty-five years ago. That is the state of the evidence for a claim the profession has treated as settled since the Ford administration.

Which raises the question this article is actually about. If the number is fake, why is the advice still right?

What the exam actually says, and what it does not

CISSP Domain 3 section 3.1.1 is titled Security’s Involvement in Design and Build, and it is where the profession’s oldest maxim gets examined. CISSP states its core concept in one line: “Security must be involved in all phases of designing and building a product or system; it must be involved from beginning to end.”

Read that carefully. It is not quite the claim the industry makes in its name, and the gap between the two is the whole of this section.

The book spends its first pages defining what is being secured. Architecture means many components working together for the purpose they were built for — a building, a firewall, a laptop. The laptop’s components are hardware, software and firmware, and, the book adds, “the user is part of the architecture as well, whenever they’re using the laptop.” Security architecture means each of those components protected “to the level of value relating to the individual components and to the overall architecture.” Enterprise security architecture applies the same decomposition to the whole organization: people, technology, processes, functions, information, hardware, networks. And then the constraint, stated plainly: “the level and degree of protection should be based upon value and cost-effectiveness.”

Engineering is the walk through the phases. The book’s life cycle runs concept, design, build and implement, test — “which happens during the design and build phases and must also be done prior to implementation” — then maintain, then dispose. Security, it says, “should be involved from the very beginning and should be a consideration throughout the life cycle.” The next two sentences are the ones to hold: “Security considered from the beginning leads to the best outcome, and it is the most cost-effective approach. It leads to what is known as security by design, which means that security should be embedded from the beginning and not just as an afterthought.”

So the book does make the earliness argument, explicitly, and makes it on cost. The Domain 3 introduction makes it again, saying the security function “needs to be involved at the start of the engineering life cycle and throughout each of the subsequent phases.” Anyone who wants to read 3.1.1 as a licence for shift-left can find the sentence, and it would be dishonest of this article to pretend otherwise.

But that is one half of the section, and it is the half everybody already teaches. The other half is the clause that never makes it onto a slide: “the level and degree of protection should be based upon value and cost-effectiveness.” Earliness is a direction. Value is a governor. A direction on its own cannot say where to stop, which is why shift-left arguments always end in the same place — everything, as early as possible, forever. Coupled to a governor it becomes a decision somebody can actually make: involved throughout, at a level the asset justifies.

Which half survives the evidence is the question the rest of this article answers. The governor does. The earliness claim survives too, but not as the settled law the number was recruited to prove — it survives one system at a time.

Six phases, and what each one has already cost somebody

The book names the phases and then leaves them as words: concept, design, build and implement, test, maintain, dispose. Words are easy to nod at and hard to hold. Every one of these phases has a public case attached to it, with a document you can open and read for yourself. Here is one for each. The last phase gets three, because disposal fails in three different shapes and almost nobody is paid to watch any of them.

Concept and design: the defect class you can decide not to have

Take one kind of flaw. SQL injection. SQL is Structured Query Language, the language most databases speak. A SQL injection flaw is what happens when something a person typed gets read by the database as a command instead of as data. In the documents below it is shortened to SQLi.

There is a design decision that removes the whole class. You keep the command and the data in separate channels, using what databases call a prepared statement. The decision costs nothing once it is made, and after it the flaw cannot be written.

In March 2024 the Cybersecurity and Infrastructure Security Agency, CISA, and the Federal Bureau of Investigation published a Secure by Design Alert about exactly this. In a box on the first page they printed the date the industry stopped having an excuse:

The software industry has known how to eliminate these defects at scale for decades. MySQL introduced prepared statements, which can eliminate SQL injection vulnerabilities, in 2004.

Twenty years. The alert states plainly why it was written:

CISA and the FBI are releasing this Secure by Design Alert in response to a recent well-publicized malicious threat actor campaign that exploited SQLi defects in a managed file transfer application to target and compromise users of that application—impacting thousands of organizations.

The alert does not name the product. CISA’s own Known Exploited Vulnerabilities catalogue does, and the join between those two documents is mine rather than CISA’s: the entry is CVE-2023-34362 — CVE stands for Common Vulnerabilities and Exposures, the public numbering scheme for known flaws — added to the catalogue on 2 June 2023 under the title “Progress MOVEit Transfer SQL Injection Vulnerability.” The National Vulnerability Database scores it 9.8 Critical, and its record notes that it was exploited in the wild in May and June 2023.

So: a design decision available since 2004, a defect class that outlived it by two decades, and one instance of that class reaching thousands of organisations.

Where you will meet this. As a buyer, not as an engineer. The alert closes with an instruction addressed to you:

CISA and the FBI urge senior executives at technology manufacturers to mount a formal review of their code to determine its susceptibility to SQLi compromises and encourage all technology customers to ask their vendors whether they have conducted such a review.

That is a procurement question, written for you by two federal agencies, and it can go into a vendor questionnaire this afternoon. Notice also what the argument for it did not need. No hundredfold multiplier appears anywhere in it.

Build: the phase people skip, because they think it means writing code

The book’s third phase is “build and implement,” and almost everyone reads “build” as “write the software.” It also means the machinery that turns source code into the thing you actually ship. That machinery is part of the architecture, and it can be attacked on its own terms.

On Friday 29 March 2024 a developer named Andres Freund posted to the oss-security mailing list. He had noticed that logging in over SSH — Secure Shell, the standard tool for remote command-line access — was using an odd amount of processor time on a test machine. He chased it, and reported what he found in one line:

The upstream xz repository and the xz tarballs have been backdoored.

xz is a compression tool, and its library is linked into a very large amount of Linux software. The National Vulnerability Database published the flaw the same day as CVE-2024-3094, scored 10.0 Critical. Its description is the part that belongs in this section:

Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code.

Read that twice. The backdoor was not sitting in the source code that a reviewer would have read. Freund’s post records that the line carrying it was present in the released archives and not in the project’s version control at all. The malicious code was assembled during the build, out of a file that looked like test data.

Reviewing the repository would not have found it. Reviewing the build would.

An honest note. CVE-2024-3094 is not in the CISA Known Exploited Vulnerabilities catalogue, as of catalogue version 2026.09.16. It was caught before it reached the stable releases of the major Linux distributions, by somebody investigating a performance oddity who was not looking for a backdoor at all. Do not let anyone tell you it was exploited in the wild.

Where you will meet this. An audit question, and a good one: can we show that the thing we ship was built from the source we reviewed? That is a design-phase decision about your build system, and if the answer is no, no amount of code review closes it.

Implement and test: the cheapest control in this article

The clearest testing failure ever priced by a regulator is not a security incident at all, which is exactly why it is worth your time. There is no attacker in it. Take the attacker out and you can see the shape of the process failure on its own.

On 16 October 2013 the United States Securities and Exchange Commission issued an order against Knight Capital Americas LLC, Release No. 70694, Administrative Proceeding File No. 3-15570. Knight had written new code for SMARS, its automated order router, and deployed it across the servers that ran it. The order records what happened:

During the deployment of the new code, however, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers. Knight did not have a second technician review this deployment and no one at Knight realized that the Power Peg code had not been removed from the eighth server, nor the new RLP code added. Knight had no written procedures that required such a review.

Seven servers out of eight. On 1 August 2012 the eighth server began acting on old code that had been left in place, triggered by a flag the new code had reused for a different purpose:

The consequences of the failures were substantial. For the 212 incoming parent orders that were processed by the defective Power Peg code, SMARS sent millions of child orders, resulting in 4 million executions in 154 stocks for more than 397 million shares in approximately 45 minutes.

Knight lost more than $460 million in three quarters of an hour, and paid a $12 million penalty. Then the order says the thing that belongs on the wall of every change-management meeting:

For example, a written procedure requiring a simple double-check of the deployment of the RLP code could have identified that a server had been missed and averted the events of August 1.

A second pair of eyes. That is the whole control, and it is the same economic shape as the British Airways case later in this article: the control that would have prevented the loss was already affordable before the loss happened.

Maintain: the phase where a correct design goes stale

A design that is right on the day it ships stops being right the day somebody publishes an advisory about the appliance sitting in front of it.

On 10 October 2023 the National Vulnerability Database published CVE-2023-4966, affecting Citrix NetScaler application delivery controllers and NetScaler Gateway appliances. How it was scored is worth a moment, because the scoring teaches something. Citrix, as the authority that assigned the identifier, rated it 9.4 Critical. The National Vulnerability Database rated the same flaw 7.5 High. Two numbers, one defect, both official.

Neither number is the one that mattered. On 18 October 2023 CISA added it to the Known Exploited Vulnerabilities catalogue, with a remediation due date of 8 November 2023 and a flag recording known use in ransomware campaigns. On 21 November 2023 CISA, the Federal Bureau of Investigation, the Multi-State Information Sharing and Analysis Center, and the Australian Signals Directorate’s Australian Cyber Security Centre published joint advisory AA23-325A:

Boeing observed LockBit 3.0 affiliates exploiting CVE-2023-4966, to obtain initial access to Boeing Distribution Inc., its parts and distribution business that maintains a separate environment.

Where you will meet this. The Known Exploited Vulnerabilities catalogue carries a due date against every entry, binding on United States federal civilian agencies and borrowed by everybody else as a standard. An auditor will ask whether you track it. This is the maintain phase with a clock attached, which is the only version of the maintain phase that anybody actually runs.

Dispose: three shapes of the thing that should have been gone

Disposal is last in the book’s list and last in every budget. Three cases, because it fails in three different ways.

Hardware. On 8 October 2020 the Office of the Comptroller of the Currency assessed a $60 million civil money penalty against Morgan Stanley Bank, N.A., and Morgan Stanley Private Bank, N.A. The grounds, in the agency’s own words:

The OCC took these actions based on the banks’ failure to exercise proper oversight of the 2016 decommissioning of two Wealth Management business data centers located in the U.S. Among other things, the banks failed to effectively assess or address risks associated with decommissioning its hardware; failed to adequately assess the risk of subcontracting the decommissioning work, including exercising adequate due diligence in selecting a vendor and monitoring its performance; and failed to maintain appropriate inventory of customer data stored on the decommissioned hardware devices.

Note the third failure especially. Not knowing which customer data sat on the machines is an inventory problem, and an inventory is a design-phase artefact that somebody has to decide to build.

Access paths. On 8 June 2021 Joseph Blount, chief executive officer of Colonial Pipeline, submitted written testimony to the United States Senate Committee on Homeland Security and Governmental Affairs:

Although the investigation is ongoing, we believe the attacker exploited a legacy virtual private network (VPN) profile that was not intended to be in use.

Not intended to be in use. That is a disposal failure stated in one clause, and it shut a fuel pipeline.

Code. Back to Knight Capital, because the same SEC order contains a disposal finding:

Further, in 2003, Knight elected to leave the Power Peg code on SMARS’s production servers, and, in 2005, accessed this code to use the cumulative quantity functionality in another application without taking measures to safeguard against malfunctions or inadvertent activation.

Dead code left in place for nine years, still reachable through a flag that was later handed to something else.

Where you will meet this. Your asset inventory is your disposal control. If the inventory does not know a thing exists, nobody will ever decommission it, and it will still be reachable on the day somebody finds a use for it.

Now look back across the cases in this section and notice what none of them needed. Not one required a cost multiplier to justify its control. In every one the control was cheap, known and available before the failure — which is the argument this article is going to end on, arrived at from eight directions before the evidence sections even begin.

The largest modern test found nothing

In 2017, Empirical Software Engineering published “Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle,” by Tim Menzies of NC State, William Nichols and Forrest Shull of Carnegie Mellon’s Software Engineering Institute, and Lucas Layman of Fraunhofer. They tested the delayed issue effect across 171 software projects run around the world between 2006 and 2014, which they believe to be the largest study of the effect ever published. The abstract states the result without softening it:

We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction.

The sample is the first thing to know about that result, and the authors put it up front, in what they call a full disclosure statement. All 171 projects were run under the Team Software Process, a methodology promulgated by the employer of two of the authors — who argue in the next sentence that “TSP is not such a radical change to software development that it can stamp out a supposedly rampant problem like the delayed issue effect,” and that it changes how a project is logged rather than how it is run. They were “mostly small to medium,” with a median duration of 46 days, a median team of seven people, and a median project producing about 4,200 lines of code. The data also stops at the point of handover: it “does not extend into post-delivery deployment,” while Boehm’s item one is a claim about cost after delivery.

The authors anticipate that objection and answer it, and the answer is what makes the result count. Every paper reporting the delayed issue effect reports it arriving early, inside development, before anything ships — Boehm’s own figure, which they reproduce, shows a fortyfold increase in effort by acceptance testing. If the effect were running in these projects, it would already be visible in the window they measured. It is not there.

Their sharpest measurement: comparing issues caught at design inspection against issues caught at system test, the ratio of resolution effort was 1.11. The greatest increase they report for requirements issues — from introduction through to integration testing — is a scale-up of 2.16 to 4.37, which they set against “the 37 to 250-fold increases” the curve literature reports. Issues injected during coding and fixed at system test took a median of thirteen minutes to resolve; the same issues caught at code review took ten.

The authors are careful about what they have shown. “We do not claim that this theory never holds in software projects; just that it cannot be assumed to always hold, as data have been found that falsify the general theory.” They offer five explanations — that the effect is a relic of punch-card-era development, that it is intermittent, that it is confined to very large systems, that modern development practice mitigates it, that modern tooling does — and they name, without claiming evidence either way, where it may still hold: “high-assurance software, architecturally complex systems, or in projects with poor engineering discipline.”

Which is exactly where the other real data set comes from. At the INCOSE International Symposium in 2004, Haskins, Stecklein, Dick, Moroney, Lovell and Dabney published error-cost escalation figures with a range wide enough to be alarming: a requirements error costing 1 unit to fix at requirements costs 3 to 8 at design, 7 to 16 at build, 21 to 78 at integration and test, and from 29 to more than 1,500 units in operations. The paper’s own scope statement is the important part. Their results “presume development of a hardware/software system having project characteristics similar to those used in the development of a large, complex spacecraft, a military aircraft, or a small communications satellite,” and their real-world data “came from two large aerospace projects.”

Put the numbers side by side and the shape of the truth appears. Spacecraft, from two aerospace projects: up to 1,500x. Small-to-medium disciplined projects, 171 of them, measured to delivery: 1.11x. Small non-critical system, per Boehm himself: 5:1.

The steepness of the curve is a property of the system, not a law of software. The exam asks when security should be involved. The evidence says the useful question is for which systems, and how hard. Knowing which kind of thing you are building — and therefore how much design-time rigour it can repay — is the actual competency, and it is the one the book’s “value and cost-effectiveness” clause was pointing at all along.

There is one more thing Boehm wrote in 2001 that belongs here, because it is the argument against his own reputation. Discussing the finding that projects spend 40 to 50 percent of their effort on avoidable rework, he noted that some rework must therefore be unavoidable, because “better user-interactive systems result from emergent processes” in which requirements are discovered by building rather than specified in advance. His conclusion: “changes to a system’s definition that make it more cost-effective should not be discouraged by classifying them as avoidable defects.” Late change is not automatically failure. Sometimes it is the system getting better.

What nobody measured

Menzies and his co-authors measured effort to resolve — hours in an issue tracker — across defects in general, up to the day the software shipped. Not security defects specifically, not consequence, and not the years afterwards in which a security defect does its work.

A shipped security flaw costs things no issue tracker records: regulatory penalty, breach notification, forensic investigation, customer remediation, litigation, and the executive attention that all of it consumes. The 1.11 ratio is a true statement about developer hours and a silent one about everything downstream of them. This is the honest gap between the best modern evidence and the security argument, and the only responsible way to close it is to find a case where somebody with subpoena power priced the decision.

There is one.

The principles were published as warnings

First, a note about what the exam calls canon. In 1975, Jerome Saltzer and Michael Schroeder published “The Protection of Information in Computer Systems” in the Proceedings of the IEEE, setting out eight design principles, several of which a CISSP candidate meets again in 3.1.2 and is examined on as law: economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability.

The authors did not present them as law. Their own framing sentence:

…these principles do not represent absolute rules—they serve best as warnings.

A violation, they wrote, signals potential trouble that warrants careful review. That is a specific instruction about process, not about outcome. It says a departure from a principle is permitted, and that what makes it legitimate is the review — a decision taken deliberately, on the record, by someone who looked.

One of the eight gets treated as a courtesy rather than an engineering requirement, and it is the one this article needs: psychological acceptability. Saltzer and Schroeder were not asking designers to be polite. They were making a claim about outcomes. A protection mechanism that people find awkward gets worked around, and a mechanism that has been worked around protects nothing.

Here is that claim tested in public, by a regulator, with the working shown.

On 15 July 2020 a seventeen-year-old and his accomplices took control of 130 Twitter accounts, including those of serving politicians and of cryptocurrency companies regulated by New York State. The New York State Department of Financial Services investigated and issued its report in October 2020. Its summary of the method is the first thing to read:

Notably, the Twitter Hack did not involve any of the high-tech or sophisticated techniques often used in cyberattacks – no malware, no exploits, and no backdoors.

What it involved was telephone calls. Twitter had moved to remote working in March 2020 and staff were having repeated trouble with the virtual private network, the encrypted tunnel they used to reach internal systems:

The Hackers took advantage of these issues and pretended to be calling from Twitter’s IT department about a VPN problem, and then persuaded employees to enter their credentials into a website designed to look identical to the real VPN login website.

Twitter had multi-factor authentication. It did not help, and the report explains why in a single sentence:

During the Twitter Hack, the Hackers got past MFA by convincing the Twitter employees to authenticate the application-based MFA during the login.

That is psychological acceptability failing as an engineering property, not as a matter of manners. The employee was asked to approve something on a phone, during a call about a problem they were genuinely having, by someone who sounded like the help desk. The mechanism was present and correct and it protected nothing.

The Department’s remedy is a design change rather than a training course — it names hardware security keys — and then it states the governor in its own words, which are worth setting beside the book’s:

Authentication requirements should also be calibrated to match the risk. For instance, for high-risk applications and functions like Twitter’s internal tools, authentication requirements should be stricter.

Calibrated to match the risk. CISSP says protection should be “based upon value and cost-effectiveness.” A financial regulator, investigating one specific failure, arrived at the same sentence from the other end.

One more line from that report, because it is the shortest statement anywhere in this article of the organisational half of 3.1.1:

The problems started at the top: Twitter had not had a chief information security officer (“CISO”) since December 2019, seven months before the Twitter Hack.

Where you will meet this. A design review. When somebody proposes push-approval multi-factor authentication for an administrative tool, the question is not “is this multi-factor authentication.” It is “does this survive a competent person being talked to for ten minutes.” Those are different questions, and only the second one is about security.

Hold that thought against what follows.

British Airways, and the design decision that could not be found

On 6 September 2018, British Airways notified the Information Commissioner’s Office of an attack on its systems. The attacker had entered through Citrix using compromised credentials belonging to a third-party supplier. On 16 October 2020 the Commissioner issued a monetary penalty notice finding that BA had infringed Articles 5(1)(f) and 32 of the GDPR, affecting 429,612 data subjects on BA’s own estimate, and imposed a penalty of £20 million — reduced, the notice records, after mitigating factors and the impact of the Covid-19 pandemic.

The interesting part of that notice is not the money. It is what the regulator found about the design.

BA had a Network Access Control Policy. Its default position, in the Commissioner’s words, was that “all remote network access” would be protected by multi-factor authentication. The security function had been involved at design. It had reached the correct conclusion. It had written the conclusion down as policy.

Then somebody departed from it. BA’s position was that it had relied on a risk assessment to justify the departure, which is precisely the legitimate move Saltzer and Schroeder described — a principle overridden by a review. The Commissioner’s response, at paragraph 6.26, is the sentence this whole article has been walking toward:

Given how dated the risk assessment is, and that no copy can now be located, it is not possible to say that BA took into consideration the risk, the state of the art, the cost, or the available technical measures when deciding what security was appropriate.

And at 6.28: BA “appears to accept” the requirement through its own policy, “but failed to implement MFA as required by its own policies, or apply appropriate alternative measures.”

The Commissioner then priced the fix. At paragraph 6.29, MFA and the alternatives she had identified were “readily available and mature solutions (i.e. solutions that have been known about in the industry for a long period of time, prior to the Attack), and which could have been implemented by BA without excessive cost.” At paragraph 6.72, on a separate set of missing controls:

None of the above measures would have entailed excessive cost or technical barriers. They are all readily available measures available through the Microsoft Operating System used by BA.

Read that as an economist would. The design-time cost of the control was approximately zero: it was written in BA’s own policy already. The build-time cost was approximately zero: the capability shipped with the operating system BA had already bought. The post-hoc cost was £20 million and a regulatory investigation that ran from BA’s notification in September 2018 to the notice in October 2020.

This is the delayed-issue effect the software studies could not see, because it was never a software problem. Nothing about British Airways is a story of security being kept out of the room. Security was in the room, was right, and was overruled by a decision that then evaporated. What failed was not the design phase. It was every phase after it.

The same control, missing again, four years later

One penalty notice is an anecdote. Here is the pattern.

On 1 May 2024 Andrew Witty, chief executive officer of UnitedHealth Group, submitted written testimony to the Oversight and Investigations Subcommittee of the United States House Committee on Energy and Commerce about the ransomware attack on Change Healthcare. His account of how it began is three sentences long:

On February 12, criminals used compromised credentials to remotely access a Change Healthcare Citrix portal, an application used to enable remote access to desktops. The portal did not have multi-factor authentication. Once the threat actor gained access, they moved laterally within the systems in more sophisticated ways and exfiltrated data.

Ransomware was deployed nine days later. In the same testimony Witty stated that the files taken contained protected health information and personally identifiable information which “could cover a substantial proportion of people in America.”

Now set the two cases side by side. In October 2020 a British regulator wrote that multi-factor authentication was a readily available and mature solution which had been known about in the industry for a long period of time. In February 2024 a remote-access portal at Change Healthcare did not have it, and the rest of Witty’s testimony is an account of what stopped when that portal was used: pharmacies submitting claims by hand, providers unpaid, and more than a billion dollars in claims payments accelerated by UnitedHealthcare to keep the system moving. In both cases the way in was a Citrix remote-access system reached with credentials the attacker had not been given.

The earliness argument is not the hard part. Nobody in either organisation would have argued against multi-factor authentication in a design review, and in British Airways’ case nobody did. What failed in both is the same thing, and it is not a phase. It is the record: who decided otherwise, when, on what basis, and can you produce the paper.

And there is now a second bill

The cost of a shipped security flaw has acquired a newer component, and it does not land on the flaw. It lands on what you say afterwards.

On 22 October 2024 the United States Securities and Exchange Commission charged four public companies with making materially misleading disclosures about cybersecurity risks and intrusions connected to the compromise of SolarWinds. Unisys Corp. agreed to pay a $4 million civil penalty, Avaya Holdings Corp. $1 million, Check Point Software Technologies Ltd $995,000 and Mimecast Limited $990,000. The Commission’s position, stated here in its framing rather than in quotation marks because I have not matched the wording byte for byte: describing a cybersecurity risk as hypothetical while knowing it has already happened is a half-truth, and the securities laws make no exception for risk-factor language.

Where you will meet this. The disclosure is yours to get right, and it gets written under time pressure in the worst week of your year. Everything it needs — what was taken, how much of it, and when you knew — comes out of the forensic work, and the forensic work depends on logging and retention decisions made at design time by somebody who was not thinking about a securities filing.

Where designing security in demonstrably worked — and the warning attached

The best-documented modern success is Android’s. On 25 September 2024, Jeff Vander Stoep and Alex Rebert of Google published the numbers: memory safety vulnerabilities fell from 76% of Android’s total in 2019 to 24% in 2024, against what they describe as a 70% industry norm, over a period in which the Android team shifted new development to memory-safe languages beginning around 2019.

The mechanism is the part worth carrying. Google did not rewrite Android. “Despite the majority of code still being unsafe (but, crucially, getting progressively older), we’re seeing a large and continued decline in memory safety vulnerabilities.” Their explanation:

The answer lies in an important observation: vulnerabilities decay exponentially. They have a half-life.

Old code has already had its bugs found. New code has not. Based on average vulnerability lifetimes, Google estimates that five-year-old code carries somewhere between 3.4 and 7.4 times lower vulnerability density than new code. The prescription that falls out of this is the opposite of what “secure by design” is usually taken to mean, and Google gave it a heading: “Interoperability is the new rewrite.” In their words: “it’s become clear that we do not need to throw away or rewrite all our existing memory-unsafe code.”

These are Google’s own vulnerability counts on Google’s own product, and the 2024 data is extrapolated to a full year, so treat the precision with the caution it deserves. But the structure of the finding is robust and it sharpens the exam material considerably. Design-time security investment pays where new code is being written. Retroactive design-time rigour applied to old, mature code buys progressively less, because the market has already found those bugs for you. The book’s “based upon value and cost-effectiveness” has a second edge: value changes with the age of the thing you are protecting.

Two more things sit on that page, both useful, neither widely quoted.

The first is not a security number at all. Google reports that the rollback rate of Rust changes on Android — emergency reverts of code after an unanticipated bug — is less than half the rate for C++. Rust is the memory-safe language Android moved its new development to. That is a design-time choice paying out in day-to-day operational stability rather than in vulnerability counts, and it is exactly the kind of second-order benefit that never survives a business case built around a cost multiplier.

The second is a limit on what you should take from Google’s comparison. The “70% industry norm” is Google’s characterisation. It is close to a figure Microsoft has reported for its own products over more than a decade, and this article has not read Microsoft’s underlying data. Take the 70% as Google’s framing, not as a measured industry constant.

And the design argument behind all of it has since been written down as policy by people who can audit you against it. In January 2025 CISA and the Federal Bureau of Investigation published version 2 of Product Security Bad Practices, aimed at manufacturers of software used in critical infrastructure. The first bad practice on the list is a design decision:

The development of new product lines for use in service of critical infrastructure or NCFs in a memory-unsafe language (e.g., C or C++) where readily available alternative memory-safe languages could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.

NCFs are National Critical Functions. For software that already exists, the document asks for something far weaker than a rewrite — a published memory safety roadmap — which is Google’s own conclusion arriving as government guidance. And then it attaches a limit that is the purest statement of the book’s governor anywhere in this article:

Publication of a memory safety roadmap does not apply to products that have an announced end-of-support date that is prior to Jan. 1, 2030.

A control scoped by how much life the asset has left. That is “based upon value and cost-effectiveness,” written by two federal agencies, with a date on it.

Where you will meet this. A vendor questionnaire, in both directions. If you buy software that runs critical infrastructure you can ask for the roadmap. If you sell it, somebody is going to ask you for yours.

The label nobody checks

The current institutional expression of 3.1.1 is CISA’s Secure by Design programme, published in April 2023 as Shifting the Balance of Cybersecurity Risk with ten US and international partners, revised that October with eight more, and built on three principles: take ownership of customer security outcomes, embrace radical transparency and accountability, lead from the top.

On 8 May 2024 CISA launched the Secure by Design Pledge with 68 software manufacturers. It sets seven goals — multi-factor authentication, default passwords, reducing entire classes of vulnerability, security patches, vulnerability disclosure policy, CVEs, evidence of intrusions — and every one of them opens with the same clock: “Within one year of signing the pledge.”

As of 16 September 2026 the pledge has 387 signers. Fifty-nine have published a progress report. Roughly one in seven, against goals written on a one-year clock, twenty-eight months after launch.

CISA is candid about what this does and does not mean, in a disclaimer printed on its own progress-reports page:

The Secure by Design pledge is a voluntary pledge. CISA does not enforce nor verify adherence to the pledge. The inclusion of a company in this page does not indicate that CISA is attesting to the security of any product, process, or service.

That disclaimer is doing more work than the pledge. No signer is required to publish a report, so silence is not evidence of non-compliance — which is the problem rather than the defence. A voluntary commitment with no verification produces a list on which the companies doing the work and the companies doing the press release are indistinguishable. Several signers have accumulated entries in CISA’s own Known Exploited Vulnerabilities catalogue since signing, which proves less than it appears to: large vendors with large exposed surfaces accumulate more KEV entries than small ones, and the pledge’s goals are about defaults and disclosure, not about shipping zero vulnerabilities. The point is narrower and harder. Nobody, including the agency that runs both lists, can currently tell you which signers changed their engineering and which signed a page.

What a signature is evidence of

There is one named case that shows how little the list can tell you, and it is a launch signer.

On 20 March 2024 the Cyber Safety Review Board — a body established under United States federal authority, drawing its members from federal agencies and from private-sector security leadership — delivered its Review of the Summer 2023 Microsoft Exchange Online Intrusion. Its central finding is two sentences:

The Board finds that this intrusion was preventable and should never have occurred. The Board also concludes that Microsoft’s security culture was inadequate and requires an overhaul, particularly in light of the company’s centrality in the technology ecosystem and the level of trust customers place in the company to protect their data and operations.

Seven weeks later, on 8 May 2024, Microsoft was among the 68 launch signers of CISA’s Secure by Design Pledge. Microsoft has also published a progress report, which puts it in the minority that has.

Both facts are true, and neither settles anything about the engineering. That is the point, and it is not an argument that the pledge is worthless. It is an argument about what kind of evidence a signature is. A voluntary list records a decision to sign. A review board with access records what happened.

The version with teeth is already written

The verification gap is being closed in two places, and neither of them is voluntary.

The first is sectoral, and it is already law. Section 524B of the United States Federal Food, Drug, and Cosmetic Act, added in 2023, makes cybersecurity a condition of bringing a medical device to market. A sponsor filing a premarket submission for what the statute calls a “cyber device” must, among other things:

design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches to the device and related systems

Read the verbs in order. Design, develop, maintain, and then updates and patches after the product is on the market. That is the book’s life cycle written into a statute, and the plan for the postmarket half has to be filed before the device is allowed onto the market at all. “Involved from beginning to end” has become a condition of market entry for an entire category of product.

The second is horizontal. The European Union’s Cyber Resilience Act, Regulation (EU) 2024/2847, covers products with digital elements placed on the Union market. It applies from 11 December 2027, with the obligation to report actively exploited vulnerabilities applying earlier, from 11 September 2026. Its first essential requirement, Annex I, Part I, paragraph 1, reads in full:

Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

An appropriate level of cybersecurity based on the risks. Put that next to the clause from CISSP that this article has been arguing is the examinable half: “the level and degree of protection should be based upon value and cost-effectiveness.”

Earliness is in both documents, and everybody already teaches it. The governor is the half nobody teaches, and it is the half that two separate legislatures independently chose to write down.

What is left

Strip out the citations that do not survive and the argument for 3.1.1 does not get weaker. It gets more precise.

Involving security in design and build is not justified by a hundredfold cost multiplier, because outside spacecraft and safety-critical systems nobody has demonstrated one. It is justified because a control decided at design is often already paid for by the time anyone has to build it — BA’s was in the operating system and in the policy — and because the consequences of getting it wrong are settled somewhere the issue tracker cannot see: in a regulator’s penalty notice, and in the personal data of 429,612 people.

And it is justified, most of all, by the half of the book that the slogan drops. Earliness is a direction, and the book does argue for it. Value is the governor, and only the book supplies that: involved in all phases, from beginning to end, at a level the asset justifies.

British Airways got the design right. What it could not produce, two years later, was the piece of paper on which somebody had decided to do otherwise.

Key Takeaways

• Know the core concept exactly as the book states it. CISSP 3.1.1: security “must be involved in all phases of designing and building a product or system; it must be involved from beginning to end.” That is a claim about coverage across the whole life cycle — concept, design, build and implement, test, maintain, dispose. The book separately argues for earliness on cost (“Security considered from the beginning leads to the best outcome, and it is the most cost-effective approach”), and separately puts a governor on how much protection each component gets. Direction and governor are two claims, and the exam expects both.
• The book’s governor is cost-effectiveness, and it is examinable. Protection is applied “to the level of value relating to the individual components and to the overall architecture,” and “the level and degree of protection should be based upon value and cost-effectiveness.” Architecture means components working together; enterprise security architecture decomposes the whole organization into people, technology, processes, functions, information, hardware and networks, and protects each by value.
• Do not cite the 100x or 30x figure. The “IBM Systems Sciences Institute study” is a citation to internal course notes from 1981 for which no underlying data has ever been produced; the Institute was an IBM staff training programme in Los Angeles. The NIST 30x number comes from RTI’s May 2002 report in a table titled “(Example Only).”
• Boehm is real, and Boehm qualified himself. IEEE Computer, January 2001: the escalation factor is “often” 100x, is “more like 5:1 than 100:1” for small non-critical systems, and is significantly reduced by good architectural practice even for large critical systems.
• The steepness of the curve is a property of the system. Haskins et al. (INCOSE 2004): up to 1,500x — from two large aerospace projects. Menzies et al. (Empirical Software Engineering, 2017): no delayed issue effect across 171 Team Software Process projects, mostly small to medium (median ~4,200 lines of code, median team of seven), measured to delivery, with a ratio of 1.11. The exam asks when security should be involved; the useful professional question is for which systems, and how hard.
• What the software studies do not measure is where security’s cost lives. Effort-to-resolve in an issue tracker excludes regulatory penalty, breach notification, investigation and litigation. Cite British Airways for this: ICO penalty notice, 16 October 2020, £20 million, 429,612 data subjects, for controls the regulator found were “readily available measures available through the Microsoft Operating System used by BA.”
• BA is not a “security wasn’t consulted” case — use it correctly. BA’s own Network Access Control Policy required MFA for all remote network access. The failure was a departure from that policy justified by a risk assessment so dated that no copy could be located, which is why the Commissioner could not find that BA had considered risk, state of the art, cost or available measures at all.
• Saltzer and Schroeder (1975) called their eight principles “warnings,” not rules. A violation signals potential trouble warranting careful review. The legitimacy of a departure lives in the documented review — which is precisely what BA could not produce.
• Design-time security pays most on new code. Google’s Android data (25 September 2024): memory safety issues fell from 76% of vulnerabilities in 2019 to 24% in 2024 without rewriting the old code, because vulnerabilities decay exponentially and older code is already hardened by having been attacked. Google’s own conclusion is “we do not need to throw away or rewrite all our existing memory-unsafe code.”
• “Secure by design” as a label is currently unverified. CISA’s pledge: 68 signers at launch on 8 May 2024, 387 signers and 59 published progress reports as of 16 September 2026, seven goals each opening “Within one year of signing the pledge,” and CISA’s own statement that it “does not enforce nor verify adherence to the pledge.”
• Learn the life cycle through cases, not through the list. Concept and design: SQL injection, eliminable by prepared statements since 2004, still reaching thousands of organisations through CVE-2023-34362 in 2023. Build: CVE-2024-3094, the xz backdoor that lived in the release archives and not in the source repository. Implement and test: Knight Capital, seven servers out of eight, $460 million in 45 minutes, and a $12 million SEC penalty for the want of a second pair of eyes. Maintain: CVE-2023-4966, Citrix Bleed, in the Known Exploited Vulnerabilities catalogue on 18 October 2023 with a due date twenty-one days later. Dispose: Morgan Stanley’s decommissioned data centres, Colonial Pipeline’s legacy virtual private network profile, and Knight’s nine-year-old dead code.
• Disposal fails in three shapes: hardware, access paths and code. The OCC fined Morgan Stanley $60 million on 8 October 2020 for the 2016 decommissioning of two data centres, including a failure “to maintain appropriate inventory of customer data stored on the decommissioned hardware devices.” Colonial Pipeline’s chief executive testified that the attacker used “a legacy virtual private network (VPN) profile that was not intended to be in use.” Your asset inventory is your disposal control.
• Psychological acceptability is an engineering property, not a courtesy. New York State Department of Financial Services, Twitter Investigation Report, October 2020: no malware, no exploits, no backdoors, and multi-factor authentication defeated by asking the employee to approve it during a phone call. The Department’s remedy is hardware keys and authentication “calibrated to match the risk” — the book’s governor, in a regulator’s words.
• The missing control repeats, which is what makes it a lesson. British Airways, 2018, no multi-factor authentication on remote access through Citrix. Change Healthcare, February 2024, no multi-factor authentication on remote access through Citrix, stated in the chief executive’s written testimony to Congress. The failure in both is the record of the departure, not the design.
• There is a second bill, and it is for the disclosure. SEC, 22 October 2024: Unisys $4 million, Avaya $1 million, Check Point $995,000, Mimecast $990,000, for describing cybersecurity risk as hypothetical when the intrusion had already happened.
• The governor is now law in two places. Section 524B of the United States Federal Food, Drug, and Cosmetic Act requires a sponsor to “design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure” before a medical device reaches the market. The European Union Cyber Resilience Act, Regulation (EU) 2024/2847, Annex I, Part I, paragraph 1: products “shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.” Applies from 11 December 2027; vulnerability reporting from 11 September 2026.
• A signature is evidence of a decision to sign. The Cyber Safety Review Board found on 20 March 2024 that the Microsoft Exchange Online intrusion “was preventable and should never have occurred” and that Microsoft’s security culture “was inadequate and requires an overhaul.” Seven weeks later Microsoft was a launch signer of the Secure by Design Pledge. Both are true; only one is an assessment of engineering.

Sources & References

The CISSP material

• CISSP Certification, Domain 3, section 3.1.1, “Security’s Involvement in Design and Build,” and the Domain 3 introduction. All definitions and quoted phrases in “What the exam actually says” are from this section.

The cost curve

• RTI for the National Institute of Standards and Technology, The Economic Impacts of Inadequate Infrastructure for Software Testing, Final Report, May 2002, RTI Project Number 7007.011, prepared for Gregory Tassey, Ph.D., NIST. Tables 5-1 and 5-2 and their titles are quoted as printed; the $59.5 billion and $22.2 billion figures are the report’s headline estimates.
• Laurent Bossavit (Morendil), “The IBM Systems Science Institute”, first published 8 August 2019. Source of the Pressman ratios and the [IBM81] citation as Pressman prints it, the Burrill quotation, the Wilshire Boulevard address and the 1967/1982 dates. Bossavit’s longer treatment is his book The Leprechauns of Software Engineering, which is not the source used here.
• Tim Anderson, “Everyone cites that ‘bugs are 100x more expensive to fix in production’ research, but the study might not even exist”, The Register, 22 July 2021.
• Barry Boehm and Victor R. Basili, “Software Defect Reduction Top 10 List”, IEEE Computer, January 2001, pp. 135–137. Items one and two quoted verbatim.
• Barry Boehm, “Software Engineering,” IEEE Transactions on Computers C-25(12), December 1976, and Software Engineering Economics, Prentice Hall, 1981 — the origin of the curve. Cited here through the papers above that reproduce and discuss it, not read in the original.
• Tim Menzies, William Nichols, Forrest Shull and Lucas Layman, “Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle”, arXiv:1609.04886, 16 September 2016; published in Empirical Software Engineering 22(4), 2017, pp. 1903–1935.
• Haskins, Stecklein, Dick, Moroney, Lovell and Dabney, “8.4.2 Error Cost Escalation Through the Project Life Cycle”, INCOSE International Symposium, 2004; NASA Johnson Space Center copy.

Design principles

• Jerome H. Saltzer and Michael D. Schroeder, “The Protection of Information in Computer Systems”, MIT; manuscript received 11 October 1974, revised 17 April 1975; published in the Proceedings of the IEEE, September 1975. The eight principles and the “warnings” sentence are quoted from the MIT text.

British Airways

• Information Commissioner’s Office, Monetary Penalty Notice: British Airways plc, 16 October 2020. Paragraph references as printed: 1.7 (penalty), 5.2 (notification date), 6.26 (the missing risk assessment and the “all remote network access” policy position), 6.28 (failure to implement MFA as required by BA’s own policies), 6.29 and 6.72 (cost and availability of the measures), 7.11 (429,612 data subjects). The published notice is partly redacted; only unredacted passages are quoted.

Android and memory safety

• Jeff Vander Stoep and Alex Rebert, “Eliminating Memory Safety Vulnerabilities at the Source”, Google Online Security Blog, 25 September 2024. Google’s own figures on its own product; the 2024 data is stated by Google as extrapolated to the full year. The underlying vulnerability-lifetime study Google cites was not consulted for this article.

CISA Secure by Design

• CISA and partners, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software, April 2023, revised 25 October 2023.
• CISA, “CISA Announces Secure by Design Commitments from Leading Technology Providers”, 8 May 2024 — 68 launch signers.
• CISA, Secure by Design Pledge — the seven goals and the “voluntary and not legally binding” statement.
• CISA, pledge signers and progress reports, both counted on 16 September 2026: 387 and 59 respectively. The “does not enforce nor verify” disclaimer is printed on the progress-reports page. These counts change; re-check before relying on them.
• CISA, Known Exploited Vulnerabilities Catalog, catalogue version 2026.09.16.

The life cycle cases (added in the examples pass, 16 September 2026)

• CISA and FBI, Secure by Design Alert: Eliminating SQL Injection Vulnerabilities in Software, dated “As of March 2024” in the document itself. The prepared-statements sidebar, the “in response to a recent well-publicized” paragraph, and the closing instruction to customers are quoted as printed. The alert does not name the affected product; the connection to MOVEit is drawn in this article and is labelled as such on the page.
• National Vulnerability Database, CVE-2023-34362, published 2 June 2023, 9.8 Critical. CISA, Known Exploited Vulnerabilities Catalog, entry “Progress MOVEit Transfer SQL Injection Vulnerability,” dateAdded 2 June 2023.
• Andres Freund, “backdoor in upstream xz/liblzma leading to ssh server compromise”, oss-security mailing list, 29 March 2024. National Vulnerability Database, CVE-2024-3094, published 29 March 2024, 10.0 Critical from both NVD and Red Hat. Not present in the Known Exploited Vulnerabilities catalogue, version 2026.09.16, checked for this article.
• United States Securities and Exchange Commission, In the Matter of Knight Capital Americas LLC, Release No. 70694, 16 October 2013, Administrative Proceeding File No. 3-15570. Paragraphs as printed: 15 (the eighth server), 17 (the 45 minutes), 41 (the double-check, and the 2003 decision to leave the Power Peg code in place), and the $12 million penalty in the sanctions section.
• National Vulnerability Database, CVE-2023-4966, published 10 October 2023; 9.4 Critical from Citrix as CNA, 7.5 High from NVD. CISA, Known Exploited Vulnerabilities Catalog: dateAdded 18 October 2023, dueDate 8 November 2023, knownRansomwareCampaignUse “Known.” CISA, FBI, MS-ISAC and ASD’s ACSC, joint advisory AA23-325A, 21 November 2023.
• Office of the Comptroller of the Currency, News Release 2020-134: “OCC Assesses $60 Million Civil Money Penalty Against Morgan Stanley”, 8 October 2020.
• Joseph Blount, written testimony, United States Senate Committee on Homeland Security and Governmental Affairs, 8 June 2021. The written testimony does not state that the legacy profile lacked multi-factor authentication, and this article does not claim it.

The repeat, and the second bill

• Andrew Witty, written testimony, Oversight and Investigations Subcommittee, United States House Committee on Energy and Commerce, 1 May 2024.
• United States Securities and Exchange Commission, “SEC Charges Four Companies With Misleading Cyber Disclosures”, Press Release 2024-174, 22 October 2024. The four penalties are quoted as figures; the Commission’s characterisation of the conduct is paraphrased here and not quoted, because the wording was not matched byte for byte against the release.

Psychological acceptability

• New York State Department of Financial Services, Twitter Investigation Report, issued October 2020. Quoted passages: the executive summary on technique, the vishing account, the multi-factor authentication bypass, the “calibrated to match the risk” recommendation, and the chief information security officer finding.

Memory safety as policy

• CISA and FBI, Product Security Bad Practices, version 2, January 2025. Bad practice 1 and the end-of-support carve-out are quoted as printed.
• The rollback-rate observation and the “70% industry norm” are both from the Google Android post already cited. The underlying vulnerability-lifetime study Google cites (Alexopoulos et al., USENIX Security 2022) and Microsoft’s own memory-safety data were not consulted for this article.

Secure by design as an obligation

• Cyber Safety Review Board, Review of the Summer 2023 Microsoft Exchange Online Intrusion, 20 March 2024. The “preventable and should never have occurred” finding is from the executive summary and is repeated in section 2.1.1.
• 21 U.S.C. § 360n-2, “Ensuring cybersecurity of devices” — section 524B of the Federal Food, Drug, and Cosmetic Act, added by section 3305 of the Consolidated Appropriations Act, 2023. Subsection (b)(2) quoted as printed.
• Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 (the Cyber Resilience Act). Annex I, Part I, paragraph 1 quoted in full; the application dates are from Article 71.

A note on quotation marks

Every block quotation in this article was matched against the source document downloaded to disk. Apostrophes and quotation marks have been normalised to plain ASCII forms where the source used typographic ones; no word, number or punctuation mark that carries meaning has been changed. Where a wording could not be matched byte for byte, the passage appears as attributed paraphrase without quotation marks, and the sources block says so.

Not used, and why

Restraint is part of the method, so here is what was found, checked and left out.

• A figure for how many people Change Healthcare affected. The widely repeated number was not verified at a primary source for this article. Andrew Witty’s own phrase — protected health information that “could cover a substantial proportion of people in America” — is used instead, because he said it under oath in the document cited.
• “Colonial Pipeline’s legacy account had no multi-factor authentication.” This is repeated everywhere. It is not in Joseph Blount’s written testimony, which is the document this article cites. The testimony supports the disposal point and nothing more, so only the disposal point is made.
• “The xz backdoor was exploited in the wild.” It was not, as far as the authoritative list says: CVE-2024-3094 is absent from the Known Exploited Vulnerabilities catalogue at version 2026.09.16. Famous is not the same as exploited.
• “Boeing was breached through Citrix Bleed.” The joint advisory says Boeing Distribution Inc., described in the advisory itself as a parts and distribution business that maintains a separate environment. The narrower statement is the accurate one.
• A named example of a documented departure done properly. Saltzer and Schroeder say a violation is legitimate when a review has looked at it. No public, re-openable case of an organisation producing that review and being vindicated by it was found. That is a gap in the evidence and it is printed here as a gap, because a manufactured example would teach the wrong thing.
• Equifax, Target, and the other standard teaching breaches. Two regulator-priced cases and one congressional testimony already carry the argument. A third familiar breach would add length and no new mechanism.
• A dollar figure for the Change Healthcare or Microsoft incidents. Both are available in company filings, and neither was needed: the argument turns on the control that was missing, not on the size of the loss.
• The Secure by Design pledge signers that have entries in the Known Exploited Vulnerabilities catalogue. The body already explains why that comparison proves less than it appears to. Naming companies on that basis would be an accusation the data cannot support.

Changelog: the examples pass, 16 September 2026

The original article is unchanged except where noted. Nothing was rewritten; everything below is an addition, apart from two dated counts.

New sections, all additive

1. Six phases, and what each one has already cost somebody — placed after “What the exam actually says,” before the evidence sections. Gives the book’s six life cycle phases a documented case each: the CISA and FBI SQL injection alert with CVE-2023-34362; the xz backdoor, CVE-2024-3094; the Knight Capital SEC order; Citrix Bleed, CVE-2023-4966, with its KEV dates; and three disposal cases — Morgan Stanley at the OCC, Colonial Pipeline’s legacy virtual private network profile, and Knight’s dead code.
2. The same control, missing again, four years later — Change Healthcare, from Andrew Witty’s written testimony of 1 May 2024, set against the British Airways notice.
3. And there is now a second bill — the SEC’s 22 October 2024 action against four companies over cybersecurity disclosures.
4. What a signature is evidence of — the Cyber Safety Review Board’s 20 March 2024 finding on Microsoft, against Microsoft’s launch signature on the Secure by Design Pledge seven weeks later.
5. The version with teeth is already written — section 524B of the Federal Food, Drug, and Cosmetic Act, and the European Union Cyber Resilience Act, Annex I, Part I, paragraph 1.

Additions inside existing sections

6. The principles were published as warnings — the New York State Department of Financial Services Twitter report is added before the existing hinge sentence, as a worked example of psychological acceptability and of the regulator’s own version of the book’s governor. No existing sentence changed.
7. Where designing security in demonstrably worked — three paragraphs added at the end: the Rust rollback-rate observation, a scope limit on Google’s “70% industry norm,” and CISA and the FBI’s Product Security Bad Practices with its end-of-support carve-out. No existing sentence changed.

Corrections to existing text

8. The CISA pledge counts were re-fetched on 16 September 2026 and moved from 385 signers and 55 progress reports to 387 and 59, in the body, in the takeaway and in the sources block. The sources block already said these counts change and should be re-checked.
9. The Known Exploited Vulnerabilities catalogue version was updated from 2026.09.04 to 2026.09.16, which is the version every new CVE claim in this pass was checked against.

No other existing sentence was altered. Seven Key Takeaways were appended; none was removed or reworded except the pledge counts in the last original takeaway.