A Multi-Layered Security and Supply Chain Risk Analysis of Hyperscale AI Networking Infrastructure

Executive Summary

This report provides a comprehensive security analysis of the networking infrastructure in Meta’s 24,576-GPU AI training clusters. The infrastructure is built on Open Compute Project (OCP) principles. It utilizes Meta’s Minahou switch and the Cisco 8501 switch. Both run Meta’s Facebook Open Switching System (FBOSS) network operating system.

Our analysis concludes that multiple layers of security and regulatory controls are in place. However, their effectiveness is limited. This is due to the nature of open-source development, the complexity of a global semiconductor supply chain, and persistent threats from sophisticated state-sponsored actors.

Key Findings:

• Personnel and Regulatory Gaps. The Open Compute Project (OCP) does not perform national security vetting. This responsibility falls to employers like Meta and Cisco. They are governed by U.S. export control laws, such as the Export Administration Regulations (EAR).¹ However, the open-source model of FBOSS and OCP specifications is a deliberate strategy. It places this technology in the public domain, legally exempting it from many of these controls.¹
• Software as a Primary Attack Vector. The disaggregated model of FBOSS—a suite of applications on a standard Linux OS—shifts the security burden to the operator (Meta). Our analysis of the ecosystem reveals a significant landscape of high-severity vulnerabilities. These exist in vendor software (Cisco, Broadcom) and Meta’s own open-source projects. This indicates the software layer is a probable and high-risk attack vector.
• Divergent Hardware Security. A notable divergence exists in the stated security postures of the underlying Application-Specific Integrated Circuits (ASICs). Cisco explicitly designs its Silicon One architecture with a foundation of hardware security. This includes a hardware root of trust and secure boot capabilities. In contrast, public documentation for Broadcom’s Tomahawk 5 overwhelmingly prioritizes performance. It has a conspicuous lack of detail on embedded security features.
• Concentrated Supply Chain and Geopolitical Risk. The entire hardware foundation is fabricated by a single foundry, Taiwan Semiconductor Manufacturing Company (TSMC). TSMC has a documented history of security breaches. Furthermore, the key design and manufacturing entities—Cisco, Broadcom, and Celestica—maintain significant operations in China. They are also active targets of sophisticated Chinese state-sponsored cyber-espionage campaigns. This confluence of factors makes the supply chain the most complex and difficult-to-secure risk domain.

This report synthesizes these findings into a holistic risk assessment. It concludes that the most acute and probable threats exist at the software and supply chain levels. It also offers strategic recommendations for enhancing security posture through a defense-in-depth approach.

Section 1: The Human and Regulatory Layer: Vetting, Access, and Control

The trustworthiness of individuals who design and build critical infrastructure is a valid concern. This section explains how the global technology sector manages this risk. It relies not on project-level identity checks, but on corporate procedures and a legal regime governing technology transfer.

1.1 Deconstructing the “Nationality Roster”: The Realities of Personnel Vetting in Global Tech

The Open Compute Project (OCP) is a standards body for open-source hardware. It is not a personnel-vetting agency. Its legal purpose is confined to managing intellectual property through a Contribution License Agreement. This agreement governs licensing and patents, not the citizenship or background of contributors.

The responsibility for personnel vetting falls entirely on the employers. These include Meta, Cisco, Broadcom, and the Original Design Manufacturer (ODM), Celestica. Standard corporate vetting includes background checks. These checks primarily focus on criminal history and employment verification, not national security clearances.

A multi-national workforce is the baseline assumption for these companies. Public data from the U.S. Department of Labor confirms that Meta Platforms, Inc. and Cisco Systems, Inc. are large-scale employers of H-1B visa holders. These roles are directly relevant to this infrastructure, including hardware, software, and network engineering. The presence of foreign nationals on these teams is not a security breach. It is a standard and legal operational reality. The critical security question is not who is on the team, but what controls govern their access to sensitive intellectual property.

1.2 U.S. Export Controls as the Primary National Security Guardrail

The U.S. government’s primary legal instrument for managing technology transfer risks is the Export Administration Regulations (EAR). The Department of Commerce’s Bureau of Industry and Security (BIS) administers these regulations. They govern the export of “dual-use” items, software, and technology with both commercial and potential military applications.¹

For managing a multi-national workforce within the U.S., the “Deemed Export” rule is the most critical component of the EAR.

The “Deemed Export” rule states that the release of controlled “technology” or “software source code” to a foreign national inside the United States is legally “deemed” to be an export to that individual’s home country.¹

The EAR defines “technology” as specific information necessary for the “development,” “production,” or “use” of a product. This can take the form of technical data or technical assistance.¹ A foreign national can legally operate controlled hardware without a license. However, providing that same individual with access to the detailed schematics or source code used to design that hardware would be a “deemed export” and may require a license from BIS.¹

To comply, corporations like Meta and Cisco must implement robust internal compliance programs. These programs involve classifying all internal technology, screening employees against restricted party lists, and implementing strict access controls. Controls can include digital “clean rooms” and file repositories designated as “U.S. persons only” to ensure foreign nationals do not access controlled technology without authorization.

1.3 Efficacy and Loopholes in the Regulatory Framework

The EAR framework has significant limitations. The most relevant limitation here is the “publicly available” exemption. Information, technology, and software that are publicly available are not subject to the EAR. They can be shared with foreign persons without an export license.¹

Developing hardware specifications like Minipack3 and software like the Facebook Open Switching System (FBOSS) in an open-source model is a deliberate strategic choice. By making designs and code publicly available, hyperscalers legally remove them from the purview of most export controls. This approach accelerates innovation but simultaneously removes a key national security backstop. The project’s security then relies on general open-source development practices rather than government-mandated controls.

Furthermore, the broader effectiveness of U.S. export controls on semiconductor technology is intensely debated. Critics note that success depends on multilateral cooperation, which is not always guaranteed.², ³ Moreover, strategic competitors have shown a remarkable ability to adapt and innovate around these restrictions, potentially accelerating their own technological independence.², ³ The U.S. government acknowledges these challenges and constantly refines the rules, as shown by recent efforts to close loopholes for corporate affiliates.⁴, ⁵

Section 2: The Software Attack Surface: Analyzing FBOSS and the Network Operating System Stack

The security of the AI cluster’s networking fabric depends on the integrity of its software stack. This report now transitions from the regulatory framework to the technical implementation, starting with the software layer. The disaggregated model, which pairs Meta’s FBOSS with hardware from multiple vendors, creates a unique and complex attack surface.

2.1 Architectural Security Review of Meta’s FBOSS

Facebook Open Switching System (FBOSS) is not a monolithic operating system. It is a suite of applications and libraries designed to run on a standard Linux distribution. This reflects Meta’s philosophy of treating switches like servers.⁶

The core architectural components include:

• The FBOSS Agent (fboss_agent): A C++ daemon that is the central control process. It runs on the switch’s CPU, manages the hardware forwarding Application-Specific Integrated Circuit (ASIC), and implements low-level control plane protocols.⁷
• Thrift APIs: FBOSS is designed for programmatic control. It exposes a set of Thrift APIs for external management systems to program routes, configure ports, and query status.⁶
• Underlying Linux OS: FBOSS runs on a standard Linux operating system, which handles foundational tasks like process scheduling and memory management.⁶

This disaggregated architecture shifts the security burden. In a traditional model, a vendor like Cisco secures the entire software stack. In the FBOSS model, the operator (Meta) is responsible for securing the base Linux OS, its configuration, and the FBOSS application layer. This grants immense flexibility but also imposes the security responsibilities of a full system integrator.

Meta’s “release early, release often” model for FBOSS introduces both risks and mitigations. Rapid iteration increases the chance of introducing a vulnerability. However, Meta manages this through a phased rollout system with automated health checks and rollback capabilities.⁸ Vulnerabilities discovered in FBOSS fall under the Meta Bug Bounty Program.⁹ The company also maintains a public Vulnerability Disclosure Policy for issues in third-party code.¹⁰

2.2 Vulnerability Deep Dive: Assessing Relevant CVEs

An analysis of publicly disclosed vulnerabilities provides a data-driven view of the security posture of the vendors and software involved. These are tracked using Common Vulnerabilities and Exposures (CVE) IDs. While the Cisco 8501 runs FBOSS in Meta’s deployment, the vulnerability history of Cisco’s native operating systems is relevant as it reflects on the company’s software development security practices.

Table 2: Vulnerability Landscape Analysis (Representative High-Severity CVEs)

CVE ID	Vendor	Affected Product(s)	CVSS v3.1 Score	Attack Vector / Impact	Source(s)
CVE-2023-20198	Cisco	IOS XE Software (Web UI)	10.0 (Critical)	Unauthenticated remote attacker can create privileged accounts. Actively exploited as a 0-day.	[¹¹]
CVE-2024-50050	Meta	meta-llama (llama-stack)	9.8 (Critical)	Deserialization of untrusted data allows remote code execution (RCE) on the inference server.	[¹²]
CVE-2023-45239	Meta	tac_plus	9.8 (Critical)	Lack of input validation allows an attacker to inject shell commands and gain RCE.	[¹³]
CVE-2019-19494	Broadcom	Broadcom-based cable modems	8.8 (High)	Buffer overflow allows a remote attacker to execute arbitrary code at the kernel level.	[¹⁴]
CVE-2024-20307	Cisco	IOS & IOS XE Software (IKEv1)	8.6 (High)	Unauthenticated remote attacker can cause heap overflow/underflow, leading to Denial of Service (DoS).	[¹⁵]
CVE-2024-20311	Cisco	IOS & IOS XE Software (LISP)	8.6 (High)	Unauthenticated remote attacker can trigger a device reload (DoS) by sending a manipulated LISP packet.	[¹⁵]
CSCwi07137	Cisco	IOS XE Software (SD-WAN)	8.6 (High)	Unauthenticated remote attacker can cause a device reload (DoS) by sending crafted traffic through an IPsec tunnel.	[¹⁶]

The data, scored using the Common Vulnerability Scoring System (CVSS), reveals critical patterns. Cisco’s networking software has been afflicted by critical, unauthenticated vulnerabilities that allow for complete system compromise.¹¹ This suggests a potential weakness in their management plane software. Even though the 8501 runs FBOSS, any underlying management components from Cisco could harbor similar latent risks.

Likewise, Meta’s own open-source projects are not immune to severe flaws. The recent critical Remote Code Execution (RCE) vulnerability in the meta-llama stack demonstrates that even new, high-profile projects can contain fundamental security errors.¹² This underscores the need for continuous and rigorous security auditing of all software components.

2.3 Threat Modeling the Open Networking Stack

Threat modeling is a structured methodology for identifying and mitigating potential security threats.¹⁷, ¹⁸ Applying the STRIDE framework—Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service (DoS), and Elevation of Privilege—to the FBOSS architecture reveals several potential attack vectors.¹⁸

• Spoofing: An attacker could spoof a legitimate network management system to send malicious commands to the FBOSS agent’s Thrift API, potentially altering routing tables.
• Tampering: An attacker who gains access to the switch’s underlying Linux OS could tamper with the fboss_agentbinary or its configuration files to inject malicious code.
• Repudiation: Insufficient logging could allow an attacker to perform malicious actions without leaving a clear, attributable audit trail.
• Information Disclosure: A vulnerability in the Thrift API could allow an unauthenticated attacker to query for sensitive information, such as the full routing table, aiding in network reconnaissance.
• Denial of Service (DoS): An attacker could crash the fboss_agent by sending a malformed packet or a crafted API request, causing the switch to cease processing traffic.
• Elevation of Privilege: A memory corruption vulnerability within the fboss_agent process could be exploited by a low-privilege process on the same system to gain root access and full control of the switch.

General mitigation strategies for these threats include robust authentication for API endpoints, hardening the underlying Linux operating system, comprehensive and immutable logging, and applying secure coding practices.

2.4 The Switch Abstraction Interface (SAI): A Double-Edged Sword

The Switch Abstraction Interface (SAI) is an OCP-led initiative. It creates a standardized, vendor-independent API for programming network forwarding ASICs.¹⁹ In the FBOSS architecture, the SaiSwitch module uses this API to communicate with the underlying hardware. This abstracts away the specifics of the Broadcom or Cisco silicon.²⁰

This abstraction provides significant operational benefits. Chief among them is supply chain resilience. It allows Meta to run the exact same FBOSS software stack on hardware from two different silicon vendors, preventing vendor lock-in.²⁰

However, from a security perspective, SAI introduces an additional software layer into the trusted computing base. This layer is the vendor’s proprietary implementation of the SAI library. This library, provided by Broadcom or Cisco, is a complex piece of closed-source software. A vulnerability within a vendor’s SAI implementation could be exploited by a specially crafted call from the network operating system. This could potentially lead to a DoS or privilege escalation.

Section 3: The Silicon Heart: Hardware Security of the Tomahawk 5 and Silicon One G200 ASICs

Moving from software to the physical layer, this section examines the silicon “heart” that performs high-speed packet forwarding: the Application-Specific Integrated Circuit (ASIC). The inherent security of this hardware forms the foundation upon which all software security is built. An analysis of the two ASICs in question—Broadcom’s Tomahawk 5 and Cisco’s Silicon One G200—reveals a significant divergence in their publicly stated security postures.

3.1 ASIC Security Postures: A Comparative Analysis of Broadcom and Cisco

Cisco and Broadcom’s design philosophies regarding the security of their ASICs differ substantially. Cisco has integrated security as a core, explicitly marketed pillar of its Silicon One architecture. In contrast, Broadcom’s public-facing materials for the Tomahawk 5 focus almost exclusively on performance.

• Cisco Silicon One G200: Cisco’s documentation consistently highlights a defense-in-depth approach to hardware security.²¹, ²² Key features include:
  • Hardware Root of Trust (RoT): An integrated, tamper-resistant module that serves as the immutable foundation for the entire secure boot process.²¹, ²²
  • Secure Boot: A process that cryptographically verifies the authenticity and integrity of each stage of the software, from firmware to the operating system, defending against persistent malware.²⁴
  • Line-Rate Encryption: Hardware engines capable of performing line-rate MACsec and IPsec encryption, supporting post-quantum resilient algorithms.²¹, ²², ²³
  • Authenticated Software and Configuration: The architecture is designed to ensure that only cryptographically signed and trusted code is executed.²¹
• Broadcom Tomahawk 5 (BCM78900): Public materials for the Tomahawk 5 emphasize its 51.2 Tbps capacity, low latency, and features for optimizing AI/ML workloads.²⁵ There is a notable absence of any detailed discussion of hardware-level security features. While Broadcom documents a robust hardware security strategy—including secure boot and a hardware RoT—for its storage and PCIe product lines, this has not been publicly extended to its Tomahawk series of Ethernet switches.²⁶ This contrasts with other Broadcom switch lines, such as the Trident, which are marketed as “Security-Enabled.”²⁷

This divergence suggests two different philosophies. Cisco appears to view hardware security as a primary feature. Broadcom appears to prioritize raw performance for its Tomahawk line, perhaps assuming the hyperscale customer will implement security controls at higher layers. This implies that the Cisco 8501 platform may offer a more robust hardware security foundation than the Meta Minipack3.

Table 1: Comparative Analysis of ASIC Security Features (Tomahawk 5 vs. Silicon One G200)

Feature	Broadcom Tomahawk 5	Cisco Silicon One G200	Source(s)
Hardware Root of Trust	Not Explicitly Documented	Explicitly Marketed & Documented	[²¹, ²²]
Secure Boot Process	Not Explicitly Documented	Explicitly Marketed & Documented	[²¹, ²⁴]
Line-Rate Encryption (MACsec/IPsec)	Not Explicitly Documented	Explicitly Marketed & Documented (with post-quantum resilience)	[²¹, ²², ²³]
Authenticated Data Plane Software	Not Explicitly Documented	Explicitly Marketed & Documented	[²¹]
Primary Marketing Focus	Performance, Bandwidth, AI/ML Optimization	Scalability, Power Efficiency, and End-to-End Security	[²¹, ²⁵]

3.2 The Hardware Trojan Threat: Feasibility and Detection Challenges

A Hardware Trojan (HT) is a malicious and intentional modification of an integrated circuit’s design. It is inserted to cause a malfunction or leak information.²⁸ In the modern fabless semiconductor model, there are multiple opportunities for an HT to be inserted, from a compromised third-party IP core to malicious modification at an untrusted foundry.²⁸, ²⁹

Detecting a sophisticated HT in a complex, 5nm-class ASIC is an exceptionally difficult problem. The primary detection methodologies have critical limitations:

• Physical Inspection: This destructive process involves de-packaging the chip and using electron microscopy to compare its physical layout to the design files. It is prohibitively expensive to perform at scale and impractical for chips with billions of transistors.²⁹
• Functional Testing: This method relies on applying test vectors to the chip’s inputs and verifying the outputs. It is unlikely to detect a stealthy HT designed to trigger only under very specific and rare conditions.³⁰
• Side-Channel Analysis: This non-destructive technique involves measuring the chip’s analog characteristics—such as power consumption or thermal emissions—and comparing them to a “golden chip” known to be free of Trojans.³⁰, ³¹ Its effectiveness is severely degraded by natural process variations between chips, making it difficult to distinguish a small HT from normal variations.³², ³³

A fundamental flaw in side-channel analysis is the “golden chip” assumption. A sophisticated state-level adversary would likely target the fabrication process itself at the third-party foundry (TSMC). In such a scenario, the malicious modification could be inserted into the master photomasks. This would mean every chip produced, including the “golden reference,” would contain the trojan, rendering it invisible to this detection method. Mitigation strategies therefore focus on securing the supply chain and implementing post-deployment monitoring, such as anomaly detection in the chip’s power consumption or thermal output.³⁴

3.3 Analysis of Known Hardware Vulnerabilities and Side-Channel Attack Vectors

Beyond the threat of malicious insertion, hardware itself can contain unintentional design flaws that create vulnerabilities. Academic research has demonstrated numerous side-channel attacks where sensitive information, such as cryptographic keys, can be leaked through subtle variations in a chip’s power consumption or electromagnetic emissions.³⁵ While no specific side-channel vulnerabilities have been publicly disclosed for the Tomahawk 5 or Silicon One G200, the theoretical risk exists for any complex ASIC that performs on-chip cryptographic operations.

Section 4: The Global Supply Chain: A Chain of Trust Under Pressure

The physical creation of the switches involves a complex global supply chain. Each stage presents a distinct set of security risks. This chain is a web of interconnected dependencies, where a vulnerability at any point can compromise the final product. This risk is magnified by a geopolitical landscape characterized by active and sophisticated state-sponsored cyber espionage.

4.1 Fabrication Risk at the Foundry: A Security Profile of TSMC

Both the Broadcom Tomahawk 5 and the Cisco Silicon One G200 are fabricated using Taiwan Semiconductor Manufacturing Company’s (TSMC) advanced 5-nanometer process node.³⁶, ³⁷ This consolidation makes TSMC the single most critical link in the hardware supply chain—a single point of failure and an exceptionally high-value target.

TSMC’s public security incident history reveals multiple vectors of compromise:

• Third-Party and Supplier Compromise: In August 2018, TSMC was forced to shut down several fabrication plants after a WannaCry ransomware variant was introduced to its network by a supplier during the installation of a new, unpatched tool. The incident resulted in an estimated $255 million in damages.³⁸ In June 2023, the LockBit ransomware group claimed to have breached TSMC, though TSMC later clarified the breach occurred at one of its IT hardware suppliers, from which server setup data was stolen.³⁹
• Insider Threat: TSMC has faced multiple incidents involving its own employees attempting to exfiltrate sensitive intellectual property. In one case, employees were implicated in the attempted theft of trade secrets related to its next-generation 2-nanometer process technology, a case prosecuted under Taiwan’s National Security Act.⁴⁰ Another incident involved engineers leaking over 1,000 confidential images of process diagrams.⁴¹

This documented history of intrusions via both external suppliers and malicious insiders establishes the fabrication stage as a significant point of risk.

4.2 Manufacturing and Assembly Risk: Profiling Celestica and Cisco’s Global Operations

After fabrication, the ASICs are assembled into the final switch systems.

• Meta Minipack3: The Minipack3 is designed by Meta and manufactured by Celestica, a global electronics manufacturing services (EMS) provider.⁴² Celestica’s portfolio includes an Aerospace and Defense sector, suggesting experience with high-security manufacturing, including International Traffic in Arms Regulations (ITAR) compliance.⁴³ However, Celestica is a global company with a significant footprint that includes operations in China.⁴⁴ While the company has not suffered major public security breaches, its role as a key manufacturer for hyperscale infrastructure makes it a valuable target.⁴⁵, ⁴⁶
• Cisco 8501: The Cisco 8501 is both designed and manufactured by Cisco itself.⁴⁷ Cisco utilizes a global supply chain and has recently announced a major initiative to establish manufacturing capabilities in India, aiming to diversify its supply chain.⁴⁸ This enhances resilience but also distributes security challenges across multiple geopolitical domains.

4.3 Geopolitical Exposure and State-Sponsored Threats

The security of the supply chain must be contextualized within the current geopolitical environment. Both Cisco and Broadcom have a significant, long-standing corporate presence in China, including large R&D centers. This presence, coupled with China’s National Intelligence Law, creates a potential vector for state-sponsored influence and espionage.

This risk is made concrete by documented, sophisticated cyber-espionage campaigns explicitly targeting these companies’ products, attributed to threat actors linked to the Chinese government.

• ArcaneDoor (Storm-1849): This campaign, identified in 2024 and 2025, exploited multiple zero-day vulnerabilities in Cisco’s firewalls. The attackers demonstrated an advanced capability to gain remote code execution and manipulate the device’s read-only memory (ROM) to install a persistent backdoor.⁴⁹
• UNC5174 (Uteus): This China-linked threat actor was observed exploiting a zero-day local privilege escalation vulnerability (CVE-2025-41244) in Broadcom’s VMware products as early as October 2024.⁵⁰

The confluence of a significant corporate presence in China and active espionage campaigns against their products by Chinese state actors creates a high-risk environment.

Table 3: Supply Chain Risk Matrix

Supply Chain Stage	Key Actor(s)	Documented Risks / Incidents	Geopolitical Vector	Source(s)
ASIC Design	Broadcom, Cisco	Direct targeting by state-sponsored actors (ArcaneDoor, UNC5174) exploiting zero-day vulnerabilities.	Operational and R&D presence in China, creating a vector for state influence and intelligence gathering.	[⁴⁹, ⁵⁰]
Fabrication (Foundry)	TSMC	Insider Threat: Employee theft of 2nm process trade secrets. Supplier Compromise: WannaCry (2018) and LockBit (2023) incidents originated from compromised third-party suppliers.	Extreme concentration of advanced semiconductor manufacturing in a geopolitically contested region makes it a primary target for state espionage.	[³⁸, ³⁹, ⁴⁰]
ODM Assembly (Minipack3)	Celestica	General risk as a high-profile EMS provider. No major public incidents, but subject to broad threats targeting the manufacturing sector.	Global operations including a presence in China. Experience with secure A&D manufacturing provides some mitigation.	[⁴³, ⁴⁴, ⁴⁶]
OEM Assembly (Cisco 8501)	Cisco	Subject to the same direct targeting as in the design phase (ArcaneDoor). Global manufacturing network distributes risk.	Diversifying manufacturing to India, but historical and ongoing presence in China remains a risk factor.	[⁴⁸, ⁴⁹]

Section 5: Conclusion

The security of hyperscale AI networking infrastructure is a complex, multi-layered challenge. This analysis reveals that while regulatory frameworks and corporate vetting provide a baseline of control, they are insufficient on their own. The open-source nature of key software and hardware specifications, while beneficial for innovation, effectively bypasses many traditional export controls. This shifts the security onus onto the operators themselves.

The software stack represents the most probable and immediate attack surface. It has a history of critical vulnerabilities across the ecosystem. Concurrently, a clear divergence in hardware security philosophy between silicon vendors presents an uneven foundational layer of trust. Cisco’s documented emphasis on hardware security stands in contrast to Broadcom’s public focus on performance for its Tomahawk line.

Finally, the entire system rests on a fragile and geopolitically exposed supply chain. The concentration of fabrication at a single, historically breached foundry (TSMC), combined with the operational presence of key vendors in regions targeted by sophisticated state-sponsored adversaries, creates a high-risk environment. The most likely threats are software exploits and supply chain compromises. The most catastrophic threat, a foundry-level hardware trojan, remains a low-probability but high-impact concern.

Section 6: Synthesis, Risk Assessment, and Strategic Recommendations

A holistic security assessment requires synthesizing the analyses of the human, software, hardware, and supply chain layers. While controls exist at each layer, the interdependencies and the sophistication of potential adversaries create a complex risk landscape where no single control is sufficient.

6.1 A Holistic Risk Assessment of the Meta AI Cluster Design

By evaluating the likelihood and potential impact of various threat scenarios, a prioritized risk posture emerges.

• Scenario 1: Software Vulnerability Exploitation.
  • Likelihood: High.
  • Impact: High.
  • Rationale: The vast and constantly evolving codebase of the underlying Linux OS, FBOSS, vendor SDKs, and SAI libraries, combined with a documented history of critical, remotely exploitable vulnerabilities, makes a software flaw the most probable vector for compromise. A successful RCE vulnerability in the FBOSS agent would grant an attacker complete control over a switch.
• Scenario 2: Supply Chain Compromise (via Supplier/Third-Party).
  • Likelihood: Medium.
  • Impact: High.
  • Rationale: The repeated security failures at TSMC originating from its suppliers demonstrate that this is a proven attack vector. An adversary could compromise a less secure entity in the supply web to gain access to a more secure target like TSMC or Celestica.
• Scenario 3: Malicious Insider.
  • Likelihood: Medium.
  • Impact: Critical.
  • Rationale: Documented incidents of IP theft at TSMC by employees highlight this risk. A well-placed or coerced insider at any point in the chain—from a chip designer to a fabrication engineer—could exfiltrate sensitive design data or intentionally introduce a backdoor.
• Scenario 4: Foundry-Level Hardware Trojan.
  • Likelihood: Low.
  • Impact: Catastrophic.
  • Rationale: This scenario involves a highly sophisticated state actor successfully compromising the fabrication process at TSMC to insert a stealthy hardware trojan. While technically challenging, its impact would be devastating, as a successful trojan could be undetectable by conventional means and provide a persistent backdoor into the infrastructure.

6.2 Strategic Recommendations

Mitigating these complex, multi-layered risks requires a defense-in-depth strategy that extends beyond traditional software patching and network monitoring.

For Hyperscalers (e.g., Meta)

Immediate Actions

1. Harden the Software Stack: Continue to invest heavily in the security of the open-source software stack. This includes expanding the bug bounty program, funding third-party security audits, and applying advanced security development lifecycle (SDL) practices like threat modeling, static analysis, and fuzzing to all critical components.

Long-Term Strategies

1. Adopt a Zero Trust Hardware Model: Operate under the assumption that the hardware supply chain could be compromised. Develop and deploy continuous, real-time monitoring of the hardware’s physical characteristics (power draw, thermal output, timing) in production to detect deviations from an established baseline that could indicate malicious activity.
2. Invest in Hardware Verification and Provenance: Enhance procurement processes to include more rigorous hardware security verification. This could involve advanced non-destructive imaging, side-channel analysis of sample batches, and demanding greater transparency from silicon vendors and ODMs.
3. Diversify Foundries and Supply Chains: Where feasible, pursue a strategy of diversifying not only silicon providers but also fabrication foundries. Reducing reliance on a single foundry in a single geopolitical region is the most effective long-term mitigation against catastrophic supply chain risk.

For National Security Stakeholders (e.g., U.S. Government)

Policy and Funding Initiatives

1. Fund Research in Hardware Trojan Detection: Sponsor public and private research into developing scalable, reliable, and non-destructive technologies for detecting hardware trojans in complex ASICs. This is a critical national security challenge that the commercial market is unlikely to solve on its own.
2. Promote Trusted Domestic Manufacturing: Utilize policies like the CHIPS Act to create and subsidize trusted, on-shore fabrication, packaging, and assembly capabilities for components deemed critical to national infrastructure.
3. Support Open-Source Infrastructure Security: Treat the security of foundational open-source projects like FBOSS and the Linux kernel as a matter of public interest. Fund independent security audits, formal verification efforts, and the development of secure-by-design software components.

Strategic Re-evaluation

1. Acknowledge the Limits of Export Controls: Recognize that for mass-market, globally-produced dual-use hardware, export controls are a porous and largely insufficient defense against determined state actors. Policy should shift focus from control-by-denial to risk management through verification and resilience.

---

Works Cited

1. University of Pittsburgh. “DEEMED-EXPORT (EAR 734.15 AND ITAR 120.50(a)(2).” researchsecurity.pitt.edu. https://www.researchsecurity.pitt.edu/deemed-export
2. Lawfare Institute. “U.S. Export Controls on AI and Semiconductors.” laweconcenter.org. https://laweconcenter.org/resources/us-export-controls-on-ai-and-semiconductors/
3. Branstetter, L., et al. “Export Controls, U.S.-China Technology Competition, and the Future of Global Innovation.” Brookings Institution. July 2024. https://www.brookings.edu/wp-content/uploads/2024/07/20240701_Branstetter_Sanctions.pdf
4. U.S. Department of Commerce. “Department of Commerce Expands Entity List to Cover Affiliates of Listed Entities.” Bureau of Industry and Security. https://www.bis.gov/press-release/department-commerce-expands-entity-list-cover-affiliates-listed-entities
5. O’Melveny & Myers LLP. “Commerce Department Significantly Expands Scope of Certain Export Restrictions.” omm.com. https://www.omm.com/insights/alerts-publications/commerce-department-significantly-expands-scope-of-certain-export-restrictions/
6. Engineering at Meta. “Facebook Open Switching System (‘FBOSS’) and Wedge in the open.” engineering.fb.com. March 10, 2015. https://engineering.fb.com/2015/03/10/data-center-engineering/facebook-open-switching-system-fboss-and-wedge-in-the-open/
7. GitHub. “facebook/fboss: Facebook Open Switching System Software for controlling network switches.” github.com. https://github.com/facebook/fboss
8. @Scale. “Safe change management in Meta data centers.” atscaleconference.com. https://atscaleconference.com/safe-change-management-in-meta-data-centers/
9. Meta. “Meta Bug Bounty.” bugbounty.meta.com. https://bugbounty.meta.com/
10. Meta. “Meta’s Vulnerability Disclosure Policy.” meta.com. https://www.meta.com/legal/security-vulnerability-disclosure-policy/
11. Canadian Centre for Cyber Security. “Alert – Vulnerability impacting Cisco devices (CVE-2023-20198) – Update 3.” cyber.gc.ca. November 1, 2023. https://www.cyber.gc.ca/en/alerts-advisories/vulnerability-impacting-cisco-devices-cve-2023-20198
12. Oligo Security. “CVE-2024-50050: Critical Vulnerability in Meta Llama (llama-stack).” oligo.security. https://www.oligo.security/blog/cve-2024-50050-critical-vulnerability-in-meta-llama-llama-stack
13. OpenCVE. “CVE-2023-45239.” app.opencve.io. February 13, 2025. https://app.opencve.io/cve/?vendor=facebook&page=2
14. NVD. “CVE-2019-19494.” nvd.nist.gov. November 20, 2024. https://nvd.nist.gov/vuln/detail/CVE-2019-19494
15. Avertium. “Flash Notice: Cisco Patches Several Vulnerabilities Impacting Cisco IOS and IOS XE Softwares.” avertium.com. https://www.avertium.com/flash-notices/cisco-patches-several-vulnerabilities-impacting-cisco-ios-and-ios-xe-softwares
16. Cisco. “Cisco Catalyst SD-WAN Routers Denial of Service Vulnerability.” sec.cloudapps.cisco.com. September 25, 2024. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-utd-dos-hDATqxs
17. OWASP. “Threat Modeling.” owasp.org. https://owasp.org/www-community/Threat_Modeling
18. OWASP. “Threat Modeling Process.” owasp.org. https://owasp.org/www-community/Threat_Modeling_Process
19. GitHub. “SAI · sonic-net/SONiC Wiki.” github.com. https://github.com/sonic-net/SONiC/wiki/SAI
20. NANOG. “FBOSS Experience in Onboarding a Second Silicon Vendor.” archive.nanog.org. https://146a55aca6f00848c565-a7635525d40ac1c70300198708936b4e.ssl.cf1.rackcdn.com/images/2a49d968a33ecaa2e98476efea21e05004764c9c.pdf
21. Cisco. “Cisco Silicon One P200 Powers the First 51.2T Scale-Across Routing Systems.” blogs.cisco.com. https://blogs.cisco.com/sp/cisco-silicon-one-p200-powers-the-first-51-2t-scale-across-routing-systems
22. Cisco Live. “Cisco Silicon One Differentiators For AI networking.” ciscolive.com. 2025. https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2025/pdf/AIHUB-1004.pdf
23. Cisco. “Cisco Sets Benchmark With Industry-Most Scalable, Efficient 51.2T Routing Systems for Distributed AI Workloads.” newsroom.cisco.com. October 2025. https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2025/m10/cisco-sets-benchmark-with-industry-most-scalable-efficient-51-2t-routing-systems-for-distributed-ai-workloads.html
24. Cisco. “Cisco IOS XE Software Secure Boot Bypass Vulnerabilities.” sec.cloudapps.cisco.com. October 15, 2025. https://sec.cloudapps.cisco.com/security/center/publicationListing.x
25. Broadcom. “Broadcom Delivers StrataXGS® Tomahawk® 5 Switch Series.” broadcom.com. https://www.broadcom.com/company/news/product-releases/60456
26. Broadcom. “Data Center Security: Building a Trusted Foundation for Cyber Resilience.” docs.broadcom.com. https://docs.broadcom.com/doc/Data-Center-Security-WP100
27. Broadcom. “Merchant Silicon Networking Chips.” broadcom.com. https://www.broadcom.com/info/switching/merchant-silicon
28. PMC. “A Survey on Hardware Trojans.” pmc.ncbi.nlm.nih.gov. October 13, 2020. https://pmc.ncbi.nlm.nih.gov/articles/PMC7570641/
29. Wikipedia. “Hardware Trojan.” en.wikipedia.org. https://en.wikipedia.org/wiki/Hardware_Trojan
30. MDPI. “A Survey of Hardware Trojan Detection Techniques on FPGAs.” mdpi.com. July 20, 2018. https://www.mdpi.com/2079-9292/7/7/124
31. ResearchGate. “Hardware Trojan Identification and Detection.” researchgate.net. https://www.researchgate.net/publication/318366385_Hardware_Trojan_Identification_and_Detection
32. ResearchGate. “Detecting Hardware Trojans using On-chip Sensors in an ASIC Design.” researchgate.net. https://www.researchgate.net/publication/273510598_Detecting_Hardware_Trojans_using_On-chip_Sensors_in_an_ASIC_Design
33. ResearchGate. “Detecting Hardware Trojans using On-chip Sensors in an ASIC Design.” researchgate.net. https://www.researchgate.net/publication/273510598_Detecting_Hardware_Trojans_using_On-chip_Sensors_in_an_ASIC_Design
34. MDPI. “A Lightweight NoC-Based Hardware Trojan and Its Detection Using Machine Learning.” mdpi.com. March 1, 2024. https://www.mdpi.com/2079-9268/13/3/50
35. ResearchGate. “ASIC-Oriented Comparative Review of Hardware Security Algorithms for Internet of Things Applications.” researchgate.net. https://www.researchgate.net/publication/312137151_ASIC-Oriented_Comparative_Review_of_Hardware_Security_Algorithms_for_Internet_of_Things_Applications
36. The Next Platform. “Like A Drumbeat, Broadcom Doubles Ethernet Bandwidth With Tomahawk 5.” nextplatform.com. August 16, 2022. https://www.nextplatform.com/2022/08/16/like-a-drumbeat-broadcom-doubles-ethernet-bandwidth-with-tomahawk-5/
37. The Next Platform. “Cisco Guns For InfiniBand With Silicon One G200.” nextplatform.com. June 22, 2023. https://www.nextplatform.com/2023/06/22/cisco-guns-for-infiniband-with-silicon-one-g200/
38. Manufacturing Business Technology. “Cyber Security Incident Forced Shutdowns, Financial Losses.” mbtmag.com. September 6, 2018. https://www.mbtmag.com/home/blog/21102105/cyber-security-incident-forced-shutdowns-financial-losses
39. Bitdefender. “TSMC Refuses to Pay $70 Million Ransom after Lockbit Falsely Claims Its Affiliates Hacked the Giant Chipmaker.” bitdefender.com. July 3, 2023. https://www.bitdefender.com/en-us/blog/hotforsecurity/tsmc-refuses-to-pay-70-million-ransom-after-lockbit-falsely-claims-its-affiliates-hacked-the-giant-chipmaker
40. AnySilicon. “TSMC Terminates Employees in Wake of Alleged 2 nm Trade-Secret Breach.” anysilicon.com. August 5, 2025. https://anysilicon.com/tsmc-terminates-employees-in-wake-of-alleged-2-nm-trade-secret-breach/
41. CommonWealth Magazine. “TSMC Espionage Shocker: 2nm Chip Secrets Leaked Over Coffee and.” english.cw.com.tw. https://english.cw.com.tw/article/article.action?id=4264
42. Engineering at Meta. “Minipack3 (Broadcom Tomahawk5 based, designed by Meta and manufactured by Celestica) 51.2T switch.” engineering.fb.com. October 15, 2024. https://engineering.fb.com/2024/10/15/data-infrastructure/open-future-networking-hardware-ai-ocp-2024-meta/attachment/minipack3/
43. Celestica. “Aerospace & Defense.” celestica.com. https://www.celestica.com/our-expertise/markets/aerospace-and-defense
44. Circus Group. “Operational Excellence Unlocked.” circus-group.com. March 3, 2025. https://www.circus-group.com/production/operational-excellence-unlocked
45. Canadian Lawyer. “Cybersecurity attacks in Canada hold steady, but things are getting worse.” canadianlawyermag.com. July 18, 2023. https://www.canadianlawyermag.com/practice-areas/privacy-and-data/cybersecurity-attacks-in-canada-hold-steady-but-things-are-getting-worse/377930
46. Celestica. “Celestica Inc. Form 10-K.” corporate.celestica.com. https://corporate.celestica.com/node/8851/html
47. Engineering at Meta. “Cisco 8501 (Cisco Silicon One G200 based, designed and manufactured by Cisco) 51.2T switch.” engineering.fb.com. October 15, 2024. https://engineering.fb.com/2024/10/15/data-infrastructure/open-future-networking-hardware-ai-ocp-2024-meta/attachment/cisco-8501/
48. TelecomLead. “Cisco to manufacture in India targeting over $1 bn.” telecomlead.com. May 10, 2023. https://telecomlead.com/telecom-equipment/cisco-to-manufacture-in-india-targeting-over-1-bn-110319
49. SecurityWeek. “Cisco Firewall Zero-Days Exploited in China-Linked ArcaneDoor Attacks.” securityweek.com. https://www.securityweek.com/cisco-firewall-zero-days-exploited-in-china-linked-arcanedoor-attacks/
50. The Hacker News. “Urgent: China-Linked Hackers Exploit New VMware Zero-Day Since October 2024.” thehackernews.com. September 30, 2025. https://thehackernews.com/2025/09/urgent-china-linked-hackers-exploit-new.html