SAST, DAST and SCA in the Pipeline
You now know the bugs to avoid. But Tiffin merges dozens of changes a week, and nobody can review every line for injection by eye. Automated scanners do the tireless first pass. There are three main families, and each sees something the others cannot.
The rule
SAST reads your code, DAST pokes your running app, SCA checks what you borrowed.
- SAST (static application security testing) analyses source code without running it. It spots patterns like string-built SQL or
innerHTMLwith user data, and points to the exact file and line. It is fast and early, but it cannot see runtime configuration and produces some false positives. - DAST (dynamic application security testing) attacks a running app from the outside, like a careful automated visitor: sending odd inputs, checking headers and cookies. It finds real, reachable problems, including misconfiguration, but it needs a deployed environment and cannot name the line of code.
- SCA (software composition analysis) reads your dependency manifests and lockfiles, and compares every library and version with databases of known vulnerabilities (CVEs). It can also flag licences. Most of your code is borrowed, so this catches a lot, but it knows nothing about bugs in your own code.
Two more scanners join them: secret scanning (from the secrets lesson) and IaC and image scanning (coming in the cloud and container section).
scan:
steps:
- run: secret-scan .
- run: sast src/ --fail-on new:high
- run: sca requirements.lock --fail-on new:high
dast:
needs: deploy-staging
steps:
- run: dast https://staging.tiffin.example --fail-on highThe shortcut
Ask "What does this scanner need to see?" Source → it can run on the pull request. Lockfile → every build. A running app → after deploy to staging.
Pull request
Secret scanning and SAST need only source. Run them on every change for fast, line-level feedback.
Drills
Answer fast — trust the rule.
Which scanner reports that Tiffin uses a library version with a known CVE?
Which approach needs the application to be running?
A finding says "string-built SQL in orders/views.py, line 88". Which tool most likely produced it?
The first SAST run reports 400 existing findings. What is the best gating policy?
Why run SCA on a schedule as well as on every build?
Remember
- SAST reads your code, DAST pokes your running app, SCA checks what you borrowed.
- Ask what the scanner needs to see: source, lockfile, or a running app.
- Baseline old findings and fail only on new serious ones, so the gate stays on.