A man-in-the-middle (MITM) attack happens when an adversary secretly intercepts, and often alters, communication between two parties who believe they are talking directly to each other. The attacker sits on the network path — between a laptop and a Wi-Fi router, between a CI/CD runner and a package registry, or between a browser and a bank's login server — and can read credentials, inject malicious payloads, or swap out a legitimate software package for a tampered one. MITM isn't a single exploit; it's a category of techniques (ARP spoofing, DNS hijacking, rogue access points, BGP hijacking, TLS stripping) that all achieve the same outcome: unauthorized interception of a trust relationship. For software supply chain teams, the stakes are higher than stolen passwords — an intercepted npm install or pip download over plaintext HTTP can silently plant a backdoor in a production build.
What is a man-in-the-middle attack?
A man-in-the-middle attack is any scenario where a third party covertly relays and can manipulate communications between two systems that believe they have a direct, private connection. The term dates to classic cryptography discussions of the 1980s, but the technique predates computers entirely — it's the digital version of a mail carrier steaming open a sealed letter, reading it, and resealing it before delivery. In modern networks, MITM attacks fall into two phases: interception (getting on the communication path) and decryption/manipulation (reading or altering the data once intercepted). CISA's 2022 guidance on network protections specifically calls out MITM as a top technique used against remote work infrastructure, VPN concentrators, and cloud API traffic.
How do attackers position themselves between two parties?
Attackers get on-path using five well-documented techniques: ARP spoofing, DNS spoofing, rogue Wi-Fi access points, BGP hijacking, and SSL/TLS stripping. ARP spoofing works on local networks — a tool like Ettercap or Bettercap sends forged ARP replies so a victim's traffic routes through the attacker's machine instead of the real gateway. DNS spoofing poisons a resolver's cache so a hostname like registry.npmjs.org resolves to an attacker-controlled IP. Rogue access points (the "Wi-Fi Pineapple" is the best-known commercial device for this) impersonate a trusted SSID like "Airport_Free_WiFi" so victims connect voluntarily. BGP hijacking operates at internet scale: in April 2018, attackers hijacked Amazon's Route 53 DNS service via a rogue BGP announcement through a small ISP (eNet), redirecting MyEtherWallet.com users to a phishing clone and stealing roughly $152,000 in Ethereum in two hours. SSL stripping, popularized by Moxie Marlinspike's sslstrip tool in 2009, silently downgrades HTTPS connections to HTTP so an attacker already on-path can read traffic in cleartext.
What are real-world examples of man-in-the-middle attacks?
Four incidents illustrate the range of MITM impact, from certificate authorities to Wi-Fi protocols to cryptocurrency theft. In 2011, attackers compromised Dutch certificate authority DigiNotar and issued over 500 fraudulent SSL certificates, including one for *.google.com, which was used to intercept Gmail traffic for an estimated 300,000 Iranian users before the CA was shut down. In 2015, Lenovo shipped roughly 750,000 consumer laptops with preinstalled adware called Superfish that injected a self-signed root certificate into every device, letting the software (and anyone who extracted its private key, which researchers did within days) intercept and modify HTTPS traffic on those machines. In October 2017, Mathy Vanhoef disclosed KRACK (Key Reinstallation Attack), a flaw in the WPA2 Wi-Fi protocol itself that let attackers within radio range force nonce reuse and decrypt traffic on nearly every WPA2-protected network then in existence. And the 2018 MyEtherWallet BGP hijack described above showed that MITM isn't limited to local networks — it can operate at the routing-table level of the entire internet.
How does a man-in-the-middle attack threaten the software supply chain?
A man-in-the-middle attack threatens the software supply chain by intercepting the exact moment a build system trusts a remote source — a package registry, a container registry, or a CI/CD artifact store — and substituting malicious content for legitimate code. Package managers that fall back to HTTP, resolve dependencies through misconfigured internal proxies, or skip integrity verification are the highest-risk points: if a CI runner fetches a dependency and an attacker on the network path (a compromised corporate switch, a poisoned internal DNS record, or a rogue AP on a shared build farm) intercepts that request, they can return a trojanized package that matches the expected filename and version string. This is distinct from but compounds dependency confusion and typosquatting attacks, because MITM lets an attacker tamper with a correctly named package rather than relying on a victim mistyping or misconfiguring a source. Sigstore's 2021 push for artifact signing and the 2020 SolarWinds incident (where build-server tampering, a related on-path compromise, injected the Sunburst backdoor into signed binaries used by roughly 18,000 organizations) both underscore why code signing and provenance verification, not just TLS, are required to close this gap.
How can you detect a man-in-the-middle attack?
You detect a man-in-the-middle attack by watching for certificate anomalies, unexpected latency, and duplicate or conflicting network identities. Certificate pinning failures and browser warnings ("Your connection is not private," HSTS violation alerts) are the most direct signal — if a client expects a specific certificate fingerprint and gets a different one, that's evidence of interception, which is exactly how researchers first caught the 2011 DigiNotar fraud when Chrome's built-in pinning for Google domains flagged the forged certificate. On networks, duplicate ARP entries for the same IP, unexplained ARP table churn, or a gateway MAC address that suddenly changes are classic signs of ARP spoofing, detectable with tools like arpwatch or XArp. At the routing layer, BGP monitoring services (RIPE RIS, BGPStream) can flag when a network's IP prefixes are suddenly announced by an unfamiliar autonomous system, which is how the security community traced the 2018 MyEtherWallet incident back to eNet within hours. In CI/CD pipelines specifically, checksum or signature mismatches on downloaded artifacts, unexpected changes in a package's SHA-256 hash between builds, and DNS resolution results that don't match expected registry IP ranges are the equivalent supply-chain tells.
How do you prevent man-in-the-middle attacks?
You prevent man-in-the-middle attacks by enforcing end-to-end encryption, verifying identity cryptographically at every hop, and eliminating fallback paths that let an attacker downgrade a secure connection. That means TLS 1.2+ everywhere with HSTS preloading (so browsers refuse to even attempt an HTTP connection), certificate pinning for high-value API clients, DNSSEC to prevent DNS spoofing, and mutual TLS (mTLS) for service-to-service traffic inside a cloud environment. On Wi-Fi, WPA3 replaced the KRACK-vulnerable WPA2 handshake with a more resistant protocol starting in 2018. For the software supply chain specifically, prevention means signing every artifact (Sigstore/cosign, npm's provenance attestations rolled out in 2023), verifying signatures before install rather than trusting registry metadata alone, pinning dependency versions and hashes in lockfiles, and routing all package fetches through registries and proxies that enforce TLS with no plaintext fallback.
How Safeguard Helps
Safeguard closes the gaps that MITM attacks exploit across the software supply chain, starting with visibility into what's actually running. Our SBOM generation and ingest pipeline gives security teams a verified inventory of every dependency and its provenance, so a tampered or substituted package introduced via network interception stands out against a known-good baseline instead of blending into an opaque dependency tree. Griffin AI correlates that inventory with runtime and code context to flag anomalous package behavior — like a dependency reaching out to an unexpected endpoint post-install — that's a common downstream signature of an MITM-injected payload. Reachability analysis then tells teams whether an affected component is actually exercised in their build or runtime path, cutting through noise so a compromised transitive dependency gets triaged in minutes rather than days. When a fix is available, Safeguard opens an auto-fix pull request that pins the verified, signed version, closing the exposure window before an attacker on the network path gets a second chance.