Definition Issues and Coverage Concerns
The scope of the legislation is broad, and coverage is not clearly defined. The disclosure requirements apply to any “product, service, or system relating to information or operational technology, cybersecurity, an industrial control system, a weapons system, or computer antivirus” offered to the Department.
One subset of disclosure obligations applies to “custom-developed” products, systems, or services. Any person offering such products, services, or systems must disclose “[w]hether the person has allowed a foreign government to review or access the code of a product, system, or service custom-developed for the Department, or is under any obligation to allow a foreign person or government to review or access the code of a product, system, or service custom-developed for the Department as a condition of entering into an agreement for sale or other transaction with a foreign government or with a foreign person on behalf of such a government.”
The bolded terms all raise questions. The bill does not define “custom-developed,” which is not a recognized term of art in procurement law. A broad interpretation could, for instance, sweep in a commercial item where the manufacturer made only a minor modification for the Department. Presumably, if a product was custom-developed for the Department, any necessary restrictions on sharing the source code would have been imposed contractually on the manufacturer. If such a limitation was not imposed at the time of the contract, it is not clear that the government should impose new restrictions post-agreement.
The concept of “review or access” is also open to interpretation. For example, if a company keeps full custody of the code but allows a customer, including a foreign government, to have an authorized representative inspect the code under the company’s control, it is not clear that such an arrangement would constitute a materially risky “review,” let alone “access.” That structure would not involve a company relinquishing control of the code, and it might not be sufficient to allow the customer/government to identify vulnerabilities. Furthermore, a “review” that entails only an analysis of results of testing conducted by the company or an agreed-upon third party would be even farther removed from the risk, but could still be considered a “review” by a foreign government under the text of the bill. It is unclear if the only code at issue is the code associated with a government-specific modification, or also the underlying commercial item product (i.e., background vs. foreground intellectual property).
The term “foreign person” also invites questions about scope. It could include employees of companies that create the product, if those employees are citizens of another country. It could also include resident aliens, or dual citizens. The structure of the bill implies that the term “foreign” would be interpreted broadly; unlike other sections of the bill that focus on the prioritized list of “countries of concern,” this section has no such limitation.
With respect to the “countries of concern,” a broader disclosure obligation applies to any goods or services, not just those “custom-developed” for the Department. Under the terms of that section of the bill, offerors must disclose whether they have allowed a listed government to access source code. While the language addressing “access or review” of source code is limited to high-risk foreign governments identified by the prioritized list, a broader prohibition applies as to products where the seller is “under any obligation” to allow any foreign person or government to review or access the product or service as a condition to entering an agreement with a foreign government or person on behalf of such a government. “Obligation” is not defined and could be interpreted more broadly than just contractual obligations. Whether contractual or not, in some instances, software products need to be modified to interface with a customer’s information systems. It is unclear whether access just to the modifications to the code that may be necessary to accomplish this interface with a foreign commercial customer’s systems would trigger a disclosure requirement.
Consequently, those disclosure obligations apply to any product, service, or system, and to a broad universe of “foreign” interests.
Opacity of Procedures to Mitigate Risks
Definitional issues also arise in the context of the mitigation provisions. For instance, the language allows the Secretary to determine whether the disclosure reveals “a risk to the national security infrastructure or data of the United States, or any national security system under the control of the Department” and then “take such measures as the Secretary considers appropriate to mitigate such risks.” Neither legislative text nor industry-wide common understanding explain what comprises “national security infrastructure” or “data of the United States.” The latter term could mean proprietary data of the U.S. government, or any data residing in the United States.
The legislation leaves practical implementation questions unaddressed. There is no timeframe or clear trigger for initial disclosure, nor discussion of procedures for mitigation. If the disclosure is made after contract award, the legislation could arguably give the government grounds for termination.
Other key operational questions include the following:
If mitigation is to be imposed pre-award in a competitive procurement, can the Secretary allow one offeror to add such mitigation to its proposal without opening discussions with all offerors?
Would that mitigation be reported in the “registry” along with the other disclosure elements?
Could mitigation include outright exclusion? If so, what is the process for aggrieved offerors to contest that exclusion, if not the normal bid protest channels?
Once a product is identified as a risk, is it excluded from future Department of Defense procurements, or is this determination done on a procurement-by-procurement basis? What procedural safeguards would be established to addressed this limit on competition?
The pending legislation also fails to identify which agency within the Department would develop and enforce these conditions. It could be left to the discretion of each service or component, or a central agency could manage the process on behalf of the entire Department. In that case, likely candidates would be the Defense Security Service, the Chief Information Officer, or the National Security Agency.
Export Control and Third-Party Testing Questions
The lack of precision raises other questions in the provisions on export controls and the standards to be used with third-party testing. The bill appears to provide the Department with nearly unfettered discretion to prohibit exports of certain technology, products, or services beyond any controls imposed by the ITAR. Even the issue of what is covered is left to the discretion of the Department. The consequences of the resulting EAR/ITAR-related disclosures are also unclear. Offerors are required to disclose whether they hold or have applied for any licenses, and that data will presumably be considered by the Secretary. However, there is no indication as to how the Department will utilize that information to determine whether it will use the product, service, or system.
The third-party testing standard also raises a number of operational questions, and the accompanying Committee Report language offers few indicators of congressional intent. If the purpose is to direct the Department to develop the standard that COTS companies can use to deal with foreign governments, it is an open question whether the U.S. government would then apply that standard to its own testing. The provisions also offer no resolution if a disconnect arises between U.S. government requirements the standard developed by the Department pursuant to this third-party testing provision.