Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free Trial
The software supply chain security landscape has shifted considerably over the last year. Two of the most significant changes have been the move to a more formalized definition of the term "software supply chain security” and the development of a better understanding of what is needed to secure the software development lifecycle (SDLC).
A year ago, securing the software supply chain was all about open-source packages, software bills of materials (SBOMs)and using software composition analysis (SCA). Now, there is a realization that the risk from the increasingly complex software supply chain is multifaceted.
Software producers and enterprise consumers have come to recognize that, while securing source code and open-source packages is important, it alone is not enough to control risk from software supply chain attacks. Teams also need to have mechanisms to detect potential compromises of the development tool chain, from the continuous integration/continuous deployment (CI/CD) orchestration platform to the build environment to code repositories and binary repositories.
In addition to updated guidance from federal agencies and the White House, analyst firm Gartner has produced guidance on managing software supply chain risk that marks a shift in thinking. It goes into detail about software supply chain security best practices. (Hint: There's more to it than just saying, "You need an SBOM.") Then there's ReversingLabs' new research-based report, the State of Software Supply Chain Security 2024, which highlights the need for a new approach.
An evolution of application security (AppSec) is under way, and a key to it is complex binary analysis, which is like a final exam for your software package before release. Complex binary analysis allows your team to review the software in final form so that you can trust all of the software your organization produces and consumes.
Here's why you need to consider complex binary analysis a requirement in the new era of software supply chain security.
Learn more with our Essential Guide: Software Supply Chain Security for Dummies
A couple of factors are driving this change. The first is the new and still largely unknown nature of the threats to software supply chains. To keep up with the demand for faster releases, organizations have moved from very staid and plodding development processes, where everybody knew what was happening, to fast development using shared code resources from platforms such as GitHub — which now is increasingly under attack. One result is that security teams are now siloed into specific responsibility areas.
Given the complexity and disparity of software supply chains, it is no longer possible to get a full picture of software risk until everything is brought together in the final package. And many software supply chain attacks are novel. Future attacks may match the severity of SolarWinds Sunburst, but they will almost certainly differ in their methodology.
In fact, several major supply chain breaches that have occurred since the attack on SolarWinds have used different execution. The breach at 3CX, for instance, resulted from a legitimately signed third-party software component. The CircleCI breach stemmed from a compromise of its CI/CD orchestration platform itself, and the breach at Codecov resulted from credentials theft and misuse.
All of these were serious software supply chain attacks, and they all took different paths. It's clear that attackers are testing the waters. They are trying to get out of the fenced yard by pushing on the fence panels to see which one will give. What these attackers are doing is looking at all aspects of the SDLC for potential weaknesses, which they can then attack.
Increasingly, teams responsible for managing risk are realizing that they need to stop thinking of SunBurst as a unique category of supply chain attack and focus instead on the bigger picture.
Technologies for identifying threats to the supply chain are vital at every step of the development process because you don't know whether a threat actor is going to try to attack the build system or code repositories or seek some other way to slip malware into the software pipeline. Increasingly, teams responsible for managing risk are realizing that they need to stop thinking of SunBurst as a unique category of supply chain attack and focus instead on the bigger picture.
Another driver for change is that software supply chain attacks have garnered much attention as a primary risk category, and organizations are starting to freak out a little bit. Security teams are buckling down, trying to find a process for securing the SDLC. A lot of the initial momentum came from the federal government, starting with the May 2021 executive order from the White House, which called for increasing the United States' cybersecurity resiliency. That was followed by a memo calling for self-attestation by software producers and the creation of SBOMs. Gartner also joined the call for SBOMs in 2022.
One initiative that received a lot of attention in 2023 was Secure by Design, championed by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), because a key aim of the initiative is to shift liability from software consumers to the producers of the software.
More recently, the Enduring Security Framework, a public-private working group led by the National Security Agency (NSA) and CISA, stepped up its software supply chain security guidance with a call for complex binary analysis and reproducible builds.
Definitive timeline: Federal guidance on software supply chain security
In the next 12 to 18 months, it is reasonable to expect that higher standards for software supply chain security are going to apply to a wider swath of organizations and not just those doing business with the federal government. Ahead of that, organizations need a way to anticipate and answer questions about the security of their software supply chain. Those that can get out in front of that risk will have a competitive advantage — and stay out of the headlines.
Software supply chain security mechanisms need to be implemented in a way that is not cumbersome, complex, or disruptive to existing CI/CD and release processes. NIST's Secure Software Development Framework is the best standard right now, but there are others as well. Organizations have to identify which standard works best for the way they develop or consume software because people code in different ways and with different kinds of technology stacks.
Organizations need to identify the standard that best works for them as they try to manage software supply chain risk, and they need to stick with it. With complex binary analysis, organizations can evaluate all of the software they produce and consume, including third-party commercial software.
While legacy AppSec testing focuses on source code, what you receive from vendors is binaries — which is why binary analysis of the compiled packages is where you should be looking to identify risks.
SBOMs can help in a lot of ways because they give a list of all the ingredients in a software package. But they don't give you information on how these ingredients interact. It is not realistic to think that a third-party vendor will send source code for you to inspect for supply chain risks. That's because no vendor is ever going to say, "My software is riddled with holes."
While legacy AppSec testing (technologies such as SAST, DAST, RASP, and SCA) focuses on application source code, packages, and an application at runtime, what you receive from vendors is binaries — which is why binary analysis of the compiled packages is where you should be looking to identify risks.
Everybody is familiar with legacy AppSec testing — and it's not going away. But this new era is calling for your organization to get comfortable with an additional security technology that provides a completely different, but very important, lens of risk. If you are not doing real software supply chain security as part of your validation processes — that is, doing a final exam with complex binary analysis — then your software and your organization are not secure.
Researchers built a worm that reasons about hosts it infects, and the open-weight models powering it sit outside AI-provider safety controls.
While prompt injection and data disclosure remain concerns, excessive agency climbed the list — not surprising with recent security incidents.
The post-mortems of two compromises by rogue AI agents show that security teams need to focus on guardrails, not the AI model.