Security Findings Management and Remediation Tracking Questions

Direct answer

Each finding's technical section must let a developer who has never seen the test reproduce the problem in minutes and confirm the fix. When reproduction fails, the usual cause is a missing precondition or an environment difference, so I list those explicitly. Sensitive data in evidence is masked, minimized and stored under access control.

What each finding's technical section contains

1. Title and severity with a one-line rationale.
2. Affected asset: URL or component, version or build, environment.
3. Preconditions (what must be true before step 1 works): account role, feature flags (settings that switch a feature on or off for some users), data state, network position (for example, on the corporate network or on the public internet), tool versions.
4. Numbered reproduction steps with exact requests, so nothing is left to guess.
5. Expected versus actual behaviour.
6. Evidence: request and response, timestamp, screenshot.
7. Root cause and fix guidance specific to the code, plus a reference (for example CWE-639, the Common Weakness Enumeration entry for authorization bypass through a user-controlled key).
8. How to verify the fix: the same steps, and what a passing result looks like.

Illustrative excerpt

Finding 2: Order data readable across accounts (IDOR, insecure direct object reference: the server returns a record by its ID without checking the caller owns it)
Preconditions: two test accounts owned by the tester, A and B, each with one order; staging build 3.4.1
Step 1: log in as B, place an order and note its id, 6002 (this is the record A must not see). Log in as A and note A's own order id, 5001, to confirm A normally sees only 5001
Step 2: request B's order 6002 while authenticated as A:
  curl -H "Authorization: Bearer <A_TOKEN_REDACTED>" https://api.staging.example.com/orders/6002
Expected: 403 Forbidden.  Actual: 200 with B's order (email shown as j***@example.com)
What step 2 does: curl sends one web request to the orders API, and the Authorization: Bearer header attaches A's login token (a Bearer token proves who is calling), so the server treats the caller as A.
Fix: check order.owner_id equals the caller's id on the server.
Verify: repeat step 2, expect 403.

When the developer cannot reproduce

• Compare the environment first: build version, configuration, test data, whether the WAF (web application firewall) sits in front.
• Check timing or state: a session that expired, or an order that no longer exists.
• Offer a short screen-share and a small script.
• Reproduction failing is a signal to fix the report, not to blame the developer.

Handling sensitive data in evidence

• Prefer test accounts and synthetic data.
• Mask what must be shown: tokens as prefixes, emails partially, card numbers to the last four digits.
• Never paste secrets into tickets or chat; keep raw evidence in an encrypted, access-controlled store with a retention and deletion date.
• If a real credential was found, tell the owner to rotate it at once and note that in the finding.
• Record what data was actually accessed, no more than needed to prove the flaw.

Pitfalls

Screenshots with no request text, "see attached" with no steps, and evidence that leaks the very data the finding is about.

Direct answer

Two findings are "the same issue" when one fix would resolve both. So identity is a rule over asset, weakness type and normalised location, applied in tiers: exact matches on that key are merged automatically; partial matches (same library, different call sites) are grouped under one parent with the occurrences as children; fuzzy matches on titles or text only suggest a merge for a human. Accept extra duplicates before wrongly merged findings, because a duplicate wastes time while a false merge can bury a real vulnerability.

How to decide

Core for interviews: steps 1, 2, 4 and the error trade-off. Steps 3 and 5 are extras that are rarely asked in detail.

1. Canonicalise (also called normalise: rewrite into one standard form) before comparing. Lowercase, strip query strings and trailing slashes, and replace identifiers in paths with a placeholder, so /orders/123?sort=asc and /orders/9/ both become /orders/{id}.
2. Exact key: asset, CWE (the weakness category), and the canonical location. Same key from different scanners means one finding with several sightings (the sources are kept as evidence).
3. Shape hashing for web findings (less common, mention briefly): hash (turn into a fixed fingerprint) things that describe how the request and response are structured (HTTP method, sorted parameter names, response status and content type), not their values, so two scanners' different payloads still collide when they hit the same parameter.
4. Partial matches: for a vulnerable library, the fix is upgrading the package, not editing each call site. Group by asset, vulnerability ID and package as a parent ticket, keep each call site as a child occurrence, and close the parent when none remain.
5. Fuzzy titles (for instance, token similarity: scoring how many words two titles share) are the weakest signal: use them only to populate a human review queue, never to auto-merge.

Worked example (executed)

Six raw findings arrive. The three SQL injection reports use different path spellings; two library findings sit in different files.

import re
from collections import defaultdict

def norm_path(p):
    p = p.lower().split("?")[0].rstrip("/")
    p = re.sub(r"/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}(?=/|$)", "/{id}", p)
    return re.sub(r"/\d+(?=/|$)", "/{id}", p)

def keys(f):
    exact = (f["asset"], f["cwe"], norm_path(f["path"]) if f.get("path") else None)
    parent_id = f["cve"] if f.get("cve") else f["cwe"]
    parent = (f["asset"], parent_id, f.get("package"))
    return exact, parent

def shape_key(f):
    return (f["method"], tuple(sorted(f["params"])), f["status"], f["ctype"])

findings = [
    {"src": "dast",  "asset": "orders-api", "cwe": "CWE-89", "path": "/orders/123?sort=asc"},
    {"src": "sast",  "asset": "orders-api", "cwe": "CWE-89", "path": "/orders/{id}"},
    {"src": "pentest", "asset": "orders-api", "cwe": "CWE-89", "path": "/orders/9/"},
    {"src": "sca",   "asset": "orders-api", "cwe": "CWE-79", "cve": "CVE-2099-0001", "package": "libfoo", "path": "checkout.js:40"},
    {"src": "sca",   "asset": "orders-api", "cwe": "CWE-79", "cve": "CVE-2099-0001", "package": "libfoo", "path": "cart.js:12"},
    {"src": "dast",  "asset": "orders-api", "cwe": "CWE-352", "path": "/orders/5"},
]

exact = defaultdict(list)
for f in findings:
    exact[keys(f)[0]].append(f["src"])
print("exact groups:", len(exact), "from", len(findings), "raw findings")
for k, srcs in exact.items():
    print(" ", k, "<-", srcs)

parents = defaultdict(set)
for f in findings:
    parents[keys(f)[1]].add(keys(f)[0])
for k, children in parents.items():
    print(k, "->", len(children), "occurrence(s)")

web = [
    {"src": "scanner A", "method": "GET", "params": ["sort", "q"], "status": 500, "ctype": "text/html", "payload": "' OR 1=1--"},
    {"src": "scanner B", "method": "GET", "params": ["q", "sort"], "status": 500, "ctype": "text/html", "payload": "\" OR \"a\"=\"a"},
]
print("same shape:", shape_key(web[0]) == shape_key(web[1]))

Output:

exact groups: 4 from 6 raw findings
  ('orders-api', 'CWE-89', '/orders/{id}') <- ['dast', 'sast', 'pentest']
  ('orders-api', 'CWE-79', 'checkout.js:40') <- ['sca']
  ('orders-api', 'CWE-79', 'cart.js:12') <- ['sca']
  ('orders-api', 'CWE-352', '/orders/{id}') <- ['dast']
('orders-api', 'CWE-89', None) -> 1 occurrence(s)
('orders-api', 'CVE-2099-0001', 'libfoo') -> 2 occurrence(s)
('orders-api', 'CWE-352', None) -> 1 occurrence(s)
same shape: True

Six raw findings become four exact groups, and the libfoo finding is one parent with two occurrences. The identifier CVE-2099-0001 is a made-up placeholder for the demo.

How to read the code

• norm_path turns each path into its standard form: it lowercases, drops the query string and trailing slash, and swaps whole numeric or UUID segments for {id} (UUIDs first, so a UUID that starts with a digit is not chopped up). /orders/123?sort=asc, /orders/{id} and /orders/9/ all become /orders/{id}.
• keys builds two dictionary keys per finding. The exact key is (asset, CWE, normalised path). The parent key is (asset, vulnerability ID, package), where the vulnerability ID is the CVE if the finding has one, otherwise the CWE. That is the line parent_id = f["cve"] if f.get("cve") else f["cwe"].
• The first dictionary maps each exact key to the list of scanners that reported it. The second maps each parent key to the set of distinct exact keys (occurrences) under it.
• The three SQL injection reports (dast, sast, pentest) share one exact key, so they collapse to one group with three sightings. The CSRF finding (CWE-352, cross-site request forgery) stays separate because its CWE differs even though the path normalises the same.
• The two libfoo findings are two different exact groups (different files), but they share one parent key, so they become one parent ticket ("upgrade libfoo") with two child occurrences. libfoo is a made-up front-end JavaScript library with a cross-site scripting flaw, which is why its CWE is 79.
• shape_key is the shape-hashing idea in code: two scanners that fire different payloads at the same method and parameters, getting the same status and content type, produce the same shape, so they can be treated as one candidate.

Which errors to accept

At scale

Comparing every pair of findings grows with the square of the count (1,000 findings need about 500,000 pair checks, 2 million need about 2 trillion). Use hashing of the exact key (one pass, constant time per record), and block, meaning only compare fuzzy candidates that already share the same asset and CWE group, so most pairs are never compared. Recompute fingerprints incrementally on each ingest instead of rescanning the backlog.

Pitfalls

• Deleting merged records instead of linking them removes the audit trail.
• Over-normalising a path can merge distinct endpoints (/users/{id} and /users/me).
• Substitution order matters in norm_path: replacing digits before UUIDs turns the UUID 3f2a9c1e-1111-4222-8333-444455556666 into {id}f2a9c1e-... and /api/2fa/setup into /api/{id}fa/setup, so two different endpoints could be mangled or merged wrongly. The UUID pattern therefore runs first, and the digit pattern is anchored to a whole path segment.
• Merging on CVE (a published vulnerability identifier) alone across assets hides which systems are affected.

Direct answer

In plain terms: a risk acceptance is a signed decision by a business owner to live with a known risk for a limited time; compensating controls are other safeguards that reduce the risk when the real fix is not possible; residual risk is the risk left after those safeguards; the vendor's ETA is its estimated date for delivering a patch.

I track it as a normal finding with a special status ("waiting on vendor"), attach a documented risk acceptance with an expiry and compensating controls, apply interim mitigations to cut exposure, and report on a fixed rhythm to stakeholders and auditors. The clock is never silently stopped: it moves onto an exception path with review dates.

1. Tracking in the remediation system

The ticket carries: the vendor's case number, the vendor's stated patch ETA, the owner on our side, the affected assets, the compensating controls in place with links to evidence, a risk-acceptance record with approver and expiry, and a review date (every two weeks for a critical). If the vendor misses its ETA, the ticket escalates to procurement or the vendor's account manager.

2. Interim mitigations (in rough order of value)

• Reduce exposure: restrict access to an allowlist (a list of the only addresses permitted to connect), put it behind a VPN (virtual private network), or block it from the internet.
• Disable the vulnerable feature or configuration if the vendor documents one.
• Virtual patching: a web application firewall (WAF) or intrusion prevention rule that blocks the known exploit pattern.
• Detect: add alerts in the security monitoring system (SIEM, security information and event management) for exploit indicators and unusual access.
• Contain: reduce the product's privileges and network reach, rotate its credentials, and limit the data it holds.
• Plan the exit: evaluate an alternative if the vendor keeps slipping.

3. Reporting

• Internal stakeholders: a short weekly update with exposure (what is reachable), mitigations status, vendor ETA and any change to it, and residual risk.
• Auditors: evidence, not narrative: the signed risk acceptance with expiry, screenshots or configuration exports of each control, rule IDs and detection logs, dated vendor correspondence, and proof the acceptance was reviewed on schedule.

Worked example (illustrative)

A vendor-managed VPN gateway has a critical remote-code-execution flaw (one that lets an attacker run their own commands on the device) and the vendor says the fix ships in six weeks.

1. Day 0: ticket opened, this is a P0 (the highest-priority tier), and the policy fixes P0 within 7 days (a number used here for illustration), so the vendor's six-week ETA already breaks that window and the ticket moves to the exception path.
2. Day 1: the gateway's administration interface is limited to corporate address ranges (the user login page must stay reachable because remote staff connect from anywhere, so it is covered instead by the vendor's workaround setting and a detection rule for exploit attempts).
3. Day 2: the CISO (chief information security officer) signs a risk acceptance expiring at day 21, listing those controls.
4. Weekly: exposure and ETA updates sent; at day 21 the acceptance is re-reviewed and renewed with fresh evidence.
5. Day 42 (patch available): apply it, then verify by rescan, and remove the exception.

Trade-offs and pitfalls

• A risk acceptance with no expiry becomes permanent. Always time-box.
• Mitigations must be verified, not assumed: test that the rule actually blocks the exploit pattern.
• Do not let SLA (service-level agreement, the fix-by deadline) compliance dashboards hide this item: show it as "accepted, with controls" instead of dropping it from the numbers.
• What would change my call: a public exploit or active attacks against this product would justify taking it offline even at business cost.

Direct answer

I report a small set of measures, each defined with numerator, denominator and window: time to remediate (median and 90th percentile), SLA (service-level agreement) compliance, overdue open findings, reopen rate, and detection-to-fix time. Every one can be gamed, so I show them together and always with counts. A guard metric is a second measure that would get worse if the first were gamed.

The metrics

Worked example

This runs unchanged with Python 3 and its built-in sqlite3 (a small embedded database) module. It builds 10 findings, with dates pinned to an as-of date:

import sqlite3, math

db = sqlite3.connect(":memory:")
db.execute("""CREATE TABLE findings(
    id INTEGER PRIMARY KEY, severity TEXT, opened DATE, closed DATE,
    sla_days INTEGER, reopened INTEGER)""")
rows = [
    (1, "critical", "2026-06-01", "2026-06-05", 7, 0),
    (2, "critical", "2026-06-10", "2026-06-20", 7, 1),
    (3, "critical", "2026-07-01", None,         7, 0),
    (4, "high",     "2026-06-02", "2026-06-20", 30, 0),
    (5, "high",     "2026-06-05", "2026-07-25", 30, 0),
    (6, "high",     "2026-07-10", "2026-07-30", 30, 0),
    (7, "high",     "2026-07-15", None,         30, 0),
    (8, "medium",   "2026-06-01", "2026-08-15", 90, 0),
    (9, "medium",   "2026-06-03", "2026-07-01", 90, 0),
    (10, "medium",  "2026-06-20", "2026-08-30", 90, 1),
]
db.executemany("INSERT INTO findings VALUES (?,?,?,?,?,?)", rows)
AS_OF = "2026-09-01"

def pctl(vals, p):                      # nearest-rank percentile
    vals = sorted(vals)
    return vals[math.ceil(p / 100 * len(vals)) - 1]

closed = db.execute("""SELECT severity, julianday(closed)-julianday(opened) AS ttr,
                              sla_days FROM findings WHERE closed IS NOT NULL""").fetchall()
ttr = [int(r[1]) for r in closed]
print("closed:", len(ttr), "median TTR:", pctl(ttr, 50), "P90 TTR:", pctl(ttr, 90))

within = sum(1 for r in closed if r[1] <= r[2])
print("SLA compliance (closed in window):", within, "/", len(closed))

open_overdue = db.execute("""SELECT COUNT(*) FROM findings WHERE closed IS NULL
    AND julianday(?) - julianday(opened) > sla_days""", (AS_OF,)).fetchone()[0]
open_total = db.execute("SELECT COUNT(*) FROM findings WHERE closed IS NULL").fetchone()[0]
print("open:", open_total, "open and overdue at", AS_OF + ":", open_overdue)

# honest compliance: count still-open overdue findings as misses too
due = len(closed) + open_overdue
print("SLA compliance incl. overdue open:", within, "/", due)

re = db.execute("SELECT SUM(reopened), COUNT(*) FROM findings WHERE closed IS NOT NULL").fetchone()
print("reopen rate:", re[0], "/", re[1])

Output:

closed: 8 median TTR: 20 P90 TTR: 75
SLA compliance (closed in window): 6 / 8
open: 2 open and overdue at 2026-09-01: 2
SLA compliance incl. overdue open: 6 / 10
reopen rate: 2 / 8

How the code works: julianday() turns a date into a day number so that subtracting two dates gives days; the nearest-rank percentile sorts the values and picks the item at position ceil(p/100 x count), so P90 of 8 values is the 8th, the largest. The same thing in a spreadsheet: add a column =closed-opened, then use MEDIAN() on it. Note the methods differ on an even count: MEDIAN() averages the two middle values, so on these 8 values it returns 24 (the mean of 20 and 28), while the nearest-rank method used above returns 20, the lower middle value; a spreadsheet PERCENTILE function interpolates and can differ again. State which method you use.

Reading it: median 20 days (nearest-rank; the midpoint-averaged median is 24) and P90 75 days across 8 closed findings. SLA compliance is 6/8 (75%) if you count only closed items, but 6/10 (60%) once you count the two open findings that are already overdue. That gap is the classic misreading. The reopen rate is 2/8 (25%).

Data source, frequency and a target

• Source: the tracker export joined to scanner first-seen dates, not screenshots.
• Frequency: weekly for engineering leads, monthly for leadership, quarterly for the board.
• Example target after an incident caused by an unpatched library: P90 time to remediate for critical internet-facing findings under 7 days within two quarters, with reopen rate under 10%. These are targets I would propose, not measured values.

Showing improvement is real and not noise

• Report n (the number of findings behind each figure) beside every percentage. A P90 over 8 findings is fragile.
• Compare cohorts by month opened (group findings by the month they were opened), so old backlog clearing does not look like faster fixes. In the data above, the 7 findings opened in June all closed, with times 4, 10, 18, 28, 50, 71 and 75 days, median 28. The 3 opened in July show only one closed (20 days), which looks fast but hides two still open. Judged by month closed instead, clearing a 200-day-old backlog item would push one month's median up and make a good team look slow, while ignoring it makes the number look better than reality.
• Watch the severity mix (the share of critical, high and medium findings): if it shifts, the metric moves without any process change. Fixing only mediums in a month, for example, lowers the median.
• Detection-to-fix example: if the scanner first saw finding 4 on 2026-05-29 but the ticket opened 2026-06-02 and closed 2026-06-20, time to remediate is 18 days but detection-to-fix is 22 days; the 4 days of triage delay only appear in the second measure.
• Require several consecutive periods of improvement before claiming a trend.

Pitfall

A single number becomes a target and then stops being a good measure: pair each with a guard metric, for example pair time to remediate with reopen rate: if teams close findings fast by applying weak fixes, time to remediate improves while the reopen rate rises, exposing the trade.

Direct answer

Spend retest effort in proportion to risk. Critical and high findings get a full, individual retest. Large groups of similar lower-severity findings get a stratified random sample with a rule that escalates to a full retest when the sample fails. Automation reruns the original test for anything a tool can check. Results then go out in two forms: per-finding pass/fail with evidence for developers, and a one-page summary for executives.

Structure

Automation first. For every finding, save the original request or scanner rule so it can be replayed. Scanner-detectable classes are rechecked by rerunning the scan against the affected application.

Sampling. Stratify (split into groups, called strata, so every group gets checked separately) by application and by finding type, so every team faces a check rather than only the luckiest ones. Choose randomly within each group. Raise the sample for internet-facing applications. Escalation rule: if a sampled item fails, retest the entire group and reopen every failure.

Worked example

300 fixed findings across 30 applications: 12 critical and 48 high, plus 240 mediums of one class (a missing security header).

• Tier 1: 12 + 48 = 60 full retests.
• Tier 2: one randomly chosen medium per application = 30 samples. Each application is one stratum (one group), and picking one at random inside each guarantees every team is checked at least once, which is why it is stratified rather than 30 picks from the whole pile. The sample size of 30 was chosen here because there are 30 applications; you would size it to your confidence target.
• Tier 3: this example has no lows, but lows only get an automated rescan (rerunning the scanner), which adds almost no manual effort. Retest here means repeating the original test against the fix.
• Effort: 60 + 30 = 90 retests instead of 300, so 30% of the work.

What a clean sample buys you: if all n = 30 samples pass, then with 95% confidence the true failure rate among the mediums is below about 9.5% (this assumes the samples really are random). Plain reading: suppose the real failure rate were p. Each sampled fix passes with chance (1 - p), so all 30 pass with chance (1 - p)^30. If p were 9.5%, that chance is about 0.905^30, which is roughly 5%. So seeing 30 clean passes would be a 1-in-20 fluke if the rate were 9.5% or worse, and we can be 95% sure the rate is lower. The bound solves 0.05 = (1 - p)^n, and the code below computes p for n = 30 and n = 60 (it prints the two bounds, as percentages of fixes that might still fail):

n = 30
print(round(1 - 0.05 ** (1 / n), 3))
n = 60
print(round(1 - 0.05 ** (1 / n), 3))

0.095
0.049

Doubling to 60 samples roughly halves the bound (about 4.9%). If 3 of 30 fail, retest the full group for those applications and report the observed 10% failure rate honestly instead of the "fixed" count.

Reporting to both audiences

• Developers: each ticket gets pass or fail, the exact request and response, and a reopen if it failed.
• Executives: one page with verified-fixed percentage by severity, retest failure rate by team, and the sampling confidence statement (for example, "medium findings: 30 of 240 sampled, none failed, so with 95% confidence the failure rate is below about 10%"). Confidence here means that if we repeated this sampling many times, the method would be wrong only about 1 time in 20, not that it is merely likely.

Pitfalls

• Sampling from a group that is not homogeneous hides the bad corner. That is why you stratify.
• A sample cannot certify a critical finding; that is why Tier 1 is 100%.
• Reporting the developers' "fixed" count as if it were verified inflates the executive number.