A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component, library, and dependency that goes into a piece of software. The easiest way to picture it is an ingredients list printed on the side of an application.
Its value shows up during an incident. When a serious flaw such as Log4Shell surfaces, an organization with current SBOMs can answer, within minutes, which of its products ship the vulnerable library and where. Two common formats, SPDX and CycloneDX, make that data portable between tools and vendors. The catch is upkeep: an SBOM generated once and never refreshed drifts out of sync with the code and hands you false confidence. The real payoff arrives when the inventory is produced automatically in the build and continuously matched against vulnerability feeds, so new risks in old dependencies surface on their own.
Why does an SBOM matter for the CISSP exam?
SBOMs belong to Domain 8, Software Development Security, which accounts for 10 percent of the exam and covers supply chain and third-party software risk. Expect the concept to appear as a control for managing dependency and open-source risk, so understand what an SBOM records and how teams put it to use after a vulnerability is disclosed.