iAs the Senate approaches the end of its debate on the National Defense Authorization Act for Fiscal Year 2019, provisions of the bill regarding access to and review of information technology code deserve close attention. These sections, if enacted, would significantly impact Department of Defense contractors and also would affect matters associated with investments subject to review by U.S. national security agencies.
As drafted, the provisions could expose current and prospective contractors to intrusive scrutiny and significant risks. They lack clarity on key definitions, leaving the precise scope of those risks unclear. We summarize major issues and concerns below. We expect these provisions to receive scrutiny during the House-Senate conference on the NDAA over the summer.
Synopsis of the Proposed Legislation
Three sections of the Senate’s version of the NDAA, which passed the Senate Armed Services Committee in May, would establish new rules designed to mitigate “risks posed by providers of information technology with obligations to foreign governments.” Those risks involve the access that foreign governments may have to code in products or services that are offered to the Department of Defense. The provisions also impose new disclosure requirements on the efforts of a prospective vendor to obtain a license under the Export Administration Regulations (“EAR”) or the International Traffic in Arms Regulation (“ITAR”).
The pending legislation would require proactive disclosure of those matters, and would impose an ongoing duty to supplement those disclosures during the period of performance on the contract. The Secretary of Defense would be authorized to assess and mitigate any resulting national security risks through contractual provisions or other performance requirements.
The bill directs the Secretary to create a “prioritized list of countries of concern regarding cybersecurity,” using factors designed to assess those countries’ capabilities, intentions, and past practice with respect to U.S. and “coalition forces.” It would also require the Secretary to develop a “third-party testing standard” for commercially available off-the-shelf (“COTS”) items “to use when dealing with foreign governments.” Finally, the bill would require the Secretary to consolidate the disclosures in a master registry and make the information available to “any agency conducting a procurement pursuant to the Federal Acquisition Regulations or the Defense Federal Acquisition Regulations.”
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 agreementfor 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.
