Laying the foundation: software supply chain security

In the broad sense, a supply chain is anything and everything that is needed to create and deliver a product to the end user. So, a software supply chain is no different – the only nuance being that it refers to code and applications, and everything involved in their development and delivery.

Just as an automobile manufacturer can have a broad network of suppliers and parts, a software vendor can depend on a complex variety of code, tools, and resources to produce their product.

The key concern here is that a defect or weakness anywhere in a supply chain can impact any entity further down the supply chain (often referred to as “downstream”).

This has always been a supply chain concern though, so why is it so top of mind today in the software industry?

As the digital transformation has us depending on technology more than ever to run our businesses and daily lives, the race for technology companies to get their products to market is very competitive. As a result, these companies focus more on the innovation of what makes their products unique, and less on “reinventing the wheel.” In other words, software has shifted from being built, to being assembled – each piece coming from different entities that specialize in making that piece. For example, an eCommerce company won’t waste time building a database; an online banking institution won’t waste time building user interface tools; an IoT company won’t waste time building a custom operating system. Instead, they’ll all turn to third parties, open source projects, and contractors to provide these pieces.

In fact, Synopsys’ latest Open Source Security & Risk Analysis (OSSRA) report found that an average of 97% of all software written contains at least some open source code. Of the 17 industries represented in the report, Computer Hardware and Semiconductors, Cybersecurity, Energy and Clean Tech, and Internet of Things (IoT) contained open source in 100% of their codebases. The remaining verticals had open source in 93% to 99% in their codebases. Even the sectors with the lowest percentage—Healthcare, Health Tech, Life Sciences—had 93%, which is still very high. It’s clear that open source really is everywhere.

But, what happens when an open source component contains a vulnerability? Or maybe the maintainer’s account was hacked, and malicious code was inserted? That means the IoT company is using an operating system with a critical vulnerability, opening the end-user to having their smart thermostat or WiFi camera to potentially be hacked. The issue began within the open source component. It was implemented by the IoT company into their product, which was sold to the end-user, who ended up being attacked. This is the very essence of a software supply chain concern. According to the 2022 OSSRA findings, 100% of codebases in the IoT sector contained open source, and an astounding 92% of the audited code in this sector was open source. Troublingly, 64% of the IoT codebases also contained vulnerabilities.

Similarly, the Aerospace, Aviation, Automotive, Transportation, and Logistics sectors had open source in 97% of its codebases, and 60% of the total code was composed of open source. Sixty percent of these sectors’ codebases had open source vulnerabilities.

Here are two real-life examples of software supply chain concerns:

1. SolarWinds.

Perhaps one of the, if not the, most notable software supply chain attacks. An internal password was leaked online, which was used by attackers to gain access to SolarWinds’ build systems. This is where the supply chain attack began. Attackers inserted malicious code into the upcoming release of Orion, SolarWinds’ flagship

product. This malicious code went undetected, was built into the product release artifacts, and shipped out to customers. And with that release, Orion now served as a portal for attackers to infiltrate SolarWinds customers. Among these customers, were multiple U.S. Federal agencies. The fact that the initial attack took place several degrees of separation away from the intended target makes it a shining example of a supply chain attack. It’s this attack, along with others affecting critical infrastructure, that led to the Cybersecurity Executive Order.

2. Log4Shell.

While there have been no [confirmed] successful attacks exploiting this vulnerability, it serves as a solid example of the potential impact of a vulnerability on the supply chain. Apache Log4J is an extremely popular Java logging framework. It works in the background of applications that countless businesses and consumers interact with every day. A zero-day vulnerability of high severity in several of its versions was disclosed in December 2021, which could be exploited by remote attackers to gain access to the operating servers. Had this been discovered by attackers first, the impact would have been devastating and widespread. This goes to show how a simple data-sanitization issue in a simple (but popular) component can snowball down the supply chain and wreak havoc on all the applications that depend on it. The 2022 OSSRA found that 15% of audited Java codebases contained a vulnerable Log4J component.

There are two types of organizations who ought to be concerned about software supply chain risk: software producers and software operators. Oftentimes, we find that most organizations are both; they consume software developed by other entities and use it to build software that they sell/distribute or operate themselves. Regardless, mitigating supply chain risk comes down to knowing what is in your software and hardening it against known attacks. Put even more simply, organizations must secure their software development lifecycle (SDLC).

Securing the SDLC can be broken into some key considerations:

Secure Code

· Open Source Dependencies. Identify all open source code being used within your applications so that they may be monitored and evaluated for security and license compliance concerns.

· Commercial/third party. Track all third-party code so that it, and its contents, can be evaluated for any associated risk.

· Custom. Ensure that any custom or proprietary code that your organization is writing is free of any defects or security weaknesses.

Secure Deployment

· Containers. Be sure what the contents of a container are before shipping it. Vulnerabilities in base images, dependencies brought in at build time, and hard-coded secrets are all areas of concern.

· Infrastructure as Code (IaC). What used to be the responsibility of a seasoned IT/Ops professional, it’s now up to developers to configure the infrastructure that their apps will run on. Common security weaknesses and open source templates can open the door to attack.

Software Bill Of Materials (SBOM)

· Produce it, Require it. If you procure software to operate, ask for an SBOM from your vendors. If you produce software, be prepared to provide one to your customers, especially if they’re in the public sector or U.S. Government. At this point, it’s best to follow NTIA guidelines for what is required of an SBOM. These documents provide visibility of what is in the software that powers your business, so you can react quickly to any threats.