sbom.study

PLATE I

What Grows in Your Dependencies

An SBOM is a Software Bill of Materials -- a complete inventory of every component that constitutes a piece of software. Think of it as a botanical catalogue for code: every library, every framework, every utility function is a specimen to be identified, classified, and understood.

Just as an ecologist must know every species in an ecosystem to understand its health, a software team must know every dependency to understand its security, compliance, and resilience.

{ "name": "express", "version": "4.18.2", "license": "MIT" }

cf. Linnaeus, but for npm packages.

PLATE II

The Root System

Beneath every visible plant lies a root network far more extensive than what appears above ground. Transitive dependencies are the root system of software: the packages your packages depend on, branching deeper and wider than most developers ever realize.

Your ten direct dependencies may import a hundred more. Each carries its own history, its own maintainers, its own quiet vulnerabilities waiting to be discovered like fungi in forest soil.

"dependencies": {
  "body-parser": "^1.20.2",
  "cookie-session": "^2.0.0",
  "debug": "~4.3.4"
}

The deepest roots often bear the oldest vulnerabilities.

PLATE III

Identifying Vulnerabilities

In the botanical tradition, identifying a diseased specimen requires careful observation: discoloration, wilting, unusual growths. In software, vulnerabilities leave similar traces -- unexpected behaviors, memory anomalies, logic flaws hidden in rarely exercised code paths.

The SBOM transforms vulnerability management from a reactive scramble into a systematic survey. When a new CVE is published, the SBOM tells you immediately whether the affected species grows in your garden.

CVE-2021-44228 // log4j-core@2.14.1
severity: critical // CVSS: 10.0
status: remediation required

Every vulnerability is a known pathogen. The SBOM is the diagnostic tool.

PLATE IV

The Living Collection

A herbarium is not built once and shelved. It is a living collection that requires ongoing curation -- new specimens added, old ones re-examined, classifications updated as understanding deepens. An SBOM functions the same way.

Software dependencies are not static. They update, deprecate, fork, and sometimes disappear entirely. The practice of maintaining an SBOM is the practice of tending a garden: seasonal, attentive, and never truly finished.

Tend your dependencies as you would tend a garden: with patience and seasonal attention.