Two Supply Chains, One Attack Surface: Why Third-Party Risk Needs a New Brand

October showed us where third-party risk really lives

In three weeks of October 2026, attackers used a stolen ConnectWise Cloud Backup app credential to sign into customers' Microsoft 365 tenants, Railway leaked customer secrets, a WordPress vendor's stolen connection keys pushed backdoors into customer sites, and an official CLI's release binaries were swapped for an infostealer. Developers and thus the rest of the internet started calling it Black October.

Many incidents do not begin with a novel exploit. Instead they begin with a stolen token, an unrotated admin key, or an application credential. A lot the malware arrives through channels customers were told to trust like official update servers, signed commands, and verified release pages. This is not a new problem either. In 2021 hackers bought stolen session cookies for Electronic Arts's internal Slack channel on the dark-web marketplace Genesis Market for roughly $10. Because the authentication cookies were still valid, the attackers bypassed password requirements and two-factor authentication (2FA). Once in, they messaged an EA IT helpdesk representative, claimed they had lost their phone at a party the night before, and asked for a 2FA login token. The helpdesk issued it, granting the intruders access to EA's internal network, where they stole 780 GB of source code, including the source code for FIFA 21 and the proprietary Frostbite game engine. Oops.

The point is that it should change how we think about third parties. The question is no longer only whether a vendor is secure but rather we should start asking what that vendor can reach inside your environment when its security fails, and how quickly you can know. You want to know how likely is this vendor to be breached or attacked? Unfortunately, assurance helps but mostly falls flat here with attestations.

October also exposed a structural flaw. The industry treats the software supply chain and the vendor supply chain as two separate problems, owned by different teams and served by different tools but attackers treat them as one.

A tale of two supply chains

The market splits supply chain risk into two categories that rarely meet.

• Software supply chain security covers SCA, SBOM management, and reachability analysis. It examines the components inside code you build, the domain is confined mostly to application & cloud security
• Vendor supply chain risk covers third-party risk management, questionnaires, and security ratings. It sees a vendor's paperwork and internet-facing hygiene, but not how the vendor integrates, what data it has access to and how that changes over time with the arrival of MCPs and increasingly third party vendor agents.

Each view is useful but both provide an incomplete picture that leaves organizations vulnerable, and operationally inefficient in the event of a breach. That is to say, companies dont understand A vendor can pass its questionnaire, score well on ratings, and appear nowhere in an SCA report, while holding a credential with administrator rights across your tenant. Many of the October incidents crossed the line between these two categories, which is where defenders lose sight of the attacker.

At Ethira, we've spent a long time on one idea: the digital supply chain and third-party risk are not two problems. They're one, and they belong in a single view. "Single pane of glass" is an overused phrase, but it's the honest description of what we built. One place where a company can see external threats to its third parties, measure that against how those vendors are supposed to behave , and decide whether a signal demands action or creates real liability.

We break this into three layers. External is what the world can see: attack surface, dark web activity, and breach signals. Declared is what a vendor says it is: its composition, components, and contractual commitments. Internal is what it actually does inside your environment. Only when all three line up do you get a true answer.

Layer one: the external attack surface

The outside-in view (also known as the external attack surface) is the earliest warning system, because attackers look here first. It answers a simple question: is this vendor showing signs of weakness or an active target of threat campaigns right now?

• External attack surface. Exposed services, unpatched edge devices, expired certificates, misconfigured cloud storage, and forgotten subdomains. These reveal how well a vendor manages what it has put on the internet.
• Dark web and criminal activity. Leaked employee credentials, stolen session tokens, access-broker listings, and breach claims. A vendor's credentials for sale is a far stronger signal than any questionnaire answer.
• Code and release hygiene. Pinned dependencies, signed artifacts, and protected publishing workflows.
• Regulatory and corporate signals. Licence status, enforcement actions, ownership changes, and financial distress, which often precede neglected security.

Outside-in data is necessary but not sufficient. It tells you a vendor is at risk but what it cannot do is tell you whether that risk matters to you.

Layer two: inventory and expected state

Companies need first and foremost an accurate and up to date inventory of which third parties exist in their systems, what has been approved and what is the expected scope for the supplier.

• A complete up to date vendor inventory: this includes more than just the questionnaire but the integrations, the API keys, MCP servers and third party agents
• Software bills of materials. SBOMs from the vendor, or composition inferred from public artifacts where none are provided.
• Open source editions. Many vendors sell a commercial product on an open source core. A flaw in the community edition usually exists in the paid one, and the two may be built and patched through very different pipelines.
• Fourth parties. The hosting, identity, and build providers the vendor depends on in addition to their subprocessors.

The inventory expected state tells your organization how you want the supplier to behave but It is still a declared picture, and over time these drift from reality. That is

Layer three: internal integrations & and reachability

You may not be able to see inside a vendor's code, but you can see exactly where it touches yours.

• Identity and privilege. The OAuth grants, API keys, service accounts, and directory roles each vendor holds, and what those permissions can read, write, or administer.
• Data flows. What data leaves your environment for each vendor, and how sensitive it is.
• Runtime footprint. Agents, plugins, CLIs, and auto-updating software running on your hosts and developer machines, and the secrets that sit beside them.
• Business dependency. Which production systems and customer-facing services would stop, or be exposed, if a vendor were compromised.

This layer turns a vendor's risk into your exposure, and much of the data it needs already lives in the providers you already have live today. It is also where the most practical fixes live: reducing scopes, removing unused SDKs, pinning versions, and isolating agents.

A full stack approach

Joined together, the three layers produce one measure: where do I land in the 'am i f***ed o-meter' if a threat actor compromises this supplier. Jokes aside, it is critically important to understand vendor reachability & blast radius analysis nearly instantly in the event of a suspected breach.

Each layer filters the next. Outside-in signals tell you which vendors deserve attention now. Inventory & composition expectations tell you which of them carry an upstream problem. The in-environment view tells you which of those can reach something that matters, and through what path.

The result changes how decisions are made. Truly understanding risk, and where to focus attention, a critically scarce resource these days, starts from a ranked list of exposed integrations instead of a vendor spreadsheet. Procurement can compare two vendors by the access each would require before signing. Renewals become a chance to shrink a vendor's footprint, not just renegotiate price.

October Examples

Each of October's major third-party incidents might would have looked something like this:

The pattern is consistent in that outside-in data raises the alarm, composition tells you who might be affected, and the in-environment view tells you whether you are, and what to do first.

So, what do you do now?

Closing this gap does not require another scanner or another ratings feed. The data already exists, scattered across the identity providers and AppSec tools organizations run today. What is missing is the layer that joins it around each vendor, and tests every third party against what it can actually reach.

1. Scope to third parties. Set aside the thousands of findings in first-party code, and focus only on where a vendor's identity, SDK, agent, or component touches your environment.
2. Prove reachability and exploitability. Show what each third party can actually reach, from OAuth scopes and service accounts to the functions your code calls in a vendor SDK.
3. Use outside-in signals as the trigger. Attack surface and dark web intelligence tell you when to look. Reachability tells you whether it matters.
4. Deliver decisions, not scores. Ranked actions for incident response, procurement, and renewal: rotate this key, cut this scope, choose this vendor.

The goal is to answer one question within minutes of the next incident: are we exposed through this vendor, and what do we do first? Five steps get you there.

1. Inventory integrations, not just contracts. List every OAuth app, API key, agent, SDK, and CLI that belongs to a third party, and tie each one to a vendor record.
2. Rank vendors by blast radius, not by spend. A low-cost backup tool with tenant-wide write access deserves more scrutiny than an expensive analytics platform that only reads anonymized data.
3. Watch the outside continuously. Monitor vendor attack surfaces and dark web activity so you hear about a compromise before the vendor's disclosure arrives.
4. Demand evidence of composition. Ask for SBOMs and know which open source editions and fourth-party platforms each vendor relies on.
5. Shrink what vendors can reach. Cut excess scopes, pin versions and image digests, disable unneeded auto-updates, and rotate the credentials vendors hold.

Third-party risk programs that only ask whether a vendor is secure will keep learning about their exposure from the news. Programs that know what each vendor can reach will already be rotating the right keys. That shift, from managing vendors to managing exposure across both software and vendor supply chains, is the problem Ethira exists to solve.

Sources

• Black October 2026: every supply chain attack, explained, Agentbeam
• Hackers breach Microsoft 365 tenants via ConnectWise supply chain attack, BleepingComputer
• ConnectWise suspends Cloud Backup, Cybersecurity Dive
• LiteLLM hit by second supply chain attack this year, Help Net Security