DevSecOps Practice Hub

Static Application Security Testing

Analyse source code, bytecode or binaries for security defects before the application is built or deployed.

BeginnerSASTApplication

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Code Static analysis, secret detection and secure coding practices.
  • Build Dependency scanning, image scanning, SBOM generation and signing.

Overview

Static analysis inspects code without executing it. Rules and dataflow engines look for injection sinks, unsafe deserialisation, weak cryptography, hardcoded credentials and other recurring defect classes. Because it runs on the repository, SAST is usually the first automated security control a team adopts.

Why it matters

Defects found while the developer still has context are far cheaper to fix than the same defect found in production. SAST gives fast, repeatable feedback on every merge request and creates an auditable record of code-level security checks.

How it works

  1. 01The scanner parses source into an AST or intermediate representation.
  2. 02Rule packs and taint-tracking queries look for untrusted input reaching dangerous sinks.
  3. 03Findings are annotated with severity, CWE identifiers and file/line locations.
  4. 04Results are published to the merge request and, optionally, gate the pipeline.

Common tools

SemgrepSonarQubeCodeQLCheckmarxGitLabGitHubPythonJenkins

Implementation examples

yamlSemgrep in GitLab CI
stages:  - test sast:  stage: test  image: returntocorp/semgrep  script:    - semgrep --config auto --sarif --output semgrep.sarif .  artifacts:    reports:      sast: semgrep.sarif
Runs Semgrep's curated rule set against the repository and publishes SARIF so findings appear in the merge request. Tune the rule set before enabling blocking behaviour.
bashLocal scan before pushing
semgrep --config auto --error .
`--error` returns a non-zero exit code when findings exist, which is useful in a pre-push hook.

Security considerations

  • Scanners need read access to the full repository; run them on trusted runners.
  • SARIF output can contain code snippets — treat reports as sensitive artefacts.

Best practices

  • Start in report-only mode and baseline existing findings before enforcing gates.
  • Scope rule packs to the languages actually present in the repository.
  • Run incremental scans on merge requests and full scans on a schedule.
  • Route findings into the same tracker developers already use.

Common mistakes

  • Blocking every pipeline on day one, which trains teams to bypass the gate.
  • Ignoring false-positive triage, so signal quality degrades over time.
  • Treating SAST as a substitute for dependency and secret scanning.

Hands-on labs

Learning resources