Triaging a Penetration Test Report Six Days Before Release
Northline Retail's release 12 is due in six days. The external penetration test delivered 14 findings, including these: (1) insecure deserialization in an internal admin batch service, CVSS 9.8, reachable only from a hardened jump host with MFA, with no route from the internet, and the testers could not demonstrate exploitation; (2) reflected XSS on a public store-locator page, CVSS 5.3, unauthenticated, with no cookies in scope on that page; (3) a scanner-reported SQL injection on the search page that the testers could not reproduce, where timing suggests the scanner measured a five-second server-side cache miss; (4) verbose stack traces returned in API error responses; (5) password-reset tokens placed in the URL query string and written to load-balancer access logs retained for 30 days. Security policy states that all critical and high CVSS findings block release. The release contains a payment feature change.
1. Evaluate each finding's real risk in this deployment and explain why the CVSS base score alone should not decide.
Read the worked answer
CVSS base score describes the intrinsic severity of a vulnerability in the abstract. It does not know your network topology, your compensating controls, or what data sits behind the affected component.
- (1) Deserialization, 9.8: a code-execution primitive, so it matters - but the path requires a hardened jump host plus MFA and there is no internet route. Real likelihood is far below the score. It stays a high-priority technical debt item and a defence-in-depth concern if the jump host is ever compromised, but it is not the most urgent item for this release.
- (2) Reflected XSS, 5.3: no cookies in scope on that page, so session theft is limited, but it enables phishing on the brand's domain and chaining against other pages. Moderate, and cheap to fix.
- (3) Reported SQL injection: unreproducible, with timing consistent with a cache miss, so probably a false positive. Do not fix blindly and do not accept blindly - verify manually against an uncached parameter.
- (4) Verbose errors: low direct impact, high convenience for attackers. Cheap to fix, no reason to defer.
- (5) Reset token in URL plus 30-day log retention: quite possibly the highest real risk in the report. Anyone who can read logs, a proxy, or a referrer header can take over accounts, and the retention window widens exposure. A CVSS-only policy might score this lower and let it through.
The policy that 'high CVSS blocks release' is a blunt instrument: it would block (1) and could miss (5).
2. Decide block, fix or defer for each finding, and define retest scope and exit criteria with six days left.
Read the worked answer
Block until fixed
- (5) Move the reset token out of the URL into a POST body or one-time exchange, redact it from access logs, purge existing logs, and invalidate outstanding tokens. This is a small code change with a clear acceptance test: no token appears in URLs, referrers or logs.
Fix now (low effort, low regression risk)
- (4) Return generic error responses with a correlation ID for support, and validate that no stack traces or internal hostnames leak.
- (2) Output encoding on the store-locator page is probably achievable in the window; if not, ship only with a signed risk acceptance from the risk owner, given that the release changes payment code.
Defer with a written acceptance and a dated commitment
- (1) Record the exposure assumptions, add monitoring and egress restriction on the batch service, and commit to remediation in the next sprint. Deferral is a decision, not an omission.
Investigate before deciding
- (3) Manual retest with time-based payloads against an uncached parameter. If it is a false positive, document the evidence and do not count it against the release.
Retest scope and exit criteria: retest only the fixed findings plus a regression check on the payment change and the endpoints those fixes touched. Exit requires captured request and response evidence per finding, no open critical or high without a signed acceptance with expiry, false positives documented with the reason, and a scheduled date for deferred items.
3. How should this report change the test approach for the next cycle?
Read the worked answer
The report's gaps are more instructive than its list.
- The false positive shows that scanner findings enter the backlog without reproduction. Add a triage step: reproduce, classify, then ticket. Track the false-positive rate and use it to tune rules.
- The log-leak finding shows the test scope over-weighted internet-facing pages and under-weighted data flows into logs, caches, proxies, referrers and browser storage. Add explicit tests for sensitive data in URLs, application logs, CDN and load-balancer logs, and client-side storage.
- The internal service finding shows that 'not routable, so acceptable' is an assumption, not a verified control. Add network segmentation verification and a threat model for the jump-host path, including what an attacker with a foothold on it could reach.
- The policy using CVSS thresholds should be replaced by a decision rule that considers exploitability, exposure, data sensitivity and compensating controls, with the risk owner making the acceptance call.
Also push left: add acceptance criteria for token handling, error responses and log redaction so these are caught at story level rather than in a six-day window. A penetration test is a detection control; prevention comes from abuse cases executed during the sprint on the payment feature itself.