NIST describes an SBOM as a formal record containing the details and supply chain relationships of the components used in building software. Think of it as the ingredients label for your app. A typical JavaScript project lists a few dozen packages in package.json but installs many hundreds once their own dependencies are counted, and the SBOM lists all of them.
The point of having one is speed when something goes wrong. When a serious vulnerability is announced in a widely used library, the first question is whether you are affected. With an SBOM you search a file. Without one you dig through every project by hand. SBOMs are usually produced in a standard format, CycloneDX or SPDX, so that tools can read them, and enterprise and government buyers increasingly ask suppliers for one.
For AI-built apps an SBOM is also a useful review step, because the assistant may have added packages you never consciously chose. Generating the list and reading it once is a quick way to spot libraries you do not recognise, abandoned projects and duplicates. Generate it automatically in your build so it always matches what you actually ship.
npm sbom --sbom-format cyclonedx > sbom.json