# Two Months Without Code: How Microsoft Halted Windows Development to Invent Modern Software Security
> In 1995-2001 the worms won. The Trustworthy Computing memo and the ten-week Windows Security Push that followed taught the industry how to ship secure software.
*Published: 2026-05-30*
*Canonical: https://paragmali.com/blog/two-months-without-code-how-microsoft-halted-windows-develop*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
Between 1995 and 2001, Microsoft shipped the most-used operating system on Earth into an Internet it was not architecturally prepared for. Concept, Melissa, ILOVEYOU, Code Red, Nimda, and Slammer demonstrated that reactive patching could not win the speed race with weaponized exploits. On Tuesday, January 15, 2002 at 5:22 PM Pacific, Bill Gates sent the roughly 1,500-word "Trustworthy computing" memo. On February 11, 2002, approximately 8,500 Windows engineers stopped writing features and spent about ten weeks and one hundred million dollars on threat modeling, banned-API review, fuzzing, and the first mandatory Final Security Review gate. The result was the Microsoft Security Development Lifecycle (SDL), and every secure-development framework the industry has standardized since (BSIMM, OWASP SAMM, ISO/IEC 27034, NIST SSDF, SLSA, CISA Secure by Design) traces back to it.
## 1. Two Months Without Code
On Monday, February 11, 2002, in Building 26 of Microsoft's Redmond campus, Brian Valentine -- Senior Vice President of the Windows Division -- told roughly 8,500 Windows engineers to stop writing features [@howard-lipner-push-2003] [@washtech-microsoft-100m] [@msft-news-valentine-mms-2002]. For the next ten weeks they would sit through mandatory secure-coding training, threat-model every component they owned, audit their code against a published banned-API list, and gate-review every change through a Final Security Review checkpoint that had not existed three weeks earlier [@howard-lipner-push-2003] [@lipner-acsac-2004]. The cost: about one hundred million dollars in foregone feature work [@washtech-microsoft-100m]. The order traced, precisely, to a 1,500-word email Bill Gates had sent twenty-seven days earlier at 5:22 PM Pacific [@gates-memo-wired] [@helpwithwindows-billg].
Stop and notice what that means. An operating-system vendor whose product ran on most business desktops on the planet ordered its largest engineering organization to *stop shipping the product* for two months. The lost revenue is the easy number. The hard number is the implicit admission: a company halts an engineering org of that size only when the cost of *not* halting is bigger.
What does a company have to lose before its CEO writes that order?
This article is the answer. It traces the seven-year run-up that made halting development the proportionate response, the memo that called the halt, the ten-week operation that followed, and the discipline that pattern became -- the discipline every secure-development framework on the industry shelf in 2026 traces back to.
It is also a quarrel with one sentence. The literal version of the article's working claim is this:
> **"Microsoft did not have a security team until January 15, 2002."**
That sentence is wrong in exactly the way every popular retelling of this era is wrong. Microsoft did have a security team. It had the Microsoft Security Response Center (MSRC), founded in 1998 and reachable from MS98-001 onward [@msrc-org] [@howard-lipner-push-2003]. It had the Secure Windows Initiative (SWI), a small in-house secure-development team running since around 2000 under Michael Howard [@howard-lipner-push-2003]. It had STRIDE, a categorized threat list written internally on April 1, 1999 by Loren Kohnfelder and Praerit Garg [@shostack-tm-book]. It had Howard and David LeBlanc's *Writing Secure Code*, published by Microsoft Press in November 2001 and reportedly required reading for every Microsoft engineer [@howard-leblanc-wsc]. The methodology, the books, the team, and the published threat list were all in the building.
By section 5, this article earns a stronger -- and defensible -- version of the literal claim. Hold the literal sentence loosely; the corrected one is worth more.
The story turns on six names you will meet in sections 3 and 4: **Concept** (July 1995), **Melissa** (March 1999), **ILOVEYOU** (May 2000), **Code Red** (mid-July 2001), **Nimda** (September 2001), and **SQL Slammer** (January 2003) [@fsecure-concept] [@cert-ca-1999-04-melissa] [@cert-ca-2000-04-iloveyou] [@caida-codered] [@cert-ca-2001-26-nimda] [@caida-slammer]. Each name is also a generation of attack. Each generation broke an assumption the previous defenses had quietly depended on. By the end of 2001, the cumulative effect was a vendor whose customers no longer believed it could keep them safe.
That is what a company loses before its CEO halts development. How it got there takes seven years to tell. Begin at the architectural starting line.
## 2. Two Windowses, Two Security Stories
The first surprise of the era is structural. There were two Windowses, and only one of them had a security model at all.
The **NT line** -- Windows NT 3.1 in July 1993, NT 3.5, NT 4.0 in 1996, Windows 2000 in February 2000 -- was the work of David Cutler's team, hired by Microsoft in August 1988 with about twenty colleagues from Digital Equipment Corporation [@zachary-showstopper] [@msft-lifecycle-products]. Cutler had led the VMS operating-system project at DEC, and he carried VMS's engineering discipline into NT: a formal kernel/executive separation, an [object manager](/blog/the-object-manager-namespace/) that treated every kernel-allocated thing as a named object with a security descriptor attached, and a small kernel component called the **Security Reference Monitor** whose only job was to consult that descriptor on every access attempt [@russinovich-solomon-iw2k] [@msft-access-control].NT was *patterned on VMS*, not literally inherited from it. DEC threatened legal action against Microsoft over the engineering similarities and Cutler's role; the parties resolved the dispute through the 1995 DEC-Microsoft alliance, in which Microsoft paid roughly $105 million (including $75 million to bolster DEC's NT service-and-support operation) and committed to keeping Windows NT supported on DEC's Alpha processor [@techmonitor-dec-microsoft-alliance] [@zachary-showstopper].
The **Win9x line** -- Windows 95 in August 1995, Windows 98 in June 1998, Windows Me in September 2000 -- shared a name and a Start menu with NT and almost nothing else [@msft-lifecycle-products]. Underneath, Win9x was a 32-bit graphical shell wrapped around the 16-bit DOS kernel. It had no SIDs, no per-object access control lists, no kernel-mediated access check, no concept of process identity at all. Every process ran with effective access to every file on disk, every key in the registry, and every other process's address space [@russinovich-solomon-iw2k].
The kernel component of Windows NT (and every NT-line OS since: 2000, XP, Vista, 7, 8, 10, 11) that performs the access check on a securable object. When a thread asks to open a file, the I/O manager hands the request to the object manager, which calls the SRM. The SRM compares the access token attached to the thread (which carries the user's SID and the SIDs of every group the user belongs to) against the security descriptor on the object (which carries the DACL listing who is allowed which access rights). If the DACL grants the requested rights, the open succeeds; otherwise it fails with `STATUS_ACCESS_DENIED`.
Every securable Windows kernel object carries a security descriptor with two access control lists. The **DACL** (Discretionary Access Control List) is an ordered list of ACEs (Access Control Entries) that grant or deny specific rights to specific principals. The **SACL** (System Access Control List) is the audit list; it tells the kernel which access attempts to log to the Security event log. The owner of an object can edit its DACL; only an administrator with the `SeSecurityPrivilege` right can edit its SACL.
A variable-length binary identifier that names a principal -- a user, a group, a computer, a service. SIDs have a defined structure (revision, identifier authority, sub-authorities) and are unique within their authority. Windows uses SIDs internally because they are stable across renames and translatable across trust boundaries; human-readable names like `DOMAIN\jdoe` are convenience labels that get resolved to SIDs before any access check runs.
When a thread on NT asks to open a file, the path through the kernel looks like this:
flowchart TD
A[User thread requests open] --> B[I/O Manager builds IRP]
B --> C[Object Manager looks up named object]
C --> D[Security Reference Monitor]
D --> E[Compare access token SIDs against DACL ACEs]
E --> F{"Granted rights ≥ desired access?"}
F -->|Yes| G[Return handle with granted access mask]
F -->|No| H[Return STATUS_ACCESS_DENIED]
That pipeline is what made NT, in principle, a hardened operating system from its first release in 1993. It is the same pipeline every NT-line Windows has executed for thirty-three years; Microsoft's current public reference still describes the same primitives [@msft-access-control].
So why was NT not, in practice, the hardened operating system the architecture promised?
The answer is the load-bearing observation of the era's first half: **the primitives existed; the defaults rendered them inert.** Through NT 3.1, NT 3.5, NT 4.0, and well into Windows 2000, the default DACL on huge swaths of the filesystem and registry was `Everyone: Full Control`. The `Everyone` SID matches every authenticated user and, depending on configuration, often the anonymous logon as well. A DACL that grants `Everyone: Full Control` is a permission check that always succeeds. Microsoft's documentation of the era is matter-of-fact about this: the defaults were preserved to maintain application-compatibility expectations carried over from the Win9x world, where applications had been written assuming no permission check at all [@russinovich-solomon-iw2k].
The Win9x side has no such defense-of-the-defaults story to tell, because Win9x had no access check to default. On a Win98 box, the file `c:\windows\system\kernel32.dll` was simply *a file*. Any program could open it, read it, write it, or rename it. The phrase "least privilege" did not apply, because there was no privilege to constrain.
This is the architectural starting line of the era. Two Windowses, two stories, one shared problem: the strongest version had a security model that defaults defeated, and the weakest had no security model to defeat in the first place. Both, in the tens of millions, were about to be connected to a public Internet that did not yet exist when either had been designed.
What happens when you connect that pair of architectures to that network is the next two sections.
## 3. The Attack Class That Cracked Office (1995-2000)
Open with a small artifact. Sometime in mid-1995, copies of a Microsoft CD-ROM shipped to customers carrying, by accident, the first widely distributed Word macro virus. It was called **Concept**. Its only payload was a benign dialog and a comment in the macro source that read `REM That's enough to prove my point` [@fsecure-concept] [@virusencyclopedia-concept].
That was the joke. Then the rest of the industry stopped laughing.
A program that infects documents (rather than executables) by hijacking the document format's embedded scripting language. Word's WordBasic in 1995 and VBA in 1997 could read and write files, manipulate the host application, and -- critically -- run automatically on document open via `AutoOpen` and on document save via `FileSaveAs`. A macro virus is the same shape as a classical file-infector virus, except its host file is `.doc` instead of `.exe` and its execution surface is the application that opens the document, not the operating system that runs the binary.
**VBScript** is a Microsoft scripting language, syntactically a subset of Visual Basic, designed for embedding in web pages (in Internet Explorer) and standalone scripts (run by WSH). **Windows Script Host** is the Windows component that executes scripts written in VBScript, JScript, or other registered languages, via the executables `wscript.exe` (windowed) and `cscript.exe` (console). WSH was first shipped with Windows 98 and was available as an optional add-on for NT 4.0 and Windows 95. It was on by default; a `.vbs` file double-clicked in Explorer ran in `wscript.exe` without further confirmation.
The era's three Office-style artifacts each carried a lesson the next one had to escalate past.
### Concept (July 1995)
Concept was a WordBasic macro virus written for Microsoft Word 6.x. On document open it ran an `AutoOpen` macro that copied itself into Word's global template `NORMAL.DOT`. Every document Word saved from that point on inherited the infection, because every `FileSaveAs` operation now ran through the infected template's hook [@fsecure-concept].First-in-the-wild detection of Concept is canonically dated to **July 1995**, per the Microsoft Defender Threat Encyclopedia and the Virus Encyclopedia [@defender-concept-encyclopedia] [@virusencyclopedia-concept]. The "September 1995" date often cited in retellings refers to CIAC Notes 95-12, the bulletin, not the first detection [@ciac-i-023-macro].
Concept was cross-platform: it infected Word for Windows 6.x/7.x and Word for Macintosh 6.x, because WordBasic was portable [@fsecure-concept]. By the time it was named and tracked, copies had shipped on at least one Microsoft CD-ROM and on training materials from at least one other software vendor [@ciac-i-023-macro].
The lesson hidden in Concept is bigger than the virus. Any application that ships with a Turing-complete macro language, an auto-execute hook, and a write-enabled global template ships an execution surface. The user did not have to "run a program"; opening a document *was* running a program, because the document carried the program inside it. That was the first time the popular distinction between "data" and "executable" failed at consumer scale.
### Melissa (March 26, 1999)
Four years later, that lesson met email.
CERT/CC's advisory CA-1999-04 records the moment: "At approximately 2:00 PM GMT-5 on Friday March 26 1999 we began receiving reports of a Microsoft Word 97 and Word 2000 macro virus" [@cert-ca-1999-04-melissa]. The virus was written in VBA (the successor to WordBasic that Office 97 introduced) by a New Jersey programmer named David L. Smith.
It carried the now-standard `AutoOpen` infection of `NORMAL.DOT`, but it added something Concept could not have done in 1995: it opened Microsoft Outlook through the MAPI interface, walked the first fifty entries of every address book it could read, and emailed the infected document to each one [@cert-ca-1999-04-melissa]. For good measure, it lowered Office's macro security settings on each infected machine, so the next infected document would run its macro without a prompt [@cert-ca-1999-04-melissa].
The propagation pattern is worth a diagram of its own:
sequenceDiagram
participant U as User
participant W as Word
participant N as NORMAL.DOT
participant O as Outlook MAPI
participant R as 50 recipients
U->>W: Open list.doc attachment
W->>W: Fire AutoOpen macro
W->>N: Infect NORMAL.DOT
W->>O: Read first address book
O-->>W: Return 50 entries
W->>R: Send list.doc to each
R->>U: Recipients open list.doc
Note over W,N: Loop repeats per recipient
The math of the loop is uncomfortable. If each infected user has at least one populated fifty-entry address book and a non-trivial fraction of recipients open the attachment, the early growth is geometric in fan-out. No spam filter of the era could outrun it, because the senders were not spammers -- they were the recipient's actual colleagues, sending a document they had actually edited, from a real email address with a real return path. Address-book amplification by trusted senders is, by definition, a self-amplifying email feedback loop.
Melissa's payload was deliberately benign (it inserted a Simpsons quote into the open document on certain dates), but its propagation forced corporate email shutdowns at a long list of Fortune 500 sites within seventy-two hours [@cert-ca-1999-04-melissa].Contemporaneous trade press reported shutdowns at Lockheed Martin, Lucent, Microsoft, and others. The CERT advisory itself describes a "widespread attack affecting a variety of sites" without naming specific companies. Smith was arrested April 1, 1999.
The lesson the industry should have read off Melissa: *a macro that can read the address book is not an Office decision; it is a platform decision*. Office let macros call Outlook because the COM-automation model invited it; Outlook let other applications read the address book because that was the entire point of MAPI. The trust boundary the user *thought* was around their inbox was, in API terms, around every other application running as the same user.
### ILOVEYOU (May 4-5, 2000)
Thirteen months later, the lesson generalized off the Office platform.
CERT/CC's advisory CA-2000-04 names the attachment: `LOVE-LETTER-FOR-YOU.TXT.vbs`, with a "Love Letter" subject line and a body asking the recipient to "kindly check the attached LOVELETTER" [@cert-ca-2000-04-iloveyou]. The `.vbs` extension matters. ILOVEYOU was not a Word macro virus.Popular retellings group Concept, Melissa, and ILOVEYOU as one continuous Office-macro story. They are not. ILOVEYOU was a **VBScript / Windows Script Host email worm**, executed by `wscript.exe` when the user double-clicked the attachment in Outlook [@cert-ca-2000-04-iloveyou]. The execution surface is WSH, not Office.
It was a VBScript file -- a script in plain text, executed by `wscript.exe`. Windows Explorer's default setting, "hide extensions for known file types," hid the `.vbs` suffix from the filename column. The user saw `LOVE-LETTER-FOR-YOU.TXT`, an apparently inert text file, and double-clicked it. Explorer handed the file to its registered handler, which was `wscript.exe`, which ran it.
Once running, the script copied itself into the Windows system directory, registered itself to run at every boot, overwrote files with selected extensions (`.jpg`, `.mp3`, `.vbs`), and -- like Melissa -- mailed itself to every address it could reach through Outlook. BBC News, datelined Thursday May 4, 2000 19:28 GMT, recorded the outbreak appearing first in Hong Kong, sweeping the US State Department, CIA, FBI, Pentagon, White House, and Congress, and the UK House of Commons, the Danish parliament, the Swiss federal government, and banks across Europe within hours, with reports pointing to a Philippine origin [@bbc-love-bug-2000-05-04] [@cert-ca-2000-04-iloveyou]. Trade-press damage estimates of "tens of millions" of infected machines and "billions of dollars" in cleanup were folk-knowledge of the era; the underlying classification as a VBScript / WSH email worm is what survives in the primary record [@cert-ca-2000-04-iloveyou].
The lesson ILOVEYOU should have forced: Windows Script Host was on by default, hidden extensions concealed the executable surface, and Outlook's auto-execute-attachments behavior treated `.vbs` like any other attachment. Three Microsoft platform decisions, each individually defensible, composed into a one-double-click remote code execution path on a freshly installed Windows 98 machine.
The three artifacts collapse into a single comparison table:
| Year | Name | Execution surface | Propagation vector | On by default? | Primary lesson |
|---|---|---|---|---|---|
| July 1995 | **Concept** [@fsecure-concept] [@virusencyclopedia-concept] | Word WordBasic macro | Infected document opened in Word | Yes (macro auto-exec) | A document is an executable when the application supports macros. |
| March 1999 | **Melissa** [@cert-ca-1999-04-melissa] | Word VBA macro | Word + Outlook MAPI; 50 address-book entries per infected host | Yes (macro auto-exec, MAPI access) | A macro with address-book access creates a self-amplifying email storm by trusted senders. |
| May 2000 | **ILOVEYOU** [@cert-ca-2000-04-iloveyou] | VBScript via Windows Script Host (`wscript.exe`) | Outlook attachment, double-extension hidden by Explorer default | Yes (WSH on by default, extensions hidden) | The "Office macro" attack class generalized to any double-clickable script the platform interpreted. |
Document-as-execution-surface had a known fix shape from the moment Concept shipped: disable auto-execute, prompt the user, and -- eventually -- block by default. The block-by-default fix, for [Office VBA macros](/blog/attack-surface-reduction-rules-the-quiet-layer-that-stopped-/) downloaded from the internet, did not fully ship until February 2022, **twenty-seven years after Concept** [@ms-learn-internet-macros-blocked]. Section 9 walks the deprecation playbook that delay is evidence for.
But document execution is only half of the era's attack story. What happens when the execution surface is not a document the user opened, but a network port a worm reached without the user doing anything at all?
## 4. The Attack Class That Cracked the Server (2001-2003)
Two dates frame the whole story.
**June 18, 2001:** Microsoft publishes Security Bulletin MS01-033, "Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise." The bulletin patches an unchecked stack buffer in `idq.dll`, the Indexing Service ISAPI extension loaded by Internet Information Services (IIS) 4.0 and 5.0. A specially crafted HTTP `GET` to a URL ending in `.ida` can overflow the buffer and execute attacker-supplied code in the IIS worker process, which runs as `LocalSystem` [@ms01-033-idq].
**July 19, 2001:** thirty-one days later, the second-generation Code Red worm saturates roughly **359,000 IIS servers** in under fourteen hours [@caida-codered] [@cert-ca-2001-19-codered]. The worm reaches its victims via a single HTTP GET. No user clicks. No email attachment. No double-click. A web server with port 80 open to the Internet and the unpatched `idq.dll` is, by definition, *already* listening for the attack.
A computing monoculture exists when a large population of independently administered hosts run identical software with identical defaults. The security significance is statistical: a single vulnerability discovered in the monoculture's shared software is, in expectation, exploitable against the entire population. The 2001-2003 Windows-server worms (Code Red, Nimda, Slammer) are the canonical case studies; CAIDA's Code Red measurement and Moore et al.'s Slammer measurement are the empirical anchors that made the monoculture argument quantitative rather than rhetorical [@caida-codered] [@caida-slammer].
What kind of defense survives a thirty-one-day patch-to-mass-exploitation window? The next seven months answer that question four different ways.
### Code Red I (mid-July 2001)
A Northern California security boutique called eEye Digital Security discovered and reverse-engineered the worm. Marc Maiffret and Ryan Permeh named it "Code Red" after the Mountain Dew flavor they were drinking through the analysis [@eeye-codered-ii].Popular retellings sometimes date the discovery to July 13, 2001. The eEye back-reference in their August 4, 2001 Code Red II advisory points at advisory `AL20010717` -- **July 17, 2001** [@eeye-codered-ii]. "Mid-July 2001" or "July 17, 2001" is the better-attested date. The Mountain Dew naming detail comes from contemporaneous interviews with the eEye analysts, not the AL20010804 advisory itself.
The initial Code Red variant -- "Code Red v1" -- carried a fixed-seed random-number generator in its IP scanner. Because every infected host generated the same sequence of scan targets, the worm spent most of its scanning budget on the same small set of IP addresses, and its spread was bounded. It was annoying. It was not yet a measurement event.
That changed when somebody fixed the scanner.
### Code Red v2 (July 19, 2001)
Code Red v2 was a rewritten worm using the same MS01-033 vulnerability but with a proper random scanner. The fix was tiny -- a different seed and a real entropy source -- and the consequences were huge. The CAIDA measurement, published by Moore, Shannon, and Brown in the Internet Measurement Workshop 2002, recorded the outbreak: **"On July 19, 2001, more than 359,000 computers connected to the Internet were infected with the Code-Red (CRv2) worm in less than 14 hours"** [@caida-codered] [@cert-ca-2001-19-codered]. The peak rate was over 2,000 newly infected hosts per minute.
The exploit path on each victim looked like this:
sequenceDiagram
participant W as Worm host
participant V as Victim IIS
participant I as idq.dll
participant S as LocalSystem shell
W->>V: HTTP GET /default.ida + long URL
V->>I: ISAPI dispatch to Indexing Service
I->>I: Buffer overflow in URL parse
I->>S: Shellcode runs in LocalSystem context
S->>S: Patch idq.dll in memory, install worm body
S->>W: Spawn 100 scanner threads
Note over W,V: Each thread tries random IP:80, repeat
The lesson that should have been read off Code Red v2 was a property of the population, not of the worm. The vulnerable population was large (anyone running IIS 4.0 or 5.0 with default modules enabled and the MS01-033 patch not applied), identical (every IIS install shipped the same `idq.dll`), and reachable (TCP port 80 is by definition Internet-facing on a web server). That set of properties is the operational definition of a monoculture, and Code Red v2 was its first quantitative case study.
### Code Red II (August 4, 2001)
Sixteen days after Code Red v2 saturated the IIS population, a *different* worm appeared with a confusing name. "Code Red II" reused the MS01-033 vulnerability and the same `.ida` injection vector, but the rest of it was unrelated to v1 or v2. eEye's August 4, 2001 analysis by Permeh and Maiffret documents the difference: where the earlier worms had a self-contained scanner-and-payload binary in memory, Code Red II dropped a copy of `cmd.exe` named `root.exe` into the IIS `/scripts` and `/msadc` directories, then dropped a trojanized `explorer.exe` that re-enabled the C: and D: drives as the IIS virtual roots `/c` and `/d` [@eeye-codered-ii].
The practical effect: any HTTP GET to `/scripts/root.exe?/c+dir` on a compromised host returned a directory listing of the victim's `C:\` drive, executed in the LocalSystem context. A permanent, anonymous, remote shell, reachable by anyone who knew the URL [@eeye-codered-ii].
The lesson Code Red II adds: *one worm's residual artifact is another worm's propagation vector*. Patching MS01-033 closed the door that let Code Red II in. It did not close the doors Code Red II left open behind it. A web server infected by Code Red II before its operator patched MS01-033 still had `root.exe` waiting in `/scripts`, indefinitely. The patching mental model -- "apply the patch, the bug is fixed" -- mismodels the state.
### Nimda (September 18, 2001)
Six weeks later, exactly that mismodeling was exploited.
The Nimda worm appeared on September 18, 2001, one week after the September 11 attacks, which the worm's name initially fed conspiracies about; "nimda" is "admin" backwards. The CERT/CC advisory CA-2001-26 records its four propagation vectors:
> "(a) from client to client via email, (b) from client to client via open network shares, (c) from web server to client via browsing of compromised web sites, (d) from client to web server via active scanning for and exploitation of various Microsoft IIS 4.0 / 5.0 directory traversal vulnerabilities" [@cert-ca-2001-26-nimda].
flowchart LR
A[Infected client] -->|Email with readme.exe| B[New client via IE MIME bug MS01-020]
A -->|Write to writable share| C[New client via SMB share]
D[Infected IIS server] -->|Inject JS into served pages| E[New client via web browse]
A -->|HTTP scan + Unicode traversal| F[New IIS server via dir traversal]
F -->|Reuse Code Red II root.exe if present| F
F --> D
Some retellings give Nimda "five" propagation vectors, conflating distinct sub-paths or counting the reuse of Code Red II's `root.exe` as a separate vector. CERT's canonical taxonomy, reproduced verbatim above, is four [@cert-ca-2001-26-nimda]. The fifth-vector phrasing in popular retellings is folk-knowledge.
The connected-graph structure matters. The patch for the IIS Unicode directory-traversal bug (MS00-078, originally posted October 17, 2000) had been available for eleven months [@ms00-078-iis-traversal]. The patch for the IE MIME-handling bug (MS01-020, originally posted March 29, 2001) had been available for nearly six months [@ms01-020-ie-mime]. The MS01-033 patch behind Code Red and Code Red II had been available for three months [@ms01-033-idq]. Microsoft shipped the cumulative remediation as MS01-044 [@cert-ca-2001-26-nimda]. Every individual hole had been a known, patched single-issue vulnerability. Nimda took the graph of those holes and walked it.
The lesson is structural. Response treats vulnerabilities as point fixes. Nimda's empirical evidence was that, in a sufficiently large monoculture, the unpatched subsets of multiple vulnerabilities had become *connected*. Patching is a per-host, per-vulnerability operation; the attacker's view is the union over all hosts of the union over all unpatched vulnerabilities. The latter is a much larger surface.
### SQL Slammer (January 25, 2003, 05:30 UTC)
Sixteen months after Nimda, the era's capstone arrived in the form of a 376-byte UDP datagram.
Slammer (also called Sapphire) exploited a buffer overflow in the SQL Server Resolution Service that Microsoft had patched in MS02-039, **six months earlier**. The payload was small enough to fit in a single UDP packet, and the protocol it targeted (UDP port 1434) was connectionless, so each scan was one packet, sent at line rate. The CAIDA measurement -- Moore, Paxson, Savage, Shannon, Staniford and Weaver, *IEEE Security & Privacy* 2003 -- is the primary record:
> "Sapphire began to infect hosts slightly before 05:30 UTC on Saturday, January 25 (2003). [...] doubled in size every 8.5 seconds. [...] infected more than 90 percent of vulnerable hosts within 10 minutes [...] at least 75,000 hosts, perhaps considerably more [...] over 55 million scans per second." [@caida-slammer]
Popular retellings often round Slammer's reach to "75% of vulnerable SQL servers." The CAIDA primary measurement is **~75,000 hosts** as the lower bound, and "more than 90 percent of vulnerable hosts within 10 minutes" as the saturation percentage [@caida-slammer]. The two figures are not the same.
The 8.5-second doubling time is the load-bearing number. Worm spread under random-constant-spread (RCS) scanning follows a logistic curve: exponential at the start, saturating as the worm runs out of vulnerable targets. The differential equation is well behaved and was modeled in detail by Stuart Staniford, Vern Paxson, and Nicholas Weaver at USENIX Security 2002, in a paper that predicted (six months before Slammer) that worms with sufficiently high scan rates would saturate the global vulnerable population in minutes, not hours [@staniford-paxson-weaver-2002].
Plug the parameters in and watch it happen:
{`
// SI-style worm spread under random constant scanning.
// dN/dt = K * N * (1 - N/V)
// Where:
// N(t) = infected population at time t (seconds)
// V = total vulnerable population
// K = effective contact rate per infected host per second
// = (scans per second per host) * (V / address-space size)
//
// Slammer defaults (CAIDA Moore et al. 2003):
// ~75,000 vulnerable MSSQL hosts (lower bound)
// ~26,000 packets/sec sent from a typical infected host before bandwidth saturation
// IPv4 routable space ~ 2^32 addresses, of which ~2^31 reachable
//
// Result: doubling time ~8.5 s, ~90% saturation in ~10 min.
const V = 75000;
const scansPerSecPerHost = 26000;
const addressSpace = Math.pow(2, 31);
const K = scansPerSecPerHost * (V / addressSpace);
const dt = 1;
let N = 1;
let lastPrint = 0;
for (let t = 0; t <= 700; t += dt) {
const dN = K * N * (1 - N / V);
N += dN * dt;
if (t - lastPrint >= 30 || (N >= V * 0.9 && lastPrint < t)) {
const pct = (100 * N / V).toFixed(1);
console.log(\`t=\${t.toString().padStart(3)}s N=\${Math.round(N).toString().padStart(6)} (\${pct}%)\`);
lastPrint = t;
if (N >= V * 0.999) break;
}
}
`}
The simulator says what CAIDA measured: saturation, regardless of where the human patch process starts from, in roughly ten minutes. Read that twice. There is no version of "patch faster" that wins this race. The race ends before a human operator can log in, open the bulletin, download the binary, and apply it. Even if every operator on the planet had been at their console with the patch staged and ready, they could not have outrun an 8.5-second doubling.
The logistic equation $dN/dt = KN(1 - N/V)$ has closed-form solution $N(t) = V / (1 + (V/N_0 - 1) e^{-Kt})$. The doubling time near the start (when $N \ll V$) is $\tau = \ln(2)/K$. For Slammer's measured doubling time of 8.5 seconds, $K = \ln(2)/8.5 \approx 0.0815$ per second. The time to reach 90% of $V$ from a seed of $N_0 = 1$ is $t_{90} = (1/K) \ln((V - N_0)/(N_0 \cdot V/(0.9V) - N_0)) \approx (1/K) \ln(0.9V/0.1) \approx (1/0.0815) \ln(9V)$. For $V = 75{,}000$, $t_{90} \approx 12.3 \cdot \ln(675{,}000) \approx 165$ seconds, plus the time spent in the slow start-up phase from $N_0=1$ to a few hundred infections. The empirical 10-minute figure includes both phases. The structural result is parameter-insensitive: any worm with a per-host scan rate that produces a sub-minute doubling will saturate before any human operator can intervene.
If the attacker's loop (find bug, weaponize, propagate) is now structurally faster than the defender's loop (find bug, ship patch, customer installs), then "patch faster" stops being the answer and a different answer becomes necessary. The only durable defense against a sub-minute doubling time is to **ship fewer vulnerabilities to begin with**. That requires changes upstream of the patch pipeline -- in how code is written, reviewed, tested, and signed off.
Which is what the advisory version of secure development had been preaching since 1975.
So why was Microsoft still shipping `idq.dll`-class bugs in 2001?
## 5. What Microsoft Already Had (and Why It Wasn't Enough)
This is the section that confronts the literal thesis head-on. Take an inventory of what existed, in Microsoft and outside it, on January 1, 2002:
- **[Microsoft Security Response Center (MSRC)](/blog/windows-security-boundaries-the-document-that-decides-what-g/).** Founded in 1998 to coordinate vulnerability disclosure and ship security bulletins (the numbered series MS98-001 onward) [@msrc-org] [@howard-lipner-push-2003]. The org chart was real; so was the bulletin pipeline; so was the working relationship with CERT/CC and external researchers.
- **Secure Windows Initiative (SWI).** Started around 2000 as a small in-house secure-development team, led by Michael Howard inside the Windows division [@howard-lipner-push-2003].
- **STRIDE.** A categorical list of threat types (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), written by Loren Kohnfelder and Praerit Garg in an internal Microsoft memo dated April 1, 1999, titled "The Threats to Our Products." The memo is no longer hosted on Microsoft's own site, but it has been publicly preserved at Adam Shostack's archive [@shostack-stride-memo-archive], with an independent mirror at FIRST [@first-stride-memo-mirror]; Shostack's 2014 book remains the authoritative chain-of-custody analysis [@shostack-tm-book].
- **A Microsoft-authored secure-coding book.** Michael Howard and David LeBlanc's *Writing Secure Code*, Microsoft Press, first edition November 2001 -- two months before the memo. Bill Gates is widely reported to have required Microsoft engineers to read it; the book itself documents the banned-API list, threat-modeling templates, and STRIDE walkthroughs that the Push later mandated [@howard-leblanc-wsc].
Outside Microsoft, the substrate was older still:
- **Saltzer and Schroeder.** Jerome Saltzer and Michael Schroeder, "The Protection of Information in Computer Systems," *Proceedings of the IEEE* 63(9), September 1975. Eight design principles -- economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability -- still the textbook starting point [@saltzer-schroeder-1975].
- **The Orange Book.** DoD Trusted Computer System Evaluation Criteria (DoD 5200.28-STD), 1983 and reissued 1985. Graded assurance levels D, C1, C2, B1, B2, B3, A1. The pre-existing vocabulary of "trusted computing" that the Gates memo deliberately echoed and broadened to "trustworthy" [@tcsec-orange-book].
- **OpenBSD audit culture.** Theo de Raadt's OpenBSD project, since the summer of 1996, with a permanent audit team that the project's own page describes verbatim: "Our security auditing team typically has between six and twelve members who continue to search for and fix new security holes. We have been auditing since the summer of 1996" [@openbsd-security].
- **Attack trees.** Bruce Schneier, "Attack Trees," *Dr. Dobb's Journal*, December 1999. A formal methodology for describing system security as goal-rooted decision trees with AND/OR composition and per-leaf cost annotations [@schneier-attack-trees-1999].
- **CERT/CC.** Carnegie Mellon's Computer Emergency Response Team, founded November 1988 in response to the Morris worm. Author of the CA-1999-04 / CA-2001-19 / CA-2001-26 / CA-2000-04 advisories that frame the previous two sections [@cert-ca-1999-04-melissa] [@cert-ca-2001-19-codered] [@cert-ca-2001-26-nimda] [@cert-ca-2000-04-iloveyou].
Lay those rows out as a table and look at the right-most column:
| Discipline component | Who had it | When | Release-blocking authority? |
|---|---|---|---|
| Foundational principles | Saltzer and Schroeder [@saltzer-schroeder-1975] | 1975 | No (academic publication) |
| Graded assurance criteria | DoD Orange Book [@tcsec-orange-book] | 1985 | No (procurement criterion only) |
| Response coordination | CERT/CC [@cert-ca-1999-04-melissa] | 1988 | No (external coordinator) |
| Audit-driven engineering | OpenBSD [@openbsd-security] | 1996 | **Yes -- within OpenBSD only** |
| Vendor response center | MSRC [@msrc-org] [@howard-lipner-push-2003] | 1998 | No (post-release) |
| Internal threat categorization | Kohnfelder and Garg STRIDE memo [@shostack-tm-book] [@shostack-stride-memo-archive] | April 1999 | No (advisory) |
| External threat-modeling methodology | Schneier attack trees [@schneier-attack-trees-1999] | December 1999 | No (publication) |
| In-house secure-development team | SWI (Howard) [@howard-lipner-push-2003] | ~2000 | No (advisory) |
| Secure-coding book | Howard and LeBlanc [@howard-leblanc-wsc] | November 2001 | No (recommendation) |
The load-bearing column is the last one. Every row except OpenBSD-within-OpenBSD reads **No**, and OpenBSD's "Yes" is a special case -- the auditors and the engineers were the same self-selected community on a small homogeneous codebase shipped without a revenue obligation.
That column is the article's first aha moment.
> **Key idea:** Microsoft was not the first to articulate secure-systems-design principles (Saltzer and Schroeder, 1975). It was not the first to do audit-driven engineering (OpenBSD, 1996). It was not the first to popularize threat modeling externally (Schneier, December 1999), have an internal threat-categorization framework (Kohnfelder and Garg, April 1999), or run a security-response organization (CERT/CC since 1988; MSRC since 1998). What Microsoft *was* first to do, on January 15, 2002 and operationalized on February 11, 2002, was apply **release-blocking executive authority across an entire dominant-platform vendor** to make secure development a non-negotiable engineering gate.
The corrected sentence is harder to fit on a magazine cover. It is also defensible.
What did "advisory" mean in 2000-2001 Microsoft? Steve Lipner's ACSAC 2004 paper is explicit: in the pre-Push state, an engineering manager could decline a security review with no organizational consequence. SWI could *recommend*. SWI could not *require*. The Microsoft-authored book sat on every engineer's desk and the threat-categorization memo had been internal for almost three years -- and Code Red v1, Code Red v2, Code Red II, and Nimda all exploited code that had shipped *after* SWI's founding [@howard-lipner-push-2003] [@lipner-acsac-2004].
That is the empirical evidence the era ran on. Methods without authority did not stop the worms.
"Microsoft was not the first to articulate, audit, popularize, categorize, or respond. Microsoft was the first to make secure development non-negotiable at desktop-monopoly scale."
So if the methods, the books, the threat-modeling framework, the response center, the engineers, and the public peer pressure were all already there, what changed at 5:22 PM Pacific on Tuesday, January 15, 2002?
## 6. The Memo (January 15, 2002)
Open with the email header itself, preserved verbatim by Wired's republication and the Help With Windows mirror, both of which kept the original `From:`, `Sent:`, `To:`, `Subject:` block intact:
```
-----Original Message-----
From: Bill Gates
Sent: Tuesday, January 15, 2002 5:22 PM
To: Microsoft and Subsidiaries: All FTE
Subject: Trustworthy computing
```
[@gates-memo-wired] [@helpwithwindows-billg]
Popular retellings sometimes describe the memo as a "5 AM email Bill Gates wrote in the dark." The preserved mail headers above are unambiguous: the memo was sent at **5:22 PM Pacific** on a Tuesday afternoon, with full distribution to "Microsoft and Subsidiaries: All FTE" -- every full-time employee of the company [@gates-memo-wired] [@helpwithwindows-billg]. The 5 AM phrasing is folk-knowledge; the headers preserved by Wired are the primary record.
The memo runs roughly 1,500 words. It is structured around four pillars -- Security, Privacy, Reliability, and Business Integrity -- that, the memo argues, must take precedence over feature work whenever the two are in tension [@gates-memo-wired]:
| Pillar | What the memo asks for |
|---|---|
| **Security** | Code resilient to attack; products that ship secure out of the box, by default, in deployment. |
| **Privacy** | Products that handle customer data with informed consent and minimal collection. |
| **Reliability** | Products that fail predictably and recover gracefully; uptime as a measurable property. |
| **Business Integrity** | Transparent dealings; respect for the customer relationship across the company's behavior, not just its products. |
Read the four together and the structure is not a list of features. It is a redefinition of what shipping the product *means*. A Windows release in 2001 shipped when the feature list closed; the memo proposed that, going forward, a Windows release ships when feature list, security posture, privacy posture, reliability posture, and the company's standing with the customer were all simultaneously acceptable.
The operational anchor of the memo is one sentence every subsequent retelling quotes, and that the Push directly inherited as its decision rule:
"When we face a choice between adding features and resolving security issues, we need to choose security." -- Bill Gates, "Trustworthy computing" memo, January 15, 2002 [@gates-memo-wired]
Note what the memo *did not do*. It did not name an algorithm. It did not invent STRIDE; STRIDE had been internal for two and a half years already [@shostack-tm-book]. It did not write `banned.h`; the banned-API list had been in Howard and LeBlanc's book on bookshelves for two months [@howard-leblanc-wsc]. And, contrary to a common retelling, it did not delay the launch of Visual Studio .NET.
Visual Studio .NET launched on schedule on **February 13, 2002**, four weeks after the memo, at the VSLive! 2002 Conference in San Francisco, with Bill Gates delivering the keynote address [@msft-news-vsnet-launch-2002]. The December 2001 work the retrospectives sometimes call a "delay" was a *pre-launch security review* of the .NET runtime; the memo references that review by name as the **template** for what the company was about to do across every product [@gates-memo-wired]. The "delayed by security" framing is folk-knowledge; the memo itself describes VS .NET's December review as a success story.
What the memo *did* do was supply the one input every other piece on the table had been missing: **executive authority, top-down, to halt feature work on security grounds without arguing about it.**
To see why that is the operational form of the memo's contribution, compare it to Gates's two other priority memos. The "Internet Tidal Wave" of May 26, 1995 redirected Microsoft toward the web; the company restructured around online services and browser strategy in its wake [@gates-tidal-wave-bbc-pdf]. The **.NET / NGWS strategy memo**, delivered alongside Gates's Forum 2000 keynote on **June 22, 2000**, redirected the company toward managed code and a unified runtime; Visual Studio .NET, the CLR, ASP.NET, and ADO.NET all trace to it.Common retellings date the .NET strategy memo to 1999. The Microsoft News Center record places the NGWS / .NET unveiling at Forum 2000 on **June 22, 2000**; the strategy was branded "Next Generation Windows Services" before the .NET name stuck. The 1999 dating slips in because the underlying COM-runtime work began earlier, but the company-wide priority memo is a 2000 document.
Both pointed Microsoft at something new. Trustworthy Computing was different in shape. It did not redirect the company toward something new. It *halted* the company in place. The pillars were not a roadmap; they were a precondition. That structural difference -- *stop, before you start anything else* -- is what gave the Push its character.
The memo was the discrete institutional moment. What it required next was the operationalization step that converted it from rhetoric into engineering. That step took twenty-seven days to start and roughly ten weeks to run.
## 7. The Windows Security Push (February-April 2002)
The mechanics come from Michael Howard and Steve Lipner's IEEE *Security and Privacy* paper of January-February 2003, "Inside the Windows Security Push," and from Lipner's December 2004 ACSAC paper "The Trustworthy Computing Security Development Lifecycle." Stripped of the framing, the numbers are:
- Feature work in the Windows Division halted on or about **February 11, 2002** [@howard-lipner-push-2003].
- The Push ran for approximately **ten weeks**, through April 2002 [@howard-lipner-push-2003].
- The participating headcount was approximately **8,500 Windows engineers** [@howard-lipner-push-2003].The round figure of "10,000 engineers" in many retrospectives is a company-wide aggregate that includes the *serial* Office, .NET, and SQL Server pushes that followed through 2002-2003. The Windows-only Push figure from the Howard and Lipner primary is **~8,500**; the trade-press corroboration (Washington Technology, July 2002) cross-references Gates's own July 19, 2002 internal newsletter [@howard-lipner-push-2003] [@washtech-microsoft-100m].
- The total cost in foregone feature work was approximately **\$100 million** [@washtech-microsoft-100m] [@howard-lipner-push-2003].
- The measurable outcome was approximately a **50% reduction in publicly reported security vulnerabilities** for Windows Server 2003 over comparable post-release windows versus Windows 2000 [@howard-lipner-push-2003].The ~50% figure is per-window externally-discovered vulnerability counts, per Howard and Lipner 2003 -- *not* per-KLoC defect density. The narrative role (measurable post-release improvement) holds either way, but the caveat matters for readers reusing the number.
The Push pipeline looked like this:
flowchart LR
A[Mandatory training: Howard, Lipner, LeBlanc as instructors] --> B[STRIDE threat model per component]
B --> C[Banned-API audit against banned.h and strsafe.h]
C --> D[Fuzz testing of network-facing components]
D --> E[Final Security Review gate]
E --> F[Release approval or block]
Three of the boxes in that pipeline need definitions, because they are the load-bearing terms the rest of the article and every SDL descendant inherit.
A C header authored at Microsoft during and after the Push that re-declares roughly forty unsafe C runtime functions (`strcpy`, `strcat`, `gets`, `sprintf`, `_snprintf`, `wcscpy`, `_mbscpy`, and more) as compile-time errors. The pattern is a `#pragma deprecated` plus a `#define` that expands to an undefined symbol, so any source file that includes `banned.h` and then calls a banned function fails to compile. The descendant in Microsoft's current Windows driver toolchain is the static-analyzer warning **C28719**, which release-gates Windows driver submissions to this day [@msft-c28719].
A safer-by-default replacement string-handling API set introduced by Microsoft alongside `banned.h`. The `Strsafe.h` header (and the Win32 reference page that still ships in Microsoft Learn) defines `StringCbCopy`, `StringCbCat`, `StringCbPrintf`, `StringCchCopy`, `StringCchCat`, `StringCchPrintf`, and their wide-character variants. Every function takes an explicit destination-buffer size and returns an `HRESULT` so the caller can detect truncation rather than overrun [@msft-strsafe]. The C11 `_s` family (`strcpy_s`, `strcat_s`, `sprintf_s`) is the standards-track parallel.
The release-blocking sign-off step at the end of the SDL pipeline. Before a product can ship, an FSR examines the threat model, the residual vulnerabilities, the banned-API audit results, the fuzz-test coverage, the static-analysis warnings, and the operational response plan, and decides whether the release meets the security bar. A failed FSR blocks the release. The FSR is the single component that converts every preceding "should" into a hard "must" -- it is where the advisory pipeline becomes the mandatory one [@lipner-acsac-2004] [@howard-lipner-sdl-book].
Place the same banned-API substitution that every Windows engineer learned that spring next to its FSR-approved replacement, with the surviving 2026 compiler-enforced warning called out:
{`
// BEFORE THE PUSH -- this compiles, and overflows if src is too long.
// C runtime; allowed in C89; the entire bug class behind Code Red et al.
void copyName_BANNED(char* dst, const char* src) {
// strcpy(dst, src);
// After banned.h is included, the above line FAILS TO COMPILE:
// error C4996: 'strcpy': This function or variable may be unsafe.
// error C28719: Banned API Usage: strcpy is a Banned API.
}
// AFTER THE PUSH -- this is the FSR-approved replacement.
// strsafe.h, mandatory after February 2002 for Windows code.
// Microsoft's C28719 still release-gates Windows drivers in 2026.
function copyName_OK(dst, dstSize, src) {
// StringCbCopy(dst, dstSize, src);
// Returns S_OK on success, STRSAFE_E_INSUFFICIENT_BUFFER on truncation.
// The compiler knows dstSize; the static analyzer can prove the bound.
console.log('FSR-approved: explicit destination size, returns HRESULT.');
}
copyName_OK('buffer', 16, 'David Cutler');
`}
The substitution is the entire engineering theme of the Push in one line. `strcpy(dst, src)` is undecidable in the general case: you cannot prove from the call site that `src` fits in `dst` without information the call site does not have. `StringCbCopy(dst, dstSize, src)` is mechanically checkable: the destination size is explicit, the function returns truncation as a recoverable error, and a static analyzer can verify the bound at every call site. The class of bugs behind Code Red did not become *easier* to write; it became *uncompilable*.
The state change is best shown as a comparison table:
| Discipline component | Pre-Push state | Post-Push state |
|---|---|---|
| Training | Opt-in; not all engineers attended | Mandatory across the Windows Division [@howard-lipner-push-2003] |
| Threat modeling | Per-team optional | Per-component mandatory; STRIDE-driven [@howard-lipner-push-2003] |
| Banned-API enforcement | Recommended in the SWI guidance | Compile-time error via `banned.h`; replacement via `strsafe.h` [@msft-strsafe] [@msft-c28719] |
| Code review | Voluntary | Release-gate via Final Security Review [@lipner-acsac-2004] |
| Authority | Advisory (SWI could recommend) | Release-blocking (FSR could block) [@lipner-acsac-2004] |
| Measurable outcome | None published | ~50% reduction in publicly reported vulnerabilities, WS2003 vs Win2000 [@howard-lipner-push-2003] |
The right-hand column is, line by line, the same activities the left-hand column lists. Training is training. Threat modeling is threat modeling. The banned-API list is the same list LeBlanc and Howard had been publishing for years. Static analysis is static analysis. What changed in every row is the verb: from "may," "should," and "recommended" to "must," "shall," and "release-blocking."
> **Key idea:** The breakthrough was organizational, not technical. The Push used the same training material, the same banned-API list, the same threat-modeling framework, and the same code-review checklist that SWI, Howard, LeBlanc, and Schneier had been writing for two years. What changed was the signoff power. Training became mandatory; threat modeling became per-component-mandatory; banned APIs became compile-time errors; code review became a release gate; and the Final Security Review acquired the authority to block a ship date. The Push did not invent new methods. It gave the existing methods executive authority.
> **Note:** Same checklists, different signoff power. That single sentence is the unit of work the Push did. Every other secure-development framework on the industry shelf in 2026 is, organizationally, a restatement of that unit at different scales: BSIMM observes how vendors did it, OWASP SAMM prescribes how to do it, NIST SSDF mandates it for U.S. federal suppliers, ISO/IEC 27034 makes it certifiable. The technology was downstream of the authority [@bsimm-home] [@owasp-samm-model] [@nist-ssdf-218] [@iso-27034-1].
Ten weeks of training is one event. A discipline is a *repeatable* event. The Push needed to be codified into something a product team could *do* on every release.
## 8. What the Discipline Became: The SDL Lineage (2002-2006)
Codification ran in two steps.
The first step was Steve Lipner's ACSAC 2004 paper, "The Trustworthy Computing Security Development Lifecycle," the first formal *external* description of the SDL as a multi-phase release-engineering process [@lipner-acsac-2004]. ACSAC is a peer-reviewed venue with a security-practitioner audience; the paper put the program on the academic record and started the citation chain.
The second step was the book. Howard and Lipner, *The Security Development Lifecycle*, Microsoft Press 2006 (ISBN 978-0-7356-2214-2) [@howard-lipner-sdl-book]. The book documents every phase, every checklist, every threat-modeling template, every banned-API entry, every FSR criterion. It is what made the methodology *exportable*: an organization not named Microsoft could pick up the book and run an SDL-shape program of its own.
A software-engineering process model that integrates security activities into every phase of a product release. The canonical Microsoft formulation, in the 2006 Howard and Lipner book, is a seven-phase pipeline: Training, Requirements, Design (with mandatory STRIDE threat modeling), Implementation (with banned-API enforcement and mandatory static analysis), Verification (fuzz testing and dynamic analysis), Release (Final Security Review and a signed-off response plan), and Response (feeds back into MSRC). The current Microsoft public formulation organizes the same activities as 10 practices spanning 5 lifecycle stages: Design, Code, Build and Deploy, Run, and Zero Trust governance [@msft-sdl-practices] [@msft-sdl-overview].
The SDL phase pipeline in its canonical 2006 form:
flowchart LR
A[Training] --> B[Requirements]
B --> C[Design: STRIDE threat modeling]
C --> D[Implementation: banned-API + static analysis]
D --> E[Verification: fuzz + dynamic analysis]
E --> F[Release: Final Security Review]
F --> G[Response: MSRC]
G -.feedback.-> A
The current Microsoft SDL has shifted with the industry. The 2026 public formulation organizes the same activities as ten practices spanning five lifecycle stages: Design, Code, Build and Deploy, Run, and Zero Trust governance [@msft-sdl-practices] [@msft-sdl-overview]. Practices 1, 3, and 10 (security standards, threat modeling, training) map directly back to the 2002 Push and the 2006 book. Practices 2 and 4 (proven security features and cryptography standards) became prominent after the 2014-2017 TLS-bug wave: Heartbleed in April 2014 [@nvd-cve-2014-0160-heartbleed], POODLE in October 2014, Logjam in May 2015, ROBOT in December 2017. Practices 5 through 9 (supply chain, engineering environment, security testing, operational platform, monitoring and response) absorb post-SolarWinds (December 2020), Log4Shell (December 2021), and xz-utils (March 2024) lessons that did not exist in the original 2006 codification [@cisa-secure-by-design] [@slsa-home] [@freund-xz-disclosure].
The SDL did not invent training, did not invent threat modeling, did not invent banned APIs, and did not invent audit-driven review. What it did was *assemble* them, *mandate* them, and *gate releases* on them at a scale and authority no one had previously attempted at a desktop-monopoly vendor. Saltzer and Schroeder (1975), OpenBSD (1996), CERT/CC (1988), Schneier (1999), Kohnfelder and Garg (1999), and Howard and LeBlanc (2001) all contributed substrate; the SDL was an organizational achievement that depended on every one of those.
A discipline becomes industry-standard when other organizations adopt or are compelled to adopt it. What happened to the SDL's template between 2006 and 2026?
## 9. What the Era Taught the Next 25 Years
Every major secure-development framework published since 2006 traces a recognizable lineage back to the same Push-shape ancestor. The genealogy fans out:
flowchart TD
P0[2002 Windows Security Push] --> M1[2004 Microsoft SDL Lipner ACSAC]
M1 --> B[2008 BSIMM descriptive 128 activities]
M1 --> S[2009 OWASP SAMM prescriptive 15 practices]
M1 --> I[2011 ISO/IEC 27034 certifiable]
M1 --> F[2018 SAFECode Fundamental Practices 3rd ed]
M1 --> N[2022 NIST SSDF SP 800-218 federal-supplier]
M1 --> L[2021-2023 SLSA Build track post-SolarWinds]
M1 --> C[2023 CISA Secure by Design + Pledge]
The shorthand for each descendant:
- **Microsoft SDL.** The 2004 ACSAC paper and the 2006 book; today's ten-practice five-stage formulation [@lipner-acsac-2004] [@msft-sdl-practices].
- **BSIMM.** The Building Security In Maturity Model, descriptive (not prescriptive): 128 activities observed across 111 organizations in 8 industries, grouped into 12 practices in 4 domains [@bsimm-home].
- **OWASP SAMM v2.** Open Software Assurance Maturity Model, prescriptive: 15 security practices grouped into 5 business functions (Governance, Design, Implementation, Verification, Operations), with 3 maturity levels per practice [@owasp-samm-model] [@owasp-samm-about].
- **ISO/IEC 27034-1:2011.** The first internationally certifiable application-security standard, confirmed in 2022 [@iso-27034-1].
- **SAFECode Fundamental Practices, 3rd ed.** A community-curated practice catalog from the Software Assurance Forum for Excellence in Code, with an explicit smallest-organization onramp [@safecode-fundamental-practices].
- **NIST SP 800-218 (SSDF).** The Secure Software Development Framework, February 2022; legally voluntary in form but de-facto mandatory for U.S. federal suppliers via Executive Order 14028 and OMB Memorandum M-22-18 [@nist-ssdf-218].
- **SLSA v1.0.** Supply-chain Levels for Software Artifacts, the post-SolarWinds extension that adds build-integrity attestation to the SDL pattern [@slsa-v1-levels] [@slsa-home].
- **CISA Secure by Design and the Secure-by-Design Pledge.** A U.S. federal policy framework restating the SDL principles as expectations on commercial software vendors; the Pledge is voluntary and not legally binding [@cisa-secure-by-design] [@cisa-sbd-pledge].
Below the family tree, every organization that picks one of these frameworks is also making a context-specific decision. A 2026 decision guide -- drawn from the SOTA work -- looks like this:
| Situation | Primary framework | Threat modeling | Supply chain | Memory safety |
|---|---|---|---|---|
| Large proprietary vendor | Microsoft SDL [@msft-sdl-practices] | STRIDE in Microsoft TM Tool [@msft-threat-modeling-tool] | SLSA Build L3 [@slsa-v1-levels] | Rust in new components [@weston-bluehat-il-2023] [@cisa-memory-safe-roadmaps] |
| U.S. federal supplier | NIST SSDF + Secure by Design [@nist-ssdf-218] [@cisa-secure-by-design] | Manifesto-aligned [@threat-modeling-manifesto] | SLSA Build L2+ [@slsa-v1-levels] | CISA memory-safe roadmap [@cisa-memory-safe-roadmaps] |
| Mid-size SaaS | OWASP SAMM [@owasp-samm-model] | OWASP Threat Dragon [@owasp-threat-dragon] | SLSA Build L1 [@slsa-v1-levels] | Language choice per service |
| Open-source project | SAFECode + SLSA [@safecode-fundamental-practices] [@slsa-home] | STRIDE or LINDDUN | SLSA Build L1 + provenance | Language choice per project |
| Privacy-critical | LINDDUN | LINDDUN + DPIA | per regulator | per language toolchain |
| AI/LLM-integrated | NIST AI RMF + OWASP LLM Top 10 [@nist-ai-rmf] [@owasp-llm-top-10] | LLM Top 10 categories | per model supply chain | per language toolchain |
The table is a snapshot, not a prescription; the underlying point is that every cell is a child of the same 2002 organizational pattern, specialized to a population.
### The five-stage cohort-migration playbook
Every meaningful security improvement since 2002 has had to walk a population through the same five-stage migration without breaking the legitimate-use long tail. The stages, drawn directly from how Microsoft has operated and what the larger industry has copied:
1. **Ship telemetry first.** Before flipping any default, instrument the current behavior so you know who is using it, how, and how often.
2. **Publish guidance naming the unsafe path as exceptional.** Documentation calls the behavior "supported but deprecated"; the change is announced.
3. **Flip the default behind documented escape hatches.** The new default is safe; users with a legitimate need can still opt back in via Group Policy, a registry key, an unblock checkbox, or an admin command.
4. **Deprecate on a published schedule.** Telemetry says the long tail is small enough to commit to a removal date; the date is announced one or more years out.
5. **Remove the capability.** The feature is no longer present; the escape hatch is no longer reachable.
Two worked examples make the playbook concrete -- the Office VBA macro block of 2022 and the SMBv1 deprecation of 1996-2017.
**Office VBA macros from the internet (announced February 2022).** Microsoft committed to blocking VBA macros in Office documents that arrived from the internet (carrying the Mark of the Web). The five-channel rollout, as documented and re-documented on the current Microsoft Learn page, ran:
| Channel | Default-block date |
|---|---|
| Current Channel Preview 2203 | April 12, 2022 |
| Current Channel 2206 | July 27, 2022 (after a July 2022 pause-and-resume) |
| Monthly Enterprise 2208 | October 11, 2022 |
| Semi-Annual Enterprise (Preview) 2208 | October 11, 2022 |
| Semi-Annual Enterprise 2208 | January 10, 2023 |
[@ms-learn-internet-macros-blocked]
The escape hatches were explicit: per-document Unblock from the file's Properties dialog, configured Trusted Locations, signed-by-Trusted-Publishers, or Group Policy overrides for managed environments [@ms-learn-internet-macros-blocked]. The capability was not removed -- the playbook stopped at stage 3. The July 2022 pause-and-resume is the playbook's self-correcting feedback loop in action: Microsoft paused the Current Channel rollout in response to deployment-side issues, fixed them, and resumed [@ms-learn-internet-macros-blocked]. That this fix took **twenty-seven years** from Concept's 1995 first detection to the Office VBA macro block of February 2022 is the era's tax for cohort migration without breaking the legitimate-use long tail.
**[SMBv1](/blog/the-connection-that-refused-to-downgrade-twenty-five-years-o/) deprecation (1996 to 2025).** Server Message Block version 1 shipped in 1996. Microsoft publicly deprecated SMBv1 in 2014 (the long tail was many years of legacy installations). Ned Pyle, Principal Program Manager for Microsoft's Storage and File Services team, published the canonical "Stop using SMB1" Tech Community post on September 16, 2016 [@pyle-stop-using-smb1]. May and June 2017 brought the empirical forcing function: the WannaCry ransomware in May, the NotPetya wiper in June, both exploiting EternalBlue against SMBv1. October 2017's Windows 10 version 1709 shipped SMBv1 off by default. Windows Server 2019 and later, plus Windows 11, do not install SMBv1 at all. For Windows Home and Pro, the SMBv1 client auto-uninstalls after 15 days of non-use [@ms-learn-smbv1-not-installed]:
| Year | Event |
|---|---|
| 1996 | SMBv1 ships with Windows NT 4.0 |
| 2014 | Public deprecation announced |
| September 16, 2016 | Ned Pyle's "Stop using SMB1" Tech Community post [@pyle-stop-using-smb1] |
| May-June 2017 | WannaCry and NotPetya empirical forcing function |
| October 2017 (1709) | SMBv1 default-off in Windows 10 |
| Windows Server 2019+, Windows 11 | Not installed by default; 15-day auto-uninstall on Home/Pro [@ms-learn-smbv1-not-installed] |
> **Note:** "Deprecation takes a decade" is not vendor inefficiency. It is the cost of executing each playbook stage without breaking the legitimate-use long tail of business-critical software that depends on the capability. An empirical forcing function -- a worm, a ransomware wave, a public catastrophe -- is what compresses the late stages from years to months. WannaCry and NotPetya did to SMBv1 in 2017 what Code Red and Nimda did to the Windows defaults in 2002.
The aggregate catalog of unsafe defaults the era's lessons forced into the playbook, each at its own stage in 2026:
- NetBIOS over TCP exposed by default (deprecated; off by default).
- [NTLM](/blog/ntlmless-the-death-of-ntlm-in-windows/) as a first-class protocol (Microsoft announced default-off deprecation in October 2023, with a rolling transition through Windows Server 2025 and later releases [@techcommunity-ntlm-evolution-2023]).
- ActiveX by default in the IE Internet zone (removed with IE retirement in 2022).
- Autorun on removable media (default-off after Windows 7 patch in February 2011 [@kb971029-autorun-wayback]).
- Office macros enabled by default (default-block for internet-marked files since 2022 [@ms-learn-internet-macros-blocked]).
- PowerShell v2 (deprecated 2017, removed by default in Windows 11 23H2 [@devblogs-powershell-v2-deprecation]).
- Office Equation Editor (deprecated 2017, removed 2018 after CVE-2017-11882 [@nvd-cve-2017-11882]).
The 2002 template won. The modern industry runs on its descendants. But "won" does not mean "solved" -- the same eight-engineer SWI of 2000 has descendants in 2026 that still ship the same memory-safety bugs Cutler's NT kernel shipped in 1993. What changed? What did not?
## 10. State of the Art (and the Wars Ahead)
Open with the humility. Microsoft's own 2019 MSRC retrospective is the figure CISA preserves verbatim: **"approximately 70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues"** [@cisa-urgent-need-memory-safety] [@cisa-memory-safe-roadmaps].
Twenty-five years after the SDL's birth, the dominant CVE class is the same one the NT 3.1 -> NT 4.0 -> IIS 5.0 series shipped throughout the 1990s and Code Red weaponized in 2001.An earlier draft credited Cutler's NT-kernel team with shipping `idq.dll` in 1993. That attribution is wrong on both counts. `idq.dll` first shipped with **Microsoft Index Server 1.0 for Windows NT 4.0 in 1996**, and it was authored by the Index Server / IIS-ISAPI team, not the Cutler-led NT-kernel team. The load-bearing claim -- that the dominant CVE class today is the same memory-safety class the NT-line products shipped throughout the 1990s and Code Red weaponized in 2001 -- is preserved without the inaccurate attribution. The discipline the era forced was necessary; it was not sufficient.
Three frontiers carry that residual problem forward into the next decade.
### Frontier 1: supply-chain integrity (SLSA v1.0 Build track levels)
SLSA -- Supply-chain Levels for Software Artifacts -- is the post-SolarWinds extension of the SDL pattern to the build pipeline itself. The v1.0 specification defines four Build track levels, with verbatim per-level guarantees [@slsa-v1-levels]:
- **Build L0.** No SLSA. No claims about provenance.
- **Build L1.** "Provenance showing how the package was built." Crucially, the spec is explicit that at L1 "provenance may be incomplete and/or unsigned" -- L1 defends against mistakes and gives consumers something to inspect, not against tampering [@slsa-v1-levels].
- **Build L2.** Signed provenance, "generated by a hosted build platform." The signature belongs to the build platform, not the producer -- specifically, "by a key that is only accessible to the build platform" -- so post-build tampering by the producer is detectable [@slsa-v1-levels].
- **Build L3.** Hardened build platform: builds run in isolation so one build cannot influence another, and the signing key is "not accessible to user-defined build steps" so an insider with a malicious build script cannot forge signed provenance [@slsa-v1-levels].
A Source track existed in SLSA's v0.1 draft and was explicitly *deferred* from v1.0. The future-directions page is direct about why: "A Source track could provide protection against tampering of the source code prior to the build" [@slsa-future-directions]. The reason it is not in v1.0: there is no automatic decision procedure that distinguishes a malicious-but-syntactically-clean patch from a benign one.
The xz-utils CVE-2024-3094 attack is the canonical case. Andres Freund's March 29, 2024 oss-security disclosure described a multi-year campaign by an attacker using the handle "Jia Tan" who, over two and a half years (the first patch landed in October 2021), built a maintainer-grade reputation and pushed a backdoor into the xz release tarballs that diverged subtly from the git source [@freund-xz-disclosure]. Russ Cox's timeline reconstructs the social-engineering chain: the "Jigar Kumar" and "Dennis Ens" sockpuppet accounts pressuring the original maintainer to delegate authority, the gradual accretion of commit access, the backdoor delivered in the release artifacts but not the git history [@cox-xz-timeline].
> **Note:** SLSA's Build track addresses the integrity of the path from source to artifact. It does not address the integrity of the source itself. A malicious patch that lands in the upstream repository and is built by an SLSA Build L3 platform produces a properly attested, properly signed artifact that is malicious. The xz-utils case is the existence proof. Detection here still depends on individual engineer-curiosity in the field -- Andres Freund noticed an anomalous CPU spike on his Debian sid SSH logins and chased it -- not on any mechanically verifiable property of the supply chain.
### Frontier 2: AI/LLM-integrated software
The threat-modeling frameworks the SDL absorbed -- STRIDE, PASTA, LINDDUN -- were designed for systems whose components have specifications. An LLM is not such a component. Its behavior is an empirical artifact of its training data and the prompt context it receives; there is no spec a verifier can use to bound the set of outputs the model will produce for a given input.
The partial responses on the table in 2026: the NIST AI Risk Management Framework (AI RMF 1.0), released January 26, 2023 [@nist-ai-rmf]; the OWASP Top 10 for Large Language Model Applications, now part of the OWASP GenAI Security Project [@owasp-llm-top-10]; and the draft **NIST SP 800-218A IPD** ("Secure Software Development Practices for Generative AI and Dual-Use Foundation Models"), published April 29, 2024, by Souppaya, Vassilev, Ogata, Stanley, and Scarfone as an SSDF Community Profile mandated by Executive Order 14110 section 4.1(a)(ii) of October 30, 2023 [@nist-sp-800-218a-ipd] [@nist-sp-800-218a-ipd-pdf].
To bring this frontier to the same mechanism-grade depth as Frontier 1, the worked example below traces a single named vulnerability class -- **Indirect Prompt Injection (IPI)** -- from primary disclosure through vendor mitigation, productization, federal-supplier profile, and a real-world CVE.
A class of attack against LLM-integrated applications in which the attacker never interacts with the model directly. Instead, the attacker plants adversarial instructions into data the model will later retrieve -- a web page the model browses, a document the model summarizes, an email the model is asked about, a code-repository file the model is asked to refactor. When the LLM ingests that data, it treats the injected instructions as part of its prompt context and acts on them. The term was defined by Greshake, Abdelnabi, Mishra, Endres, Holz, and Fritz in their AISec 23 paper [@greshake-ipi-arxiv] [@greshake-ipi-acm].
**The vulnerability class.** The Greshake et al. paper (arXiv v1 February 23, 2023; AISec 23 proceedings November 30, 2023, Copenhagen) demonstrated working IPI attacks against Bing Chat (GPT-4 powered), GPT-4-integrated synthetic applications, and code-completion engines [@greshake-ipi-arxiv]. The paper's threat taxonomy enumerates four families: data theft, worming (LLM-to-LLM propagation through injected outputs that subsequent LLMs read), information-environment contamination, and arbitrary code execution at the application-functionality layer [@greshake-ipi-arxiv] [@greshake-ipi-acm].
**The vendor mitigation -- Microsoft Spotlighting.** Hines, Lopez, Hall, Zarfati, Zunger, and Kiciman published "Defending Against Indirect Prompt Injection Attacks With Spotlighting" (arXiv v1 March 20, 2024) [@hines-spotlighting-arxiv]. Spotlighting is a family of prompt-engineering techniques -- datamarking, encoding, per-token-marker transformations -- that, in the paper's words, provide "a reliable and continuous signal of provenance" so the model can distinguish instructions from retrieved data. The empirical claim is verbatim: **"spotlighting reduces the attack success rate from greater than 50% to below 2% in our experiments with minimal impact on task efficacy"** on GPT-family models [@hines-spotlighting-arxiv].
**The productization -- Azure AI Content Safety Prompt Shields.** Spotlighting moved from a research paper to a productized API surface: Microsoft Learn documents Prompt Shields as "a unified API in Azure AI Content Safety that detects and blocks adversarial user input attacks on large language models" [@azure-prompt-shields]. The Microsoft Docs Zero Trust SFI guidance documents the layered defense-in-depth pattern Prompt Shields and Spotlighting compose into: "Prompt shields ... Spotlighting ... Plan drift detection ... Critic agents ... Tool chain analysis ... Security guardrails" [@msdocs-defend-ipi]. MSRC's July 2025 blog "How Microsoft defends against indirect prompt injection attacks" is the canonical Microsoft narrative [@msrc-ipi-blog].
**The framework mapping -- OWASP LLM01.** The OWASP GenAI Security Project's LLM01 page enumerates seven prevention-and-mitigation strategies for prompt injection [@owasp-llm01-prompt-injection]. Spotlighting is the algorithmic implementation of Category 6 ("Segregate and identify external content"); system-prompt enforcement is Category 1 ("Constrain model behavior"); tool-call permission scoping is Category 4 ("Enforce privilege control and least privilege access"); human-in-the-loop checkpoints for high-risk tool calls (file write, email send, payment) are Category 5 ("Require human approval for high-risk actions") [@owasp-llm01-prompt-injection].
**The federal-supplier profile -- NIST SP 800-218A IPD.** The draft NIST SP 800-218A profile takes the OWASP and Microsoft Research mitigation vocabulary and translates it into SSDF practice-level language [@nist-sp-800-218a-ipd] [@nist-sp-800-218a-ipd-pdf]. The legal anchor is Executive Order 14110 section 4.1(a)(ii) of October 30, 2023; the initial public draft published April 29, 2024 with a comment deadline of June 2, 2024 [@nist-sp-800-218a-ipd].
**The real-world CVE -- CVE-2024-5184 (EmailGPT).** The OWASP LLM01 page Scenario #5 references CVE-2024-5184 directly. The NVD record classifies it as CWE-74 (Improper Neutralization, Injection) with CVSS Base Score 6.5 Medium; the CNA is Synopsys (Black Duck) [@nvd-cve-2024-5184]. The Black Duck CyRC advisory reconstructs the disclosure timeline: initial contact February 26, 2024; reminders April 4 and May 1; public advisory June 5, 2024 -- about ninety-nine days with **no vendor response** [@blackduck-cyrc-emailgpt]. Mohammed Alshehri at Black Duck CyRC discovered the vulnerability; the CyRC recommendation, verbatim, is to **"remove the applications from networks immediately"** [@blackduck-cyrc-emailgpt]. That recommendation is the operational evidence that the field still lacks a reliable in-band mitigation it can ship without removing the application from production.
> **Note:** Four gaps deserve naming for readers reusing this material. First, **no primary-source-grade threat-modeling method exists** for the prompt-context, training-data-supply-chain, or fine-tuning-data attack surfaces in the closed-list way STRIDE exists for component-with-spec systems; OWASP LLM01's seven categories are a useful checklist but not a generative methodology. Second, **Spotlighting's empirical 50%-to-2% reduction is per-model, per-task, and adversary-specific** [@hines-spotlighting-arxiv] -- tested against specific GPT-family models with specific attack templates. Third, **the CVE-2024-5184 disclosure timeline (Feb 26 to Jun 5, 2024, no vendor response)** [@blackduck-cyrc-emailgpt] demonstrates the field still lacks the institutional analog of MSRC's 2002-era coordinated-disclosure norms for LLM-integrated applications. Fourth, **the 2002-style cohort migration is not yet available**: there is no equivalent of "ship telemetry, publish guidance, flip the default, deprecate, remove" for "prompt-injection-vulnerable LLM agent integrations," because the legitimate-use long tail is the entire space of LLM-integrated applications, not a single deprecated protocol like SMBv1.
Mapping the article's thesis onto this frontier: Greshake et al. named the **class** (February 2023) the way Saltzer and Schroeder named the **principles** in 1975; Microsoft published the **mitigation** (Spotlighting, March 2024) with a measurable effect; Microsoft **productized** it (Azure Prompt Shields); NIST published the **federal-supplier profile** (SP 800-218A IPD, April 2024); and a **real-world CVE with no vendor response** demonstrates the cycle has not yet completed at industry scale. The 2002 pattern -- discipline, then authority, then mitigation, then productization, then federal-supplier mandate, then coordinated-disclosure norm -- is *in progress* for the AI/LLM frontier, and the reader can see exactly which steps remain.
### Frontier 3: the formal-verification gap
The proof-of-correctness path has narrowed the gap between SOTA shipped code and the theoretical upper bound, but not closed it.
The canonical worked example is **seL4**: a formally verified microkernel, Klein et al., SOSP 2009 [@klein-sel4-sosp-2009]. The seL4 FAQ lists per-architecture kernel sizes for the verified configurations: roughly 10,000 source-lines-of-code on RISC-V 64, 12,100 on AArch32, 12,600 on AArch64 with hypervisor extensions, and 16,000 on x64 [@sel4-faq]. The proof-to-code ratio is approximately **20 to 1** -- twenty lines of Isabelle/HOL proof for every line of kernel C -- and the proof effort was approximately twenty person-years for the original 2009 verification [@klein-sel4-sosp-2009].
Why has seL4-class verification not scaled from a microkernel to a desktop OS? The barrier is compositional: each new feature requires re-proving every relevant invariant compositionally. The cost grows non-linearly with feature surface; even with two and a half decades of tooling improvement, no verified OS at desktop-Linux or Windows scale exists in production.
Microsoft's parallel path -- the one running today, not over the next twenty years -- is the introduction of [memory-safe Rust](/blog/rust-in-the-windows-kernel-a-field-guide-to-the-2024-2026-me/) into selected Windows components. David Weston's BlueHat IL 2023 talk gave the two named exemplars: the Win32k GDI region engine (~36,000 lines of Rust) and DWriteCore (~152,000 lines of Rust) [@weston-bluehat-il-2023].
Why does Rust help when seL4-style proof does not scale? Because Rust does not try to prove "the program is correct." It enforces a weaker but mechanically checkable property at the type-system level: no aliased mutable borrows, no use-after-free. That weaker property closes most of the bug class behind the 70% memory-safety figure, by construction, at compile time -- without any per-program proof effort.
That trade-off is the load-bearing engineering pattern of every secure-development framework since 2002. There is a name for it in the formal-methods literature, and a 1953 theorem behind it.
A mechanically checkable proxy property that closes the most common subset of an undecidable semantic property's bug class. Rice's theorem (Henry Rice, *Transactions of the AMS* 74, 1953) says any non-trivial semantic property of a Turing-recognizable program is undecidable -- you cannot, in general, write a checker that decides whether an arbitrary program has the property. The SDL's engineering workaround has always been to substitute a *decidable* property that catches the most common cases. `banned.h` substitutes "is this textual symbol present?" (trivially decidable, mechanically enforceable) for "is this string copy memory-safe?" (undecidable). C28719 is the descendant of that substitution that still release-gates Windows drivers in 2026 [@msft-c28719]. Rust's borrow-checker is the same trick at the language layer: it substitutes "is every borrow either exclusive or shared?" for "is the program memory-safe?", closing a much larger class of bugs by construction.
The unifying pattern across sections 7, 9, and 10:
> **Key idea:** Rice's theorem says the question we *want* to answer is undecidable. The discipline that emerged from the 2002 Push said: substitute a question we *can* answer, make the substitution good enough, and gate releases on the substituted question. Every generation since -- `banned.h`, `strsafe.h`, C28719, the Rust borrow-checker, SLSA Build attestations -- has substituted a better question.
The series this article opens has five more parts -- beginning with [Part 2 (2002-2008)](/blog/eight-primitives-one-worm-the-windows-security-wars-part-2-2/) -- each working a generation forward:
flowchart LR
P1[Part 1: Wild West and TwC memo 1995-2002] --> P2[Part 2: XP SP2 DEP NX Windows Firewall WRP early ASLR Aug 2004]
P2 --> P3[Part 3: Vista UAC MIC BitLocker PatchGuard driver signing Nov 2006]
P3 --> P4[Part 4: Windows 7 to 10 AppContainer Credential Guard Device Guard 2009-2015]
P4 --> P5[Part 5: Cloud era Azure AD Conditional Access Entra ID 2015-present]
P5 --> P6[Part 6: Endpoint defenses HVCI VBS Pluton Rust in Windows 2018-2026]
Mandatory Integrity Control (MIC) is a Windows Vista (2006) feature, not an NT-era latent design. Vista introduced integrity levels (Low, Medium, High, System) and the integrity-level-tagged DACLs that make MIC work; UAC builds on top. Part 3 of this series will work the mechanism in detail.
For readers who want the mechanics rather than the history: this article is the institutional birth; the companion in-depth posts cover the primitives. The [Windows access-control model](/blog/windows-access-control-25-years-of-attacks/) post walks the SRM, DACLs, SACLs, and SIDs in operational detail; the [DPAPI](/blog/dpapi-and-dpapi-ng-the-credential-vault-under-everything/) post covers the user-key derivation pipeline; the [NT Kerberos](/blog/kerberos-in-windows-the-other-half-of-ntlmless/) post covers the LSA, the KDC, the TGT, and the ticket-granting flow; the [smart cards](/blog/the-card-that-wasnt-a-card-how-windows-authentication-outgre/) post covers the certificate-bound credential path.
The story ends, but the wars do not. The institutional pattern the era forced is now twenty-five years old; the bug class that forced it is still ~70% of shipped CVEs. The next twenty-five years will repeat the operationalization pattern at progressively more abstract layers -- supply chain, machine-learning model, the developer's autonomous agent. The hard part has never been the technical question. The hard part is always the executive willingness to halt feature work to answer it.
## 11. Frequently Asked Questions
Every retelling of this era invites a predictable set of pushbacks. Address them head-on, so the article can end on wonder, not on quibble.
No, and the cost-and-mechanism evidence is the rebuttal. The Push was approximately ten weeks of paused feature work across ~8,500 Windows engineers at a total cost of ~$100 million in foregone feature work, and the methodology survived twenty-plus years as the published Microsoft SDL, ISO/IEC 27034, OWASP SAMM, BSIMM, NIST SSDF, SLSA, and CISA Secure by Design [@howard-lipner-push-2003] [@washtech-microsoft-100m] [@msft-sdl-practices] [@iso-27034-1] [@owasp-samm-model] [@bsimm-home] [@nist-ssdf-218] [@slsa-home] [@cisa-secure-by-design]. A PR move does not survive a fiscal-quarter reporting cycle, let alone two decades and a peer-reviewed primary-source accounting in IEEE *Security and Privacy* [@howard-lipner-push-2003].
Partly. OpenBSD's audit-driven engineering culture started in the summer of 1996, six years before the Windows Security Push; its "six to twelve" auditor team has been continuously active since [@openbsd-security]. The OpenBSD slogan -- "only two remote holes in the default install, in a heck of a long time" -- is real and earned [@openbsd-security]. The distinction is scale and incentive: OpenBSD's model worked for a small homogeneous codebase with self-selected auditors and a permissive-license, no-revenue context; the SDL's model was built for a fifty-thousand-person, hundred-million-line, quarterly-revenue context. Parallel paths, not competitors.
No -- the eEye back-reference in their own August 4, 2001 Code Red II advisory points at advisory `AL20010717.html`, that is, **July 17, 2001**, for the original Code Red I discovery [@eeye-codered-ii]. CAIDA's measurement of the saturating Code Red v2 outbreak covers the **July 19, 2001** event with ~359,000 unique IPs in under fourteen hours [@caida-codered]. The defensible phrasings are "mid-July 2001" or "July 17, 2001" for Code Red I, and "July 19, 2001" for Code Red v2.
No. ILOVEYOU was a **VBScript / Windows Script Host email worm**, executed by `wscript.exe` when the user double-clicked the `LOVE-LETTER-FOR-YOU.TXT.vbs` attachment in Outlook [@cert-ca-2000-04-iloveyou]. The "Concept / Melissa / ILOVEYOU" grouping in popular retellings conflates two distinct execution surfaces: Office macros (Concept, Melissa) and the Windows scripting host (ILOVEYOU). The classification matters because the fixes are different -- Office macro auto-execute is an Office configuration; WSH-by-default and the hidden double-extension display in Explorer were Windows shell decisions.
No. The January 15, 2002 memo halted *Windows-division* feature work for the February-April 2002 Push, at the ~8,500-engineer scale Howard and Lipner document [@howard-lipner-push-2003]. The Office division, the .NET division, and the SQL Server division ran analogous pushes *serially* through 2002-2003, not simultaneously. The company-wide aggregate figure of "10,000 engineers" rolls those serial pushes together; the Windows-only number from the primary record is ~8,500 [@howard-lipner-push-2003] [@washtech-microsoft-100m]. Visual Studio .NET launched on schedule on February 13, 2002, after the December 2001 pre-launch security review the Gates memo names as the **template** for what the rest of the company was about to do [@gates-memo-wired].
Loren Kohnfelder and Praerit Garg, internal Microsoft memo "The Threats to Our Products," dated April 1, 1999 -- nearly three years before the Gates memo [@shostack-tm-book]. The memo is **no longer hosted on Microsoft's own web site**, but it has been publicly preserved at Adam Shostack's archive [@shostack-stride-memo-archive] (Shostack's landing page notes the document is no longer available on Microsoft's web site, "so we keep a copy here"), with an independent mirror at FIRST's CTI SIG curriculum [@first-stride-memo-mirror]. The chain-of-custody analysis is Shostack's *Threat Modeling: Designing for Security*, Wiley 2014 [@shostack-tm-book]. Microsoft's current Threat Modeling Tool is the operational descendant [@msft-threat-modeling-tool]. STRIDE's existence is the strongest single piece of evidence that the article's literal thesis ("Microsoft had no security team before January 15, 2002") needs the corrected reading in section 5 -- the methodology was *internal* by 1999; what was missing was the authority to require its use.
No, and the article explicitly disclaims this reading. The underlying ideas -- Saltzer and Schroeder 1975, the Orange Book 1985, CERT/CC 1988, OpenBSD 1996, Schneier's Attack Trees December 1999, Kohnfelder and Garg's STRIDE April 1999, Howard and LeBlanc's *Writing Secure Code* November 2001 -- all predate it [@saltzer-schroeder-1975] [@tcsec-orange-book] [@openbsd-security] [@schneier-attack-trees-1999] [@shostack-tm-book] [@howard-leblanc-wsc]. What January 15, 2002 was, is the moment a fifty-thousand-person desktop-monopoly vendor first applied release-blocking executive authority to make secure development a non-negotiable engineering gate. The corrected reading -- **industrial-scale operationalization at a dominant vendor**, not the *invention* of the field -- is the only one the evidence supports.
For readers who finish the article wanting to verify or extend the claims directly, the five most-useful primary sources cited throughout, by section:
- **Section 6 (the memo).** Bill Gates, "Trustworthy computing" memo to "Microsoft and Subsidiaries: All FTE," sent Tuesday, January 15, 2002 5:22 PM Pacific. Wired's republication preserves the original mail headers verbatim [@gates-memo-wired]; the Help With Windows mirror preserves the same `From:` / `Sent:` / `To:` / `Subject:` block [@helpwithwindows-billg].
- **Section 7 (the Push).** Michael Howard and Steve Lipner, "Inside the Windows Security Push," IEEE *Security and Privacy* 1(1):57-61, January-February 2003 [@howard-lipner-push-2003]. The primary-source paper for the approximately 8,500-engineer, approximately ten-week, approximately one-hundred-million-dollar, approximately 50% post-release-vulnerability-reduction numbers. DOI of record: `10.1109/MSECP.2003.1176996`; IEEE Xplore is paywalled.
- **Section 4 (Code Red).** David Moore, Colleen Shannon, Jeffery Brown, "Code-Red: a case study on the spread and victims of an Internet worm," CAIDA 2002 [@caida-codered]. The 359,000-host measurement.
- **Section 4 (Slammer).** David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, Nicholas Weaver, "The Spread of the Sapphire/Slammer Worm," CAIDA / ICSI / Silicon Defense / UCSD / UC Berkeley 2003 [@caida-slammer]. The 8.5-second-doubling, ten-minute-saturation, approximately 75,000-host primary.
- **Section 10 (formal verification).** Gerwin Klein, Kevin Elphinstone, Gernot Heiser, et al., "seL4: Formal Verification of an OS Kernel," SOSP 2009 [@klein-sel4-sosp-2009]. The formal-verification anchor; project FAQ at [@sel4-faq].
One sentence to carry forward, restating the article's load-bearing observation in plain English: the breakthrough was organizational, not technical. Same checklists, different signoff power. That pattern -- "make existing methods mandatory, and gate releases on them" -- is what every secure-development framework on the industry shelf in 2026 has, in its own vocabulary, copied. The next twenty-five years will copy it at the supply-chain layer, the machine-learning-model layer, and the autonomous-agent layer; the pattern is what travels.