27. The Codex of Safeguards
Domain: Application Security — Secure SDLC, Threat Modeling, Secure Coding, Testing POV: Quill Reading time: ~15 minutes
The gear-works had always built things the same way: an engineer designed a mechanism, the guild approved it, the foundry cast it, and the mechanism was installed. The process had produced reliable mechanisms for centuries. But the voice-devices and the repeater in the Spire and the backdoor in the automaton control network had all been built the same way — by skilled engineers, using legitimate materials, through approved processes — and they had all been weapons.
“We need to change how things are built,” Quill said to the council. “Not just the mechanisms themselves, but the process by which they are designed and approved and deployed. Every new mechanism, every new device, every new system that is added to the city’s infrastructure must be reviewed for security before it is built, not after it is compromised.”
The new development process — which Quill, drawing on the Library’s treatises, called the “secure design lifecycle” — was structured around a series of gates that every new mechanism had to pass through before it could be deployed.
The first gate was requirements. Before any design work began, the mechanism’s designers had to document what the mechanism was supposed to do, who would use it, what data it would handle, and — crucially — what could go wrong. The “what could go wrong” analysis was a new concept for the Citadel’s engineers, who had been trained to think in terms of function rather than failure. Quill called it “threat modeling” — the systematic identification of threats to the mechanism, before a single gear was cut or a single line of code was drafted.
The second gate was design review. The mechanism’s design — its architecture, its components, its interfaces — was reviewed by a panel that included not just engineers but security specialists. Sable served on every review panel, because Sable had spent months studying the city’s vulnerabilities and understood, better than almost anyone, where designs were likely to fail. The review looked for weaknesses: components that could be exploited, interfaces that could be compromised, assumptions that had not been questioned.
The third gate was implementation review. Once the mechanism was built, its actual construction was examined to ensure that it matched the approved design. This was the gate that had caught the automaton backdoor — not during the original construction, but during a retrospective review that was part of the new process. The review compared the mechanism’s actual components to its documented design, and any discrepancy — any component that did not match, any connection that had not been documented, any capability that had not been approved — was flagged for investigation.
The fourth gate was testing. Not just functional testing — the old process had always included functional testing, verifying that the mechanism performed its intended function — but security testing. Thread led the security testing effort, developing a suite of tests that attempted to compromise every new mechanism before it was deployed: feeding it malformed commands, probing its interfaces for weaknesses, attempting to exploit any vulnerability that the design review had identified. Mechanisms that failed the security tests were sent back for redesign, no matter how well they performed their intended function.
“Secure by default,” Quill said, summarizing the principle for the assembled engineers. “Every mechanism must be secure in its default configuration. Not secure after additional hardening, not secure after special configuration — secure out of the box, with no additional work required. If a mechanism cannot be deployed securely in its default state, it should not be deployed at all.”
The first mechanism to pass through all four gates of the new process was a simple one: a replacement for the boundary controllers that regulated communication between the city’s segmented systems. The old controllers had been adequate but had not been designed with security in mind. The new controller was designed, from the first sketch, to be secure.
The requirements document — written by Sable, reviewed by Quill and Thread — specified exactly what the controller should do and what it should not do. It should allow authorized messages to pass between segments. It should block unauthorized messages. It should log every message that it processed. And it should fail secure — if the controller itself failed, it should block all traffic rather than allowing traffic to pass unchecked.
The threat model — facilitated by Kip, who had become surprisingly adept at thinking about what could go wrong — identified six potential threats to the controller. An adversary could attempt to send unauthorized messages through the controller. An adversary could attempt to disable the controller. An adversary could attempt to alter the controller’s configuration. An adversary could attempt to impersonate an authorized sender. An adversary could attempt to flood the controller with traffic, overwhelming its processing capacity. An adversary could attempt to exploit a vulnerability in the controller’s own design.
For each threat, the design review panel proposed a countermeasure. Unauthorized messages would be blocked by a message validation system. Impersonation would be prevented by digital signature verification. Flooding would be mitigated by rate limiting. The fail-secure design — which the old controllers had also incorporated, though less rigorously — would ensure that a failed controller blocked traffic rather than passing it.
The implementation review caught three discrepancies between the design and the actual construction — small errors, none catastrophic, but each one a vulnerability that an adversary could have exploited. And the security testing — Thread’s assault on the controller, using every technique that the investigation had documented from Vale’s attacks — found two additional weaknesses that the design review had missed. Both were corrected before the controller was deployed.
“The process worked,” Quill said, reviewing the final test report. “The controller is secure. Not perfectly secure — no mechanism is perfectly secure — but more secure than it would have been under the old process. The threats were identified. The countermeasures were designed. The implementation was verified. And the testing was rigorous enough to catch the weaknesses that slipped through.”
“This process took three times as long as the old one,” one of the senior engineers observed, not quite complaining but not quite accepting either.
“Yes,” Quill said. “It did. And the extra time is the price of security. The old process was fast — and it produced mechanisms that were compromised before they were deployed. The new process is slower, but the mechanisms it produces are more trustworthy. Given the choice between speed and trustworthiness, I will choose trustworthiness every time.”
The secure design lifecycle became, over the following months, the standard for every new mechanism in the city — not just boundary controllers and communication devices, but automata and gear-trains and archival systems and everything else. The engineers complained about the extra paperwork, the slower timelines, the additional review panels. But they complied, because the alternative — building mechanisms that could be compromised by the adversary before they were even deployed — was no longer acceptable.
And Quill, who had spent his entire life believing that the right procedures, applied consistently and rigorously, could prevent disaster, found in the new process a vindication of everything he had ever believed. The process was not perfect. The process would never be perfect. But it was better than what had come before — more systematic, more rigorous, more resistant to the kind of quiet, incremental corruption that Vale had practiced for years. And that, in the end, was what mattered: not perfection, but improvement. Not a single victory, but a better way of doing things that would outlast the current crisis and protect the city against the crises that were still to come.