Understanding the Spectra Assure approach
This page is intended as a product alignment guide that helps you understand the philosophy behind Spectra Assure products while you research and evaluate them.
Learn how Spectra Assure can help you address security challenges when developing your software, and identify if Spectra Assure products are the right fit for your use-case.
What is Spectra Assure?
The Spectra Assure platform is a set of ReversingLabs products primarily designed for software assurance and software supply chain security.
The fundamental idea is to use Spectra Assure to scan software release packages intended for software publication or consumption as they are - without requiring access to source code or debug builds. However, the full potential of Spectra Assure is unlocked when it is used continuously. By monitoring the evolution of application behaviors and software risks across subsequent software releases, it can detect and stop novel supply chain attacks.
Across all Spectra Assure products, ReversingLabs combines in-house developed classification technologies with industry-leading threat intelligence and analyst-vetted results to provide the most accurate threat verdicts.
Spectra Assure analysis reports provide an in-depth view of application and container misconfigurations while measuring coverage and effectiveness of security controls. Analysis reports also make it easier to prioritize remediation of known vulnerabilities by leveraging threat intelligence to surface active exploitation, malware abuse, and patching mandates.
With Spectra Assure, organizations can protect themselves from material risks caused by the use, deployment, modification, and patent limitation for software covered by restricted open source and commercial licenses.
If you're not sure which Spectra Assure product or integration to use, you can get advice from our product recommendation quiz.
How Spectra Assure helps keep software releases malware-free
Spectra Assure integrates into software build and deployment processes with the goal to detect malware and tampering as early as possible in the software development lifecycle. To achieve this, Spectra Assure products combine built-in threat detection methods with user-configurable policy controls.
More specifically, Spectra Assure can identify the following:
- Malicious open source and commercial dependencies
- Malicious tampering of first and third-party code
- Unwanted software components and protestware code
- Open source components prone to hijacking (typosquatting)
- Open source components with history of malicious incidents
- Unstable/undependable open source maintainers
- Bad software quality practices that may cause compromise
More complex problems usually require more effort and additional customization on top of the default Spectra Assure product configuration. Software producers can use Spectra Assure to cover the following threat detection scenarios, in increasing order of complexity:
Baseline threat detection - Real-world malware and tampering (in OSS and commercial software) are detectable with Spectra Assure signatures, heuristics, ML models and policies without any additional configuration. It is not required to customize the products to detect attacks that mimic common attacker techniques. There is no need to perform differential analysis.
APT pattern detection - Known attack patterns from APT actors, such as the ones that targeted SolarWinds and 3CX, are detectable by Spectra Assure differential analysis and reproducibility checks. Techniques these attacks used can be detected out of the box without any product customization or configuration. The only requirement is to analyze subsequent package versions so that Spectra Assure can compare them (perform differential analysis).
Novel threat detection - Novel attack patterns also detectable by Spectra Assure differential analysis and reproducibility checks. However, in this threat model the user is expected to put in the same amount of work they would with their EDR solution. Specifically, they should review the Spectra Assure findings and do threat hunting to spot anomalies that cannot be accounted for programmatically.
For malware and tampering detection, Spectra Assure leverages:
- Proprietary ReversingLabs technologies and Explainable Machine Learning models
- ReversingLabs proprietary URL and domain reputation
- ReversingLabs proprietary Open Source Threat Intelligence, File Reputation, and partnership with 40 security vendors
- Detections vetted by ReversingLabs analysts that reinforce automation
Additionally, Spectra Assure products rely on the following advanced features:
Differential analysis
Recommended for users who are concerned about the type of attack that targeted 3CX. Differential analysis can uncover unusual modification of commonly used libraries and shared components. The diff report itself lists all changes, against which Spectra Assure runs a number of automated checks. No user configuration is required.
In the context of Spectra Assure, differential analysis refers to comparing two versions of the same software to highlight changes between them. The resulting analysis report warns if any of the detected changes between software versions are problematic or indicators of potential code tampering.
Differential analysis is a powerful feature because it can detect known software supply chain attacks based on their signatures, as well as predict novel supply chain attacks based on expected attacker patterns and heuristic rules. This is achieved by performing checks against a number of built-in policies to identify indicators of tampering that resemble previous software supply chain attacks.
| CLI | Use the rl-secure scan command to analyze software versions you want to compare. Then use the rl-secure report command for the newer version, and specify the older version with the --diff-with option to generate a report that will include differential analysis results. Only the SAFE and rl-diff report formats are supported. |
| Portal | Upload the older software version to a project, then upload the newer one and mark it as Derived from the older version. Differential analysis is automatically performed, and the results are included in the SAFE report. File Stream does not support differential analysis; the feature can only be used in Projects. |
| API | Scan software versions with the Upload and scan a version API endpoint, and use the diff_with query parameter when scanning the newer version to specify the older version as the predecessor to compare against. Then use the Export RL-SAFE archive API endpoint to download the SAFE report for the newer version that will include differential analysis results. |
Reproducible builds
Recommended for users who are concerned about the type of attack that targeted SolarWinds. This is a universal protection against build system tampering. No additional configuration is required. Spectra Assure reproducibility checks take into account that the files do not need to be bit-to-bit equivalent to pass this check.
In the context of Spectra Assure, reproducible builds refer to checks performed during analysis to verify code reproducibility and spot functional changes between build artifacts. With the reproducibility checks feature, users can compare different build artifacts for any version of their software. The comparison is based on detected software behaviors and functionalities.
Detecting software behavior differences is an effective way to uncover new malware or stealthy software supply chain attacks on CI/CD environments and build systems.
If a reproducibility check fails, detailed analysis reports warn about suspicious and potentially dangerous differences between analyzed build artifacts.
| CLI | Use the rl-secure scan command to analyze a software version and add a reproducible build artifact to it with the ?build=repro parameter. Then use the rl-secure report command to export the SAFE report for the software version with the ?build=repro parameter. |
| Portal | Upload a software version to a project, then use the Upload Reproducible Build option to add a reproducible build artifact to it. Reproducibility checks are automatically performed, and the results are included in the SAFE report. File Stream does not support reproducible builds; the feature can only be used in Projects. |
| API | Scan a software version with the Upload and scan a version API endpoint, and use the build=repro query parameter to add a reproducible build artifact to it. Then use the Export RL-SAFE archive API endpoint to download the SAFE report that will include differential analysis results. |
Threat hunting policies
Recommended for teams that want to lock down their software packages against unexpected changes. More specifically, policy controls supported by Spectra Assure CLI allow creating processing filters that block unwanted software behaviors.
In the context of Spectra Assure, threat hunting policies are a set of built-in rules that prescribe how software should behave in order to be considered secure. More specifically, they focus on detecting malicious and suspicious behaviors in software components to prevent tampering incidents and software supply chain attacks.
Threat hunting policies are used by all Spectra Assure products when analyzing software packages, and do not need to be manually enabled. Together with differential analysis policies, they are a powerful tool for discovering tampering early in the software development process.
How Spectra Assure relates to SLSA
Supply-chain Levels for Software Artifacts (SLSA) is a set of industry-recognized practices and guidelines for how software should be built, signed, and verified to reduce tampering and increase supply chain resilience against malicious actors and threats.
One of the key SLSA concepts are threat categories, which refer to common threat types that SLSA is designed to mitigate. With threat categories, SLSA groups supply chain threats by where they happen (source, build, usage...) and prescribes controls that map to those stages of the software development lifecycle.
Software producers can use Spectra Assure to address threats in every SLSA category. General guidelines provided by SLSA can be put into practice with Spectra Assure by performing specific actions recommended by ReversingLabs.
Source threats
This SLSA threat category includes threats that target the codebase, software maintainers, or software dependencies before the code enters the build system. Generally speaking, source threats refer to code changes that do not reflect the intent of the software producer.
Common examples of source threats include:
- Contributors with legitimate access intentionally or accidentally inserting malicious content or bypassing controls
- Malicious code commits or source code repository takeover by malicious actors via stolen developer accounts, compromised developer machines, or social engineering techniques
- Attackers sneaking in malicious code through third-party packages or transitive dependencies
| SLSA Source threats | ReversingLabs recommendations |
|---|---|
| Producer | Scan the final build package for malware and unwanted applications |
| Authoring and reviewing | Perform differential analysis in CI/CD to detect anomalous code changes |
| Source code management | Perform differential analysis in CI/CD to detect anomalous code changes |
Build threats
This SLSA threat category includes threats that target the CI/CD pipeline, build environments, or signing infrastructure. Generally speaking, these threats occur while the source code is being transformed into a software artifact.
Common examples of build threats include:
- Attackers tampering with the build environment to cause a legitimate source to produce a malicious artifact during the build
- Stolen credentials or signing keys that allow attackers to inject or sign malicious builds, impersonate legitimate builders, publish malicious artifacts to package registries, or exfiltrate secrets
- Contributors with legitimate access intentionally or accidentally altering outputs or disabling provenance enforcement
| SLSA Build threats | ReversingLabs recommendations |
|---|---|
| External build parameters | Perform differential analysis of reproducible builds to detect anomalous code changes |
| Build process | - Scan the final build package for malware and unwanted applications - Perform differential analysis in CI/CD to detect anomalous code changes - Perform differential analysis of reproducible builds to detect anomalous code changes - Harden the default scanning configuration with package-specific threat hunting policy |
| Artifact publication | Sign the final build package and monitor the integrity at the software distribution site |
| Distribution channel | Check the software integrity and provenance through component verification |
Usage threats
This SLSA threat category includes threats that target the end-user of the software. Generally speaking, these threats occur in distribution, consumption, or runtime usage, after the software artifact is built.
Common examples of usage threats include:
- Attackers pushing malicious or unsigned artifacts to replace legitimate artifacts in software repositories and package registries
- Package resolvers returning the wrong package to users because of typosquatting, malicious mirrors, or hijacked dependency versions
- Users installing unverified artifacts in production without checking their provenance or signatures
| SLSA Usage threats | ReversingLabs recommendations |
|---|---|
| Package selection | - Before selection, scan the software dependency for malicious and unwanted code - Check the software integrity and provenance through component verification - Harden the default scanning configuration with provenance-related policies - Harden the default scanning configuration by enforcing threat hunting policies - Pin and stagger deployment of freshly released software dependencies by 14 days |
| Usage | Review sensitive information exposures to prevent build pipeline compromise |
How to deploy Spectra Assure effectively
Start by scanning the most important software releases manually.
Determine the appropriate SAFE Level as the goal for quality (e.g. L3).
Ensure that the software is consistently passing set SAFE Levels.
Start leveraging differential analysis to prevent code tampering.
Increase resilience by enforcing select threat hunting policies.
Automate scanning by integrating the CLI in your CI/CD pipeline.
Automate dependency vetting by integrating CLI with your artifact management systems.