Security

Dependency Analysis

Modern software is mostly other people's code — a typical application pulls in dozens or hundreds of third-party libraries, and each one is a potential vector for a known vulnerability the application team never wrote and might not even know is there. Dependency analysis (often called Software Composition Analysis, SCA) is the practice of systematically finding out exactly what's in a codebase and checking each piece against known-vulnerability databases.

Quick reference

What it is: Identifying every third-party component — direct and transitive — in a codebase and cross-referencing each one against known CVEs.
Mental model: An ingredient list for software — you can't know if something contains a recalled ingredient until you know exactly what's in it, including ingredients your ingredients brought along.
Key numbers: A typical application has far more transitive (indirect) dependencies than direct ones — one direct dependency can pull in dozens more nobody on the team ever explicitly chose.
Reach for it when: Before shipping anything with third-party dependencies — virtually all software — and continuously afterward as new CVEs get published against components already in production.

Why it matters: a known, unpatched CVE

The 2017 Equifax breach is the standard example cited across the security industry precisely because it wasn't a zero-day at all — it exploited a vulnerability in Apache Struts that already had a public CVE and an available patch for months before the breach happened. The failure wasn't a lack of security research; it was that nobody's dependency-tracking process caught that a known-vulnerable version was still running in production.

Direct vs. transitive dependencies

A vulnerability three layers deep in a transitive dependency is exactly as real a risk to the running application as one in a dependency the team picked directly.

SBOM: the Software Bill of Materials

An SBOM is a formal, machine-readable inventory of every component (and typically every specific version) that makes up a piece of software — increasingly a regulatory and contractual requirement, not just an internal nicety. Two formats dominate: SPDX and CycloneDX, both designed to be generated automatically from a build rather than maintained by hand.

How scanning actually works

The component list produced here is exactly the SBOM — the vulnerability report is what you get once you cross-reference it against what's currently known.

Real tools

Tool	Ecosystem	What it does
npm audit / yarn audit	JavaScript/Node	Built into the package manager itself — flags known vulnerabilities in the resolved dependency tree.
pip-audit, safety	Python	Scan installed or declared packages against known Python-ecosystem vulnerabilities.
OWASP Dependency-Check	Java and others	A long-standing, general-purpose open-source SCA tool covering multiple language ecosystems.
Snyk, GitHub Dependabot	Multi-ecosystem	Commercial/hosted scanning, often with automated pull requests bumping a vulnerable dependency to a fixed version.
Syft + Grype	Multi-ecosystem, containers	Generate an SBOM from a filesystem/container image (Syft) and scan it for known vulnerabilities (Grype).
Yocto's cve-check class	Embedded Linux	Cross-references every build recipe's declared version against the NVD feed at build time — see below.

Why this is harder in embedded

Dependency analysis in embedded systems runs into real constraints web and application development mostly don't have:

No package manager, often — vendored or copy-pasted source (a vendor's HAL, a driver copied from a reference project) doesn't appear in any manifest a scanner can automatically read.
Cross-compiled binaries obscure contents — a scanner looking at a compiled firmware image can't easily tell which library versions were statically linked into it.
Long field lifespans — a device shipped years ago keeps running whatever library versions it shipped with, quietly accumulating new CVEs against those versions with no manifest-driven alert to notice.
Yocto's cve-check class is a real, concrete answer built for exactly this: it checks every recipe's declared version against the NVD feed during the build itself, specific to the embedded Linux build-system constraints above.

Real-world applications

CI/CD gating — automatically failing a build when a new critical CVE is found in a dependency, before it ever reaches production.
Contractual/regulatory SBOM delivery — increasingly required for software sold into regulated industries or to government customers.
Embedded firmware build-time scanning — Yocto's cve-check class catching a known-vulnerable library version before an image ships.
Incident response — when a new CVE breaks, an existing SBOM lets a team instantly know which products are affected, instead of re-auditing everything from scratch under time pressure.

Gotchas

Field notes

A clean scan today doesn't mean clean tomorrow — new CVEs get published against old, unchanged code constantly, so scanning has to be continuous, not a one-time gate at release.
Vendored or copy-pasted source code with no formal dependency manifest is functionally invisible to most automated scanners — a real, common blind spot in embedded specifically.
A flagged CVE doesn't automatically mean a given application's specific usage is actually exposed — the vulnerable code path might not be reachable the way the library is actually used, though proving that takes real analysis, not just assumption.
Pinning dependency versions without a process to periodically revisit those pins quietly turns "we controlled our versions" into "we're stuck on old, increasingly vulnerable versions."