To Find a Cybersecurity Solution for Everyone, We First Need to Admit Cybersecurity Is Everyone’s Problem

To Find a Cybersecurity Solution for Everyone, We First Need to Admit Cybersecurity Is Everyone’s Problem

Cyber breaches and costs reached all-time highs in 2021, and the first half of 2022 saw a 42% global increase in attacks. Organizations want to better prepare for and defend against cyber attacks, but they’re not getting the information they need to do it. 

In the U.S., there’s still no federal mandate for open disclosure of data breaches and other cyber attacks. Organizations aren’t incentivized to share information, and it’s human nature that they don’t like exposing their own problems. But cybersecurity problems are everyone’s problems.

The U.S. government is working on solutions. The Cybersecurity & Infrastructure Security Agency (CISA), Cyber Safety Review Board (CSRB), Securities and Exchange Commission (SEC), and Senate are each working to establish guidance and disclosure protocols for preventing and responding to cybersecurity incidents. The Senate’s proposed Securing Open-Source Software Act of 2022 (SOSSA) is a step in the right direction, but the legislation doesn’t go far enough. To explain why, I’ll offer context, break down the legislation, and share my take on its limitations — as well as why SOSSA embodies the problems we face in getting the disclosures needed to prevent and combat cybercrime more effectively.

Background: The Ongoing Impacts of the Log4j Vulnerability

Poor-quality software is to blame for many attacks. The Consortium for Information & Software Quality’s 2022 report found that the “cost of poor software quality in the U.S. has grown to at least $2.41 trillion.” Cyber attackers find and exploit software vulnerabilities, leaving organizations scrambling to assess their risk, find the software in their systems, and apply patches. 

SOSSA was developed in response to the critical Log4j (aka Log4Shell) vulnerability — discovered in November 2021 — which hackers continue to exploit. Log4j is a widely deployed open-source Java-based logging utility used in countless software applications, including those of major tech companies like Cisco, IBM, and VMware. Attackers use the vulnerability to take control of applications, servers, networks, and devices to steal data and deploy malware and ransomware. The CSRB assesses Log4j as an “endemic vulnerability” expected to impact systems until at least 2032. 

Why can’t we fix Log4j now? Most organizations don’t know what’s in the software they’re using, failing to understand their risk and take action to find/patch vulnerabilities. In most cases, the risk is there: Synopsys’ 2022 Open Source Security and Risk Analysis report found that 81% of codebases contain at least one vulnerability and 88% use open-source components that haven’t been updated in the past two years.

What Is the Securing Open Source Software Act (SOSSA)?

SOSSA was introduced in the Senate in September 2022 with bipartisan support, but it has yet to progress. Given prospective gridlock in a split Congress, it’s hard to say if and when it’ll pass. 

SOSSA focuses on new requirements for federal agencies under CISA’s authority. It charges CISA with outreach, engagement, and support for federal efforts to strengthen the security of open-source software. Specifically, CISA would create a risk assessment framework to help federal agencies determine which applications to target for closer scrutiny. CISA would ask software vendors to provide Software Bills of Materials (SBOMs) accounting for what’s embedded in their applications. The annually updated framework would incorporate government, industry, and open-source software community frameworks and best practices for assessing the risk of open-source software components. 

SOSSA also charges CISA to coordinate with non-federal entities on measures ensuring the protection and long-term safety of open-source software, and to support federal and non-federal efforts to bolster supply chain security. It includes a critical infrastructure assessment study and pilot assessment, and opens the door for CISA to create a software-security subcommittee. 

How SOSSA’s Limitations Highlight Central Challenges

The bill’s intentions are sound, but we face significant obstacles in establishing the cybersecurity disclosure standards that will enable us to more effectively prevent and respond to cybercrime. SOSSA embodies several of the most central problems.

Too slow. It would be years before SOSSA creates change. First, CISA has a year to develop the framework; then, agencies need time to conduct risk assessments and coordinate with contractors. Meanwhile, cybercrime accelerates.

Too narrowly focused. The legislation targets open-source software when the same types and quantities of cyber attacks can happen just as easily with proprietary software. 

Undeserved bad press. SOSSA risks giving the mistaken impression that open-source software is somehow riskier than proprietary software. 

No teeth. SOSSA doesn’t establish penalties, liability, or incentives for failing to provide or obtain the requested SBOMs or other information. It simply asks federal agencies to do their best to get it. President Biden’s 2021 cybersecurity executive order also relies on voluntary compliance. The SEC’s proposed public company cybersecurity disclosure rules may ultimately force disclosures of material incidents, but it’s unclear if/when the legislation will move forward. Why would organizations step up and be accountable?  

Likely resistance to SBOMs. Vendors may resist providing SBOMs due to:

  • Intellectual property rights — keeping competitors from knowing what’s in their software.

  • Compliance cost/effort — given daily/hourly software updates and hundreds of components per codebase, maintaining accurate SBOMs is no simple prospect. 

  • Legal liability — disallowing plausible deniability (i.e., “we didn’t know it was in there”) in the event of losses. 

The InfoSec Survival Guide: Achieving Continuous Compliance

Cybersecurity Sea Change Is Needed

We’ve got to start somewhere. SOSSA is a step in the right direction, but it doesn’t go far enough, and fails to embed incentives or accountability. Both are needed to create real change.

SBOMs are crucial for enabling true change. Federal law requires food manufacturers to tell us what’s in their products and where they came from. After all, if there’s a salmonella outbreak near you, you need to know where your bagged salad came from. Why shouldn’t the same be true for our software, such that we aren’t eternally scrambling to figure out what’s in it and where it came from? If every software vendor is held accountable, the playing field stays level. 

Many organizations look to cyber insurance to mitigate cyber risks and costs. But insurers also need more data to make better risk assumptions, which is why some discount premiums for organizations willing to share data. With premiums skyrocketing, that may be another incentive. 

SOSSA shows Congress testing the waters, dipping a toe — but it’s time everyone jumps in together. We need legislation that makes it clear: Cybersecurity is everyone’s problem. 


John A. Wheeler is the Senior Advisor, Risk and Technology for AuditBoard, and the founder and CEO of Wheelhouse Advisors. He is a former Gartner analyst and senior risk management executive with companies including Truist Financial (formerly SunTrust), Turner Broadcasting, Emory Healthcare, EY, and Accenture. Connect with John on LinkedIn.