It may feel like beating a dead horse to say it, but the threat of software supply chain attacks is increasing at an alarming rate. And, in fact, it can’t be said too often.

Two recent reports illustrate this point: The “2024 Verizon Data Breach Investigation Report” (DBIR) found that breaches stemming from third-party software development skyrocketed by 68% from what was reported in Verizon’s 2023 report. And ReversingLabs’ “State of Software Supply Chain Security 2024” report chronicled the dramatic rise in threats from open-source repositories (1300%), as well as a string of high-profile attacks on commercial software — from SolarWinds’ Orion update that was released to thousands of firms and federal agencies in 2020 to the exposure of CircleCI users’ software secrets and the hack of VoIP vendor 3CX in 2023. 

As software producers, enterprise buyers, and other key stakeholders prepare their cybersecurity and risk management efforts for 2025, they should be looking for ways to prevent and quickly mitigate any and all software supply chain attacks. But modern enterprise security programs suffer from a sprawl of uncoordinated tools and continually fail at achieving software supply chain security (SSCS). This calls for a new era of SSCS management, one in which universal controls can prioritize the mitigation of these threats.

ReversingLabs is now introducing the Software Assurance Foundational Evaluation (SAFE) report as a part of RL Spectra Assure. This report is much more than the simple list of components that a software bill of materials (SBOM) provides, offering much-needed visibility into the risks and threats in the entire application or software binary, in context.

Here’s how Spectra Assure’s new SAFE Report works — and why the time for SAFE is now.

Why the time is right for SAFE

The constant uptick in software supply chain attacks is impetus enough, but there are three pressing reasons why security leaders should adopt a powerful SSCS approach — one with controls that mitigate the lack of cross-coordination and threat-intel sharing between the software supply chain’s key stakeholders: 

1. Inadequate tooling won’t stop SSCS threats

A major problem with how SSCS is managed is that key stakeholders responsible for different aspects of the supply chain lack truly effective tools. Software developers, cybersecurity teams, and risk managers all are working without comprehensive tooling that identifies all SSCS threats – something that SAFE solves for. 

For those needing to secure their software development processes, traditional application security (AppSec) tools — static and dynamic application security testing (SAST/DAST) and software composition analysis (SCA) — have been the go-to approach. But while these tools have proved their value in traditional AppSec, they are focused largely on open source and therefore do not detect and mitigate all the kinds of threats facing software supply chains. 

And while SBOMs will continue to be essential for software producers and consumers that want a transparent view into the components of a software product, they fall short for SSCS because they can’t spot malicious tampering or behavioral differences in software versions.

Likewise, organizations purchasing commercial software products have had to rely on processes such as vendor security questionnaires, but non-vetted self-assessments can miss key threats. And tried-and-true legacy technologies such as antivirus, endpoint protection platforms, and penetration testing work well for cybersecurity but can’t thwart a software supply chain attack. 

2. New regulations call for supply chain accountability

Ever since the White House released “Executive Order 14028 on Improving the Nation’s Cybersecurity” in May 2021, it has been clear to the cybersecurity community that the U.S. government has its sights on SSCS. And indeed, since then the Office of Management and Budget (OMB) has released its M-22-18 memorandum, the Cybersecurity and Infrastructure Security Agency (CISA) has unveiled its Secure by Design program, the Food and Drug Administration (FDA) has issued new mandates for medical devices, and many other regulations and policies have been enacted. Software producers and consumers are smart to pay attention to what’s expected of them in regard to these government standards.

In addition, the Securities and Exchange Commission (SEC) adopted cybersecurity disclosure rules for all SEC registrants and also prosecuted both SolarWinds and its CISO for allegedly misleading the company’s investors about its “cybersecurity practices and known risks” in the wake of the 2020 software supply chain attack on the company. 

SSCS policies have also been taking shape abroad. In the United Kingdom, the government is adopting a “Code of Practice for Software Developers” that is similar in scope to the CISA’s Secure by Design Pledge. Also, the European Union’s Digital Operational Resilience Act (DORA) and the European Cyber Resilience Act (ECRA) mandate strict cybersecurity practices for a wide range of entities and digital products – including commercial software. 

The bottom line is that, while it may be someone else’s software, it’s still your security outcome. And the standard of due care has shifted from “Did you know?” to “Should you have known?”

3. The CVE is failing

The reliance on the Common Vulnerabilities and Exposures (CVE) system as the backbone of cybersecurity risk management is increasingly problematic, particularly in the context of software supply chains. Despite its value in cataloging known vulnerabilities, the CVE system has several inherent limitations that compromise its effectiveness in today’s complex cybersecurity environment.

First, the pace at which new vulnerabilities are identified and the system’s limited capacity to catalog them results in a significant lag, leaving organizations exposed to zero-day attacks. Additionally, the CVE system’s coverage is not exhaustive, missing threats in custom, proprietary, or less widely used software components that are often integral to supply chains.

The CVE descriptions also tend to lack the depth and context needed for organizations to assess the real-world impact on their specific environments. This gap is critical because understanding the nuanced ways a vulnerability might affect a particular software supply chain is essential for effective risk management.

Furthermore, the CVE system is inherently reactive, focusing on vulnerabilities after they have been discovered. This approach misses the opportunity to incorporate proactive security measures and best practices that could prevent vulnerabilities from being exploited in the first place.

What SAFE software looks like

That triple whammy of challenges has proactive organizations looking for relief. That’s where SAFE comes in. 

Combining an SBOM with a comprehensive software risk and threat assessment, the Spectra Assure SAFE report provides critical information on the state of an application before release or deployment. Additionally, the SAFE report brings transparency and visibility to software supply chains’ key stakeholders — software development teams, cybersecurity leaders, and risk managers — because it can be securely shared between software vendors and purchasing organizations.

SAFE meets and exceeds the minimum SBOM requirements outlined by the National Institute of Standards and Technology by cataloging every proprietary, open-source, and commercial component, plus any build artifacts, with their publisher and license terms. 

SBOMs within the SAFE report can be exported to widely accepted formats such as CycloneDX and SPDX. But SAFE goes well beyond a mere list of ingredients, building out a complete picture of software supply chain security risk that enables organizations to find hidden threats — and take action to remediate them effectively.

The Spectra Assure SAFE report delineates specific criteria to ensure that software meets the highest benchmarks for trust and security, with each criterion designed to manage distinct cybersecurity risks effectively:

• Malware: Prevents the execution and spread of malicious software in a software supply chain attack.
• Tampering: Protects against malicious modifications that could make a software product susceptible to an attack.
• License violations: Mitigates legal and financial risks associated with software production and consumption.
• Leakage of sensitive information: Reduces the potential for data breaches and the violation of data privacy regulations.
• Sound cryptography: Ensures that data is stored and transmitted securely, guarding the organization against breaches and other incidents.
• Vulnerabilities: Minimizes exposure to known exploitable vulnerabilities (KEVs) that could be used to carry out a software supply chain attack.
• Secure behavior: Aids in identifying and mitigating suspicious or malicious activities.
• Proper software hardening: Minimizes the attack surface available to potential attackers.

By using the Spectra Assure SAFE Report, stakeholders responsible for all parts of SSCS will ensure that software supply chain attacks remain at bay. In addition, SAFE reports provide the comprehensive coverage that inadequate tooling lacks and keeps organizations ahead of the game when it comes to government compliance.

With all this in mind, it’s clearly time for risk and threat analysis to evolve for the software we build, purchase, or deploy across our organizations. It’s time that we build SAFE, buy SAFE, and stay SAFE with Spectra Assure.

Learn how your team can use SAFE

The Spectra Assure SAFE report provides the most comprehensive SBOM and risk assessment of applications currently available, identifying malware, tampering, suspicious behaviors, and more. Software producers or enterprise buyers can tailor their use of the SAFE report to best meet their needs. Teams that oversee software engineering, AppSec, third-party cyber-risk management (TPCRM), and more can all benefit from SAFE differently, and it will even allow these stakeholders to work better together from all ends of the supply chain.

To learn exactly how SAFE can put proper SSCS controls in place for your organization, see ReversingLabs’ “Go Beyond the SBOM” solution page. And dive deeper with the “Going Beyond the SBOM” whitepaper.

*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by Saša Zdjelar. Read the original post at: https://www.reversinglabs.com/blog/why-safe-why-now