Data privacy and collection

This page explains what data is collected and how it is handled by ReversingLabs when you use the Spectra Assure CLI (rl-secure) to analyze your files.

ReversingLabs prioritizes the privacy and security of your data, and collects only the essentials required for the optimum user experience and product performance.

Consequently, the following data is never collected or sent anywhere by rl-secure:

• the contents of your software packages. Files are analyzed locally, and only their hashes may be shared.
• the contents of your configuration files. Policy controls are processed and applied locally.
• your password vault and passwords saved to it. Password-protected files are decrypted locally.
• your analysis reports. Reports in all formats are stored only locally, on the system where rl-secure is installed, unless explicitly configured otherwise by the users.

When your data is collected by rl-secure, it is sent only to the official ReversingLabs servers listed in the next section.

Data privacy conditions and exceptions described on this page apply only for the default, out-of-the-box rl-secure settings from official ReversingLabs sources. Different conditions may apply if you're using rl-secure through ReversingLabs partner solutions or CI/CD integrations.

ReversingLabs cloud endpoints

rl-secure sends your data only to the following ReversingLabs resources:

• data.reversinglabs.com
• api.reversinglabs.com

These endpoints are often referred to as "the ReversingLabs cloud".

Depending on your network configuration, you may need to explicitly enable access to these endpoints for rl-secure to function properly.

Data collected during installation and updates

When you install or update rl-secure, the following details about your system are sent to the ReversingLabs cloud:

Information type	Description
Operating system name and version	Operating system name and version on which rl-secure is running. It is stored by rl-secure for compatibility purposes.
C runtime library version	Not collected for Windows OS. Version of the C runtime library present on the Linux-based operating systems. It is stored by rl-secure for compatibility purposes.
License version	Version of the license used rl-secure. It is stored by rl-secure for compatibility purposes.
Machine ID	Not collected when site keys are used. Machine number computed by rl-secure for licensing purposes.
Site key	Not collected for licenses locked to your machine ID. Hashed version of the site key stored by rl-secure for licensing purposes.

This data is jointly referred to as "telemetry".

It is used to verify that the system is compatible with the latest rl-secure version, and that the license installed on the system is valid.

The verification is performed:

• when rl-secure is installed on a system for the first time (either directly or with the rl-deploy utility),

• every time rl-secure is updated (manually with rl-secure update or automatically when running rl-secure scan and rl-secure sync commands),

• when running the rl-secure license command to check the current status and usage information for the installed license.

Data collected during file analysis

When you use rl-secure to scan software packages on your system, the following data is sent to the ReversingLabs cloud:

Hashes of analyzed files and their components	rl-secure calculates MD5, SHA1, and SHA256 hashes for every analyzed software package and for each component in the analyzed software package. Hashes are sent to the ReversingLabs cloud to look up file reputation information and retrieve classification for the software package and/or its components using ReversingLabs TitaniumCloud as the classification technology. Based on this cloud lookup, components can get the "Verified by Cloud source" status (indicated in the Verified column of the SBOM section in the report).
License type, version, and status	rl-secure verifies that the installed license is valid and checks its current status and usage in the ReversingLabs cloud. The available analysis capacity is updated to account for the file size of the analyzed software package. If you are using both rl-secure and the Spectra Assure Portal, your license is shared between the two products. Any analysis capacity you spend while analyzing files with rl-secure is automatically reflected in your Spectra Assure Portal instance. This means that the information about your rl-secure license is also sent to your Portal instance.
Original filename and identity of the installation context for ELF files	Starting with version 2.1.0, rl-secure sends the original filename and the identity of the installation context only for Linux executables and shared objects. This is done to improve the data quality and information completeness in analysis reports when required metadata is absent or insufficient for rl-secure to automatically generate an accurate component identity. Specifically, this data is sent to the ReversingLabs cloud to look up application identity information and retrieve more accurate metadata in the SBOM (package URLs, publisher name, license) for Linux packages.

This data is collected:

• every time the rl-secure scan command is used to analyze files,

• when running the rl-secure sync command to reanalyze files (after modifying the configuration or updating to a new rl-secure version).

The contents of your software packages are never sent anywhere by rl-secure. All supported file types are statically analyzed with rl-secure locally, and rely on threat detection technologies embedded in the analysis engine.

Live secret validation

The live secret validation (secret liveness check) feature enables rl-secure to automatically check if any of the detected secrets in your packages are still considered active and susceptible to abuse. This feature is enabled by default in all rl-secure installations.

The secret liveness check is performed by rl-secure during file analysis. When a secret is detected in your software, rl-secure automatically recognizes which service it belongs to and determines its type (for example, a GitHub access token).

If the service is supported by the live secret validation feature, rl-secure then pings the least-privilege public endpoint of that service and checks if the detected secret can be used to authenticate to the service.

Secrets are never sent for validation through ReversingLabs servers. They are sent to the appropriate service endpoint directly through your network (and your proxy if you have it configured). This happens only after the connection is verified as secure by checking the pinned certificate.

Detecting secret exposure

Some of the secrets in your packages may have the Exposed status in the analysis reports. This status indicates that the secret was previously recorded in the ReversingLabs cloud at least once.

Exposed secrets are detected based on file hashes. If a file is uploaded to the ReversingLabs cloud as public, all the secrets it contains are public as well.

Data privacy with CLI integrations

rl-secure supports a number of official integrations created by ReversingLabs to facilitate automation use-cases and CI/CD workflows.

By default, data collected by rl-secure is not transferred to any third parties unless explicitly configured in the CI/CD integration settings.

Depending on your CI/CD service and workflow configuration (self-hosted or cloud-based), additional data may need to be stored externally or shared with third-party services to enable rl-secure functionalities for the integration.

That data may include, but is not limited to:

• rl-secure license file contents and license keys,
• package store contents, including configuration files and software packages,
• analysis reports.

For specifics, consult the documentation for the CLI integrations you intend to use, as well as the official documentation of your CI/CD services.

Need more information?

If you have any further questions or concerns regarding data collection and privacy, contact ReversingLabs Support for assistance.