We're always going to have to assess the security impact of acquired software. Now, when we think of this, what we're really considering is the level of confidence that the software is free of vulnerabilities, whether they may be intentionally designed in, or left in inadvertently by the developing organization due to insufficient or improper testing.

We have to consider that these are present and develop testing regimes and requirements so that they can be tested for, and when found, removed or amended. It's going to have to be conducted throughout its life cycle to make sure that the software continues to function as intended. This is the supply chain management requirement that we have and in doing so we must be sure that we understand exactly what is going on in the supply chain, so that we can make sure that the requirements are both precise, correct, and communicated from the earliest phases of the acquisition process through the end and its deployment.

We must regard testing as a mandatory element in this process as the proof of the assurance that we need so that we know that it has been tested for, and that the things that can be found, that are vulnerabilities or gaps or failed functions, that all of those have been examined and not found wanting. We have to remember every step along the way that risk flows along the lines of the signatories to the contract, that it flows from one party to the other based on who has signed and who is getting what deliverable from which party. We also have to realize that it is a shared responsibility to ensure that what is being designed and built will meet that, and that it is of the best assurance levels that we can establish through testing.

So we must engage in risk-based management of our supply chain. We must think about it in terms of what it is, how it's constructed and the various characteristics of the parties that make it up. We have to be sure that we have resilient and integrated security as it flows up and down the lines of responsibility in the supply chain. We have to be sure that we understand what this contributes to the cost of ownership of the supply chain itself and the products being developed and delivered. What is the positive or negative contribution that outsourcing will make to it? And how do we decide to go with it or to retain it in-house and not outsource?

When we look at the various members, the processes and the flows within the supply chain, we need to develop a sense of the integrated security assessments that will be needed to involve multiple parties so that we can see all of the different steps in the supply chain and examine them for vulnerabilities, flaws, gaps, single points of failure and other things that will disrupt it. And then we have to put in place proper monitoring and management.

Now, when it comes to monitoring, these of course are the routine tests that we do to make sure that what is being done is what is being represented as being done and the deliverables represent that the requirements are in fact being met as specified. We can do this through onsite assessments, document exchanges, and reviews. We can make use of independent third-party assessments, such as the SSAE-18 and its attendant SOC reports. We can do it through high trust. We can do it through ISO standards, the ISO 27001, for example.

All of these are ways to give us increased assurance and the independent examination of any party along our supply chain. But those two are only the beginning. They tell us about things we no longer have to be concerned with, but without interactive and proactive management of the supply chain, a lot of other things can go wrong and we need to be prepared to act if that is the case.