So we move into section four and we're going to discuss delivery, operations and maintenance. We're going to talk about chain of custody, publishing and dissemination controls, a System of Systems integration, the authenticity and integrity, deployment and sustaining engineering, and vulnerability management. So when we talk about operation and maintenance, what we're doing is we're talking about something that is considered under the single title of sustainment or sustaining engineering. These activities take the delivered product, they put it into the target environment to perform its function and then maintain it in the correct and operable condition, placing it under management and configuration control.

Now, given that this portion of the software lifecycle is generally regarded as rather outside of the supply chain proper, it is considered to be a continuing part of it with respect to product updates and patches. Part of this continuation is when the contractor is bound to provide guidance and support to end users for the use and operation of the supplied product. Now, strictly speaking, upgrading too is somewhat outside the strictly defined supply chain. However, this activity again becomes part of the process once the customer makes a decision to upgrade the supplied software and then chooses to reengage with the contractor who provided it to accomplish the conversion.

Part of this is going to be the issue of chain of custody. This is the notion through which configuration management throughout the supply chain is established and enforced. As software code or components move from supplier to supplier in its software supply chain, it's extremely important to make sure that this chain of custody is controlled until the software reaches the final user or acquirer of the software. Controlling the chain of custody of the software means that each change to the software and handoff is authorized, transparent and verifiable.

Authorized means that the modification to the software is requested and permission to change the software has been given, preferably in writing. Transparency is that the requester of the change and the entity that is making the change knows about the change being made. In other words, no hidden or unknown changes are being made to the software. And then verifiable refers to the fact that the changes made to the software and that it can be attested to against the request for the change and that no unauthorized or unrequested changes were made as part of this.

In other words, what was requested to be done is what and only what has been done. Configuration management itself can be seen as a process level at the micro level, meaning that it's to ensure consistency and integrity through all levels of the specific elements of a component. Change management, on the other hand, is performed by the acquirer at a much higher level or macro level that governing all links in the chain while each one is performing configuration management at their specific level or the micro level. When it comes to publishing and dissemination controls, what we're talking about here is it's now going to be published, disseminated to other members of the supply chain. This also means it has now been published to the customer at the far end.

Now, out of these, the most visible is going to be the software license or EULA as we call it. This is and provides a certification of the legitimacy of the copy of the product, meaning that it is a legally provided, legally obtained one. It is a statement of usage rights and limitations for the users, and it declares that the software is given to them by this license in an as-is condition, meaning there's full disclosure that we don't intend for you to accept this as a perfectly done, absolutely flaw-free program. But it does mean that it's sufficiently blessed by its maker.

The ultimate intention here is to install trust in the recipient that the copy is authentic, that the statement of ownership is genuine, that their rights of usage are clear and that the copy itself is unaltered. So what we have here is actually a System of Systems. This is a product that is the synergistic amalgam of the various components or subsystems and they've been brought together in a way that hopefully makes them function smoothly. The System of Systems, as it's known, is not a specific supply chain element. It's more of a concept. And the activities and individual elements are themselves concerned with supply chain issues as collaborative events or the products of it.

Now, full composition and interoperability are the main goals of the System of Systems concept. Supply chain brings the parts together and system engineering integrates them to attain the required synergies. A critical element will be the integrity and authenticity of the program elements provided. The standards for these qualities should be set early on in the project cycle and they should be applied rigorously and strictly throughout unless indications are that something about them should be altered, and that, if necessary, should be done through a widely understood and accepted process with, of course, transparency.

The authentication of the modules moving through to ensure that they are correct configurations, that they are correct and they're coming in the proper version from the correct sources. There should not ever be any undisclosed changes that have been made that may possibly have corrupted the anticipated integrity of the received modules. The testing that has been done at each level should determine and verify that this has, in fact, been the case. Because the trustworthiness of these aspects are direct results of having instituted and enforced appropriate controls from project inception with the potential additions that are periodically re-verified in the sources and cryptographic code signing.

Following will be the activities of deployment and sustaining engineering. These activities are extensions of the supply chain that focus primarily on the configuration management and the sustaining engineering of the program over its lifecycle and they deal with component organization, various functionalities, and changes to this. The goal here is to manage change in order to assure protection of the integrity of the program and ensure that it follows the product roadmap throughout its lifecycle. This, of course, will require a plan and a roadmap to assure that this alignment stays organized and on mission objectives.

The process enables the evaluation of proposed changes in terms of functional necessity and performance. And this, of course, will include security and compliance as well. In the course of performing these functions, other areas will because impacted, such as baselines, repositories, and specification conformance. Part of this will be vulnerability management. This activity plays a key part in both configuration management and maintaining the security and integrity of the program objects.

Now, in simplest terms, this function identifies and enables the repair flaws in the supply chain element, such as code modules, but it also serves to affect the actual performance of patching and updating. Vulnerability management will require a well-formed and disciplined process to conduct the activity on a routine basis so that exposures are kept to a minimum and exploits receive counter activity in a timely manner to keep Windows vulnerability and exploitability for the entity to an absolute minimum duration. This ensures that this activity is carefully tracked. Each update that is performed updates the baseline as well and must be captured as part of its history. All outcomes must likewise be recorded in case reversal of future complications should require action. Ad-hoc performance, though on occasional needful, needs to follow the same process despite its urgency to patch a serious flaw.