Report: Power Sector Supply Chain Dependent on Adversaries

An estimated 90% of software products used to manage the U.S. power grid contains code “contributions” from Russian or Chinese developers. The finding from cyber risk management solution firm Fortress Information Security highlights new supply chain gaps and points to a dire need for more robust strategies to safeguard against insidious threats that lurk in the global software supply chain, Alex Santos, co-founder and CEO of Fortress Information Security, told POWER.

The finding stems from recent research conducted by Fortress, a company that specializes in critical infrastructure supply chain security. Starting in 2022, the firm looked at roughly 900 kinds of software used by power companies, including IT products utilized for network management, as well as operational technology (OT) products, which are used to monitor and control physical processes and equipment.

“This includes products from large well-known vendors like feeder terminals, chromatographs, network switches, management relays, and routers,” a Fortress report released on Dec. 5 says. “The researchers pulled 392 files that used multiple complementary tools for firmware and binary analysis. From those files, they were then able to create 224 Software Bills of Materials (SBOMs). They looked at mostly open-source code.” it notes.

Of 7,918 components Fortress reviewed, 13% had contributions from Russian and Chinese developers. However, the firm found that 90% of the products used to manage the U.S. grid contains component contributions from developers that identified as Russian or Chinese. The researchers also found contributions from Cuba, Iran, and North Korea.

“To be clear, researchers only counted components with contributions as coming from Russia, China, or any country if the creators acknowledged their country of origin,” Fortress says. “Only those developers who self-identified on a software development platform as being from a country were put on that country’s list. There is no information on the platforms indicating that the code resulted from a state-sanctioned project.” While Fortress sees “a clear correlation between the increased vulnerabilities in some contributions and the country of origin,” its experts “cannot yet establish if the country of origin is the cause of the higher number,” the report acknowledges.

Still, the research suggests that software with Russian or Chinese-made code examined by Fortress research “is 2.25 times more likely to have vulnerabilities,” the report notes. “Perhaps even more troubling, that software is three times more likely to have critical vulnerabilities—the vulnerabilities that are easiest to exploit and more likely to allow damage to hardware.”

Long-Standing Vulnerabilities

According to the report, firmware—software embedded directly in hardware that provides low-level control for a device’s specific hardware—shows the most vulnerabilities, with an average 620 vulnerabilities per product. “But operating systems had just as many critical vulnerabilities—with 12% being critical,” it notes. “In all, approximately 7% of all vulnerabilities were critical—the vulnerabilities that should be prioritized for remediation.”

In another potentially alarming finding, the report suggests that vulnerabilities built into the software running critical operations and components don’t get immediate attention from vendors, suppliers, or utility providers. While vulnerabilities are generally seven years old, the average age of critical vulnerabilities is nearly three years. Meanwhile, only 10% of components are responsible for 92% of the most critical vulnerabilities, it suggests. “Two components, glibc and linux_kernal, were responsible for around 40% of these potential vulnerabilities.”

Fortress’s report arrives as actionable cybersecurity mitigation efforts are showing a “slow down” compared to momentum after the Log4J and SolarWinds crises, highly sophisticated nation-state attacks, more than three years ago. “Those two, the attack and the vulnerability, drove a lot of cyber policy from the executive branch. But because we’re humans, we tend to forget the crisis,” Santos said.

While regulations have pushed IT departments to focus on software security, “nothing has happened in the last couple of years,” he noted. “Now the pressure is off, the regulators are slowing down, they are feeling and succumbing to the pressure of the software manufacturers,” he said. “And the end-result is that our grid is not as secure as it should be, given that we know that our adversaries can use can hide deep inside of the software to to perpetrate their missions,” he said. “We released the report because we need to keep reminding people that this is a big problem.”

According to Santos, a key solution may lay in pinpointing problematic components. The firm has been adamant in its advocacy for universal adoption of SBOMs as the most efficient way of shedding light on vulnerabilities in a product. “In our research, we’ve shown that if you fix 10 components—if we can fix those components, make them secure, update the software that’s in the field—you’ll knock out 70% of vulnerabilities,” he said. “That’s the cheapest solution, but it’s still not cheap, so it’s going to have to be an investment.” 

However, in addition, Fortress suggests that cybersecurity should be key procurement criteria, though that will require more certainty from the federal government. “America needs regulation of software development platforms—either from industry or from Washington,” it says.

SBOMs: A Software ‘Ingredient List’

SBOMs are essentially an “IT list of ingredients in software,” Santos explained. “Software is not coded anymore—it’s assembled like Lego in blocks” from catalogs. Blocks, for example, comprise a database or a login screen, he said. “So the SBOM is an ingredient list of the Lego pieces in our software.”

The process of curating an “ingredient list” is complex, given the varied contributions to a software product. Citing technological research and consulting firm Gartner, the report notes an estimated “40% to 80%” of lines in new software project code come from third parties, such as runtime, libraries, and component and software development kids.

The advent of artificial intelligence (AI), which automates software building, is posing new challenges “to label and understand what is in the software,” Santos said. An even bigger risk, however, may be posed by older software versions, which may include obscure components, he said.

A key reason that SBOMs have emerged as a crucial cybersecurity mitigation effort is that that they can provide transparency into what software is made up of. SBOMs, notably, also helped security teams track and mitigate damage from attacks, such as from the 2020 SolarWinds attack and more recent ransomware attacks in MOVEit software applications, Santos said.

However, organizations are struggling to implement SBOMs. According to Gartner, only 5% of organizations have adopted SBOMs, though it projects that by 2025, 60% of organizations may “mandate and standardize SBOMs” in software engineering practices. According to Fortress, “those numbers are still way behind.” The firm notes: “It just takes a backdoor, in one company, in one critical sector, to give bad actors an opening into the systems running critical services, like the power grid.”

In the power space, “what’s blocking the earnest” to adopt SBOMs is two-fold, Santos suggested. One is that “utilities are now under massive cost pressures,” he said. At the same time, software developers have resisted SBOMs. Santos suggests this may be owing to cost and liability concerns. “My estimate is it’s $40 billion for vendors to fix the software,” he said.

Some utilities use software that’s 10 years old, and that poses a circular dilemma with questions about “whose job it is to fix it,” he said. “The old stuff is still there sitting vulnerable, and manufacturers refuse to fix it. So now, by default, it’s the utility’s problem, but it’s really hard for them to act on it, because you have to get really into the weeds of the software, and it’s very costly to do that.”

What’s Needed: A Collaborative Effort for More Transparency

In the U.S., federal entities like the Cybersecurity & Infrastructure Security Agency (CISA) have supported SBOMs as a critical tool to prevent cyber attacks.The bipartisan Cyberspace Solarium Commission in 2020 urged the federal government to require SBOMs for software it purchases, and in 2021, the White House issued Executive Order 14028, which mandates government agencies should have SBOMs for software purchased beginning in 2024.

However, industry craves more certainty, Fortress suggests. “Congress’s decision in 2022 to remove language from the National Defense Authorization Act (NDAA) that would have required software makers to include an SBOM on products offered to federal agencies certainly muddied the picture,” it says.

Some progress is underway. On  Aug. 10, CISA asked the open-source community for ideas on how to secure code from their community. “The hope is to craft a report from these suggestions that could come out later this year,” Fortress notes.

CISA is also working on producing a “Secure Software Self-Attestation Common Form for government vendors,” a document that Fortress says will require software producers supplying products to the federal government to guarantee the implementation of specific security practices. The measure will mean that “software makers will either have to promise the products are being tested or have a specific timeline for testing to occur,” the firm explains.

Fortress suggests that once a reasonable and robust standard is developed, all parties can work with the government to devise “sensible enforcement mechanisms.” It notes: “If the industry takes steps to require SBOMs and Attestation forms voluntarily, the less the government will have to mandate them.”

Still, for now, private-sector collaborations and industry solutions remain integral. “The software development community would do us all a great service if they joined the effort to ensure code contributions on the platforms are secure. Especially when those companies are trying to avoid a $40 billion-dollar tab,” the firm says.

“Nobody wants to create a situation where we need a software industry bailout, but we need the software industry to find solutions instead of fighting SBOM legislation—which reportedly their lobbyists did before the SBOM provision was pulled from the NDAA.”

—Sonal Patel is a POWER senior associate editor (@sonalcpatel, @POWERmagazine).