SAST, DAST and SCA: buy coverage your delivery teams can use

The application security lead has two scarce resources: engineering time and the opportunity to catch a defect before it reaches users. A scanner that consumes the first without improving the second is an expensive way to create a backlog.

Static application security testing (SAST), dynamic application security testing (DAST) and software composition analysis (SCA) examine different evidence. Choosing among them starts with the applications being delivered, the failures that matter and the stages at which the team can act. A broad product licence does not establish broad coverage.

Three methods, three different views

Method	Evidence examined	Useful selection question	Limit to investigate
SAST	Application code and its modelled behaviour, without testing the deployed service.	Can the tool analyse our languages, frameworks and relevant data flows?	Unsupported code or unmodelled dependencies may leave gaps.
DAST	The behaviour of a running application under test requests.	Can the scan reach the protected functions and roles that matter?	Undiscovered paths and failed authentication can restrict coverage.
SCA	Third-party components and associated vulnerability information.	Does the inventory represent the dependencies in the delivered build?	An incomplete inventory cannot support a complete dependency assessment.

These methods can complement one another. A dependency advisory, a suspicious code path and an observable runtime flaw are different findings, even when they concern the same service. None should be converted automatically into an interchangeable “security score”. The buying decision needs to identify the evidence each method contributes and the risks left for other testing or design review.

Make coverage a demonstration requirement

GitHub’s CodeQL documentation provides a concrete example of why language coverage matters. It lists supported languages including Java/Kotlin, JavaScript/TypeScript and Python, and explicitly excludes unsupported languages such as PHP and Scala. It also describes extending analysis with models for custom dependencies. A successful scan of a mixed-language repository therefore needs inspection: which parts were actually analysed?

Ask the evaluator to show the analysed code, selected rules and relevant exclusions for a representative service. If the organisation relies on a custom framework, include a security-sensitive path through that framework. A product’s general support for a language is a starting point for this test, not proof that every application-specific flow is understood.

For dynamic testing, authentication is part of the test design. ZAP separates the authentication method from the strategy used to verify that requests remain authenticated. Its configuration also includes session management, application context and users. That distinction matters when a scan can log in initially but later loses its session.

Require evidence that the scan reached a protected operation as the intended role. Test session expiry as well as initial login. Use an authorised environment with representative accounts and data, and agree which actions must be excluded or contained. A clean report produced mainly from the login page cannot answer a question about the payment or account-management workflow behind it.

For dependency analysis, GitHub’s dependency graph draws on repository manifests, lock files and dependencies submitted through its API, within supported ecosystems. The evaluation should therefore compare the recognised inventory with the delivered build. Check dynamically resolved or separately supplied components instead of assuming everything shipped is described by the first manifest the scanner finds.

Follow a finding all the way to a fix

Consider a hypothetical evaluation in which a tool produces hundreds of findings, but developers cannot reproduce them or identify the responsible service. The correct response is to examine a representative sample. Some may be duplicates, some may need environment context, and some may reveal a genuine ownership problem. Raw volume cannot distinguish those cases.

For each sampled finding, ask the delivery team to establish the affected version, location, evidence and consequence. Then follow its path into the team’s normal work system. Can the finding retain that context when exported or synchronised? Can an engineer propose a fix, and can the tool show whether the relevant issue remains after the change?

Include known, deliberately introduced defects in a controlled test application, labelled as test cases. Use them to check specific coverage claims, alongside representative application code. Passing that corpus demonstrates detection of those cases; it does not prove a general detection rate across production software. Include benign cases too, so the team can assess how much investigation unhelpful findings demand.

Separate triage from suppression. A false positive needs an explanation of why the rule does not apply. An accepted risk needs a reason, an accountable decision-maker and a point at which it will be reconsidered. An unresolved finding needs an owner and a next action. A “dismiss” button should not erase these distinctions.

Place the gate where the team can respond

A fast check on a proposed change and a longer authenticated scan of a deployed test environment serve different purposes. Agree the evidence required at each stage, the delay the delivery team can accommodate and the response when the scanner itself is unavailable. Start blocking releases only where the rule, coverage and exception route are understood.

Include configuration upkeep, scan infrastructure, triage effort and remediation support in the commercial comparison. A tool that integrates with the existing delivery process may justify a higher licence cost; a cheaper tool may still be the right choice if its coverage fits and the team can support it. Compare the complete operating arrangement.

Once the selected methods produce usable evidence, connect them to secure release decisions and accountable exceptions. The purchase succeeds when a finding changes the right release decision and the team can demonstrate the fix.