One of the most alarming facts of modern software, considering the deep insecurity of most software, is the degree to which it is composed of many other software components of varying origin and unknown security. Almost every enterprise software portfolio has internally developed, purchased, outsourced and open source software; but almost every application in a portfolio has code that has multiple origins as well.
This is one of the things that makes a pure source code based security analysis of software, by definition, incomplete: if you can’t scan the components for which you don’t have source, you don’t have a complete picture of the software risk.
But worse than the problem of finding the flaws is the problem of getting them fixed. If you learn that your supplier has an issue in their code, you may be able to hold them accountable for a fix, but if the issue is actually in fourth party code that they use in their application, you are reliant on their ability to manage their own software supply chain to get a fix.
Considering one level of risk removed from the software itself, the supplier may use purchased software that puts the quality of their own software at risk, thereby putting you at risk. A real world example a few years ago was the compromise of the Apache project’s source control credentials via a cross-site scripting vulnerability in their local copy of Atlassian’s JIRA software. Though the break-in was caught, it is possible that Apache’s software might have been compromised due to this hack.
This is where securing the software supply chain starts to seem like an intractable problem. Even if you can get security attestations about the quality of the vendor’s software, what about their internal systems and processes that might put you at equal risk?
Here, as before in this series, other supply chain transformation efforts suggest a solution: use the supplier as a force multiplier. Specifically, require the supplier to hold their supply chain to the same standards that you hold them to. An example (cited in Wharton, “Managing Green Supply Chains” is IBM’s Social & Environmental Management Systems program, which holds its suppliers responsible for achieving measurable performance against stated environmental goals. IBM’s program requires that its suppliers publicly disclose their metrics and results, and “cascade” the program to any suppliers whose work is material to IBM’s business. The result: a rapid transformation of the compliance level of the whole supply chain.
This approach of cascading compliance requirements is in force in other efforts, such as generation of environmental bill of materials impact information (BOMCheck), corporate responsibility initiatives, and material data systems reporting requirements at Volvo. Indeed, organizational research suggests that cascading performance factors and associated goals to the supply chain is required for effective supply chain management.
Given the sensitive nature of the data protected by software and the complex nature of the software supply chain, cascading software supply chain security program requirements to major suppliers may be the only way to ensure that the enterprise is completely protected. The good news is that it need not be an uphill struggle. The more enterprises require secure software, the more vendors will read the writing on the wall and start to understand that security is a market requirement.