Why Attackers Understand Supply Chains Better Than Companies
Published
Key Takeaways
- A vendor can pass compliance checks while still exposing credentials or operating vulnerable systems.
- Companies often rank vendors by contract value; attackers rank them by access and exposure.
- Tapkan described data curation as an art that AI is now making harder, not easier.
- Findings frequently stall because ownership disappears between procurement, IT, and security teams.
- Black Kite observes attackers target upstream vendors because smaller suppliers often offer higher ROI and lower visibility.
Müzeyyen Gökçen Arslan Tapkan, Director of Data Research at Black Kite, warns that organizations still confuse compliance posture with actual security risk, creating blind spots across third-party risk programs.
In this LeadHER in Security interview, Tapkan, whose work focuses on AI governance, cyber risk intelligence, and enterprise security systems, explained why attackers understand supply chains better than defenders.
Tapkan says vendors can quickly shift from low risk to high risk because vulnerabilities, exposed credentials, and infrastructure weaknesses change continuously.
AI is worsening noise, misattribution, and confidence problems inside cybersecurity datasets all while many organizations deploy automation without redesigning systems around human decision-making.
We explore why attackers target upstream vendors, companies rank vendors by spend instead of exposure paths, and why concentration risk hides beneath supposedly diversified vendor ecosystems.
Vishwa: Can you share one pattern you’ve observed in cyber risk data that feels more layered or complex than it first appears?
Müzeyyen: Working on the compliance side of cybersecurity for years, and bringing AI into that mixture in the past 5 years, I've observed a particular assumption across organizations: the belief that compliance posture and security posture should align. They don't, at least not in the way most programs assume.
- A vendor can hold a clean SOC 2 Type II and still expose credentials
- run unpatched devices, or
- sit on infrastructure with active ransomware indicators
The compliance documentation or questionnaires, capture only a moment, scoped to specific systems. The technical signal is continuous, ecosystem-wide, and indifferent to scope.
What makes this layered is the unspoken assumption that the two pictures should match. At Black Kite, these live on different modules, with real intersection between them, of course. That intersection is actually what excited me when I first joined: the chance to work on the place where compliance and live cyber risk meet, instead of treating them as separate worlds.
- Compliance answers: Did this organization meet a defined control set during a defined window?
- Cyber risk intelligence answers: What is exploitable about this organization right now?
When teams use the answer of the first also as an answer to the second, then they have this blind spot.
Vishwa: When you look at how organizations assess third-party risk, where does the data tend to tell a different story than internal assumptions?
Müzeyyen: Internal assumptions are usually shaped by the human mind. The relationship with the vendor sits at the top of the list — including the history, both in social and technical terms.
Perception matters a lot. We tend to rank vendors by:
- spend
- contract size, or
- executive visibility
- The data ranks them by exposure path.
- Those two lists occasionally match.
- The data ranks them by exposure path.
A small SaaS tool used by one team can hold more access than a multimillion-dollar enterprise platform. The size of the invoice does not tell you about identity, data flow, or how deep the integration goes.
When we compare the technical signals to a company's critical-vendor list, we often see the same thing: a Tier 3 vendor with read access to a production database carries more real risk than a Tier-1 vendor with a clean, monitored integration.
But even looking at the exposure path once does not solve the problem. A vendor may have been carefully reviewed during procurement, but that view expires quickly.
An A-level vendor-a star vendor- can become a C-level vendor in a single day, with one freshly discovered vulnerability.
This is exactly what continuous monitoring is trying to achieve: moving the question from:
"What did we see at onboarding?" to "What are the continuous signals telling us right now?"
And honestly, this is a wilder time than ever, because AI is changing how fast vulnerabilities get discovered both by defenders and by attackers.
Vishwa: Risk scores are widely used to simplify decision-making. Where do they risk oversimplifying?
Müzeyyen: It is true that a single rating compresses a multidimensional picture into one number. But that compression comes from a real need. Our brains are not shaped to process multidimensional risk, especially in fight-or-flight moments.
A simple rating gives the mind something to hold onto first, before it can take in more. So I do not see ratings as the problem.
I also do not see pages of complex reports as the cure. Neither one, on its own, is the answer. What matters is how the signals are consumed.
A rating is a great starting point — not to scare executives, and not to overwhelm technical teams with hundreds of lines of findings. It tells you whether to pay closer attention.
From there:
- you add a few more signals to the mixture
- set an alert level, and
- go deeper where it actually matters
- That is the part most programs miss.
- They either stop at the rating, or they get lost in the report.
- Neither approach helps anyone make a decision.
The way I think about it: a rating is the first signal of many, not the final word.
The job of a good TPCRM program is to make the path from "first signal" to "deep dive on the right vendor" short, defensible, and fast.
Vishwa: As datasets grow richer, what becomes harder to interpret?
Müzeyyen: Signal-to-noise gets harder, for sure. But the deeper problem, and the one I keep coming back to, is data curation.
Working on the data and AI side, I see curation as an art - an old art that is almost forgotten because of AI.
There is a small joke in that, but it is also a real problem. And AI is making it worse, not better. So much noise, and so much misattribution, come in as datasets grow.
AI brought massive data into our equations and we welcomed it as a blessing, almost as if there would be no repercussions. There are.
The problem now lives on both sides:
- The input side, where the quality and provenance of the data going into the model and
- The output side, where confident-sounding answers can hide the fact that the underlying signals were never clean to begin with
- This is why so much of my engineering time goes into data quality, result validation and consensus across models.
When data is rich, the cost of being wrong confidently goes up. The richer the dataset, the more discipline curation demands, not less.
Vishwa: When data is available but not acted upon, what could get in the way of the transition from insight to decision?
Müzeyyen: My first answer, instinctively, would be ownership; an old problem that never goes out of style.
A finding can land in a place where there is no accountable party. IT thinks procurement owns the vendor, procurement thinks IT owns the risk, and the finding ages.
A more technical one is the trust. Teams hesitate to act on findings they cannot fully explain. If a model flags a vendor as high-risk and the analyst cannot trace the reasoning, the finding gets quietly deprioritized.
This is where the quality of your security automation comes into play. To be more specific, both the rule-based components and the non-deterministic AI components are the main barriers to trust and the main path through it.
Findings only make their way to a decision when the people accountable can stand behind the evidence.
Vishwa: What is one way organizations should start looking at third-party risk differently if they want to stay ahead?
Müzeyyen: Working in a cyber-rating company, and now being a continuous monitoring advocate, my number-one advice is this: stop treating the vendor list as a static inventory and start treating the cyber ecosystem as a living system.
The other extreme is trusting the automation too much and stepping out of the decision-making - which brings to the second advice although uncomfortable. No matter how intelligent your security automation software is, you have to design your own HITL — your own human-in-the-loop.
We have been talking about HITL for over three years now, and I have been one of the people saying it loudly at conferences, as if implementing it is easy. (It is not.)
What many people are ignoring is that HITL in TCPRM requires a new system design.
- Who approves an onboarding when the cyber rating drops below a threshold?
- Who decides to escalate when a vendor's exposure changes overnight?
Many organizations have deployed intelligent automation and AI without ever changing their underlying system architecture to support these decision shapes. That is the part I want more people to sit with.
Saying HITL in TCPRM is easy. Designing for it , vendor by vendor, signal by signal, decision by decision, this is the real work.
Vishwa: In supply chain attacks, what part of the attacker’s decision-making process is still not well understood?
Müzeyyen: Honestly? Target selection at the Nth-party layer. And I want to be transparent — this is an area we are actively trying to understand and model, not one we have already solved.
Defenders have gotten reasonably good at modeling why a direct vendor gets chosen:
- high access
- broad customer base
- weak controls
What is less understood is how attackers identify and prioritize targets two and three hops upstream. In such a case, a single compromise can cascade through dozens of downstream organizations who do not even know the vendor exists in their supply chain.
We have seen numerous attacks follow this pattern, and we do not believe it is a coincidence. An attacker compromising a small, specialized service provider may be making a far more rational ROI decision than one going after a known SaaS vendor with mature security.
The economics of attacking favor depth and the visibility advantage favors the attacker, because most organizations cannot see past their first-tier vendors.
Vishwa: When you connect different data points across vendors, what kinds of relationships or dependencies tend to emerge unexpectedly?
Müzeyyen: Concentration risk is almost always larger than organizations think it is. When you map the ecosystem properly, you find that vendors who appear independent on a procurement spreadsheet are running on the same cloud region, the same identity provider, the same DNS infrastructure, or the same code-signing authority.
A diversified vendor portfolio can have a single point of failure buried four layers down. What is more interesting is that most of this is public data. You do not need fancy cybersecurity tools to see it; the signals are out there, sitting mostly in public places.
- Trust centers
- DNS records
- public filings
- code repositories
- breach disclosures
- The data has been there the whole time
The other pattern that surfaces is temporal correlation: clusters of vendors that experience the same exposure at roughly the same time, because they all consume the same upstream software component.
When a vulnerability hits a widely embedded library, the question is nowadays mostly "Which of my vendors are exposed and why?" rather than “Is my vendor exposed?”
Related
Get expert insights on threats, breaches, scams, and security trends — delivered every Monday.
Most Popular
Get expert insights on threats, breaches, scams, and security trends — delivered every Monday.
Most Popular