Code Scanning: What SAST, DAST and SCA Actually Observe

TL;DR: A code scan is evidence about a particular input under a particular analysis. Separate source paths, dependency inventory and running application behavior, then check that the assessed revision is the one you deploy.

Different observations answer different questions

Static application security testing (SAST) analyzes source or a representation derived from it. A useful dataflow finding connects an input to a sensitive operation and explains whether validation interrupts that path. Software composition analysis (SCA) identifies third-party components and known advisory matches. Dynamic application security testing (DAST) observes a running application's responses within an explicitly authorized scope. Fuzzing exercises input handling against a defined failure oracle.

These methods overlap, but their negative results are different. A SAST rule can miss a framework it does not model. An SCA inventory can omit a bundled library. A dynamic test may never reach an authenticated workflow. A fuzzer may exercise only a parser and say nothing about tenant authorization. None of these alone proves that a generated patch preserves a payment rule.

Preserve the evidence envelope

Record the repository revision, build configuration, analyzed languages, rules or query pack version, excluded directories, analysis status and timestamp. For dynamic testing, also retain the application version, account permissions, endpoints exercised and written authorization. Analyze only systems you own or are explicitly authorized to test; the exercises here use synthetic records rather than live targets.

A finding needs enough context for a reviewer to reconstruct the reasoning. Keep source and sink locations, relevant assumptions and the proposed control. Do not copy secrets or personal data into issue trackers to make a report look concrete. Redacted identifiers and minimal excerpts can establish the defect without duplicating sensitive material.

A worked review

In a fictional document service, source analysis finds an untrusted filename reaching a storage operation. The reviewer confirms that the service supplies its own object identifier and never uses that filename as a path. The finding may be inapplicable to this revision, but the explanation must name that control. A blanket suppression for every file-operation finding would hide a future code path that bypasses it.

The next release moves the operation into a plugin. If the analysis cannot model plugin calls, record an analysis gap. Add a focused defensive test of permitted and denied object access, and retain the manual review. Do not relabel a partial analysis as a full pass merely because the scanner emitted no alerts.

Tool examples, checked November 2026

GitHub code scanning reports potential vulnerabilities and coding errors in repositories. Its workflow configuration describes event-triggered and scheduled analysis. Assess language coverage, build behavior and query configuration for your repository rather than assuming the default checks cover business logic.

Snyk's data-handling documentation distinguishes how product integrations process source and manifests. That distinction matters when approving an integration for a repository containing regulated data. Procurement should review actual data flows, not just the product category.

From detection to a release decision

Block a release on a confirmed boundary failure or a missing required assessment, using an explicit emergency exception process. Route uncertain findings to an owner with a deadline. Re-run the relevant analysis after the repair and check a legitimate workflow as well as the denied case. This keeps the gate meaningful when scanners change their rules.

Practise the SAST, DAST, SCA and fuzzing interview.