Secure Your Supply Chain at the Identity Layer

Traditional vendor risk management (VRM) and third-party risk management (TPRM) platforms are built around posture assessment. They send questionnaires, scan vendor-facing web assets, and conduct point-in-time reviews of security controls. These approaches measure what a vendor says about its security practices, not whether vendor employee credentials or device access is actively circulating in criminal markets right now. A questionnaire completed last quarter cannot tell you whether a vendor’s employee was infected by infostealer malware last week, or whether their credentials appeared in a new breach or combolist overnight. Third-party involvement in breaches doubled year over year from 15% to 30% of incidents. The attack path in the vast majority of those cases is not a misconfigured firewall that a scan would catch; it is compromised identity data that gave attackers trusted access. SpyCloud Supply Chain Threat Protection monitors vendor employee domains against recaptured breach records, infostealer malware logs, phishing captures, and combolists continuously, surfacing active identity threats rather than posture indicators.

The Identity Threat Index is SpyCloud’s composite risk score for each monitored vendor, calculated from the volume, recency, and source type of identity exposures detected across that vendor’s employee domains. It combines signals across four threat categories: credential breaches, infostealer malware infections, phishing campaign captures, and combolists. The index gives security teams a normalized, comparable view of risk across their entire vendor portfolio rather than raw exposure counts that are difficult to contextualize. A vendor with a large workforce will naturally accumulate more total exposures than a small vendor; the index accounts for this by weighting exposures relative to the monitoring scope. Tracking the index over time shows whether a vendor’s security hygiene is improving or degrading. A rising trend in malware infections over 60 days is a different risk profile than a one-time breach event from three months ago. Security teams can use the index as their pre-incident response triage layer: instead of waiting for SIEM alerts to escalate into incidents, they can identify which vendors are trending toward elevated risk and act before that risk cascades into their environment.

Vendors and managed service providers typically have privileged or trusted access to enterprise environments: they connect to corporate applications, access shared infrastructure, or operate within the same SSO federation. When a vendor employee’s credentials are stolen through infostealer malware, a phishing campaign, or a third-party breach, those credentials may provide direct access to the same applications the vendor uses to serve the enterprise customer. Attackers who acquire credentials from a vendor’s workforce through criminal markets can test them against corporate login portals, use stolen session cookies to bypass authentication entirely, or use the vendor’s trusted network presence to evade perimeter controls that block unfamiliar IP addresses. This is not a theoretical attack path. It is consistently in the top causes of enterprise breaches. SpyCloud surfaces compromised vendor identities including not just the credential itself but also the exposed applications recorded in infostealer malware logs, showing exactly which applications a vendor employee accessed from an infected device and whether any of those applications are shared with the enterprise environment.

SpyCloud monitors vendor employee domains across four distinct exposure sources. Credential breaches surface username and password pairs from third-party breaches where vendor employees used work email addresses to register for services. Infostealer malware logs capture everything exfiltrated from infected vendor devices: saved passwords, active session cookies, browser-stored credentials, device fingerprints, and a list of every application the device accessed. Phishing campaign captures surface credentials and session artifacts stolen during successful phishing attacks targeting vendor employees. Combolists surface credential pairs that have been aggregated and redistributed from multiple breach sources, which attackers use for automated credential stuffing at scale. Standard dark web monitoring scans indexable portions of darknet forums and marketplaces for mentions of email addresses or domains. SpyCloud recaptures the underlying data directly from criminal sources rather than indexing forum posts, which means it surfaces infostealer log data and phishing kit output that never appear in searchable dark web forums. The result is a significantly broader coverage footprint, particularly for the malware and phishing vectors that are the primary supply chain attack paths today.

When SpyCloud detects that a vendor employee’s identity has been exposed, the security team has two options for acting on that information. They can use it internally to adjust their own controls: increasing authentication scrutiny for connections from that vendor’s domain, restricting access to sensitive systems during the exposure window, or flagging the vendor relationship for accelerated review. They can also share evidence of the exposure directly with the vendor’s security team to enable remediation on the vendor’s side. SpyCloud supports this through a vendor access model that allows enterprise customers to grant vendors visibility into their own exposure data without surfacing the broader enterprise monitoring context. This turns what would otherwise be a one-sided security posture assessment into an evidence-based security partnership. Vendors who can see their own exposure data can take direct action: forcing password resets for affected employees, investigating infected devices, and validating that the exposure path into the enterprise has been closed. The Samsonite case study on SpyCloud’s site describes this model directly: SpyCloud’s Supply Chain Threat Protection enabled their security team to uncover and address supply chain gaps they would not otherwise have known about, and to enforce higher security standards across their vendor ecosystem through shared evidence rather than questionnaire pressure.