Four Thousand SAST Findings and a Blocked Log4j Upgrade

Answer: convert an undifferentiated list into a risk-ranked work queue, then baseline only what is genuinely accepted.

1. Segment before counting. Group findings by ASC, by service, and by whether the data path is reachable from an external interface. The monolith's 4,200 endpoints are not equal: authentication, payment and partner-facing endpoints carry the exposure; internal batch endpoints do not. This typically reduces the 'high or critical' 900 to a much smaller set that must be fixed before the season.
2. Apply a rule quality pass. A newly enabled ruleset always carries false positives and duplicates. Sample 50 findings across rule IDs and confirm against code. Rules with a high false-positive rate get tuned or disabled with a recorded rationale; disabling one rule with reasons is legitimate, suppressing the whole ruleset is not.
3. Fix at the sink and at the source. Where a shared library causes 400 identical findings, one fix removes 400 findings. Prioritise framework-level and utility-level remediation over per-endpoint patching; it also survives the next scan.
4. Baseline deliberately. Anything deferred goes into a baseline with an owner, a reason, an expiry date and a review trigger, and every deferred finding is mapped to the ASC it belongs to. The ASC remains 'partially implemented' until the baseline is burned down. A blanket baseline hides the ASC's real state and makes every future scan uninformative.
5. Re-scan on a schedule and report the trend, not just the total: new findings introduced per release are the metric that changes developer behaviour.

Answer: a layered, evidenced, time-bound mitigation - and the ASC is not 'implemented' until the upgrade lands.

Elements to put in place for the 11 services:

• Disable the vulnerable lookup mechanism by configuration where the version permits it, and verify by attempting the exploit in a test environment, not by reading the release notes. A mitigation that is asserted but not tested is not a control.
• Move the WAF from monitor to blocking mode for those 11 services, with a tested rule set and alerting to the on-call channel. Monitor mode WAF is detection, not prevention; claiming it as compensation while it is not blocking is a misstatement in the security file.
• Egress restriction and outbound DNS control, since the exploit path typically requires the target to fetch a remote payload. Network-level blocking reduces exploitation even if injection succeeds.
• Detection content for outbound LDAP/RMI/DNS from application servers, with a named responder and a tested playbook.
• Documented risk acceptance for eight weeks, signed by the application owner, with the upgrade date, the re-test date and the escalation trigger if the vendor library slips.
• Record the ASC as partially implemented with a compensating control reference in the application's security file, so the position is visible to the verifier and the auditor.

The pattern to avoid is treating the WAF as a permanent substitute. Compensating controls buy time; they do not remove the defect, and the evidence trail must show that distinction.

Answer: the ASC is not verified; a screenshot of a review is an assertion about an activity, not evidence that the control works.

Steps:

1. Re-open the ASC as partially implemented. Record the reason: the recorded evidence does not demonstrate the ASC's verification criteria. This is not blame; the evidence requirement was never specified at the point the developer was asked for proof.
2. Define what evidence would satisfy the ASC. For secure logging that typically means: a test showing an authentication failure, an authorisation denial and a validation rejection each produce a structured event; that credentials and tokens do not appear in the event payload; that logs reach the central store within an agreed interval; and that tampering with the source does not silently disable forwarding. Each item needs a named verification method - test, inspection or analysis - and a retained artifact.
3. Sample, do not inspect one endpoint. Given 38 services, verify a risk-based sample covering the externally exposed and payment-handling services, plus any service whose logging configuration deviates from the standard.
4. Fix the systemic cause. Add an evidence template to the ASC library so the requirement is stated before implementation, and add an evidence-quality check to the verifier's role description. Otherwise the next 40 ASCs will be closed on screenshots too.
5. Update the application security file so the auditor sees the corrected status and the reason for the change - a corrected self-assessment is a strength, a discovered false claim is a finding.