NOTE: What follows is a strong overview and summary of the topic, but we've also prepared a comprehensive software supply chain introduction with additional background and insights.
---
The vast majority of developers today don't develop software from the ground-up and instead rely on third-party resources when creating software. By using pre-built libraries and open source components, engineers can expedite development and reduce production costs, bringing products to market faster.
As a result, companies need to recognize that software happens outside their walls and networks. What people, processes, and tools make up the software you deploy?
Read on for a big-picture overview of the software supply chain.
---
The term "supply chain" refers to the people and processes for making and distributing a product, often applied to manufacturing. For example, a company building airplanes will make some parts of their own, as well as purchase and assemble component parts from other companies. They assemble the parts based on design specs and then put new aircraft through testing before putting it in the hands of airlines and pilots.
Modern software development happens in a similar way: It is also built from parts, involves multiple developers, teams, and systems both inside and outside of a given company. And, just like airplanes, some software must continue to function under stress.
We therefore define the software supply chain as anything that impacts this evaluation, production, and distribution.
You can't manage something if you can't see it or don't have a plan, so visibility, clear policy, and ongoing improvements are crucial. With hundreds or thousands of component parts, multiple teams, and the real danger of software supply chain security issues, there are strategies to get a handle on your company's software.
Good software supply chain documentation is hard to build, but one type of particular benefit is a list of third-party ingredients in your code. This provides a basic understanding of what's happening, as well as a guide to know if the latest security news affects components in your software.
Known as a software bill of materials (SBOM), these documents are formal, machine-readable lists detailing all the various components and dependencies within a piece of software.
Benefits beyond just visibility include building trust with customers, demonstrable security awareness, and license compliance. You don't need to open all your source code to all customers and can still share as much or as little of this information with customers as required.
Furthermore, what started out as a best practices recommendation is now becoming a requirement for some customers. Most notably, the US government now requires vendors to provide a formal SBOM when selling software to federal agencies.
For more on this, our blog posted a deep dive into SBOMs, including use cases, benefits, and ways to manage.
Until recently, software development was a fragmented process that was highly linear and similar to a production line. Now, companies are knocking down barriers and integrating workflows across teams and individuals. Often referred to as DevOps, this merge between development and operations means increased collaboration between groups has shown competitive results.
However, it's in this environment of rapid change where it's more important than ever to avoid data leaks or loss of sensitive information. To increase software supply chain security, companies need to consider and implement strong IAM policies and data governance procedures. Some companies have even employed DevSecOps as a way to explain how security is part of effective collaboration.
Successful software is constantly improving and taking customer expectations with it. Being a part of this industry means always trying to push the boundaries of speed and efficiency. Even though Agile development is turning 20 this year, the concepts of constant software testing and performance monitoring are no less relevant and important.
Because software is made up of third-party component parts, attacks have shifted to target the supply chain. The attack against SolarWinds is maybe the best example, where a complex effort against multiple components enabled access to the company's network and application monitoring platform — a system used by over 30,000 organizations.
After gaining entry, the attackers inserted malicious code into the company's software. When SolarWinds sent out an update to its customers, it inadvertently granted backdoor access to customer accounts.
Other high-profile issues we've covered:
The issue is becoming so pervasive, a debate about what represents a supply chain attack is underway. You can read our view on the issue with the recent Kaseya attack, where a ransomware attack granted access to more than 1,500 small business networks.
Our research shows that hackers are aggressively targeting open source components to gain entry into supply chains. A 650% increase in next-generation cyberattacks against open source tools was recorded over a 12-month period.
As the report explains, legacy software supply chain attacks focus on publicly disclosed vulnerabilities. Attackers have changed tactics over the last three years, and are actively launching malicious code into open source projects that connect to the global supply chain.
In other words, they're targeting components "upstream," or the services that distribute software workflows and updates. This impacts large volumes of end-users located downstream, across multiple organizations.
Avoiding these attacks means dodging serious financial, operational, and reputational harm, potentially impacting entire industries.
Legacy software supply chain attacks are still a concern and companies have an increasingly narrow window of how to address exploits following a vulnerability disclosure. Organizations that fail to increase software supply chain security updating their application after a vulnerability risk losing to adversaries. Yet we found only 17% of organizations become aware of new open source vulnerabilities within a day of public disclosure. And 35% find out within one to seven days.
The faster you respond to vulnerabilities, the better off you'll be.
Discovering a vulnerability is only half the battle. After learning about a software supply chain security issue, developers then need to update any software that uses the code. This requires deep visibility across the software supply chain.
Fortunately, solutions are available that scan applications and highlight problematic components and to reduce the time to repair.
Communication is critical for preventing attacks. Once developers and community members discover harmful components, those items can't make their way into production. Teams can flag problematic components and set up a framework to track and prevent them from re-entering the software development life cycle (SDLC).
When code loses support or reaches the end-of-life (EOL) stage, it can't remain in the app. It's that simple. As such, it's essential to make sure that code is still being widely used and supported by a community, which requires vigilance.
Leaving outdated and unsupported code leads to vulnerabilities that can affect your supply chain. Once you know a code base or project is shutting down, it's important to move to an alternative or removing functionality.
At the end of the day, monitoring and protecting the software supply chain can be very difficult. It's especially hard for companies with multiple programs and supply chains.
To streamline the process, a growing number of companies are using software supply chain automation technologies. Sonatype's offer in this space contains software supply chains solutions for building and managing artifacts and binaries, identifying open source risk in containers, and preventing questionable components from entering your SDLC.
Sonatype also eliminates software license compliance issues by automating manual license attribution and avoiding incompatible or conflicting licenses.
Our goal is to strengthen your software supply chain without allocating more human or back-end resources.
Our "State of the Software Supply Chain" report explores how high-performing enterprise software development teams can balance performance and risk management practices when working with open source components. This report contains data visuals, survey results, and other information to help put a finger on the pulse of open source security.
Our State of the Software Supply Chain report is available for free.
---
You can read a more comprehensive introduction to the topic or schedule a product demo to see Sonatype in action.