A software bill of materials, usually shortened to SBOM, is a list of the components and libraries that make up a piece of software, along with details such as their versions and where they came from. It works like an ingredient list. Common SBOM formats include SPDX and CycloneDX, and many tools can generate one from a build or a container image.
An SBOM matters when a vulnerability is found in a widely reused component. Software often bundles or links libraries that its users do not know about, so a flaw in a single library can affect many products. With an SBOM, you can search for the affected component and see which of your products contain it, instead of guessing from product names.
An SBOM shows what is present, not whether a product is exploitable. Whether a vulnerable component can actually be reached depends on how the software uses it, its configuration and whether untrusted input gets to it. An SBOM can also be incomplete or out of date, particularly for statically linked or vendored code, and it only helps if it matches the version that is really deployed.
To use SBOMs effectively, generate them as part of your build, store them with each release, and match them against vendor advisories when new vulnerabilities are announced. Ask vendors for SBOMs for software you depend on, and confirm any match by checking the running version and the vendor's statement about whether the component is affected.