Securing the Pipeline
Automated scanning that catches vulnerabilities before they ship.
The heart of DevSecOps is automated scanning in your CI/CD pipeline. Three complementary techniques — SCA, SAST, and DAST — catch different classes of problems. Together they form a security net that runs on every change.
🎯 Learning Objectives
By the end of this lesson you will:
- Understand SCA, SAST, and DAST and what each catches
- Add security scans to a CI pipeline
- Decide when to fail a build on findings
- Understand the value of an SBOM
Three Kinds of Scanning
| Type | Full name | What it checks | Analogy |
|---|---|---|---|
| SCA | Software Composition Analysis | Known vulnerabilities in your dependencies | Checking recalled parts in your supply chain |
| SAST | Static Application Security Testing | Flaws in your source code, without running it | Proofreading the blueprint |
| DAST | Dynamic Application Security Testing | Flaws in the running application | Testing the finished building’s locks |
💡 They complement each other
No single scan finds everything. SCA covers third-party risk (most of your codebase!), SAST catches insecure code patterns, and DAST finds runtime issues only visible when the app is live. Use all three.
SCA — Your Dependencies Are Most of Your Risk
Modern apps are mostly third-party code. A vulnerability in a library you imported is your vulnerability. SCA tools compare your dependencies against known-vulnerability databases.
# In a CI job
npm audit --audit-level=high # Node
pip-audit # Python
trivy fs . # multi-language, filesystem scanAdding Scans to CI
Security scans are just more pipeline steps. In GitHub Actions:
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Dependency scan (SCA)
run: npm audit --audit-level=high
- name: Static analysis (SAST)
uses: github/codeql-action/analyze@v3
- name: Filesystem & secret scan
run: trivy fs --exit-code 1 --severity HIGH,CRITICAL .The --exit-code 1 makes Trivy fail the build when it finds high/critical issues — turning the scan into an enforced gate.
When to Fail the Build
Failing on every finding causes alert fatigue; failing on nothing is pointless. A common policy:
| Severity | Action |
|---|---|
| Critical / High | Fail the build — must be fixed or explicitly waived |
| Medium | Warn; track and fix in due course |
| Low / Info | Report only |
⚠ Don't drown in noise
If the pipeline screams about every low-severity issue, people start ignoring it — including the real ones. Tune severity thresholds and manage false positives so failures stay meaningful.
The SBOM
An SBOM (Software Bill of Materials) is a complete inventory of every component in your software. Generating one lets you answer, instantly: “Are we affected by the new vulnerability in library X?”
trivy image --format cyclonedx --output sbom.json myapp:1.0💡 Why SBOMs matter now
When a major vulnerability drops, teams with an SBOM know within minutes whether they’re exposed. Teams without one spend days searching. SBOMs are increasingly a compliance and supply-chain-security requirement.
🧪 Hands-on Lab
Add a Security Stage
- Add a CI job that runs an SCA scan (
npm auditortrivy fs) - Configure it to fail on HIGH/CRITICAL findings
- Explain which scan (SCA/SAST/DAST) would catch a vulnerable dependency vs a SQL injection in your own code
🧠 Knowledge Check
Which scan type finds known vulnerabilities in the third-party libraries your app depends on?
What is a sensible policy for failing a build on security findings?
💼 Interview Preparation
Explain SAST, DAST, and SCA and how you'd combine them in a pipeline.
Summary
You can now add SCA, SAST, and DAST scanning to a pipeline, set sensible build-failure policies, and generate an SBOM. Next, we tackle one of the most common and dangerous security mistakes: how secrets are handled.