3,200 Findings, One Security Engineer, and an Eight-Week Audit
FinCo has 140 repositories and uses SAST, software composition analysis, container scanning, and DAST. The security dashboard shows 3,200 open findings: 210 critical, 900 high, and the rest medium or low. The policy says critical findings must be fixed within 30 days and high within 90 days, but compliance is 38%. The legacy payments service has 48 critical findings, no named owner, and its last commit was two years ago; it still processes 4% of transactions. Developers say 40% of SAST findings are false positives and that the scan adds 9 minutes to every pull request. The company has one security engineer and an external audit in eight weeks. Leadership wants to block merges with critical findings immediately.
1. How would you triage the backlog and set policy, given one security engineer and an audit in eight weeks?
Read the worked answer
Do not block all merges immediately. With one security engineer and 3,200 findings, a blanket block will stop delivery and push teams to bypass controls. Triage by exploitability and exposure, not just severity. For the 210 criticals, ask whether the service is internet-facing, whether it handles regulated data, whether the vulnerable path is reachable, and whether a compensating control exists. Use EPSS and reachability data to rank. The legacy payments service needs a named owner before remediation; if no one will own it, isolate it behind a network policy and a WAF, and document the risk exception. Set a two-tier SLA: critical and internet-facing within 7 days, other critical within 30; high within 90. Automate deduplication and direct-versus-transitive dependency classification. For the audit, report a burn-down plan with dates and owners, not a promise to fix everything. Block only new critical findings on changed code, which is enforceable and fair.
2. How would you reduce false positives and developer friction without weakening the audit evidence?
Read the worked answer
Tune SAST rules to the languages and frameworks in use; disable rules with a measured false-positive rate above 30% until reviewed. Baseline existing findings so PRs only show new or changed issues. Require every suppression to have an owner, a reason, and an expiry date. Move full-repo scans to nightly and run diff-aware scans on PRs; keep the nine-minute budget by caching dependencies. Use reachability analysis for software composition analysis to separate exploitable from unused transitive libraries. Add a developer self-service triage portal and a weekly 30-minute office hour. Measure false-positive rate by rule and scan duration; target below 15% and under five minutes for PR scans. This preserves audit evidence because suppressions and exceptions are explicit, owned, and time-bound rather than silent.
3. Which metrics would you present to the external auditor, and what would you avoid reporting as a headline?
Read the worked answer
Report leading and lagging indicators: open criticals by age and owner, mean time to remediate by severity, percentage of repositories with scanning enabled, SLA compliance trend, exception count and expiry, and false-positive rate. Also report the legacy payments service separately, because aggregate numbers hide concentrated risk. Show a burn-down from 210 criticals to the target, with a forecast based on the last four weeks of throughput. Auditors will ask who accepted each risk and when, so keep an exception register. Avoid reporting only total findings, which can improve by closing easy low-severity issues while criticals age. Also avoid claiming compliance from scan coverage alone; coverage shows visibility, not remediation.