Dependency Scanning and SAST
Modern applications are built mostly from other people's code: a typical service might pull in hundreds of transitive open-source dependencies for every line a team writes itself. Dependency scanning (also called software composition analysis, SCA) inspects a project's dependency tree against databases of known vulnerabilities (like the National Vulnerability Database or GitHub Advisory Database) and flags packages with disclosed CVEs, often recommending or auto-generating an upgrade to a patched version. Static Application Security Testing (SAST) instead analyzes the team's own source code without executing it, pattern-matching for insecure constructs — SQL built via string concatenation, hardcoded credentials, unsafe deserialization, missing input validation — that could become exploitable vulnerabilities.
Cricket analogy: Like a team analyst cross-checking every imported overseas player's disciplinary record against the ICC's database before selection, separately from a batting coach reviewing home-grown players' technique for an exploitable flaw like a suspect off-stump weakness without them facing a single ball yet.
How Dependency Scanning Works
Scanners parse lockfiles (package-lock.json, requirements.txt, go.sum, pom.xml) to build an exact dependency graph, including transitive dependencies pulled in indirectly, then cross-reference each package/version against vulnerability feeds. Findings are usually reported with a severity score (often CVSS-based) and, where a fix exists, the minimum version that resolves the issue. Because new CVEs are disclosed continuously, dependency scanning needs to run on a schedule, not just at merge time, so a dependency that was clean last month but has a newly disclosed vulnerability this month still gets flagged.
Cricket analogy: Like a selector tracing a domestic player's entire pathway through club, age-group, and state team to build a full lineage before cross-checking each stop against disciplinary records, and re-checking that lineage every season since a clean record last year doesn't guarantee one this year.
How SAST Works
SAST tools build an abstract representation of the codebase (an AST or control-flow graph) and run rule sets against it to detect patterns associated with common weakness classes cataloged in the OWASP Top 10 and CWE list. Because SAST never executes the application, it can run early and fast — directly in CI on every commit — but it also tends to produce more false positives than dynamic testing, since it lacks runtime context about how data actually flows in practice; tuning the rule set and triaging findings is an ongoing part of adopting SAST successfully.
Cricket analogy: Like a coach analyzing a bowler's action frame by frame against a checklist of known illegal-action patterns, without a ball being bowled — fast to run after every net session, but it can flag a legal, unusual action as suspicious, needing an umpire's judgment to tune out false alarms.
name: Security Scans
on:
pull_request:
schedule:
- cron: '0 6 * * *' # daily, catches newly disclosed CVEs
jobs:
dependency-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Scan dependencies for known CVEs
run: |
npm audit --audit-level=high
sast:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run static analysis (CodeQL)
uses: github/codeql-action/analyze@v3
with:
fail-on: errorSCA is like checking every ingredient label in a recipe against a public food-recall list, while SAST is like a chef reviewing their own cooking technique for unsafe practices — both matter, but they catch entirely different classes of problems and neither substitutes for the other.
Treating every SAST or dependency-scan finding as a hard pipeline-blocking failure without triage leads teams to either drown in noise or, worse, add a blanket continue-on-error that silently defeats the scan's purpose. Effective adoption usually means gating on severity (e.g., block on critical/high, track medium/low) and maintaining a documented exception process for accepted risk.
Placement in the Pipeline
Both scan types are cheap enough to run on every pull request, giving developers feedback before code merges — this is often called 'shifting left,' catching security issues at the point they're introduced rather than after deployment. Scheduled, repository-wide scans complement PR-time scans by catching newly disclosed vulnerabilities in dependencies that were already merged and considered safe at the time.
Cricket analogy: Like a fitness test being cheap enough to run before every single training session, catching issues before selection, while a full annual medical re-screens the whole squad, catching a new condition that wasn't diagnosable when a player first joined years ago.
- Dependency scanning (SCA) checks third-party packages against known-vulnerability databases like the CVE/NVD.
- SAST analyzes a team's own source code statically for insecure patterns without executing it.
- Dependency scans should run both at merge time and on a recurring schedule to catch newly disclosed CVEs.
- SAST catches issues early and cheaply but tends toward more false positives than dynamic testing.
- Findings should be gated by severity rather than treated as uniform pass/fail, with a documented exception process.
- Running both scan types on pull requests exemplifies 'shifting left' security into the development workflow.
Practice what you learned
1. What does dependency scanning (SCA) primarily check for?
2. What distinguishes SAST from dynamic testing approaches?
3. Why should dependency scanning run on a recurring schedule in addition to at merge time?
4. What is a known drawback of SAST tools compared to dynamic analysis?
5. What is a recommended way to handle scan findings instead of blocking on every single one?
Was this page helpful?
You May Also Like
Pipeline Security Basics
CI/CD pipelines are a high-value attack surface with broad access to source, secrets, and production, so securing them requires trusted inputs, isolated execution, and verified artifacts.
Managing Secrets in CI/CD
CI/CD pipelines need credentials for external systems, so secrets must be stored encrypted, injected at runtime, scoped narrowly, and never committed to source control or build logs.
Test Reporting and Quality Gates
How pipelines surface test and coverage results in a structured, actionable way, and how quality gates use those results to block risky changes automatically.
Least Privilege for CI/CD Service Accounts
CI/CD service accounts should hold only the exact permissions their pipeline needs, scoped narrowly and time-limited, so a compromised job can't cascade into a broader breach.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics