Software Supply Chain Paradigm

Years ago, enterprises were closed loop systems. Everything an enterprise needed was inside its perimeter, and that perimeter was guarded by firewalls and Sysops. Any software the enterprise bought was delivered to the enterprise, hosted and operated inside its perimeter, and all data that the software used was stored, managed, and processed inside that perimeter.

Today, this paradigm is massively changed. Every enterprise has third party data processors, data enrichment affiliates, SaaS application providers, integrations hosted by fourth parties such as Salesforce or Servicenow, etc.

So there are multiple supply chains involved in any enterprises IT/OT existence.

• Software supply chain is about the applications that ingest, process, and visualize information.
• The network supply chain is about the APIs, network links, and interconnections between enterprises.
• A data supply chain would be data collected, aggregated, stored, processed, output visualizations, and enrichments of the data.
• An Identity supply chain would be when employees and services work between enterprises.
• Firmware supply chain is the firmware/bios in most networking devices and PCs
• OT hardware and software
• etc etc etc

This Supply Chain Multiverse has a lot of ramifications. For example, the Software Supply Chain includes every chunk of code used in any application sold to an enterprise, including defining the meanings of versions of software, defining the provisions for various licenses, and understanding what makes a significant or non-significant change in an application, or chunk of code.

When an enterprise buys a piece of software, that software comes from a string of people and companies. From writing the code, to legoing the libraries together, building integrations, adding encryption and APIs, securing the implementation, marketing the software, selling a license, delivering the code as a pile of source code or binaries, there is a huge list of involved parties. That software supply chain adds a plethora of risk factors to the software, such as malicious upgrades, hardcoded API keys, and abandonware. Those risk factors have been largely unaddressed, and to a large extent, unrecognized as risk factors.

CISA has broken down the entire software supply chain into three parts. Software manufacturer, software vendor, and customer. Each of those three links of chain (Manufacturer, vendor, customer) have responsibilities, built in the same model as a Cloud Service Providers shared responsibility model.

While this model is a bit of an oversimplification, and totally ignores in-house developed or customized software, contracted consultants building integrations, and many other potential scenarios, its a good starting point. It clearly outlines and divvies up those responsibilities, and provides structure to the software supply chain.

The documents are clearly written, refer to multiple standards from NIST and other regulatory bodies, and delineate responsibilities well. There is no question that these will become a reference model.

However, from the diagram above, Developers have, in their purview, some activities that they currently perform, such as Architecture and Design Review, Coding to standard, and code and executable testing. There are also many activities for developers that, oftentimes, arent performed at all. How many dev shops are concerned with Secure delivery of code? Secure software development? Checking libraries to make sure they are secure?

You may notice similar issues with both Suppliers and Customers in this chain. How many VARs or distributors actually test code, verify 3rd party software, etc? And how many customers/users of software properly implement risk and security controls?

This framework is asking every level of the software supply chain to adjust and add costs to their responsibilities. Will customers pay more to run secure software? Will suppliers pay more to supply secure software? And will developers pay more in effort to build secure software?

No, of course not. Not until everyone does it. If the playing field is not level, then the ones at the lower end of the cost field will win. In the short term, a lower price will win in the procurement world. So how could the playing field be leveled?

There are two ways that are easily foreseen. One is the mandated way, in which regulatory agencies across the critical infrastructure and government world mandate that this framework (or a similar one) be adopted. The other is almost mandatory, but its cyberinsurance based. With the costs of cyberinsurance rising drastically, if a major cyberinsurance vendor decreed that unless the software procured by its policyholder uses this framework, any breach resulting from non-framework software would not be covered.

So there is a way to mandate the use of the framework. And there is value from the use of the framework. But, at the end of the day, there is an added cost to the consumer for this added safety. Software Bill of Materials and Zero Trust Network Access and . all cost money and effort. Is it worth it?

There are even organizations that are saying that SBoMs and ZTNA arent good ideas yet because theyre immature and not fully featured. On the contrary view, if nothing is used until its perfect, nothing will ever get done. And SBoMs have a full ISO standard on the SPDX protocol, integrations with popular business applications on the CycloneDX side, and a very simple application use case with SWID tags. Zero trust is a method of performing authentication and authorization on every request, not merely trusting any request inside the firewall. Its not easy to implement, but it is a very mature set of protocols.

The worthiness of the framework depends on the threats that the enterprise is facing, and the value of the assets and data that the security is protecting. It depends on the regulatory environment and the verticals that the enterprise is working in. It depends on many factors, but in the end, with ransomware and breaches a daily story, is it possible that its necessary for our digital lives to be safe? At least to have the table stakes for enterprises and applications raised to a standardized level? At least clearly define what is a developers responsibility, so that open source software can still be built. Perhaps its time to regulate how software is built, and stamp some seal of approval on it. But who is trusted enough to do that? Who indeed.

Who will be the Underwriters Laboratory of the digital world?