Security Engineering In progress
Intermediate 17 min read Security Engineering
SCA and SBOM: Know Your Dependencies
The supply-chain of code you didn't write: software composition analysis, SBOM generation, CVE reachability, and the incident-readiness puzzle that Log4j built.
SCASBOMsyftgrypesupply chainCVEreachability
Introduction
What is this?
SCA (Software Composition Analysis) scans your dependencies — npm, pip, images, OS packages — for known CVEs and license risks; an SBOM is the machine-readable inventory that makes the scan meaningful.
Motivation
Why do you need it?
- The average app spends most of its attack surface inside dependencies you never wrote.
- SBOMs let you answer 'was we exposed to Log4j?' in minutes, exactly when the world asks.
- Software bills of materials are now demanded by regulators and auditors — they are evidence, not a binder.
Think about it
Mental model
Imagine
A kitchen's pantry
Think of
A list of ingredients with best-before labels
You cannot run a recall on mysterious bags; the SBOM is the inventory that makes the recall take 5 minutes.
Mechanics
How it works
- SCA tools parse manifest and lock files (package.json, poetry.lock, go.sum) plus image layers.
- They cross-reference the catalog against CVE databases with severity and (in better tools) reachability.
- An SBOM (SPDX/CycloneDX) captures names, versions, and relationships as a structured artifact next to the binary.
- New releases feed diffs: 'this release adds 3 CVEs via one library' becomes an instant review prompt.
Dependency to decision
Inventparse manifests/lockfiles
Matchagainst CVE feeds
Reachis the vulnerable path actually exercised?
Gateblock/remediate aware
SBOMship the inventory artifact
Real world
In production
- An org ships an SBOM with every release; the day a critical CVE drops they answer 'affected? yes, 12 images' in an hour.
- A team's Dependabot/renovate PRs auto-triage by reachability, so low-reachability bumps don't flood the queue.
- A vendor contract now requires an SBOM in the artifact; procurement reads it at due-diligence.
Guidelines
Best practices
- Generate SBOMs at build time, signed and stored with the artifact.
- Scan at every commit and on new releases; treat 'new CVE appeared' as an auditable event.
- Triage by reachability, not score alone: a vulnerable-but-unreachable lib is a plan, not a fire.
- Keep license checks in the same scan — supply-chain risk includes legalese.
Watch out
Common mistakes
- Scanning 'dependencies' but missing lock file drift, so the deployed image never matches the scanned manifest.
- Treating every CVE hit as a P0 — the queue floods and the real exposure drowns.
- No SBOM anywhere, then Log4j week is a week of archaeology.
- Silently updating 'to clear the scan' without a license/reachability review of the new version.
When things break
Debugging tips
- When a scan's CVE count disagrees with the feeder, verify the lockfile is what actually built the image.
- Use SBOM diffing across releases to spot exactly which library introduced a spike.
- Check reachability tools' call-graph claims before you panic-drop the dependency.
Security
Security considerations
- SBOMs and scan databases are consumption-grade: verify the tool's update cadence and sign your SBOMs.
- The scan itself reads dependency names only; secrets in manifests still leak — scan those too.
Interviews
Interview checkpoint
Practice
Hands-on lab
Generate an SBOM and Simulate a CVE Triage
45 min · intermediate
Objectives
- Publish an SBOM from a local project.
- Scan it for known vulnerabilities.
- Triage the top finding by reachability and write a plan.
Generate an SBOM and Simulate a CVE Triage
45 min · intermediate
0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself
Quick quiz
0/2
1
An SBOM's primary job is...
2
Reachable dependency vulnerabilities are...
Go deeper