3.5 Infrastructure as Supply Chain¶

The previous sections have focused on software dependencies—the packages, libraries, and components that applications incorporate. But modern software depends on far more than code. A hidden layer of infrastructure services underpins every software supply chain: DNS resolution that translates package registry names to IP addresses, cloud platforms that host build systems and registries, CDNs that distribute assets globally, certificate authorities that enable secure connections, and time synchronization services that coordinate distributed systems. Compromise or failure at this infrastructure layer can undermine software supply chain security regardless of how carefully individual packages are vetted.

DNS: The Foundation Beneath the Foundation¶

The Domain Name System (DNS) translates human-readable domain names into IP addresses that computers use to communicate. Every time a developer runs npm install or pip install, DNS resolution determines which servers receive those requests. This makes DNS a critical, largely invisible supply chain dependency.

DNS compromise enables powerful attacks:

DNS hijacking redirects traffic intended for legitimate services to attacker-controlled servers. If an attacker can control DNS resolution for registry.npmjs.org, they can serve malicious packages to any developer whose DNS queries they intercept. The DNSpionage attacks (2018-2019), attributed to Iranian threat actors, hijacked DNS records for government and private organizations across the Middle East and North Africa, demonstrating nation-state capability and interest in DNS-based attacks.¹

DNS cache poisoning inserts malicious records into DNS resolvers, affecting all users of those resolvers. While modern DNS implementations include protections against classic poisoning attacks, vulnerabilities continue to emerge. The SAD DNS attack (2020) demonstrated that cache poisoning remained viable against significant portions of DNS infrastructure.²

Registrar compromise provides control over authoritative DNS records. Attackers who compromise accounts at domain registrars can redirect any domain those accounts control. The Perl.com hijacking (January 2021) saw the perl.com domain redirected after a social engineering attack against the registrar, temporarily disrupting access to Perl resources.³

Availability attacks on DNS infrastructure can prevent access to package registries entirely. A DDoS attack against the DNS infrastructure serving npm or PyPI would prevent developers from installing packages, potentially breaking CI/CD pipelines and deployments globally. The Dyn DDoS attack (October 2016), executed using the Mirai botnet, demonstrated this risk by disrupting DNS for major internet services including GitHub, Twitter, Netflix, and Reddit, affecting developer workflows worldwide.⁴

Organizations rarely consider DNS in supply chain risk assessments, yet DNS compromise could enable attacks against any package installation that relies on network resolution.

Cloud Provider Dependencies¶

Modern software supply chains are deeply entangled with cloud providers. Package registries run on cloud infrastructure. CI/CD systems operate as cloud services. Container images are stored in cloud registries. This concentration creates shared fate—the security and availability of your supply chain depends on your cloud provider's security and availability.

Infrastructure compromise at cloud providers would have cascading effects throughout the software ecosystem. If an attacker compromised AWS infrastructure hosting npm's registry backend, they could potentially modify packages served to millions of developers. While major cloud providers invest heavily in security, their central position makes them attractive targets for sophisticated adversaries.

Cloud service vulnerabilities periodically affect supply chains. The Codecov breach (2021) exploited a vulnerability in Codecov's Docker image creation process that exposed credentials, enabling attackers to modify the Bash Uploader script and harvest secrets from over 23,000 customer CI pipelines for more than two months before detection.⁵ Cloud-based CI/CD services—GitHub Actions, GitLab CI, CircleCI, Travis CI—execute customer code with access to credentials and secrets, making them high-value targets.

Multi-tenancy risks arise because cloud services serve many customers from shared infrastructure. Security boundaries between tenants are logical rather than physical, and vulnerabilities that break these boundaries enable cross-tenant attacks. The ChaosDB vulnerability (2021), discovered by Wiz researchers, allowed unauthorized access to other customers' Azure Cosmos DB instances through a flaw in the Jupyter Notebook feature, illustrating how cloud multi-tenancy risks can affect data and potentially supply chain assets.⁶

Availability dependencies mean that cloud provider outages disrupt supply chains. When AWS us-east-1 experiences degradation, npm availability may be affected. When GitHub experiences downtime, millions of CI/CD pipelines fail. Organizations building on cloud infrastructure inherit both the provider's security investments and their single points of failure.

The concentration of supply chain infrastructure in a small number of cloud providers creates systemic risk. If AWS, Azure, and GCP account for the majority of supply chain hosting, the software ecosystem's resilience depends on those three organizations' security postures.

Content Delivery Networks¶

Content Delivery Networks (CDNs) distribute static assets—JavaScript files, fonts, images—from servers geographically close to users. Many websites load JavaScript libraries directly from CDNs rather than bundling them locally. This creates a supply chain dependency where the CDN becomes a trust point: compromise of the CDN enables modifying assets served to website visitors.

The Polyfill.io incident (June 2024) demonstrated CDN supply chain risk vividly and deserves detailed examination as a case study in third-party JavaScript risks.

Background: Polyfill.io was a popular CDN service providing JavaScript polyfills—code that implements modern JavaScript features in older browsers. The service was created in 2014 by the Financial Times as an open source project to help developers support older browsers without bundling unnecessary code for modern browsers. The service dynamically detected browser capabilities and served only the polyfills needed, making it an elegant solution adopted by hundreds of thousands of websites.

The Acquisition: In February 2024, a Chinese company named Funnull acquired the polyfill.io domain and the associated GitHub organization from the original maintainers. Shortly after acquisition, the original project creator, Andrew Betts, warned website operators via social media that he no longer controlled the service and recommended removing any references to polyfill.io from their sites. He noted that modern browsers no longer require most polyfills, making the service largely unnecessary for contemporary development.

The Attack: Beginning in June 2024, the new operators modified the JavaScript served by cdn.polyfill.io to include malicious code. The malicious payload:

• Redirected mobile users to sports betting and adult content sites
• Targeted specific referring domains to avoid detection during analysis
• Used obfuscation techniques to evade automated security scanning
• Included anti-debugging measures to frustrate investigation
• Executed only under certain conditions (mobile browsers, specific referrers) to reduce detection probability

Scale and Impact: Security researchers at Sansec initially identified the attack affecting over 100,000 websites.⁷ Subsequent analysis by Censys found over 380,000 hosts embedding the malicious polyfill script, including 182 government websites.⁸ High-profile properties operated by major corporations were affected, including Warner Bros., Hulu, Mercedes-Benz, JSTOR, Intuit, and the World Economic Forum.

Response: The CDN providers Cloudflare and Fastly responded by creating their own mirrors of the legitimate polyfill.io library code and automatically redirecting requests for cdn.polyfill.io to their clean versions. Google began warning advertisers that their ads would be blocked if served on pages including polyfill.io scripts. Domain registrars eventually suspended the polyfill.io domain, though the attackers registered alternative domains in attempts to continue operations.

Why It Succeeded: The attack was effective because website operators had delegated trust to a third party by including <script src="https://cdn.polyfill.io/..."> in their pages. They had no control over what code that URL would serve in the future. When the service changed hands, so did control over code executing on their visitors' browsers. Many site operators were unaware they included this dependency—it had been added years earlier, perhaps by developers who had since left, or included transitively through other libraries and frameworks.

Lessons Learned:

1. Third-party JavaScript is a supply chain risk: Every external script is a dependency you don't control. The polyfill.io incident was not a technical vulnerability: it was a trust chain failure.

2. Domain and project ownership can change: Unlike package registries where maintainer changes may be visible, domain ownership changes are opaque to downstream consumers. The previous owner's reputation provides no guarantee about future operators.

3. Subresource Integrity (SRI) provides partial protection: Sites that had implemented SRI—a browser feature that verifies loaded resources against expected cryptographic hashes—would have blocked the modified scripts, as the hash would no longer match. However, SRI adoption remains limited, and it doesn't work for dynamically generated scripts like polyfill.io's browser-specific responses.

4. Self-hosting eliminates third-party risks: Bundling dependencies locally rather than loading from CDNs ensures you control what code executes. The performance benefits of CDN loading rarely outweigh the security risks.

5. Audit third-party dependencies regularly: Many affected sites were loading polyfill.io scripts added years ago that were no longer needed. Regular review of external dependencies—including third-party JavaScript—should be part of security hygiene.

The Polyfill.io incident represents a new category of supply chain attack—not compromising a package registry, but acquiring a widely-trusted distribution service and weaponizing it. As more services and domains change hands, similar attacks become increasingly likely.

Similar risks exist whenever websites load resources from external domains:

• JavaScript CDNs like cdnjs, jsDelivr, and unpkg serve libraries to millions of websites
• Font services like Google Fonts serve typography resources with potential for tracking or malicious modification
• Analytics scripts execute on pages with access to page content and user interactions

As noted above, SRI provides partial mitigation by specifying expected cryptographic hashes for externally loaded resources. Browsers verify loaded content against these hashes and refuse to execute content that doesn't match. However, SRI adoption remains limited, and it requires knowing the expected hash in advance, which is problematic for services that update JavaScript content regularly and doesn't cover dynamically-loaded dependencies, images, or other types of content.

Certificate Authorities and Trust¶

Certificate Authorities (CAs) issue the TLS certificates that enable secure connections between clients and servers. When you install packages over HTTPS, your trust that the connection is secure ultimately derives from trust in CAs. CA compromise enables man-in-the-middle attacks against any connection the attacker can intercept.

The DigiNotar compromise (2011) demonstrated CA risks dramatically. Attackers compromised the Dutch certificate authority and issued over 500 fraudulent certificates for high-profile domains including google.com. Investigators identified over 300,000 Iranian Gmail users as the primary targets of subsequent man-in-the-middle attacks. DigiNotar's root certificates were removed from all major browsers, and the company declared bankruptcy within weeks—demonstrating how CA compromise can undermine internet security broadly.⁹

More recently, certificate misissuance—certificates issued incorrectly, whether through error or malice—has affected supply chain-relevant domains. While certificate transparency logs now provide visibility into certificate issuance, detection requires active monitoring.

For software supply chains, CA trust has specific implications:

• Package managers verify registry connections using TLS, depending on CA-issued certificates
• Code signing certificates from CAs authenticate software publishers
• Compromised CAs could enable man-in-the-middle attacks during package installation
• Revocation mechanisms (CRL, OCSP) may not propagate quickly enough to prevent exploitation

Time Synchronization¶

Network Time Protocol (NTP) synchronization may seem distant from supply chain security, but accurate time underpins many security mechanisms:

• Certificate validation checks that certificates are within their validity period. Systems with incorrect time may accept expired or not-yet-valid certificates.
• Signature verification for some schemes depends on timestamp validation. Incorrect time can cause valid signatures to be rejected or invalid signatures to be accepted.
• Log correlation during incident investigation requires accurate timestamps. Systems with time skew produce logs that are difficult to correlate.
• Rate limiting and timeout mechanisms behave incorrectly when system time is wrong.

NTP attacks can manipulate time on target systems. Researchers have demonstrated attacks that shift victim system clocks hours or days from actual time, potentially affecting certificate validation and other security mechanisms. Network Time Security (NTS), standardized in RFC 8915, addresses these weaknesses by using TLS for initial authentication and authenticated encryption for subsequent time synchronization packets—providing cryptographic assurance that time data hasn't been tampered with.¹⁰ However, NTS adoption remains limited, leaving most systems vulnerable to time-based attacks.

The Hidden Infrastructure¶

Modern software depends on a complex web of infrastructure services that developers rarely consider:

Public key infrastructure beyond CAs includes systems like keyservers that distribute GPG keys for package signing, update-framework implementations that manage key rotation, and certificate transparency logs that provide auditability.

Package registry infrastructure includes not just the registry servers themselves but the mirrors, caches, and CDNs that improve availability and performance. Many organizations use caching proxies (Verdaccio, Nexus, Artifactory) that introduce additional trust points.

Build infrastructure beyond CI/CD includes the base images used for container builds, the compilers and toolchains that transform source to binaries, and the orchestration systems that coordinate distributed builds.

Each infrastructure component represents a supply chain dependency. Comprehensive supply chain security requires considering these infrastructure dependencies alongside the more visible software dependencies.

Implications for Security Strategy¶

Infrastructure dependencies create supply chain risks that traditional software composition analysis does not address. Effective security strategy must consider:

Identify infrastructure dependencies: Map the infrastructure services your supply chain depends on—DNS providers, cloud platforms, CDNs, certificate authorities. Understand that compromise of these services affects your security regardless of your own security practices.

Reduce unnecessary dependencies: Self-host where practical. Bundle assets rather than loading from CDNs. Use private DNS where appropriate. Each external dependency is a trust point outside your control.

Implement integrity verification: Use Subresource Integrity for externally loaded assets. Verify package signatures rather than relying solely on TLS. Defense in depth reduces reliance on any single infrastructure component.

Plan for infrastructure failure: Assume infrastructure dependencies will occasionally fail or be compromised. Caching, fallback mechanisms, and incident response plans provide resilience.

Chapter 7 examines attacks targeting distribution infrastructure in detail, and Book 2 discusses defensive measures for securing delivery and deployment. The infrastructure layer explored here provides context for those discussions—a reminder that software supply chain security extends far beyond the packages that appear in dependency manifests.