SBOM for Everyday Users: How to Check What an Application Contains Before Installation

Installing an application means trusting much more than the company whose name appears on the download page. Modern software commonly includes dozens or even hundreds of external libraries, frameworks, system packages and other ready-made components. A weakness in any one of them can affect the finished application, even when its main developer did not create the vulnerable code. A Software Bill of Materials, usually abbreviated to SBOM, provides a structured record of these components. It can help an ordinary user check what is inside a program, identify outdated dependencies and investigate known vulnerabilities before allowing the software to access personal files, passwords or business information. An SBOM is not a guarantee of safety, but it adds verifiable evidence to a decision that would otherwise depend mainly on reputation, reviews and antivirus results.

What an SBOM Reveals About an Application

An SBOM is often described as an ingredients list for software. Instead of listing flour, sugar or preservatives, it records libraries, packages, modules and other components included in an application. A useful SBOM normally identifies the main product, the names and versions of its components, their suppliers, the relationships between them and the date on which the record was created. It may also include licences, file hashes, package identifiers and information about the tool used to produce the document. These details make it possible to distinguish between two releases that appear similar to a user but contain different internal components.

The component version is one of the most important fields. A vulnerability rarely affects every release of a library. It may apply only to versions before a particular update, to one branch of the software or to a specific operating system. A report stating that an application contains OpenSSL, for example, is not enough to assess the risk. The exact release number is needed to determine whether the included code falls within the affected range published in a security advisory. When version information is missing, a scanner may fail to identify a real problem or may incorrectly associate the component with an unrelated vulnerability.

An SBOM should also show dependency relationships. Some components are added directly by the application developer, while others are brought in indirectly by another library. These indirect dependencies can be several levels deep and may be invisible in the normal application interface. A developer might intentionally add one document-processing library, which then relies on separate packages for image handling, compression and character encoding. If one of those lower-level packages has a security flaw, the finished application may still be affected. A dependency map helps explain why the component is present and which part of the software relies on it.

How to Recognise a Useful and Relevant SBOM

The first check is whether the SBOM describes the exact file being considered for installation. Compare the product name, version number, operating system, processor architecture and release date with the information shown on the download page. A component list for the Windows edition may not describe the macOS build, while a record for version 5.1 cannot automatically be applied to version 5.2. Even a small application update may replace several libraries or remove a vulnerable package. An accurate SBOM should therefore be linked to a specific release rather than presented as a permanent component list for every version of the product.

SPDX and CycloneDX are the two formats that ordinary users are most likely to encounter. They store component information in a consistent, machine-readable form that security tools can process. As of July 2026, SPDX 3.0 is the current stable specification, while SPDX 3.1 RC1 is available for testing rather than general production use. CycloneDX 1.7 is the current published version. Common filenames include bom.json, bom.xml, product.cdx.json and product.spdx.json. A user does not need to understand the complete structure of these files because an appropriate scanner can convert their contents into a readable vulnerability report.

Completeness matters as much as format. Warning signs include components without version numbers, repeated “unknown” values, missing suppliers and an inventory that appears far too small for the application. A modern browser, video editor or communication program is unlikely to contain only a handful of external packages. At the same time, a long component list is not evidence of poor security. Large applications naturally depend on many separate projects. The more useful question is whether the SBOM identifies those components precisely enough for a scanner to match them with reliable vulnerability records.

How to Verify and Scan Software Before Installation

Begin by obtaining the installer and its SBOM from a source controlled by the software publisher. The document may appear beside the application in a release repository, security centre or download section. Search for filenames containing “SBOM”, “SPDX”, “CycloneDX” or “BOM”. Some suppliers provide the record only to customers or upon request, particularly when it contains details about proprietary components. Avoid relying on an SBOM copied to an unrelated download site. A genuine component list is valuable only when there is a credible connection between the document, the supplier and the exact application release.

Verify the installer before analysing its components. A cryptographic hash acts like a digital fingerprint for a file. When a publisher supplies a SHA-256 value, calculate the hash of the downloaded installer and compare every character with the official value. Windows users can run Get-FileHash .\setup.exe -Algorithm SHA256 in PowerShell. On macOS, the command is shasum -a 256 filename.dmg, while many Linux systems use sha256sum filename. A matching result confirms that the downloaded file is identical to the file measured by the publisher. It does not prove that the original software is secure, but it can reveal corruption or unauthorised modification.

A digital signature provides another layer of verification. On Windows, right-click the installer, open Properties and look for the Digital Signatures tab. The signature should be valid, and the signer should correspond to the application publisher or a clearly related company. Microsoft’s Sigcheck can display the file version, timestamp, certificate chain, hashes and signature information without running the installer. On macOS, signing and notarisation checks can help establish whether an application has been submitted through Apple’s security process. An unsigned file is not automatically malicious, especially when it comes from a small open-source project, but the absence of a signature leaves the user with less evidence about its origin.

A Practical Workflow Using Free Scanning Tools

If a valid SBOM is available, Grype offers a direct way to compare its components with known vulnerability data. After installing Grype from its official release source, a command such as grype sbom:./application-sbom.json scans the document without launching the application. The report identifies the affected component, the installed version, the vulnerability reference, its severity and the version containing a fix when that information is available. Grype supports common SBOM formats and can use additional risk information, including CISA’s Known Exploited Vulnerabilities data and Exploit Prediction Scoring System values, to help prioritise findings.

OSV-Scanner is another suitable option, particularly when the downloaded package contains recognised SBOM files, dependency records or source-code lockfiles. Its current V2 documentation describes a two-stage process: the tool extracts package information and then matches those packages against known vulnerability records. The output can include the package name, version, advisory identifier, severity score and fixed release. Standard filenames matter when scanning SBOM documents, so an SPDX file should normally retain a name ending in .spdx.json, while a CycloneDX file should use a recognised CycloneDX naming pattern. Renaming every document to a generic filename can prevent correct detection.

When the publisher does not provide an SBOM, Syft can create an estimated inventory from an extracted directory, archive, filesystem or supported container image. For example, syft dir:./unpacked-app -o cyclonedx-json=app-sbom.cdx.json analyses an unpacked folder and saves the result as a CycloneDX document. That file can then be checked with Grype. Do not run an untrusted installer merely to obtain its files. ZIP archives and some installation packages can be unpacked without executing their code, but other formats require specialist handling. A generated SBOM may also miss statically compiled, encrypted or unusually packaged components, so it should not be treated as more authoritative than a complete record created during the publisher’s own build process.

How to Assess the Vulnerabilities Found in an SBOM

A scan result may contain CVE, GHSA or ecosystem-specific advisory identifiers. A CVE number is a common reference for a publicly disclosed vulnerability, not proof that the application is currently under attack. Open the associated advisory and confirm the affected component, version range and operating conditions. Similar package names can belong to unrelated projects, and a scanner may occasionally produce an incorrect match when the SBOM contains incomplete identifiers. The finding becomes more credible when the package name, supplier, ecosystem and version all correspond to the component recorded in the advisory.

Severity is usually expressed through a CVSS score or a label such as low, medium, high or critical. This score estimates the technical seriousness of a vulnerability under defined conditions, but it does not fully describe the risk to a particular user. A critical flaw that requires a disabled feature may be less urgent than a high-severity flaw exposed whenever the application opens a file from the internet. Check whether exploitation requires local access, user interaction, special privileges or a network connection. Also consider what the application will be allowed to access. A weakness in software handling passwords, confidential documents or remote connections carries greater practical consequences than the same weakness in an isolated offline utility.

Pay particular attention to vulnerabilities included in CISA’s Known Exploited Vulnerabilities Catalogue. Inclusion means there is evidence that attackers have exploited the weakness in real situations. The Exploit Prediction Scoring System, or EPSS, provides a probability-based estimate of how likely exploitation is within a short period. Neither indicator replaces careful assessment, but both can help separate urgent findings from older vulnerabilities that have limited practical exposure. A component with a critical score, active exploitation and no available fix should receive much more attention than a low-severity issue that requires physical access to an already unlocked computer.

When to Install, Delay or Reject an Application

Installation is easier to justify when the installer comes from the publisher, its hash matches, its digital signature is valid and the SBOM corresponds to the exact release. The scan should show no unresolved high-risk vulnerabilities that can be reached through the way the application is used. Some findings may be acceptable when the publisher supplies a clear Vulnerability Exploitability eXchange, or VEX, statement explaining why the product is not affected. For example, the vulnerable library may be present but the relevant function may be disabled or removed during compilation. A useful VEX statement identifies the product version, vulnerability and technical reason rather than offering a general assurance that the application is safe.

Delay installation when the SBOM is incomplete, belongs to a different version or reports a serious vulnerability for which a fixed component already exists. Check whether a newer application release has been issued and read the publisher’s security notes. When no explanation is available, contact the supplier with the product version, component name and vulnerability identifier. A credible response should address the specific package and affected code path. For workplace software, send the information to the person responsible for IT or security. An individual user should not accept a business-wide risk simply because the installation process appears routine.

Reject the file when its hash differs from the official value, its signature is invalid, the claimed publisher cannot be confirmed or the download comes from an untrusted source. The same decision is reasonable when a remotely exploitable vulnerability is being actively used in attacks and no corrected release or effective mitigation is available. The absence of an SBOM does not prove that a program is dangerous, but it reduces transparency and makes independent checking more difficult. In that case, place greater weight on the supplier’s update history, security contact, public advisories and the sensitivity of the information the application will handle. An SBOM is most effective when combined with source verification, limited permissions, current backups, antivirus protection and prompt installation of security updates.