Now one thing that seems absolutely certain is that the interaction of businesses with other businesses, partners, governments, et cetera is becoming more complex every day. And the IT solutions and systems that are developed to deal with these things are themselves becoming equally increasingly complex. It has brought about collaboration across a global front rather than local or even in country. And it introduces a number of things that we really have to account for, especially when outsourcing of software design and build, testing, and ultimate implementation can be outsourced across any number of these geographic locations.

It produces the potential for a large number of threats, both known and possibly unknown. And the software developed in the supply chain such that it now complicates and requires a much higher level of trust and assurance that is built into the software product. Because now we have to make certain that the software that has been built and delivered does not contain any malicious logic. And the supply chain issues that we're going to discuss don't relate to software alone, but to the entire spectrum of delivery, build, design, activities.

Now complicating issue is that a lot of the software suppliers from which we get a primary product are themselves subcontracting a portion of the work and this further makes it more complex when we try to manage the total supply chain. We're going to cover all of these topics and more as we explore this issue. So we're going to look at these topics, understand supply chain risk, how to do a risk assessment on it, and how it impacts the software development life cycle. We have to explore supplier sourcing and how that associates with and impacts the SDLC.

We have to look at the process options and development criteria that are part of this whole picture. We need to look at options for software delivery and operations as they apply to software acquisition. We have to look at the transitioning process as it moves from one supplier to another, up and down and across the supply chain. And then we need to look at software escrow and the protection it affords to these involved parties. This module is going to be covered in these five sections. Supply chain risk assessment, sourcing, software development and testing as it relates to the activities associated with supply chain. This is a subject we've talked about a great deal, but now we have to put it in the context of the supply chain itself.

Software delivery, operations, and maintenance and then the process of supplier transitioning. So here we begin with supply chain risk assessment. So the question that has to be asked, why do we need to be concerned with supply chain risk and assessing it? Well, one thing that seems apparent these days is that software is not so much built as it might have been back in the early years of computing all by one supplier, one contractor, one provider of the system, in fact. But rather it seems now it is bought in pieces and integrated. Now this means, of course, the software purchased is composed of opponents from a variety of sources, not a single one. And the integration itself might not even be done by a single source.

Now, the issue that is raised here is that we have to make reasonably certain and let me emphasize that word, reasonably, through the contract relationships it may not be able to achieve absolute certainty but we have to do our due care and due diligence and make sure we do all that we reasonably can to make certain that all the parts meet a certain standard of trust, which should be captured in the contract language. And this by extension means that their source must also meet that same standard. It certainly is a case where the weak link analogy is entirely appropriate.

One software provider, a subcontractor to another may provide something that is flawed, if it is not checked and verified as good that can be the linchpin to the whole thing failing. And we need to take that as our example of what could happen if we don't practice these particular risk management processes. It also means that an entity seeking to acquire software must be the one to establish the standards that have to be met and then making sure that they are captured in the contract language as well as vet potential sources and suppliers against them.

So here's the basic process we're going to follow. Planning, contracting, monitoring and acceptance, and then the follow-on activity. So in the planning phase, we're looking at first making the decision about make or buy. In the contracting phase, decisions involving supplier selection vetting. And this should include the risk assessment process. In the monitoring and acceptance phase, work has actually begun. We've picked a vendor, they're beginning to work on, and they're very likely subcontracting certain pieces. So we have the work and we have the project management controls over the process. And in the follow-on phase, the product is delivered. It's been implemented and support services are provided possibly by the same vendor, possibly by a different one, possibly done from in-house.

Now in each phase, various risks exist that must be recognized and mitigated. So here's the need. According to the US General Accountability Office known as the GAO, there are five categories of threats to the software supply chain. One is installation or embedding of malicious logic in hardware or software. And we do have to consider hardware aspects as well as the software because these two things act in concert, not separately. What happens in one will affect the other. Number two, the installation of counterfeit hardware or software. And this can raise other issues that we'll talk about later in this module. Number three, failure or disruption in the production or distribution of a critical product or service. Four, reliance on a malicious or unqualified service provider for the performance of a tactical service. And this is especially important if it happens to be a mission-critical component. And the number five, installation of unintentional vulnerabilities and software hardware. And this of course is a common problem even in the most innocuous of circumstances.

Now clearly these five elements are going to cover a great deal of ground and they need to be included as high to low probability items that need to be assessed. These risks go up and down the supply chain, meaning that they're potentially pervasive. Some of these are processes employed to conduct the vendor selection, some exist in the vendor candidate, and all of them have to be identified and mitigated. Now this combination creates a necessity to perform a supplier assessment. And this is where we getting into the background and exploring a potential candidate and vetting them through their background and past performance and other factors.

So as part of the acquisition strategy, a key supplier risk assessment is absolutely a vital function that we have to perform. It identifies and evaluates each potential threat. We're talking about what is probable, not necessarily only what is possible. We need to look at that and assess the possible impact and associates the controls with optimal effectiveness of that particular risk and its impact. Now the outcome of informs the decision-making process for vendor selection and for the most appropriate controls to address the risks.

So we get two things out of this. And as you see, we start with the needs determination, developing the software requirements, creating an acquisition strategy, and that third level is where this process really takes place. Then we do monitoring and acceptance, and we develop evaluation elements, and analytics, and process steps afterwards.