Skip to main content

Behaviors

Most software products are created for a specific purpose, with features and functionalities that align with that purpose and help software users achieve their goals. When users set out to work with any software, they already have expectations or at least an idea of what the software should and should not be able to do.

For example, a text editor is created for the purpose of working with textual files. It usually has features that let users create and view text files, modify them, and navigate within them. It's uncommon for a text editor to contain features for encrypting images, and most users would not expect that capability.

At this stage, we are talking about the surface-level software behavior; the overt software capabilities. They are immediately obvious to the users because they are directly accessible and exposed through the software interface or the configuration files. However, what actually happens "under the hood" while the software is running is often not transparent at all.

An application may start multiple background processes or require access to different parts of the operating system in order to function properly. It may connect to the internet or change system settings without ever alerting the users. All those activities may be part of the application's normal operation, as intended by the software authors. At the same time, software may have other, hidden capabilities that activate only under specific circumstances and that have been implemented by malicious actors. With an ever-increasing amount of components and third-party dependencies, it's a serious challenge to understand when software is doing something it is not supposed to do.

The Spectra Assure platform is a solution that helps you overcome this challenge. As part of the static analysis and file decomposition process, Spectra Assure converts complex code patterns into descriptions that clarify what the analyzed software is capable of doing, or how the software may "behave" when used.

Those descriptions are called software behaviors and organized into categories based on their shared characteristics. In Spectra Assure analysis reports, they are represented as human-readable explanations of software intent, giving a highly detailed, fine-grained insight into the capabilities of the analyzed software. Every behavior is assigned a unique ID, which is visible in the analysis reports when the behavior is triggered for the analyzed file.

In addition to identifying thousands of different behaviors, Spectra Assure can compare and track behavior differences across multiple versions of the same software package. Any unexpected behavior changes can be easily spotted in this way, potentially indicating malicious behaviors introduced by an attacker or a compromised software dependency. You can pinpoint behavior changes to specific components inside a software package, and check if those changes are expected in the context of the latest software version. This enables early detection of anomalies in software behavior before your product is released.

Spectra Assure also supports creating custom policy controls based on software behaviors, allowing you to tailor the platform to your use-case with your knowledge and expertise.

Behavior prevalence​

ReversingLabs regularly collects and analyzes packages from popular package management repositories. In each of those software communities, ReversingLabs identifies and tracks software behaviors. Malicious behaviors, as well as behaviors that are uncommon or unusual for a community, are distinguished from typical behaviors that are expected from highly used packages in a community. This wealth of data is then used to enrich analysis reports with behavior prevalence information.

When prevalence information is available for a behavior, it can be one of the following:

  • Common - the detected behavior is often found in the community the software component belongs to
  • Uncommon - the detected behavior is rare within a community the software component belongs to
  • Anomalous - the detected behavior was never seen in a community the component belongs to
  • Important - the detected behavior is not malicious, but should be prioritized for code intent review
  • Malicious - the detected behavior is seen only in malicious packages within a community the component belongs to

When prevalence information is not available for a behavior, it is indicated by the "Unknown" prevalence status.

Software behavior categories​