Halcyon Logistics: 4,180 SAST findings and a six-minute DAST scan

SAST: signal-to-noise and scope, not tool choice.

• Scope out test, generated, vendored and migration paths. That alone removes roughly 232 of the 380 Criticals and a large share of the noise, and it is defensible because those paths do not ship.
• Validate the three loud rules against a hand-reviewed sample of 20 findings. At a 70% false-positive rate, an unreviewed Critical is noise; tune, downgrade or disable, and record the decision.
• Teach the engine your frameworks: custom sanitizers and sinks for the internal ORM and template helpers, so it recognizes existing escaping instead of flagging it.
• Baseline existing findings as accepted debt with an owner and a date, then gate only on new or changed code. Diff scanning on pull requests is what makes a build gate survivable.

DAST: coverage, not frequency.

• An unauthenticated scan of a login page reaches perhaps 5% of the attack surface. Configure a recorded login with session refresh, run two roles from different tenants to catch broken object-level authorization, and import the OpenAPI spec so the API endpoints are actually crawled.
• Seed realistic data; an empty staging database hides most business-logic findings.
• Run nightly and on every release, against an isolated environment whose configuration mirrors production.

Both: a quarterly scan is a compliance artifact. Until the tools run in the pipeline, nothing changes.

Filter, then dedupe, then score.

1. Filter: remove non-shipping paths (test, generated, vendored). Volume drops by more than half before anyone reads a finding.
2. Dedupe by root cause: dozens of findings usually trace to one unsafe helper, one deserialization config, one string-concatenated query builder. Count fixable causes, not findings - the 30-day plan should be a handful of engineering tasks, not 380 tickets.
3. Score the survivors on four axes: is the input attacker-controlled and reachable from an untrusted source; is the endpoint internet-facing; what data does it touch; does the threat model already list it as a crown-jewel flow. Score against the six flows that actually matter - login, file upload, payment, admin console, API keys, report export.

First 30 days:

• Fix the top three confirmed-exploitable Criticals in internet-facing services.
• Land the systemic fixes: parameterized query helper, safe deserialization settings, output encoding defaults. One change often retires a hundred findings.
• Complete the rule tuning and publish the exclusion list with rationale, so developers stop distrusting the tool.
• Open an exception register: every deferred Critical gets an owner, a compensating control and an expiry date.
• Cross-reference with a DAST run and one targeted manual test to validate that SAST Criticals are real.

Do not attempt 380 individual fixes: the plan dies in week two and the program loses credibility.

Why raw counts mislead. Finding volume rises when scanning improves and falls when developers stop reporting or when rules get suppressed - the number moves for reasons unrelated to risk. A dashboard showing 4,180 falling to 1,200 may mean the program got quieter, not safer. It also rewards the wrong behavior: teams learn to make the number go down.

Better measures:

1. Pipeline coverage: percentage of merges to production that passed SAST and authenticated DAST before release. A leading indicator.
2. Time-to-remediate by severity for confirmed findings: median and 90th percentile days for Critical and High. Shows execution, not backlog size.
3. Escape rate: vulnerabilities found in production incidents or external pen tests divided by total findings confirmed that quarter. This is the closest proxy for whether the program works.
4. Crown-jewel coverage: number of the top ten business-critical services with a current threat model, authenticated DAST coverage and an owner.
5. Tool precision: confirmed-true-positive rate per rule and the volume of developer-suppressed findings. Rising precision means the program is earning trust.

Presentation: trend lines with definitions and data sources, plus the ageing distribution of open Criticals. State plainly that a rise in reported findings after enabling authenticated DAST is expected and healthy - new visibility is not new risk. Set the target as escape-rate reduction and remediation time, never as a finding count. Also give the board the exception register total: that is the accepted-risk figure they are actually accountable for.