CSSLP Domain 8:1 - Supply Chain Risk Assessment

The course is part of this learning path

Supply Chain Risk Assessment

This course covers the supply chain risk assessment process and will prepare you for the first section of CSSLP Domain 8. 

Learning Objectives

  • Understand how to assess risk in your supply chain
  • Learn about intellectual property and compliance in the context of software development
  • Learn how to identify and choose suppliers for your software development supply chain

Intended Audience

This course is intended for anyone looking to develop secure software as well as those studying for the CSSLP certification.


Any experience relating to information security would be advantageous, but not essential. All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.



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.

About the Author
Learning Paths

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.


Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.

Covered Topics