A pipeline runs security scanning and produces hundreds of findings that nobody acts on. What should change?

What should change

• Prioritise by reachability and exploitability, not by severity score. A critical vulnerability in a code path the application never calls is a different risk from a medium one in the request handler, and severity scores cannot make that distinction because they are computed without knowing your application.
• Block the build only on reachable, exploitable findings, and route the rest to a tracked backlog with an owner. Blocking on everything produces blanket exceptions and the control stops operating.
• Measure time-to-remediate for the exploitable class, which is the metric that reflects risk. The finding count is not a security outcome.
• Generate the dependency inventory from the build, not by hand, so a new disclosure is answered by a query rather than a search — a difference of days.

What else belongs in the pipeline

• Secret scanning on code, artefacts and logs, with automated revocation on detection rather than a ticket — the window between a secret appearing publicly and being exploited is too short for human triage.
• Static analysis for the patterns that matter in this domain: injection, authorisation checks on every endpoint, insecure deserialisation, missing idempotency on mutating operations.
• Policy checks: no unencrypted storage, no public network exposure without approval, no service without a tenant identifier.
• Provenance attestation, so "was this artefact built from our source" is answerable.
• No ambient credentials in the build environment, which is the single highest-value hardening step and is independent of any scanner.

What does not belong

• Deep dynamic testing on every commit, which is slow and belongs on a schedule.
• Manual review of scanner output, which does not scale and stops happening.
• Anything with a false-positive rate high enough to train the team to ignore it, which is the failure mode that destroys every subsequent control's credibility.

The distinction that makes the programme survivable

Automated checks for the mechanical; human review for the small set requiring judgement — a design change, a new trust boundary, a novel authentication flow. With the trigger for human review stated in advance, so the reservation is a rule rather than a judgement made under pressure.