You inherit a large, long-lived codebase with thousands of queries assembled by string concatenation. How would you drive injection risk toward zero over time, and what limits the damage in the meantime?

## Frame the problem correctly Thousands of concatenated sinks is not a security finding, it is a systemic property of the codebase. Any plan that consists of "scan, ticket, fix" loses, because new sinks appear as fast as old ones are closed and the backlog never converges. The goal is to change the codebase so that the defect becomes *impossible to express*, and then to drain the residue. ## 1. Make the safe path the only path Define one internal data-access entry point. Its signature should make the unsafe call unrepresentable: the statement argument accepts only a constant template type (many languages have a compile-time-constant string or a template-literal type), and values arrive as a separate typed collection. Where identifiers must vary, the API accepts an enum, not a string. If the language cannot express that, the next-best is a single small module where all statement assembly lives, so the reviewed surface is one file rather than the whole repository. This matters more than any scanner: a control enforced by a type signature holds for every future author without their cooperation, while a guideline in a wiki decays. ## 2. Ratchet, do not sweep Add a static-analysis rule that flags untrusted data flowing into statement text (a taint rule if the toolchain supports it; a structural rule against concatenation at the sink otherwise), and record the current violations as a frozen baseline. The build fails on any violation *not* in the baseline. Every new line of code is therefore safe from day one, while the existing thousands do not block delivery. Removing an entry from the baseline is a one-way door — the file can never regress. This converts an unbounded remediation project into a monotonically shrinking number, which is the only shape that finishes. Pair it with a pre-merge check that fails if the baseline grows, and publish the count as a visible metric. ## 3. Sequence the burn-down by real risk Not all sinks are equal. Rank by three factors: reachability (is the input attacker-controlled and reachable without authentication?), privilege (what can the connection this code uses actually do?), and data sensitivity (what tables are in reach). The order that follows is usually: unauthenticated public endpoints, then authenticated but tenant-crossing endpoints, then admin tooling that runs on a powerful account, then batch jobs whose inputs are internal but which often read attacker-planted rows — the second-order case that scanners miss precisely because the injecting request and the triggering request differ. Measure conversion percentage of sinks, not tickets closed. Tickets reward slicing; percentage of the invariant achieved rewards finishing. ## 4. Cap blast radius while the work runs Migration takes quarters, so assume some sinks remain exploitable and reduce what an exploit yields. - **Least privilege per service account.** Separate credentials per service, granted only the tables and operations it uses, no DDL, no access to other schemas. An injection in the reviews service should not be able to read the payments tables. - **Read-only replicas for reporting.** Report paths are the most dynamic and the most concatenated; pointing them at a replica with a read-only account removes tampering entirely from the highest-risk code. - **Disable multi-statement execution** in the driver where the option exists, removing the stacked-statement escalation. - **Data-level controls.** Encrypt or tokenise the crown-jewel columns so a mass `SELECT` returns ciphertext; keep the keys outside the database's own trust boundary. Rate-limit and cap result-set sizes so bulk exfiltration is slow and noisy. - **Detection.** Alert on database error-rate spikes (blind injection is noisy in errors), on unusual query shapes or unusually large result sets per endpoint, and on unexpected tables appearing in a service's access pattern. A WAF or database firewall belongs here: it buys time to respond and raises the cost of automated scanning, but it is a signature-matching heuristic in front of a parser you do not control, so never treat it as remediation or as a reason to defer a sink. ## 5. Verify, do not assume Add regression tests at the boundary for the shapes that matter — a payload in a filter, in a sort key, in a stored value read back later — and run a query-level fuzz pass in CI against the endpoints you have converted, so "converted" means demonstrated rather than declared. Include the database side: procedures containing dynamic SQL live outside the repository and must be inventoried explicitly, or they will be the last thing anyone looks at. ## 6. Know when to stop The programme is done when the baseline is empty, the type-level API is the only way to reach the driver, and the residual controls (least privilege, replicas, encryption) stay in place as defence in depth rather than as compensating controls. Retain the ratchet permanently; the cost is a few seconds of build time and it is what prevents the next decade of drift.