Attorneys focused on government contracts work are thoroughly familiar with terms like “Kaspersky,” “Huawei,” and “Solarwinds.” They generally possess a working understanding of, if not an expertise in, the various cybersecurity regulations imposed on contractors selling software for use in environments with exposure to sensitive information. And they are aware of new rules that focus on cybersecurity issues in their clients’ supply chains. Where we, the authors, perceive a gap is in understanding the practical ways new and developing statutes, regulations, and agency supply chain risk management practices can lead to contractor exclusion and what contractors can do to best position themselves for potential government investigation and enforcement actions.
In this article, we first summarize recent legal developments aimed at addressing cybersecurity vulnerabilities in the IT supply chain, primarily focusing on software. Next, we examine the actions agencies may take with regard to supply chain–related cybersecurity concerns and how those actions can result in contractor and product exclusions. Finally, we offer suggestions and strategies for contractors faced with challenges in complying with these rules and in addressing claims, investigations, and customer concerns regarding software supply chain risk.
In this section, we summarize key legal authorities that impose supply chain requirements affecting software vendors. However, we first discuss some basic concepts. Supply Chain Risk Management (SCRM) is the process of identifying, assessing, and subsequently mitigating any substantial risks associated with the global supply chain. In this article, we focus on rules related to the global supply chain involved in procurement of products/services relating to information and communications technology (ICT), which includes software.
The SCRM landscape is currently fragmented and chaotic. There are more than 30 different SCRM initiatives ongoing across the U.S. government, which makes industry compliance both time-consuming and confusing. Historically, the Department of Homeland Security (DHS) has taken the lead on these supply chain–related issues. The Cybersecurity and Infrastructure Security Agency Act of 2018 established the Cybersecurity and Infrastructure Security Agency (CISA) as a component of DHS. This makes it challenging for a government contractor to prepare for, let alone prevent, specific adverse outcomes that may occur if an agency determines that there is an actual or potential supply chain risk associated with that contractor. In this article, we hope to provide clarity regarding the main compliance concerns for information technology contractors, with an emphasis on software vendors.
The U.S. Department of Homeland Security (DHS) and the National Institute of Standards and Technology (NIST) feature prominently in the discussions below. Historically, DHS has played a leading role with respect to cybersecurity in the supply chain. CISA’s mandate is to lead the efforts on managing and reducing risk to the United States’ cyber and physical infrastructure. In December 2018, DHS, operating through CISA, announced the formation of a new public-private task force designed to focus on supply chain threats specific to ICT solutions (the ICT SCRM Task Force). This ICT SCRM Task Force works with industry and government agencies to assess national security risks stemming from vulnerabilities, including supply chain threats, in ICT hardware, software, and services. Similarly, NIST, a nonregulatory agency of the Department of Commerce, has implemented a cybersecurity risk management program to help organizations manage the increasing risk of supply chain attacks. In connection with this program, NIST has recently announced an additional public-private task force aimed at helping organizations build, evaluate, and assess the cybersecurity of products and services in their supply chains.
In December 2018, the president signed into law the SECURE Technology Act (the “Act”). Title II of the Act, called the Federal Acquisition Supply Chain Act of 2018, addressed supply chain concerns and created the Federal Acquisition Security Council (FASC). The creation of FASC brings structure and a coordinated effort to centralize the government’s SCRM initiatives. FASC includes representatives from several key agencies, including DHS, the Department of Defense (DoD), the Office of Management and Budget, the General Services Administration (GSA), the Office of the Director of National Intelligence, the Department of Justice, and the Department of Commerce. FASC focuses on governmentwide approaches to supply chain issues, rather than agency-specific measures. The Act empowers the government to exclude contractors (referred to as “sources” in the Act) and covered articles (i.e., products, including software) from a single procurement or a class of procurements over ICT supply chain concerns and directs FASC to establish criteria and procedures for the implementation of exclusion and removal orders.
FASC released a final rule, effective September 27, 2021 (the Final Rule), which outlines the exclusion and removal process. The Final Rule also established the role of FASC’s information sharing agency and assigns that responsibility to CISA. As the information sharing agency, CISA is responsible. for managing the receipt and sharing of information on behalf of FASC. The Final Rule contains three subparts. Subpart A generally explains the scope of the rules and establishes the membership of FASC. Subpart B establishes the role of the ISA and sets forth information-sharing criteria. Lastly, Subpart C of the Final Rule outlines the procedures by which FASC will evaluate supply chain risk from sources and covered articles and, if appropriate, recommend issuance of orders requiring removal of covered articles (removal orders) from current ICT systems and orders excluding sources or covered articles from future procurements (exclusion orders).
Under both the Act and the Final Rule, FASC is granted broad authority to request any information from executive agencies that FASC deems necessary for FASC to carry out its functions. As part of FASC’s efforts to coordinate information sharing, the Act directs FASC to coordinate its efforts with any relevant councils and interagency committees, including the Federal Acquisition Regulatory Council. As such, government contractors should expect to see coordinated efforts to update the Federal Acquisition Regulation as FASC makes formal recommendations on supply chain risk mitigation requirements. The information-sharing procedures set forth in the Final Rule require agencies to provide information to FASC in certain situations, including (i) when FASC requests information relating to a particular “source,” a “covered article,” or a” covered procurement,” and (ii) when an executive agency determines there is a reasonable basis to conclude that a substantial supply chain risk exists in connection with a source or covered article. FASC is empowered to then disclose its recommendations and any supply chain risk information relevant to those recommendations to any federal or non-federal entities if FASC determines that sharing such information “may facilitate identification or mitigation of supply chain risk.” However, there is a limitation—FASC may not disclose the information or recommendation to non-federal entities unless an exclusion or removal order has been issued and the named source has been notified. Based on these regulations, it is likely that FASC could share supply chain risk information to other federal entities without notifying the source at issue—thereby depriving that source of a chance to combat or correct that supply chain risk assessment prior to the assessment’s dissemination inside the government. Furthermore, FASC declined to adopt any measures to ensure that information submitted to the FASC is accurate, which would disincentivize companies from submitting false information regarding their competitors. FASC noted instead that the Final Rule requires FASC to conduct “appropriate due diligence” in evaluating the supply chain risk and stated that as a result, it already has “ample means to assess the reliability of information received from the private sector or elsewhere.”
As mentioned above, CISA will serve as the ISA. The ISA standardizes the procedures for submission, evaluation, and subsequent dissemination of supply chain information, and additionally facilitates the operations of a SCRM Task Force under FASC (the FASC Task Force). The FASC Task Force comprises technical experts who are tasked with assisting FASC in implementing FASC’s information-sharing, risk-analysis, and risk-assessment functions. These technical expert positions are expected to be staffed by individuals from across federal agencies. The Task Force is required to release further rules governing the submission of information to FASC, including any necessary requirements for information handling, protection, and classification, as well as processes and procedures governing the sharing of information submitted to FASC.
Subpart C of the Final Rule should concern every government contractor that works in the ICT space. This subpart identifies the specific procedures that govern exclusion and removal orders. FASC is permitted to commence an evaluation of a source or covered article based on (i) a referral from any member of FASC, (ii) a written request from the head of an executive agency, or (iii) information submitted to FASC by any federal or non-federal entity that FASC deems credible. The Final Rule provides a nonexhaustive list of factors that FASC may utilize in its evaluation of an article, including (i) the article’s access to data/information logs; (ii) general functionality of the article; (iii) user environment in which the article is installed; (iv) security and integrity of the article, and any associated supply chains, including any embedded, integrated, and bundled software; (v) foreign ownership or control over the article; (vi) national security implications regarding use of the covered article; (vii) vulnerabilities or threats of federal systems and potential for exploitability; (viii) confidence in information available regarding proceeding with the article or use of alterative article (if possible); and (xi) transmission of data by a covered article to a country outside of the United States.
When evaluating a source(i.e., a contractor), FASC will evaluate based on the same nonexhaustive list of potentially relevant factors, including (i) the source’s access to data and information system privileges, (ii) the ability of the source to produce and deliver covered articles as expected, (iii) foreign ownership or control over the source or other ties to foreign governments, (iv) national security implications regarding use of the source, (v) vulnerabilities or threats of federal systems and potential for exploitability, (vi) capacity of the source or the U.S. government to mitigate risks, and (vii) credibility of and confidence in information used for assessment of risk associated with proceeding with the source, using an alternative source, or enacting mitigation efforts. FASC is also permitted to evaluate any other information FASC deems appropriate. With respect to the evaluation of foreign ownership and control, there are several subfactors FASC may evaluate: (i) whether the country has been identified by the government as a foreign adversary or country of concern; (ii) whether the source or its suppliers have “headquarters, research, development, manufacturing, testing, packaging, distribution, or service facilities or other operations in a foreign country”; (iii) professional and personal ties between the source (including officers, directors, employees, consultants, or contractors) and any foreign government; and (iv) applicable laws/regulations of any foreign country in which the source has facilities or operations. However, no exclusion or removal orders may be issued based solely on foreign ownership or control.
In the event FASC identifies an article or source that FASC determines should be excluded or removed, FASC will make a formal recommendation to the Secretary of Homeland Security, Secretary of Defense, and/or Director of National Intelligence. The Secretary of Homeland Security issues any orders relating to civilian agencies, while the Director of National Intelligence issues any orders relating to the intelligence agencies and sensitive compartmented information systems, and the Secretary of Defense issues any orders relating to the DoD and national security systems. The recommendation must include (i) the identity of the source or article; (ii) the scope of the recommendation, including whether the order should apply to all executive agencies or a subset of executive agencies; (iii) a summary of the assessment, including significant conflicting or contrary information, if any; (iv) a summary of the basis for the recommendation, including a discussion of less intrusive measures that were considered and why such measures were not reasonably available to reduce supply chain risk; (v) a description of the actions necessary to implement the recommended exclusion or removal order; and (vi) “[w]here practicable, in the FASC’s sole and unreviewable discretion, a description of the mitigation steps that could be taken by the source that may result in the FASC’s rescission of the recommendation.” Note that while the recommendation must include a summary of any less intrusive measures that were considered but were deemed insufficient, it is still possible that FASC could provide specific mitigation steps a contractor could undertake in order to escape removal or exclusion. However, it is not mandatory that FASC provide these mitigation steps, and in the event FASC does offer a mitigation alternative, the contractor will not be made aware of this until after the recommendation is made by FASC.
After FASC submits a formal recommendation, it is required to provide notice to the source named in the recommendation. The notice must contain information regarding the criteria on which FASC relied, the information that forms the basis for the recommendation, the procedures governing the review and issuance of an exclusion or removal order, and, if applicable, any mitigation steps that could be taken by the source that would result in FASC rescinding the recommendation. The source may submit information in response, including any arguments in opposition to the recommendation, within 30 days following receipt of the notice. If the source submits a response, the ISA must convey the response to FASC and to the Secretary of Homeland Security, the Secretary of Defense, and the Director of National Intelligence. Upon review of the source’s response, FASC may rescind the recommendation if it determines that the source has undertaken sufficient mitigation to reduce supply chain risk to an acceptable level, or if FASC determines that other grounds justify rescission. In the event that FASC rescinds its recommendation, the ISA will communicate that decision to the source.
After the Secretary of Homeland Security, the Secretary of Defense, and/or the Director of National Intelligence have assessed the information and recommendation from FASC, the relevant agencies will determine whether to issue an exclusion or removal order. In the event an agency issues an exclusion or removal order, the agency must notify the source affected by the order. These orders are subject to judicial review pursuant to 41 U.S.C. § 1327(b). The U.S. Court of Appeals for the District of Columbia Circuit has exclusive jurisdiction over any removal or exclusion orders. Within 60 days following notice of an exclusion or removal order, a source may file a petition for judicial review claiming that such removal or exclusion order is unlawful. The court may overturn an exclusion or removal order only if it finds the order to be (i) arbitrary, capricious, an abuse of discretion, or otherwise not in accordance with law; (ii) contrary to constitutional right, power, privilege, or immunity; (iii) in excess of statutory jurisdiction, authority, or limitation, or short of statutory right; (iv) lacking substantial support in the administrative record taken as a whole or in classified information submitted to the court; or (v) not in accord with procedures required by law. The arbitrary and capricious standard is a high bar. Review under this standard is “narrow and a court is not to substitute its judgment for that of the agency.” To satisfy this review standard, “the agency must have considered relevant data and articulated an explanation establishing a rational connection between the facts found and the choice made.” Given the standard of review, as long as the agency has articulated a basis for the exclusion or removal order and followed the mandated procedures in issuing the order, it would be quite difficult for a contractor to successfully overturn an order.
Although the Final Rule provides much-needed clarity surrounding the exclusion/removal process, the reality is that the process provides little time for a contractor to combat any erroneous conclusions made by FASC. A contractor is not notified of any negative supply chain evaluations—or even that an evaluation has occurred—until after FASC has submitted a formal recommendation to the agencies. At that point, it is a fire drill for the contractor. The contractor must evaluate the information provided by FASC and provide any counterarguments and information within 30 days of receipt of FASC notice. There is no requirement that FASC engage with the contractor to verify any information, or to provide any clarity, during FASC’s evaluation process. And with an “arbitrary and capricious” judicial standard of review, the contractor certainly should not be hanging its hat on overturning any exclusion or removal order in the context of the judicial review process. Furthermore, many of the evaluation factors FASC utilizes are dependent on information only the procuring agency would have (e.g., user environment in which the article is installed, vulnerabilities or threats of federal systems and potential for exploitability, capacity of the source or of the U.S. government to mitigate risks, etc.). It should also be noted that FASC is permitted to disseminate information to federal agencies prior to the issuance of an exclusion or removal order if FASC determines that sharing such information “may facilitate identification or mitigation of supply chain risk.” There is no requirement that FASC seek clarification or information from the contractor prior to such dissemination—therefore, the contractor may not even be aware that FASC has provided negative information regarding that contractor to other agencies.
There is also a supply chain risk statute that applies to DoD agencies, 10 U.S.C. § 3252 (Section 3252). Enacted in 2018, Section 3252 empowers DoD agencies to exclude contractors from information technology procurements based on supply chain risk concerns and, to the possible alarm of any contractor so excluded, “limit, notwithstanding any other provision of law, in whole or in part, the disclosure of information relating to the basis for carrying out a covered procurement action.” An exclusion may be based on broadly described contractor shortcomings: failure to qualify under criteria established for the purpose of reducing supply chain risk in a DoD acquisition, for instance, or failure to achieve an acceptable rating on a supply chain risk evaluation factor in a solicitation. The statute also allows the DoD to exclude subcontractors without tying that determination to criteria developed for a specific procurement or solicitation.
Section 3252 describes the required predicate for any exclusion in a way that is broad and provides leeway for agencies to exercise discretion, though agencies that wish to exclude a contractor must get information and approvals from other DoD authorities. DoD agencies may exclude a contractor or subcontractor if they determine the exclusion “is necessary to protect national security by reducing supply chain risk.” “‘Supply chain risk’ means the risk that an adversary may sabotage, maliciously introduce unwanted function, or otherwise subvert the design, integrity, manufacturing, production, distribution, installation, operation, or maintenance of a covered system so as to surveil, deny, disrupt, or otherwise degrade the function, use, or operation of such system.” Section 3252 does not articulate any burden of proof for an exclusion determination, nor does it describe or limit the type of information DoD may rely on when deciding to exclude a contractor. However, the statute does stipulate that exclusions must be based on risk assessments prepared by the Under Secretary of Defense for Intelligence and Security and that the Under Secretary of Defense for Acquisition and Sustainment must concur with the decision to exclude. Section 3252 vests authority to make exclusion determinations in DoD agency heads, and that authority may not be delegated to officials at a level lower than the service acquisition executive for the relevant agency.
A notable aspect of Section 3252 is that an exclusion decision is not subject to review in a bid protest action. The Department of Defense Federal Acquisition Regulation Supplement (DFARS) provisions implementing Section 3252 clarify that bid protest review is unavailable before both the U.S. Government Accountability Office (GAO) and federal courts. Therefore, if a contractor loses a competition based on a supply chain risk assessment by the agency conducting the procurement, the contractor lacks the ability to leverage bid protest procedures to stay an award even if the contractor can identify errors the agency made in its supply chain assessment.
The use of Executive Orders to strengthen the government’s ability to combat supply chain–related issues has increased in recent years. President Biden issued Executive Order 14028, Executive Order on Improving the Nation’s Cybersecurity, on May 12, 2021 (Executive Order). This Executive Order generally requires agencies to focus on implementing and/or enhancing cybersecurity and software supply chain integrity measures. The Executive Order imposes new cyber incident reporting requirements on certain providers, establishes baseline security standards for the development of software sold to the government, and directs agencies to improve the government’s ability to detect cyberattacks on federal networks by enacting a government-wide endpoint detection and response system.
Among the cybersecurity initiatives it announced, the Executive Order includes a section on Enhancing Software Supply Chain Security. The Executive Order directs NIST to solicit input from the private sector and government agencies to develop new standards, tools, and best practices to enhance supply chain security, focusing on “critical software.” Prior to the issuance of the Executive Order, NIST had already focused on assisting organizations in securing the supply chain—the NIST Cybersecurity Supply Chain Risk Management (C-SCRM) program helps organizations manage the various risks associated with the supply chain and encourages organizations to adopt best practices in the SCRM area. In April 2015, NIST published NIST Publication 800-161, “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.” The second draft of Revision 1 of this publication was released for comment in October of 2021 (following a first draft released in April) and is expected to be finalized this year. The goal of this revised publication is to tailor recommendations to the regulations promulgated by FASC and to the Executive Order requirements. Contractors should expect to see multilevel, enterprise-wide SCRM mandates in the final publication.
The Executive Order required NIST to do a number of things, including (i) work with appropriate agencies to define “critical software,” (ii) publish guidelines for security measures that are required for use of critical software, (iii) recommend minimum testing standards for vendors and developers of software code, and (iv) publish guidance on enhancing software supply chain security. NIST accordingly published its definition of “critical software,” which includes any software that has (or has a direct software dependency on) a component with one or more of the following attributes: (i) is designed to run with elevated privilege or manage privileges, (ii) has direct or privileged access to networking or computing resources, (iii) is designed to control access to data or operational technology, (iv) performs a function critical to trust, or (v) operates outside of normal trust boundaries with privileged access. The Critical Software Security Measures published by NIST attempt to mitigate unauthorized access to the platforms and propose encryption requirements to protect data in the platform. These measures further require the implementation of a patch management system to rapidly deploy patches for known vulnerabilities. Contractors should expect agencies to rely heavily on the private sector to ensure that any critical software employed will meet these requirements. Thus, although these measures are not mandatory for the private sector at this time, all agencies that are running any software that meets the definition of critical software will be required to conform to these newly published security measures. These measures will therefore trickle down to contractors, as agencies will impose these requirements on any vendors or developers of critical software through either solicitations or modifications to current contracts.
Also as directed by the Executive Order, NIST has issued a publication entitled “Guidelines on Minimum Standards for Developer Verification of Software,” which is applicable to all software vendors. This publication outlines the recommended minimum testing/verification procedures for software development, not just “critical software.” In the document, NIST, in collaboration with the National Security Administration, identified 11 specific recommendations for software verification and development in order to ensure that software is developed without vulnerabilities, whether such vulnerabilities are intentionally designed into the software or accidentally inserted during the development life cycle. The recommendations are as follows:
These standards comport with NIST Publication 8397, which was issued in October 2021, and recommends developers implement a variety of secure development practices, including threat modeling testing, static code scanning, code-based structural test cases, and other tools to verify the security of the code. Although it is not mandatory to follow these guidelines, procuring agencies may enforce these standards through the text of future solicitations and contracts.
With respect to SCRM, section 4(e) of the Executive Order directs the Secretary of Commerce, acting through NIST, to issue guidance identifying practices that will enhance the security of the software supply chain. Section 4(e) sets forth 10 specific actions that software producers should take to help secure the supply chain.
Prior to the issuance of the Executive Order, NIST published the initial Secure Software Development Framework (SSDF), which set forth secure software development practices to be integrated into each software development lifecycle implementation. Many of the specific practices set forth in section 4(e) of the Executive Order were already addressed in the SSDF (SP 800-218). Following the issuance of the Executive Order, NIST revised the SSDF to comply with the requirements set forth in the Executive Order. The updated SSDF recommends that when a federal agency acquires software or a product containing software, the agency should require attestation from the software producer that the software’s development complies with government-specified secure software development practices. Contractors should therefore become intimately familiar with the secure software development practices set forth in the updated SSDF, as they may be required to attest to compliance with these standards in order to sell any software products to the federal government. These practices require, among other things, using separate build environments; auditing trust relationships; establishing multifactor, risk-based authentication and conditional access across the enterprise; minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software; and employing encryption for data. NIST announced that it would continue to refine these standards and procedures and would publish additional guidance by May 6, 2022.
With a plethora of regulations and agency-specific guidance relating to ICT and supply chain mitigation coming down the pipeline, contractors should expect rapid-fire changes to supply chain verification requirements as well as software security requirements. The Executive Order clearly identified several areas of focus, including (i) implementing cybersecurity requirements across agencies, (ii) continuing to shift the federal government to cloud-based technology, and (iii) creating a uniform response to cybersecurity incidents.
Moving forward, contractors should expect zero-trust security requirements to be included in NIST requirements (NIST 800-53 (FedRAMP) and NIST 800-171 (CMMC)). Zero-trust security requirements effectively require organizations to take a position that no user or third party can be trusted. All users attempting to access an organization’s network, systems, applications, or data must be verified, and every user and device should be treated as a potential threat to the system. Zero-trust measures aid in preventing supply chain attacks in multiple ways. Most software supply chain attacks infiltrate systems through third-party providers with poor security practices. By implementing zero-trust measures, an organization can limit a third party’s ability to access its network. However, this requires implementing advanced security controls, such as multifactor authentication, and limiting privileges for third parties. Critically for contractors, zero-trust requires a thorough assessment of a contractor’s security protocols during the software development process, to ensure no attacks infiltrated the software’s source code, update mechanisms, or build processes. This will require extensive insight by the procuring agencies into the contractor’s development process and associated security measures. CISA and the Office of Management and Budget are working on meeting the goals set forth in the Federal Zero Trust Strategy, a strategy released by the Office of Management and Budget on January 26, 2022. This strategy, which is in line with Executive Order 14,028, aligns with the notion that no actor, system, network, or service operating outside or inside the security perimeter is to be trusted. This shift will move the government towards implementing identity and access controls, ensuring that agency systems are isolated from each other and that federal security teams work across functions to develop security rules that will automatically detect and block any unauthorized access. As this strategy is implemented over time, all federal agencies will be expected to comply with CISA’s Zero Trust Maturity Model, which complements OMB’s strategy and is designed to provide agencies with a clear roadmap and resources to achieve a zero trust environment.
Contractors should expect to see contract modifications that implement these attestation requirements surrounding secure development practices. It will no longer be “best practices” to comply with NIST’s SSDF, but rather such compliance will be the floor in order to do business with the government. In fact, GSA has expressly stated that contractors should expect to see modifications to standard contract language to reflect these updated NIST and CISA requirements and that any contractors unable to accept these modifications will not be permitted to sell to the government. Contractors should additionally expect more questions from agencies regarding the contractor’s supply chain risk management practices.
Contractors should also expect to see more government-wide mandates, as opposed to ad hoc agency initiatives. In fact, CISA recently issued its first ever government-wide mandate to remediate known software and hardware vulnerabilities. The CISA directive applies to all software on federal information systems. In its directive, CISA implemented a public catalog of known vulnerabilities and mandated that agencies establish a remediation process within 60 days of issuance of the directive. This government-wide mandate will undoubtedly affect the private sector, as agencies turn to software vendors or developers for assistance in remediation efforts.
Contractors should also expect to see mandatory cyber incident reporting in the near future. It is estimated that around 85% of the United States’ nondefense critical infrastructure is owned by the private sector. Although efforts to pass a mandatory cyber incident reporting bill failed in 2021, CISA continues to push such legislation in an effort to ensure that CISA and other agencies receive timely information regarding any vulnerabilities or exploitations.
Every federal software vendor should implement a supply chain risk management program. With highly publicized cases of cyber hacks and other exploitations, SCRM has unified government agencies, and there is a clear, coordinated effort to mitigate any known vulnerabilities and prevent future attacks. Contractors should focus on compliance with several important initiatives, including NIST SSDF, NIST Publication 800-161 (which is expected to be finalized in 2022), and any publications by the CISA SCRM Task Force. At a minimum, contractors need to be able to make the certification required under the NIST SSFD regarding compliance with secure development practices, in order to protect their federal procurement business.
When faced with the threat of exclusion over supply chain risk issues, key questions for a contractor include “What standards govern the types of information agencies may consider and the rigor they must apply in assessing supply chain risk?” and “How can I hold agencies to those standards?” The following discussion attempts to answer these questions in the context of specific proceedings where such questions may be addressed.
The authors’ research on bid protests that involved exclusion of a contractor based on supply chain concerns revealed only one case. In that protest, a disappointed vendor of desktop printers claimed that the U.S. Social Security Administration (SSA) improperly excluded the vendor from a procurement on supply chain risk grounds. The protester complained that SSA’s determination that the company’s printers, which were manufactured in China, presented a supply chain risk was “flawed and irrational.” In that case, the solicitation stated that SSA would consider information presented by each bidder, as well as any other information available to SSA from any source, to determine if the supply chain risk was unacceptably high. The protester proposed to supply printers manufactured by a company called Lexmark, and, in response to a request for supply chain information issued by SSA, the protester disclosed that Lexmark was a Chinese company owned in part by Chinese investment firms. Based on further information SSA gleaned from a Bloomberg Company Overview, SSA determined that the investment firms with interests in Lexmark employed former Chinese government officials and that at least one had the Chinese Academy of Sciences as an investor. The Court of Federal Claims reasoned that the administrative record supported SSA’s determination that there were “connections” between Lexmark and the Chinese government and congressional reports indicating that the Chinese government engages in espionage against the United States. The court rejected the protester’s argument that SSA overreached on the basis that there was no information in the administrative record indicating that Lexmark actually was compromised by actors looking to conduct cyberespionage and pointed out that the solicitation warned bidders that the supply chain risk assessment would include “potential” supply chain risk.
The lesson of this case is that contractors should assume that the GAO and the Court of Federal Claims will not scrutinize the quality of supply chain information agencies rely on or the logic (or lack thereof) that underpins analysis of supply chain information following awards. Contractors should strive to utilize question-and-answer and pre-award bid protest procedures to limit the scope of potentially unfavorable supply chain information agencies may consider in the course of evaluating proposals.
The Administrative Procedures Act (APA) provides for judicial review of agency actions that aggrieved parties claim to have been harmed by. The APA accords great deference to agency actions. The APA provides that a reviewing court shall “hold unlawful and set aside agency action, findings, and conclusions found to be—(A) arbitrary, capricious, an abuse of discretion or otherwise not in accordance with law. . . .” The court should decide on the basis of the record the agency provides whether there is a rational basis for the agency’s decision.
Conversely, if the record before the court does not support the agency action, if the agency has not considered all relevant factors, or if the reviewing court cannot evaluate the challenged action on the basis of the record before it, it may set aside the agency decision. To prove an agency’s decision was arbitrary and capricious, the challenging party must show the record is devoid of reasonable evidence supporting the agency’s decision. When plaintiffs have brought APA claims seeking relief from agency suspension or debarment decisions, courts have focused on whether the agency followed regulations and whether any deviation from a process prescribed by regulations actually prejudiced the plaintiff. Absent any deviation from the regulatory process that prejudices the excluded party, courts seem to uphold exclusions.
Based on the foregoing, an excluded contractor’s best chance at obtaining APA relief is to point to a required procedural step the excluding agency skipped. If an agency excludes a contractor under, say, Section 3252, the contractor should focus on whether the excluding agency obtained a written risk assessment prepared by the Under Secretary of Defense for Intelligence and Security and written concurrence from the Under Secretary of Defense for Acquisition and Sustainment and leverage any missteps to get the exclusion rescinded. The weakness of this approach is that an agency may correct administrative errors to resolve APA claims, and discretionary judgments an agency makes regarding the types of supply chain information it considers and how it interprets such information are entitled to a great deal of deference; success in identifying procedural errors may just delay the inevitable if an agency has decided that a contractor presents an unacceptable supply chain risk. What little precedent we have suggests that courts will hesitate to question the information agencies rely on or their analyses of that information.
Finally, practitioners should determine whether there is a specific statutory provision regarding judicial review that applies to a particular negative supply chain determination that is likely to preclude APA application. As noted above, for example, the SECURE Technology Act contains a specific provision, 41 U.S.C. § 1327, that provides for judicial review. Of course, the grounds for overturning agency action under the SECURE Technology Act mirror the grounds for overturning agency action under the APA. Nevertheless, the Act offers a good example of a judicial review provision that practitioners must be familiar with when advising clients regarding potential avenues from adverse decisions related to supply chain risk.
Generally, it is always in a contractor’s best interests to facilitate as much open communication with its government customers consistent with procurement integrity rules so that the contractors have a chance to address any supply chain issues prior to such issues being escalated to FASC. As previously noted, FASC is not required to notify a contractor that a supply chain risk evaluation is occurring—rather, FASC simply must provide notice to the contractor once FASC has formally recommended an exclusion or removal order be issued by the agencies. The authors’ best recommendation is that contractors should (i) track and study the ICT supply chain guidance issued by FASC, NIST, and any agencies they sell to; (ii) to the extent possible, adopt written policies and procedures that “check each box” associated with that guidance; and (iii) be prepared to respond on an informal basis to any final or proposed exclusions with evidence demonstrating adherence to best practices and refuting concerns raised by whatever information the agency is relying on. In our experience, persuading agency decision-makers via telephone calls and letters is the best way to resolve concerns and get an exclusion lifted, though a contractor cannot force an agency to reconsider its decision.
The SCRM landscape is constantly changing, which presents significant compliance challenges for the industry. Every government contractor engaged in providing ICT products or services to the federal government should be prepared to explain its current SCRM policies and procedures, demonstrate compliance with updated NIST guidance relating to cybersecurity and supply chain security, and defend itself against an erroneous supply chain risk assessment. Given the heightened focus on supply chain risks, and the interconnectivity of the global supply chain, it is likely that, at some point in the next few years, every contractor will field some questions from procuring agencies regarding the contractor’s supply chain and potential vulnerabilities. By evaluating FASC factors now, and preparing a template response to these questions, the contractor can get out ahead of these issues rather than being caught off guard and playing catch-up.
