SBOM Viewer Guide: Read a Software Bill of Materials Like a Map

A software bill of materials, or SBOM, is a structured list of the components inside a piece of software: the libraries, frameworks, and packages it was built from, with their names, versions, suppliers, and licenses. Raw SBOM files, however, are written for machines, not people. They are long, nested, and full of identifiers that mean little at a glance, which is why most SBOMs that get generated are never actually read. The SBOM Viewer presents an SBOM as a readable inventory, so a person can search it, sort it, and answer questions about it without learning the file format first.

The questions an SBOM answers are practical ones. A vulnerability is announced in a popular library, and a team needs to know within the hour whether their product uses it and which version. A customer asks for a list of open-source components and their licenses before signing a contract. An auditor asks whether any component in a release carries a license the company cannot accept. A developer inherits an old project and wants to know what it is actually built from before changing anything. In each case the SBOM already contains the answer; the viewer is what makes the answer reachable in minutes instead of after a day of parsing files.

Reading an SBOM well also means knowing what it cannot tell you. An SBOM lists components, but it does not say whether a vulnerable function inside a component is actually reachable by an attacker, and it does not prove that the software contains nothing beyond what is listed. It is an inventory, not a verdict. Its value is that it turns a vague question, are we affected, into a specific one, which versions of which components do we ship, and that specific question is the one a team can act on.

How an SBOM is viewed

The viewer starts by parsing the SBOM document, which will usually be in one of the two standard formats, SPDX or CycloneDX. Both formats describe the same kinds of information in different shapes, and the viewer normalizes them into a common view: a table or tree of components, each with a name, a version, a supplier where known, a license, and a unique identifier. Many viewers also show the relationships between components, so you can see that a top-level library pulls in several smaller ones beneath it, which is the dependency tree that matters when a vulnerability appears in a small, deeply nested package.

The most useful features of a viewer are the ones that turn a long list into a searchable inventory. Search by name finds a component immediately, instead of requiring a scroll through hundreds of entries. Filtering by license shows every component under a particular license, which is the view an auditor wants. Sorting by name or version groups related components together. Some viewers also highlight components with missing information, such as a component with no version or no license declared, because those gaps are themselves findings: a component without a declared license cannot be cleared for use, and a component without a version cannot be matched against vulnerability reports.

A viewer works on a document you supply. It does not scan your systems, it does not reach into your code repository, and it does not need credentials. That is a safety advantage, but it also sets a responsibility: the document you view should be generated from the actual build, not assembled by hand, because a hand-assembled inventory reflects what someone believed was in the software rather than what was actually shipped. Generate the SBOM in the build pipeline, store it with the release, and view the stored document whenever a question arises.

Worked example

Consider a team that ships a small web service and generates an SBOM for each release. One morning, a widely reported vulnerability is announced in a data parsing library, affecting versions below 4.2. The team opens the current release's SBOM in the viewer and searches for the library by name. It appears twice: once as a direct dependency at version 4.1, and once as a transitive dependency, pulled in by another library, at version 3.9. The direct dependency is one the team knows about; the transitive one is not, and it is the older, more affected version.

The team now has a precise task list instead of a vague worry. They upgrade the direct dependency to 4.2, and they upgrade the library that pulls in the transitive copy, which brings its bundled copy to 4.2 as well. They regenerate the SBOM for a patched release, open it in the viewer, and confirm that both entries now read 4.2 and that no other copy of the library remains anywhere in the tree. The whole investigation, from announcement to confirmed fix, takes under an hour, because the inventory was already generated and the viewer made it searchable.

A second use appears in the same week. A prospective customer asks for the list of components under a particular copyleft license. The team filters the SBOM by that license and finds three components. Two are used only in a development tool that is not shipped to customers, and one is used in the shipped product. The team can answer the customer precisely, naming the one shipped component and explaining the status of the other two, instead of guessing or commissioning a week-long audit. The SBOM, read through a viewer, becomes a sales and compliance asset as well as a security one.

Mistakes to avoid

The first mistake is generating an SBOM and never opening it, which is the same as having no inventory at all. The second is trusting a hand-written SBOM instead of one generated from the build, because hand-written lists drift from reality within a release or two. The third is searching only for direct dependencies and missing transitive copies of a vulnerable library, which is where the older versions usually hide. The fourth is treating a component with a missing license or version as acceptable, when the gap itself means the component cannot be cleared or matched against vulnerability data. The fifth is viewing an old SBOM and acting on it, when the software has since shipped new releases with different components.

Putting it into practice

Start by generating an SBOM from your build for your current release and opening it in the viewer. Search for the components you know you use and confirm they appear with the versions you expect; any surprise is a finding about your build, not about the viewer. Note every component with a missing version or license and resolve those gaps at the source. Then store the SBOM with the release and make viewing it the first step of your vulnerability response routine: search, confirm versions, and act on what you find, rather than debating whether you might be affected.

For related tools, the SBOM Diff Checker compares two SBOMs release over release, the Hash Generator lets you record a checksum proving a stored SBOM has not changed, and the companion guide on comparing two documents covers careful diff reading in general. An SBOM is only useful when someone can read it, and a viewer is what turns a machine file into a map your team can actually use.

Key points

• An SBOM is a structured inventory of the components inside a piece of software, with names, versions, suppliers, and licenses
• A viewer turns the machine-readable file into a searchable, sortable inventory a person can actually use
• Search by name and filter by license are the views that answer vulnerability and compliance questions fastest
• Always check transitive dependencies, where older copies of a vulnerable library usually hide
• Generate the SBOM from the build itself, store it with the release, and view the stored document when questions arise

In short: generate the inventory from the build, open it in a viewer, and let search and filtering turn a vulnerability announcement into a precise, fixable task list.