Skip to main content

How Spectra Assure identifies components

As a crucial step in the analysis process, the Spectra Assure platform identifies components and dependencies of your software packages and represents their relationships in the analysis reports.

All the components and dependencies detected during analysis get added to the Software Bill of Materials (SBOM) to provide a complete inventory of software materials that make up a software package and are involved in its lifecycle. Even though the SBOM is focused on software components and dependencies, it also captures their hierarchical relationships and displays information about licenses, copyrights, and security references in a standard data format. This simplifies information sharing among various software publishers and buyers along a software supply chain.

An SBOM, with its clearly documented software components, increases trust into the particular software and enhances its transparency. It also helps reduce supply chain risk by facilitating identification of potential changes, vulnerabilities, and other software quality issues.

This page provides the information needed to understand what components and dependencies in Spectra Assure exactly are, how they're identified, and where to find them in various Spectra Assure products.

What are components?​

In the context of Spectra Assure, two types of components exist:

SBOM components​

SBOM components are primarily physical files, such as executables or libraries, that serve as key parts of the software being scanned. They are typically included within the software package or application and are essential for its functioning. This includes the root file (the main software artifact being scanned), as well as any bundled libraries, applications, or packages that are shipped along with it.

They appear on the Bill of Materials > Software page of the SAFE report, as well as in the Audit > Components file explorer. Since these are actual software components, they always appear in CycloneDX and SPDX reports.

Non-SBOM components​

Non-SBOM components are physical files that are not pieces of software, which includes textual files, scripts, binaries, and similar. In technical terms, they're referred to as artifacts. In the SAFE report, they appear alongside the SBOM components on the Audit > Components page only if they:

  • contain secrets, networking strings, or issues that violate policies
  • contain SaaS services, ML models, or cryptographic assets
  • represent a package manifest containing a comprehensive list of dependencies included in the software

This makes it faster and easier for users to find the relevant files on the Components page.

For example, imagine your software package includes a Bash script containing a malicious component. This script is not a component, but an artifact since it's not a software, but a script file. However, its contents trigger a policy, which makes the artifact a non-SBOM component that appears on the Components page.

What is the difference between components and dependencies?​

Dependencies are connections between software components, where one component relies on the functionality or resources provided by another. These dependencies are typically packages within the same ecosystem as the software being analyzed. The software includes these packages in specific versions, as defined in a manifest file - usually specified by the user or development teams.

Unlike components, dependencies may not be physically included in the software by default. Instead, they are often declared in manifest or configuration files and imported during build or runtime as needed.

Statically linked dependencies are typically bundled directly into the software package, meaning they are physically present in the file, as they are a part of the component they refer to.

In contrast, dynamically linked dependencies and package dependencies are not necessarily included in the software package itself. Instead, they can be loaded or imported at runtime from their original locations or package sources. Dynamically linked dependencies are always included in the SBOM, along with the components they are tied to.

In some cases, a component can also be a dependency. For example, consider two JAR packages: Package 1 and Package 2. Suppose Package 2 includes Package 1 as part of its distribution — either bundled together or loaded at runtime. In this case, Package 1 is a component of the software package (i.e., it's part of the deliverable). At the same time, Package 2 depends on Package 1 to function properly. Therefore, Package 1 is both a component of the larger package and a dependency of one of its parts.

Even though components and dependencies in a software package may differ in certain ways, they share one key trait: each has its own unique identity.

What is software identity?​

Software identity is like an ID card for a piece of software — it tells you what the software is, who made it, what version it is, and whether it’s authentic and unaltered.

It is important because it enables precise tracking, analysis, and decision-making throughout the software development and security lifecycle.

What methods are used to verify software identity?​

Software identity verification methods are fundamental to establishing trustworthiness in systems, as they determine how confidently the authenticity, origin, and integrity of software components can be verified.

There are different levels of verification when it comes to software identity and integrity, and they directly impact how much trust you can place in a software.
These levels can be thought of as a trust hierarchy, ranging from simple SHA-256 hashes to full manifest-based identity.

A software identity can be matched using multiple verification methods, but it can have only one verified status, determined by the most accurate method. Every software component listed in the SBOM receives a badge reflecting its verified status and is filtered accordingly.

There are multiple types of software identity verification methods, ordered by significance:

  • Not verified - the identity is generated for the component based on the metadata found in the file. Therefore, there is no reliable confirmation of the software origin, version, integrity, or authenticity
  • User override - a component or dependency has been modified by the user through policy configuration
  • SHA-256 - the most accurate application identity validation mechanism based on mapping between file hash and the exact software version. This data is obtained from the ReversingLabs cloud
  • Authentihash - hashing mechanism specific to Windows files. Similar to SHA256, authenticode hash verifies that the software is published by a trusted party. The file is signed either directly or through a catalogue file
  • Certificate - the file is signed by the certificate that the software publisher used to release a particular software version
  • Cloud source - the file is found in the high trust source reputation zone, but has not been manually checked yet
  • Byte pattern - the hash of the file in question has been compared to the original hash that was generated when the file was first created or distributed by a trusted source
  • Similarity - the package in question has been deemed similar to a known package in the database. This similarity match confirms its identity based on a lookup in the ReversingLabs cloud database, which contains an extensive inventory of packages from various ecosystems
  • Manifest - the file has been listed within a developer manifest file containing details on components, dependencies, and metadata of a software application

For example, let's take a look at a special case - Docker image. When the SAFE report indicates "Declared by Manifest" next to the Docker image components, this does not refer to the software package manifest file that can be found in typical software packages. A Docker image usually starts with a base OS, and using instructions in the Dockerfile, additional packages are installed into that OS. These packages become part of the image’s filesystem, but a manifest of installed packages is not generated or included by Docker. Instead, the components that are declared by package manifest are found by parsing the OS/Linux-specific database of installed packages. This is a database within the Docker image that every Linux package manager maintains for itself.

Each component listed in the SBOM includes a "Provided by" field under the "File information" section (located above "Software identity"). This field indicates the package from which the file originated. As vulnerabilities are associated with individual files, you can look for an updated version of the package that provides the component since this version might resolve the reported vulnerabilities.

What does Spectra Assure use identity for?​

Spectra Assure uses software identity for:

How does Spectra Assure identify components and dependencies?​

For every uploaded software binary, Spectra Assure uses the Spectra Core advanced binary analysis engine to identify, unpack, extract, and uncover its internal structure.

This includes extracting embedded elements such as executables, libraries, documents, resources, and icons. From these unpacked files, the tool collects detailed internal indicators. The result of this deconstruction process is a comprehensive Software Bill of Materials (SBOM) that lists all components and dynamic, static, or package-based dependencies, whether direct or transitive.

The entire analysis process is described in detail in the Spectra Assure analysis guide.

How does Spectra Assure detect vulnerabilities in components and dependencies?​

The Spectra Assure platform identifies publicly disclosed vulnerabilities (CVEs) across supported communities, programming languages, and file formats.

Like other SCA tools, Spectra Assure focuses on the underlying packages and libraries that developers use to build applications.

The analysis engine behind Spectra Assure performs both vulnerability lookup and vulnerability matching. It first retrieves detailed information about known vulnerabilities, then determines whether the software is affected by any known vulnerabilities by comparing the software identity against entries in vulnerability databases such as:

For statically linked dependencies, precise identification of the library and its version is generally sufficient to determine known vulnerabilities. As a result, a separate vulnerability lookup step is not necessary.

Spectra Core behavior analysis determines whether vulnerable code paths are actually included in the final binary. This allows it to eliminate false positives resulting from unused or unreferenced portions of code. For example, if a vulnerability affects the inflate function in zlib, but only deflate is linked into the binary, the vulnerability is not reported.

Architecture-specific checks are also applied. If a known vulnerability targets x86 binaries, but the analyzed file is compiled for ARM, the vulnerability is not reported.

This method ensures that only relevant vulnerabilities are reported, minimizing false positives and enhancing the accuracy of static analysis.

What is the difference between automatic and manual vulnerability triage?​

Vulnerability triage is the process of evaluating and prioritizing security vulnerabilities to determine their relevance and impact.

In a manual triage workflow, security analysts or engineers individually review each detected vulnerability to assess factors such as exploitability, business risk, and potential impact. Based on these findings, they determine the urgency and order of remediation.

By contrast, automatic vulnerability triage uses specialized algorithms to perform this evaluation without human involvement. A vulnerability may be automatically classified as "not applicable" if, for example, the vulnerable library is not included in the deployed package, or the affected file has been removed. This approach speeds up remediation and allows teams to focus on vulnerabilities that truly require attention.

How does Spectra Assure detect malware in components and dependencies?​

Spectra Assure identifies each software component using its name, version, and hash, and assigns it a verification method. These verification methods allow Spectra Assure to determine whether a component has been altered and validate its origin, i.e., determine its identity. This identity is then used to match components against known malware databases and analyze them for suspicious behavior.

Since components often rely on other packages, Spectra Assure also inspects their entire dependency chain. By analyzing identity trustworthiness across all components and their dependencies, this approach strengthens overall supply chain integrity.

The dependencies have different use scenarios. This means that a dependency could be used in the final build (during release) or during development and testing (development). Depending on when the dependency is used, it is possible to assess the impact a malicious dependency may have. Malicious development dependencies target the build machines, while the malicious release dependencies target the end user of the software application.

By applying layered verification across both direct and transitive dependencies, Spectra Assure can detect not only explicitly malicious components but also those compromised indirectly through infected dependencies.

Where to find information on components?​

You can find information on components in:

CLI​

When using the CLI, getting information on components is possible with the rl-secure inspect --sbom command. For every component, the output of this command shows the information on its licenses, copyrights, and security references.

If any malicious or suspicious components are found, the command output points to the file that triggered the detection. This helps you understand the severity of the issue and address it more rapidly by locating the source of the problem.

Dependencies can be excluded with the --no-dep[endencie]s option. 

rl-secure inspect --sbom --no-deps pkg:rl/my-project/my-package@1

Portal​

For all package versions uploaded to the Portal, whether to File Stream or Projects, all SBOM components are listed on the Bill of Materials > Software page of the report. All components and relevant non-SBOM components can be found on the Audit > Components page of the report. This also applies to all reports shared from the Portal.

Report​

In the SAFE report, the information is organized in the following way:

  • Bill of Materials > Software - a comprehensive list of components and dependencies
  • Audit > Components - a file explorer, where for each component inside a software package, a list of dependencies is shown