Find out why a too-narrow definition of "supply chain" may be hindering software security efforts.
The SolarWinds attack in December 2020 was a stark wake-up call for the cybersecurity community, emphasizing the urgent need for software supply chain security. The breach demonstrated how trusted relationships and mechanisms can be exploited by bad actors, and that it is hard to trust third-party software, even if coming from a reputable enterprise vendor.
Once the full impact of the attack – which affected 18,000 SolarWinds customers, including major corporations, government agencies, and critical infrastructure entities worldwide – was realized, it became clear that the software supply chain is a target. But what exactly is the “software supply chain”? In the years since the SolarWinds attack, this question has led to both confusion and increased risk of breach.
The Wrong Focus on Supply Chain Security
A recent survey conducted by Legit Security among Information Systems Security Association (ISSA) members reveals a concerning trend: a majority of security professionals hold a dangerously narrow and antiquated view of what constitutes software supply chain security. While 71 percent of respondents focused primarily on securing third-party or open-source dependencies, only 29 percent embraced a broader, more accurate definition that considers all the links in the software supply chain.
This limited perspective creates significant security gaps. The modern threat landscape has evolved, with attackers exploiting vulnerabilities in the development pipeline itself, far beyond just third-party components.
An effective approach to software supply chain security must encompass every component of the SDLC, from code inception to production deployment, which requires a mindset shift from software supply chain to "software factory.”
The Perils of Complexity — and the Need to Modernize
The complexity of modern software development is a key reason why it’s dangerous to only focus on third-party components. Any security or dev leader knows that this increasing complexity of modern development is a double-edged sword. On one side, it allows for more agile, scalable, and feature-rich applications. On the other, it significantly increases the chances of misconfiguration, mistakes, and the inadvertent exposure of sensitive secrets (such as passwords, tokens, and keys) within development pipelines.
As an example, build servers are a part of the software “supply chain,” but aren’t often thought of as such nor treated as critical systems. They also frequently contain misconfigurations that leave organizations vulnerable to breach.
In fact, before Solarwinds customers were compromised, Solarwinds’ build servers failed to provide a first line of defense.
Exposed secrets can be a goldmine for attackers as well, enabling them to escalate privileges or access critical infrastructure. Why have secrets become such a problem? Because modern apps require hundreds of secrets to function (API keys, third parties, cloud credentials, etc.). At the same time, developers are pushed to innovate and develop code as fast as possible, frequently leading to shortcuts intended to drive efficiency and speed. One of those shortcuts is using secrets in development to accelerate testing and QA.
For example, a developer may test a piece of code with a key. When it works, they move it into production without removing that key. They either forget, or the key works and they don’t want to adjust it.
The Sisense breach from mid April 2024 demonstrates this well – a GitLab server was hacked, and stolen secrets were used to further compromise the organization.
This is why it is essential for security and dev leaders to ensure their approach and definition of software supply chain security is broader and modern. An outdated approach leaves organizations vulnerable to compromised development pipelines — as we saw in the SolarWinds and Kaseya incidents — and also foster insecure practices, like executing third-party code without proper verification. A narrow focus fails to account for the myriad ways attackers can infiltrate the development process, targeting the interconnected and automated "software assembly line."
Gaining Visibility Into the “Software Factory”
Full visibility into the “software factory” — everything from the assets and tools used in software development to the pathways and pipelines through which code travels before becoming a finished product — is now key. However, getting a complete and accurate view of this factory is a challenge. Modern development practices, such as the use of microservices, containerization, and continuous integration/continuous deployment (CI/CD) pipelines, not only increase complexity but also obscure the full picture, making it difficult for security teams to track and safeguard every component effectively.
Compounded by the visibility challenge is the difficulty in correlating various types of risk across the software development lifecycle (SDLC). Today's software products are often built on a complex interplay of cloud services, third-party applications, and proprietary code, each introducing its layer of risk. The lack of a unified view to correlate these risks, from cloud vulnerabilities to supply chain threats, forces security teams to engage in time-consuming manual efforts. These efforts are inefficient and increase the likelihood of oversight, leaving software products vulnerable to attack.
Updating and Broadening the Approach
To navigate out of this challenge, organizations should modernize their definition of software supply chain security to consider the entire “software factory.” This means shifting the focus from solely guarding against external dependencies to securing the end-to-end SDLC process. Security must be a holistic endeavor, encompassing tools, systems, people, workflows, and pipelines, all dedicated to producing secure and trustworthy software.
Achieving this broader security coverage starts with gaining accurate visibility into your development pipelines, creating a comprehensive SDLC asset inventory in collaboration with development teams. This foundational step allows for the identification and prioritization of critical security risks needing urgent remediation.
While manually creating this inventory is possible, leveraging modern software supply chain security tools for automation offers a more efficient and less resource-intensive solution. These tools not only streamline the process but also ensure a higher degree of accuracy, particularly vital for securing large-scale, frequently changing software supply chains.
The Road Ahead for Software Security
As the software supply chain security landscape continues to evolve, so too must our approaches and definitions. By embracing a more inclusive and modernized perspective, organizations can better safeguard against the sophisticated threats of today's digital world.
Learn more about securing the software factory in our whitepaper.
