Selecting Security Tools and Producing Audit Evidence Under Pipeline Constraints

Match each tool type to what it can actually see, and to where it fits in the delivery flow.

• Secret scanning: cheapest and highest value given the incident. Pre-commit hook, CI check on the diff, and a full history scan of all 40 repositories (rotating anything found). Open-source options are adequate, so no licence spend.
• SAST: sees source and dataflow, good for injection and unsafe API use, but needs build integration and tuning. Run incremental analysis on changed code in the pull request (target under three minutes) and a full scan nightly.
• SCA: already present. The problem is signal, not coverage. Add reachability or exploitability filtering, prioritise direct dependencies, allowlist with owners, and severity-based SLAs.
• DAST: needs a running, authenticated environment, so it cannot fit a 12-minute build; run it nightly against staging.
• IAST: useful but needs agents deployed across services - too much for this cycle.

Spend the licence where the gap is largest. If API and web exposure dominate the risk, buy DAST with good authentication support; if the main languages are poorly served by the open-source SAST rule sets, buy SAST. Never buy a tool to solve an alert-volume problem that is really a tuning and triage problem.

At 300 alerts a month with 85% unfixable transitive dependencies, blocking on everything stops delivery within days. The predictable response is bypass - developers find a workaround, the gate becomes theatre, and the one finding that matters is ignored along with the rest. That is exactly the failure mode that let the AWS key reach a public repository.

Gate design

• Block on newly introduced findings in changed code, critical or high severity, in rules with demonstrated precision.
• Baseline existing debt and burn it down through a prioritised backlog with SLAs (for example critical 7 days, high 30, medium 90), not by blocking merges.
• Allow suppression only with an owner, a reason and an expiry date - never a permanent blanket ignore.
• Tune rules during the first two sprints using the first 100 findings to measure precision; remove or downgrade noisy rules.
• Surface findings where developers already work (pull-request annotations, ticket creation) rather than a separate dashboard nobody opens.
• Measure precision and mean time to remediate, not alert count.

Sequencing: roll out secret scanning first, then SAST, then DAST, so each is tuned and trusted before it can block anything. Announcing all three as blocking in one sprint guarantees the same fatigue that killed the SCA dashboard.

The auditor wants evidence that a process is defined, operated and improved - not that a product was purchased.

Evidence pack

• Secure development policy and the security requirements baseline (OWASP ASVS as the verification reference).
• Tool configurations and versions, and where each runs in the lifecycle.
• Scan results with triage decisions, including false-positive records and accepted risks with owner and expiry.
• Gate definitions plus proof of enforcement, for example blocked merge requests and the reasons.
• Training and awareness records for developers.
• Release test reports and remediation metrics such as mean time to remediate by severity.

Mapping: cite the Statement of Applicability entries under ISO/IEC 27001:2022 Annex A control 8 (technological controls), including 8.25 secure development life cycle, 8.28 secure coding, 8.29 security testing in development and acceptance, and 8.31 separation of development, test and production environments.

To management: buying a tool does not create compliance. The evidence is the process around the tool, and the current unfiltered SCA backlog would read as an unmanaged risk rather than a control. Keep the single commercial licence where it produces the most verified signal, and note that open-source coverage for secret scanning and SCA is sufficient - the gap to fund is tuning and triage ownership, not another scanner.