Home / Knowledge hub / SBOM
Knowledge hub
SBOM
A list of every component your application includes, with versions.
What it means
An SBOM is a software bill of materials: a list of every component your application includes, with versions. Not only the packages you chose, but everything those choices pulled in behind them.
Your build generates it. Nobody writes one by hand, because a hand written list goes stale the week after somebody finishes it.
Why it matters
The value shows up on a bad morning. A widely used library turns out to be flawed, it reaches the news, and your customers want to know whether it affects them. With a bill of materials you answer in minutes. Without one, engineers spend a week reading dependency files.
Buyers now ask for one directly, so having it ready answers a sales question as much as a security one. It settles internal arguments too. Somebody has to judge whether an upgrade is urgent, and that goes faster when everyone sees which releases carry the affected version. It helps you argue the other way too. Sometimes the honest answer is that the flawed version never shipped, and you want that on paper within the hour.
How it shows up
The usual gap is a bill of materials that exists but has gone stale. Somebody generated it once for a questionnaire, never regenerated it, and it now describes a release from last year.
Depth is the other gap. A list of the twenty packages you chose is not the answer, because the flaw usually sits three levels down, in a dependency nobody chose directly. CISA and the NTIA both set out minimum elements worth meeting. Generate it in the build, store it with the release it describes, and make sure somebody can retrieve last quarter's copy when an awkward question arrives.
Questions people ask
SBOM, answered
Do we have to give customers an SBOM?
Buyers increasingly ask, and some contracts now require one. Nothing forces you in general, but refusing is a conversation you will keep having.
Producing it is cheap once the build does it. Producing it by hand for every request is not.
Should we use CycloneDX or SPDX?
Either. Both are established, and most tooling emits both, so generating both in your build costs one extra command.
Choose by what the customer or the regulator in front of you asks for.
Is an SBOM just a compliance checkbox?
It becomes one if you generate it once and file it away. It earns its keep on the morning a popular library turns out to be flawed and somebody asks whether you ship the affected version.
The test is simple. Can you answer that about a release from last quarter, in minutes?
How is an SBOM different from our dependency file?
A dependency file lists what you asked for. A bill of materials lists what you actually got, including everything those packages pulled in behind them.
That second layer is where the awkward flaw usually lives.
Does Cyberlop produce an SBOM for us?
No. Cyberlop tests applications and reports findings, and dependency issues are one of the ten classes it covers.
Generating and storing a bill of materials belongs in your build, next to the release it describes.
Related
Terms that sit next to this one
SCA
Checking your libraries against databases of published vulnerabilities.
Dependency vulnerability
A known flaw in a library your application ships.
Supply chain attack
Reaching you through a library, a build tool or a vendor you trust.
Known-vulnerable component
A library or runtime with a published flaw that you are still shipping.
A library breaks tomorrow. Then what?
Dependency issues make up one of the ten classes Cyberlop tests, alongside the code your own team wrote. Try it on one application for 30 days and read both lists.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.