Security Findings Management and Remediation Tracking Questions

Direct answer

The guidance is staged by urgency: contain now, fix properly this sprint, prove the fix works, then watch for misuse. The fix is parameterized queries. Filters are stopgaps only.

Remediation guidance: SQL injection (CWE-89, the numbered entry for this weakness in the Common Weakness Enumeration catalogue) in the order-lookup endpoint

1. Now (within 24 to 48 hours)

• Review database and web logs since deployment for injection strings (' OR, which closes a quote and adds an always-true condition; UNION, which bolts a second query onto the first to pull data from other tables; and unexpected SQL errors) to learn whether it was already exploited. A typical suspicious log line (illustrative): GET /orders/lookup?customer=x' UNION SELECT ... followed by a 500 response.
• Add a temporary web application firewall rule for this parameter. State plainly that this is a stopgap: filters can be bypassed.
• If the log review shows exploitation, escalate to the incident process, and rotate (change to new values) any credentials the database account could read.
• Reduce the application's database account to the minimum tables and permissions it needs, so a success gives the attacker less.

2. This sprint

• Replace string-built queries with parameterized queries (the SQL text and the user values travel separately, so values can never be read as commands).
• Sort columns, table names and other identifiers cannot be parameters: accept them only from a fixed allow-list.
• Search the code base for the same pattern in every other query.
• Prefer the framework's query builder or object-relational mapper (a library that generates SQL from objects), but check raw-SQL escape hatches in it too.

Code-level recommendation (this runs as shown, using Python's built-in sqlite3, where the placeholder is ?; other drivers use %s or named parameters):

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE orders (id INTEGER, customer TEXT, total REAL)")
db.executemany("INSERT INTO orders VALUES (?, ?, ?)",
               [(1, "alice", 20.0), (2, "bob", 35.5)])

def find_orders_vulnerable(customer):
    return db.execute(f"SELECT id, total FROM orders WHERE customer = '{customer}'").fetchall()

def find_orders_fixed(customer):
    return db.execute("SELECT id, total FROM orders WHERE customer = ?", (customer,)).fetchall()

payload = "x' OR '1'='1"
print("vulnerable:", find_orders_vulnerable(payload))
print("fixed:     ", find_orders_fixed(payload))
print("fixed, normal input:", find_orders_fixed("alice"))

Output:

vulnerable: [(1, 20.0), (2, 35.5)]
fixed:      []
fixed, normal input: [(1, 20.0)]

The attack string turns the vulnerable query into "return every row"; the parameterized one treats it as a customer name that does not exist.

3. How to test the fix

• Add an automated regression test (a test that fails if the bug ever returns) that sends the payload above and asserts no rows and no error leak (the response must not contain database error text that reveals the query).
• Ask the original tester to replay the exact original exploit (retest), plus variants such as time-based payloads (the attacker makes the database pause for a few seconds, for example with a sleep call, to infer yes or no answers when nothing is printed) and error-based payloads (the attacker provokes error messages that leak data).
• Run static analysis (SAST, Static Application Security Testing: scanning source code) on every pull request to flag string-built SQL, and dynamic scanning (DAST, Dynamic Application Security Testing: attacking the running app) against the staging deployment, in the pipeline.

4. What to monitor afterwards

• Alerts on database syntax errors from the application account, for example more than 5 in 10 minutes (illustrative threshold; set it from your normal baseline, which is close to zero). A sample line (illustrative): ERROR app_orders: syntax error at or near "'" (statement from /orders/lookup).
• Alerts on unusually large result sets or slow queries from that endpoint, for example an order lookup returning over 1,000 rows when normal lookups return under 50.
• Track WAF hits on the parameter for several weeks; remove the stopgap rule only after the retest passes.

Pitfalls

• Escaping quotes by hand or blocklisting words: bypassable, not a fix.
• Closing when the WAF rule blocks the tester's payload: the flaw is still in the code.

Direct answer

A stopgap that is not tracked becomes permanent. So the moment service is restored I turn it into a recorded, owned, time-boxed risk: written down in the incident timeline, converted to a ticket with a named owner and a due date, communicated to the people who own the risk, and closed only when the stopgap is removed and someone independent confirms it.

Worked scenario (illustrative)

During an outage, to let a failover database replica connect, an engineer changed a firewall rule (the network filter that decides who may connect) so the database port (5432, the door clients use to talk to it) accepted connections from every address on the internet (written 0.0.0.0/0) instead of only the replica's own address (10.0.4.17). Service returned in 10 minutes. The gap: the database is now reachable from outside, by anyone who can guess or find it, instead of by one server.

Step by step, in order

1. Document during the incident. In the incident timeline: exact change, who made it, time, and the gap it created. A one-line note beats memory later.
2. Create a temporary-mitigation record the same day. Fields: what changed and where, why, what risk it adds (who could reach what), compensating controls now in place (a compensating control is a temporary safeguard that reduces the risk while the real fix is pending, such as extra logging or an alert on connections from unexpected addresses), owner, expiry date, and the permanent-fix ticket link. Filled in for this scenario:

Record:        TM-2026-041
Change:        Firewall rule db-failover-allow, port 5432, source 0.0.0.0/0 (was 10.0.4.17/32)
Why:           Failover replica could not connect during the 2026-09-28 outage
Risk added:    Anyone on the internet can attempt to log in to the production database
Compensating:  Password-only logins disabled for non-replica users; alert on any 5432
               connection from outside 10.0.0.0/8; connection log reviewed daily
Owner:         Payments platform team lead
Expires:       2026-10-05
Permanent fix: SEC-2210 (restrict source to 10.0.4.17/32), due 2026-10-05

3. Turn it into tracked work. One ticket for the permanent fix (restrict to the specific hosts), owned by the service team, with a due date (for example 5 business days, since this is a live exposure). Also add it as an action item in the postmortem (the blameless review after an incident: it asks what failed in the system, not who to blame).
4. Communicate the risk. A short message to the service owner, the security team and the on-call manager: what is exposed, what compensates, when it ends, what triggers escalation. Plain wording, no blame. For example: "Since 14:10 today the production database port accepts connections from any internet address, a side effect of restoring failover. We have restricted logins and are alerting on outside connections. Fix is ticketed (SEC-2210), due Oct 5. If the alert fires, security will block the port immediately and we will take the failover replica offline until it is fixed."
5. Make the expiry enforceable. Tag the change with an expiry date, and run an alert that fires when an expired tag is still present. A calendar reminder alone is not enough, because it depends on someone remembering. Concretely: put a label expires=2026-10-05 on the firewall rule, and run a daily job that lists every rule whose expires date is earlier than today and pages the owner. On 2026-10-06 the broad rule shows up in that list if it still exists, without anyone having to recall it.
6. Replace and verify. Apply the proper rule, remove the broad one, test the failover still works, and have someone other than the author confirm from outside that the port is no longer reachable. Attach the evidence and close both the record and the ticket.

What would change my call

If the permanent fix needs weeks (for example a network redesign), I stop calling it temporary: it becomes a formal, time-limited risk acceptance (a written, signed decision by the person who owns the risk that the organisation will live with it for a stated period), with stronger compensating controls and a renewal date.

Pitfalls

• Closing the incident and the ticket together, so nothing carries the exposure forward.
• Blame-heavy wording that discourages people from disclosing stopgaps next time.
• "Fixed" declared without confirming the old rule is gone.