ReversingLabs Levels
ReversingLabs Levels (RL-Levels) introduce a gradual, guided approach to improving software quality by letting users attain specific security goals in their packages and projects.
With the RL-Levels feature, users can configure a level (1-5) to analyze and validate their software against predefined security criteria. Packages that satisfy the criteria are considered acceptable to build and deploy. Detailed analysis results and reports clearly show the effort needed to get to the best possible security level.
All Spectra Assure products come with an extensive set of built-in policies carefully crafted according to industry standards and expert ReversingLabs insights. Those policies are used when analyzing software packages to identify and report a range of software quality and security issues. The policies also impact the priority of every reported issue and the final build status of analyzed software packages.
ReversingLabs aims to provide sensible defaults for built-in policy settings to make Spectra Assure products as widely applicable and useful as possible. Additionally, users can extend the built-in set of policies by writing their own YARA rules and customize the behavior of each individual policy.
However, not all organizations and teams have the capacity or expertise to maintain dozens of policy settings manually. The push to automate workflows is often written into business goals, as it promises increased productivity and more resources for high-impact projects and deep work. With those and many other constraints, efforts to develop secure software can often seem inefficient. It's common to hear about developers and DevOps engineers struggling with long lists of failed security checks caused by overly strict rules that may be mutually incompatible or even inappropriate for their specific use-case.
RL-Levels solve those challenges by providing predefined baselines users can choose for their software instead of manually tweaking policy by policy. Engineering teams can evolve their software security over time without the need to overhaul their entire process or implement complex frameworks. With RL-Levels, they can choose the security foundation they're most comfortable with, and build from there step-by-step by focusing on the most pressing issues.
Another way to look at RL-Levels is to relate them to the concept of maturity models, where each level is a maturity estimation. At Level 1, your software is the least mature and satisfies only the bare minimum of security. At Level 5, your software is the most mature and able to pass the most advanced security checks.
With this incremental approach, organizations can:
- Suppress CI/CD failing conditions depending on the organization maturity
- Identify issues at each level and make plans to address them
- Understand how software will handle the next level before switching to it
- Prioritize issues according to their current and long-term impact
Why should your organization use RL-Levels?
A gradual approach to software security like RL-Levels helps you implement changes and best practices at all stages of the software development lifecycle in a flexible, measurable way. Compared to other common strategies, this approach is:
Less disruptive. Your organization can make software security and quality improvements in small steps, rather than through large-scale changes all at once. Incremental improvements are less likely to disrupt existing processes or negatively impact the software functionality.
More progressive. Your organization should move forward, not hang back. A gradual approach helps you prevent degradation of software quality and encourages you to keep striving for the next RL-Level. Once you move up a level, all previous level policies start being enforced, too. There's no incentive to downgrade to a lower level, and it should be avoided in practice.
More manageable. Your teams can break down the improvements into smaller tasks to track their progress, implement mitigations recommended by Spectra Assure, and test how your software behaves with fixes applied.
More efficient. Your organization can focus on the most critical issues first and prioritize work according to risks that pose the greatest threat to your business.
More sustainable. Software security is not a set-it-and-forget-it switch that can be flipped for your whole organization. It requires continuous attention and consistent maintenance. A gradual approach can help your organization build a culture of security awareness and shared responsibility where improvements are made to be sustainable in the long run.
More cost-effective. Your organization can use RL-Levels-based assessments to prioritize improvements according to your risk and budget constraints and achieve the greatest return on your security investment.
ReversingLabs Levels definitions
There are five RL-Levels, with L1 being the most basic security level, and L5 the most advanced.
Levels build up on each other, so every level higher than L1 implicitly requires the criteria from all previous levels.
The following table describes the criteria that software needs to satisfy at each level to successfully pass it.
| ReversingLabs Level | Security goals at this level |
|---|---|
| L1 | No malware detected No tampered signatures No unprotected keys No source code leaks |
| L2 | No CVE patching mandates No riskware applications No code signing abuses No private key leaks |
| L3 | No malware-exploited CVEs No unsafe loading practices No signature coverage gaps No embedded private keys |
| L4 | No actively exploited CVEs No code loading abuses No revoked code signatures No deprecated code signing |
| L5 | No critical severity CVEs No executable code packers No self-modifying executables |
How do RL-Levels work?
Every RL-Level is a set of policy rules for suppressing CI/CD failures.
If a policy is not essential for achieving security goals at a specific level, failing conditions are suppressed (transformed to PASS) for any violations of that policy.
In the rl-secure CLI, RL-Levels can be configured globally, where all packages in a project target the same level; and individually, where every package uses its own level settings.
In the Portal, RL-Levels can be configured for an organization and for groups (every group can have its own RL-Levels settings). If groups do not have group-specific overrides, they inherit organization-level configuration.
To configure a level means to set it to a value between 1 and 5. This value is your Scan Level - the set of policy rules used to scan your software; the level you are trying to attain.
Another related concept is Best Level. This is the next best level your software can attain without any effort (any required changes).
Best Level may be the same as Scan Level, which means your software cannot attain a higher level until you make some changes. When Best Level is lower than Scan Level, that indicates your software can't attain the currently configured level.
When you configure a specific level for a package, the ultimate result of that change is whether your package can pass the build at the configured level.
This information is conveyed by CI/CD status indicators in Spectra Assure products that change from CI:PASS/FAIL to LX:PASS/FAIL when levels are configured.
In Spectra Assure reports (rl-secure HTML report and Portal report), P0 priority indicators change color depending on the RL-Level settings and the CI/CD status.
| Priority indicator | Status | Description |
|---|---|---|
 | CI:FAIL, LX:FAIL, CX:FAIL | One or more P0 issues have been detected that ultimately resulted in the CI:FAIL status for the package. |
 | LX:PASS, CX:PASS | One or more failing conditions are suppressed by the current level settings (either RL-Level or Custom Level). This indicator warns you there are unresolved P0 issues in the package despite its CI:PASS status. The Issues page on the left-hand side of the report can help you identify those issues, as well as the policies that have been modified and the files where the issues have been detected. |
Why suppress build failures?
Treating all policy violations as equally important issues that should prevent deployment is often an overly strict approach to software development and release management. RL-Levels allow users to apply some nuance and decide what is actually important enough to focus on and resolve before shipping software.
For example, users may choose to use different RL-Levels during development and release. During development, we expect most teams to use L1, while releases should use L3 or better.
Suppressing failures does not mean RL-Levels ignore detected issues. All detected issues (policy violations) are still reported to users, because all enabled policies are always evaluated on every level. Selecting a specific RL-Level does not eliminate issues - it only changes their impact on the resulting CI/CD status.
How does priority relate to RL-Levels?
Priority indicates how important it is to resolve an issue in relation to other issues. In Spectra Assure products, priority is expressed as a scale from P0 (highest) to P4 (lowest).
Every built-in policy has a priority value assigned to it. When a policy is violated, the issue reported by Spectra Assure gets the priority that was assigned to the policy.
All built-in policies with P0 (highest priority) can influence the CI/CD status through their Blocker value.
This becomes effective on the RL-Level that's associated with the policy.
Generally, P0 policies will always transform the CI/CD status to FAIL when there are policy violations at the scan level equal to or higher than the RL-Level associated with the policy.
How do policies relate to RL-Levels?
Every P0 policy is associated with a RL-Level at which the CI/CD status transforms to the policy's Blocker value when the policy is violated.
For example, let's look at a policy with the RL-Level 3 and Blocker: FAIL.
On RL-Levels 2 and 1, the status is transformed to PASS even if the policy is violated.
RL-Levels 3 and higher transform the CI/CD status to FAIL when the policy is violated.
In all cases, the issue is reported to the user.
This also illustrates how the policy violation relates to the concept of maturity. It will be important for mature software projects (RL-Levels 3 and higher) to resolve and prevent this issue. For projects on the lower end of the maturity scale, this type of issue is not considered critical. Seeing the issue in the report and being aware of its impact on the build status helps both types of projects shape decisions about security improvements.
How to achieve maturity with RL-Levels
The purpose of RL-Levels is to:
- continuously provide your developers with relevant guidelines on how to improve their code
- provide your DevSecOps teams with a reliable release validation tool
- help your entire organization understand the strengths and weaknesses in your code and your processes
An effective way to integrate RL-Levels into your workflows is to treat it as adopting a maturity model.
Start somewhere. In this phase, you're starting to use RL-Levels in your organization. It's a good idea to start with a single project and use it as a proof-of-concept. Review the RL-Levels definitions and experiment with different settings to understand their impact.
Apply shared best practices. In this phase, you're starting to follow Spectra Assure recommendations and gradually improve your software security. You understand how RL-Levels work and you're able to interpret Spectra Assure reports to inform your security decisions.
Target your specific needs. In this phase, you're starting to identify problematic patterns and recurrent issues in your code and processes thanks to RL-Levels. You understand how to align RL-Levels with long-term security goals. You're able to modify policies to suit your specific use-cases.
Become security-first. In this phase, you've fully integrated Spectra Assure products in your workflows. You no longer use RL-Levels "after the fact", to check if anything is failing before a release. Instead, you use RL-Levels throughout your software development lifecycle to ensure the highest level of security at all stages.
How to upgrade to a higher RL-Level
The process of upgrading to a higher RL-Level - and the reasoning behind the decision - may differ from organization to organization. However, the general approach should be similar in most cases.
Resolve the most pressing issues at the current level. All Spectra Assure products include information about issue severity, priority, and effort required to fix each issue. This information should help you create and execute actionable improvement plans.
Pay attention to issues that will fail on the next level. If there are any, your software is not yet ready for the upgrade. Review recommended mitigations for those issues, and resolve the issues if possible.
Continuously scan your software with Spectra Assure products at the current level to understand the impact of every change you make. At some point, when all issues at the current level are resolved and there are no issues blocking your upgrade, Spectra Assure reports will indicate that your software is ready.
Change the scan level in your configuration to a higher RL-Level (the level you were trying to attain by making improvements). When you rescan your software with the new level configuration, Spectra Assure reports will indicate whether it passes or fails at that level. You will also be able to see how your software will fare at the next level, and view issues that are blocking further upgrades (if there are any).
What are Custom Levels?
In some cases, RL-Levels settings for a policy may be incompatible with your organization's compliance requirements, third-party integrations and legacy systems used in your environments, or may simply be irrelevant for your use-case.
If this happens, you can consider manually overriding the Blocker setting for that specific policy.
If you make the setting stricter than it is on the current level, Spectra Assure will continue working as if you're still using RL-Levels. The only visible change will be the CI/CD status on issues triggered by the policy you modified.
However, if you relax the setting, Spectra Assure will show that you are using Custom Levels. This is done because RL-Levels represent minimum requirements your software must satisfy to pass. If you degrade those minimum settings and start using Custom Levels, you accept all risks associated with the changes you make.
Note that relaxing the Blocker setting for a policy counts as using Custom Levels only when it has an effect on the file processing.
If the policy you modified only starts transforming the CI/CD status at L4, and your current scan level is L3 or lower, Custom Levels indicators will not be used, and Spectra Assure will continue working as if you're still using RL-Levels.
When you use Custom Levels, CI/CD status indicators in Spectra Assure products change to CX:PASS/FAIL, where X corresponds to the currently configured RL-Level (the level at which a package was scanned).
Your software will be scanned using RL-Levels settings combined with your custom settings. All Spectra Assure products will still show changes required to upgrade to higher levels. However, all CI/CD status indicators will show you're using Custom Levels until you revert your manual overrides.