4,200 SAST Findings and a Critical Transitive Dependency
Lumen Pay is a fintech with 120 developers and weekly releases. SAST was added to CI six months ago; it now produces about 4,200 findings per month, 78% marked false positive by developers, and the security team has two application security engineers. The pipeline does not block on findings, so teams merge anyway. A critical vulnerability in a transitive Java dependency, CVSS 9.8 with a public exploit, is present in 17 services; the fix requires upgrading a framework that breaks two services. Release freeze starts in five days for a regulatory reporting deadline. The VP of Engineering says security must prove the vulnerability is exploitable before any delay; the security team has no runtime evidence. A business unit also wants a new partner API with file upload next month.
1. Triage the critical dependency finding and decide the release approach. Show the reasoning you would use and how you would communicate it.
Read the worked answer
Start by replacing the exploitability argument with exposure facts. Build a service inventory for the 17 services: internet-facing or internal, authenticated or anonymous, which framework function is reached, whether the vulnerable path is exercised at runtime, and what data the service can access. CVSS 9.8 plus a public exploit is enough to prioritize, but it is not enough to say every service must delay. The decision should be risk-based and documented.
For internet-facing or anonymous-access services, block release until patched or mitigated. Mitigations can include a WAF rule, network policy, disabling the vulnerable feature, or removing the dependency path. For the two services that break on upgrade, assign a named engineer to test the upgrade immediately, and prepare a rollback plan. If the upgrade cannot be completed before the freeze, require a time-bound risk acceptance signed by the product owner, VP Engineering, and CISO, with compensating controls and a post-freeze remediation date.
For internal-only services with strong authentication and no reachable vulnerable path, allow release with monitoring and a patch date. Communicate in business terms: which customer paths are exposed, what could happen, what is being done, and who owns the residual risk. Do not ask security to prove exploitability in five days; ask engineering to prove exposure or accept risk. That reverses the burden appropriately without ignoring the finding.
2. Redesign the application security program to reduce noise and improve signal with only two AppSec engineers.
Read the worked answer
Stop treating SAST volume as the program. With two engineers, the only viable model is guardrails plus risk-based review. First, establish a baseline and report only new or changed findings on pull requests, not a monthly flood. Second, tune rules for the tech stack and suppress test code, generated code, and known false-positive patterns with documented expiry. Track false positive rate per rule and retire rules that cannot be tuned.
Define severity and action thresholds. Block merges on verified secrets, critical dependency vulnerabilities with a known exploit in reachable code, and high-confidence injection findings in internet-facing services. Other findings become backlog items with owner and SLA. Route findings to the team that owns the repository, not to AppSec. AppSec reviews high-risk designs, threat models, and the top services by data sensitivity.
Add software composition analysis with SBOM generation and reachability where feasible, plus secret scanning. Use security champions in each product group for first-line triage. Measure time to remediate critical and high findings, percentage of repos with SBOM, false positive rate, and percentage of high-risk services with a threat model. Do not measure total findings; that rewards noise.
3. Advise the business unit on the new partner API with file upload given the team's constraints. What conditions would you set?
Read the worked answer
Treat the partner API as a design review, not a last-minute scan. The file-upload feature creates concrete risks: malware upload, unrestricted file type, path traversal, storage exposure, denial of service through large files, and cross-tenant data access. Start with a short threat model covering who the partner is, what data is uploaded, where it is stored, who can retrieve it, and what happens on failure. Reuse a pre-approved upload pattern rather than inventing one.
Set conditions: enforce file type and size limits, scan uploads asynchronously, store files outside the web root with random object names, serve through short-lived signed URLs, and enforce authorization on every retrieval. Add rate limiting, logging of upload and download events, and a quarantine path for malware. Do not allow public bucket access. Require a penetration test or focused security review before launch, and include the partner in incident notification expectations.
If the deadline is tight, phase the launch: limited file types, manual review for the first weeks, and no external sharing. Document residual risk with a business owner and an expiry date. The two AppSec engineers should review the design once and provide a reusable pattern, not act as gatekeepers for every line of code.