Supply chain attacks: when your vendor is the attacker's toehold

A field-update explainer published on this site. Sources at the bottom.

Over the past five years, supply-chain and third-party breaches have roughly quadrupled in frequency. 2026 has been particularly bad: the year the pattern stopped being a quarterly headline and became a weekly one.

This post collects three concrete recent incidents and pulls out the patterns they share. The pattern matters more than the specifics: these will keep happening, and the defenses are mostly the same regardless of which vendor turns out to be the entry point next.

Three incidents from 2026

Korean Air via a catering vendor

Korean Air disclosed a data breach in early 2026 originating not in their own systems but in KC&D Service, a vendor managing inflight catering and duty-free operations. The Cl0p ransomware group claimed responsibility and reportedly exploited an Oracle E-Business Suite vulnerability in the vendor's environment.

The blast radius: personal data on roughly 30,000 Korean Air employees, including names and bank account numbers. From an attacker perspective, the airline was the prize; the catering vendor was the way in.

Trust Wallet's Chrome extension supply-chain compromise

Trust Wallet, a major cryptocurrency wallet provider, disclosed a second Shai-Hulud supply-chain compromise of their Chrome extension in 2026. Attackers obtained a leaked Chrome Web Store key and used it to publish a tampered version 2.68 of the extension that exfiltrated wallet recovery phrases every time a user unlocked the extension.

Documented losses: approximately $8.5 million in user funds.

The compromise wasn't of Trust Wallet's code in their git repository. It was of their publishing pipeline, the keys and processes between "the developers approve a release" and "the extension store ships a new version to every user."

Marquis Software → 1.35M US bank customers

Marquis Software, a vendor used by financial institutions for marketing and customer engagement, was breached in August via a SonicWall vulnerability. Two of their customers (Artisans' Bank and VeraBank) disclosed that customer data had been exposed. Researchers estimate the incident may have affected up to 1.35 million people across dozens of financial institutions that all relied on the same vendor.

None of the affected banks were directly compromised. The single shared vendor was the multiplier.

The pattern

In all three cases, the attacker did not need to get past the target's security perimeter. They got past a vendor's security perimeter, and the vendor handed them the access by virtue of the integration.

Specific shapes:

Vendor → customer data: Korean Air, Marquis. The vendor handles your data; if their systems are compromised, your data leaks. There is no firewall configuration on your end that prevents this.
Vendor → customer code paths: Trust Wallet's extension store keys, npm package compromises, container base image compromises. The vendor ships software your users run; if their pipeline is compromised, your users execute attacker code with full app permissions.
Vendor → customer trust: SaaS integrations with read/write OAuth scopes into your environment. The vendor's compromise is your compromise, transitively.

What to demand of vendors

The enterprise security questionnaire was designed for a different era. The questions it asks ("do you have ISO 27001?" "do you encrypt at rest?") are still necessary but increasingly insufficient. The questions that matter for supply-chain risk in 2026:

What is your software supply chain? Specifically: how is your CI/CD pipeline secured? Who can approve a release? Are signing keys hardware-backed? Do you have reproducible builds?
How are publishing credentials stored? (For Trust Wallet, the answer should have been "in an HSM, with manual approval per release." It evidently wasn't.)
What's your incident-disclosure SLA to us? Many vendors take days to weeks to disclose. By then, the data is on the dark web. Demand single-digit-hour SLAs in the contract.
What's the blast radius of an OAuth token issued to your service? Read-only on a specific scope is acceptable. Mail.ReadWrite.All + offline_access is a different conversation.
What's your access to our environment when a contract ends? Stale offboarding is a leading source of "former-vendor breach" stories.

What to instrument internally

Because the vendor will eventually be compromised, your detection layer has to assume that.

Anomaly detection on vendor traffic. Vendor X normally pulls 50 records a day; today they pulled 5 million. That should page somebody.
Per-vendor identity. Every vendor integration gets its own service account with its own credentials, never a shared one. Then a single compromise rotates one credential, not your whole environment.
Vendor-scoped audit logs. Tag actions by which vendor's identity executed them. When the next disclosure email arrives, you should be able to query "show me everything Vendor X did in the last 90 days" in seconds, not days.
Treat third-party JS like attacker JS. Subresource Integrity (SRI) on all script tags. CSP script-src that doesn't trust everything. The Trust Wallet incident is the same class of bug as the Polyfill.io supply chain compromise from 2024: a third-party CDN you trusted shipped malicious code.

The honest framing

You cannot security-questionnaire your way out of supply-chain risk. The questionnaire is a snapshot of the vendor's posture on one Tuesday, filled in by their sales team. The breach happens on a Saturday two years later because somebody forgot to rotate a key.

The defense is assume vendor compromise as a baseline scenario, instrument for it, contract for fast disclosure, and reduce the vendor blast radius to whatever the integration strictly needs and not a permission more. That's the boring answer. It's also the only one that works.