Gauging the Safety Level of Your Software with Spectra Assure

It’s been a little over a year since we first introduced security levels into Spectra Assure™ with the goal of reducing the remediation burden on developers. It automatically generates a plan for addressing prioritized software risks, recommending manageable projects to continually improve the software’s level of supply chain security in the same way that developers continually improve software capabilities.

A lot has changed since then. Our complex binary analysis and threat classification capabilities continue to advance as software threats evolve, prompting us to add the new policy controls at the appropriate levels. More importantly, an increasing number of enterprise software buyers are asking how to gauge the safety of their commercial software and how to use this new level of transparency – i.e. what to do with the findings.

Cross-organizational coordination and information sharing can improve outcomes by ensuring a consistent approach to SSCS standards. And individual groups can benefit from shared information.

Gartner Leader's Guide to Software Supply Chain Security

Teams tasked with managing commercial software risks have two related goals:

1. Implementing policy-based controls to consistently evaluate the current level of software risk and enforce the organization’s software risk tolerance.

2. Establishing processes that clarify the actions various stakeholders must take based on the evaluation results (e.g. pass/fail or assessed risk rating).

Fundamental to achieving those goals is a consistent approach for benchmarking the current level of software safety and configuring the level required for software to be considered safe to deploy (i.e. within the organization’s risk tolerance).

With Spectra Assure SAFE Levels, organizations can quickly understand the current level of software safety, which threats require immediate action, and how the other risks and exposures can be addressed over time.

Spectra Assure SAFE Levels

The Spectra Assure SAFE Levels are a series of predefined, increasingly strict criteria that benchmark the overall supply chain security for a software package. They go from Level 1 (base level of security) to Level 5 (highest level of security). When a software binary is analyzed, Spectra Assure will identify the current - or best - SAFE level attained at that time (see Figure 1). The SAFE Levels enable AppSec, cybersecurity, and non-technical stakeholders (e.g. TPRM, GRC, Procurement, and Legal teams) to quickly and easily understand the risk that a specific software package presents to their business. SAFE Levels also simplify policy enforcement as organizations can configure the level required before software can be acquired or deployed.

Figure 1: SAFE Levels make it simple to gauge the risk that a specific software package presents to your business through a series of predefined, increasingly strict security policies.

SAFE Levels allow organizations to define which level is considered acceptable. Enterprises can configure different levels for:

• Specific applications
• Categories of software (e.g. all business process software is set at Level 5 while all employee productivity applications are set at Level 2)
• The criticality or inherent risk posture of the software (e.g. critical software is set at Level 5, high priority software is set at Level 4)

Remediation efforts are automatically prioritized, making it clear how to attain the next SAFE Level. When the SAFE report is shared with software suppliers, their remediation teams can drill down into the specific components and threat details needed to fix security issues. The recommended roadmap helps the teams design a series of manageable projects to improve software supply chain security without over-burdening developers.

How SAFE Levels Work

Figure 2 shows how Spectra Assure benchmarks software by deconstructing and assessing it using complex binary analysis. It identifies the software bill of materials (SBOM) and included files. It then uses hundreds of predefined policy controls to assess embedded threats, risks, and security issues. Spectra Assure’s policy controls are built-in rules and ML/AI models that prescribe how software should behave in order to be considered secure. For example, digital signatures used to verify software’s origin and integrity should have independent identity validation provided by a reputable certificate authority. If the analysis detects that this rule is broken (i.e. the policy control is violated because a self-issued digital signature is trying to impersonate a trusted publisher) then it is an indication that the software should not be trusted until the provider inspects the software for tampering and resigns it with a valid signature.

Figure 2. How Spectra Assure Benchmarks SAFE Levels for a Software Package.

The detected violations are then assessed against the criteria for achieving each SAFE Level. These criteria are designed as milestones that set specific goals for security improvement. For example, the primary question we want to answer at SAFE Level 1 is: Does this software pose an obvious or immediate threat to my environment or business? SAFE Levels build upon each other, so every higher level implicitly requires the criteria from all previous levels, with SAFE Level 5 requiring all high priority policy violations be resolved to receive a PASS status.

Once the assessment determines the “best” level that the software achieved (see Figure 3), it is compared against the desired Scan Level configured by the organization. The policy controls associated with the configured Scan Level determine the software’s final PASS or FAIL status. For example, in Figure 3 the software has achieved Level 1, however, the organization has set Level 5 as its desired state. This means the software producer has to remediate the Vulnerabilities and Tampering policy violations reported with a red failing icon, making it easy to see what needs to be addressed before software is acceptable and the steps required to achieve.

Figure 3: Spectra Assure SAFE Levels Also Determine the Pass/Fail Status for a Software Package.

The policy violations that are not essential for achieving the desired Scan Level do not impact the software’s PASS/FAIL status. For example, since “copyleft licensed components” are not required to achieve SAFE Level 5, its detection will report a yellow warning icon (see Figure 3). As a result, remediation teams can start on the most pressing issues and have a clear roadmap for leveling up their software’s security over time.

Getting Started with SAFE Level 1

SAFE Level 1 is useful for software producers or enterprise buyers starting their software risk management program, and then realize that their risk tolerance definition isn’t specific enough to create meaningful operational controls. In our experience, it is often recommended to start with a small set of policy controls that can work for just about any type of software. Then as different teams gain more experience with both the process and increased visibility, they can evolve the requirements over time. Thus the organization can adapt the policy controls depending on the environment where the software will run, or how critical the software is to business operations, or any other important organizational criteria.

SAFE Level 1 is a good fit for this initial situation because it’s focused on obvious threats for both enterprise software buyers and software producers (see Figure 4). For example, the risk of compromise significantly increases for software vendors releasing software with packaging missteps that leak source code or expose unprotected keys in the final build.

Similarly, both software producers and enterprise software buyers would prefer to avoid releasing or deploying software with obvious threats such as:

• Malware or behaviors exclusively used by malicious software
• Disallowed URLs known to be associated malicious actors
• Indicators of tampering resembling prior software supply chain attacks
• Tampered digital signatures or signatures that impersonate trusted publishers

Figure 4: Spectra Assure SAFE Level 1 is a good fit for organizations starting software risk management programs because it focuses on obvious threats

Organizations can also choose to begin with a higher SAFE Level or by setting different Levels for different groups of enterprise applications or for specific software projects. For example, in cases where the first assessment shows software is already higher than SAFE Level 1, we’ve often seen organizations set the achieved level as the foundational security goal. In other words, it is unacceptable for future versions to drop below the software’s current level.

The Collaboration Value of SBOM + Risks + Sharing

Knowing that policy violations exist is just the beginning for software teams charged with remediation. The combination of SBOM and risk analysis in a shared Spectra Assure SAFE Report is an extremely powerful tool because there is no confusion or miscommunication about:

1. What the issues are and their prioritization, a shared report gives remediation teams the same high-level summary as well as more information about each policy, next steps, and estimated remediation effort (see Figure 5).

2. How many software components or file artifacts have failed this policy and where to find them within the package as well as their software hashes and other integrity verification information.

3. How many other issues each component has, these details are useful for increasing remediation efficiency because most of the time using a more secure version of a component or file will resolve several other policy violations at once.

4. Attesting or demonstrating that software has achieved a higher level of software supply chain security, since subsequent scans will highlight the resolved issues, automatically determine the software’s new SAFE Level, and adjust the remediation roadmap.

Figure 5: Sharing SAFE reports simplifies collaboration with teams who need more detailed information to efficiently remediate issues.

Spectra Assure SAFE Levels apply a systematic, yet customizable, approach for benchmarking the level of commercial software security. It empowers organizations to clearly communicate their expectations of what secure, trusted software should be, while also providing the ability to share contextual, actionable data to prioritize and map out the road to get there. Compared to the status quo, this collaborative approach to continually improving software risk is just the thing needed to bridge the current chasm between enterprises and software providers.