Security Engineering
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

Invent
Match
Reach
Gate
SBOM
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
In progress
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

Official documentation