Every few months I sit in a conversation with a security team, a regulator, an analyst, or an awards committee and face the same question: where do you fit?

The cybersecurity industry has spent thirty years building a rich taxonomy of domains. Cloud security. GRC. Vulnerability management. Attack surface management. Identity. SIEM. Each category has a clear definition, a competitive set, a set of evaluation criteria, a buyer persona. The industry knows how to think about these things.

For years, we tried to fit ThingsRecon into existing categories. Eventually, it became clear the issue wasn’t positioning, it was that the map itself is incomplete.

What the Existing Categories are Built On

Every established category in cybersecurity is, at its core, built around something the organization already knows about:  

• Cloud security protects infrastructure you control

• GRC evaluates vendors you have declared

• Vulnerability management operates on assets you have already identified

• Attack surface management starts from your own domains and works outward

Supply chain security starts from the opposite premise:

The most material risk exists in the dependencies you rely on but do not fully control, and often do not fully know about.

A vendor your procurement team approved last year. A subprocessor three tiers down that your vendor's vendor uses. An API integration a development team added without going through formal procurement. A subdomain from a decommissioned partnership that is still, technically, live.

When we run a discovery scan on an organization's external surface, we start from their own domains, following DNS records, reading scripts, tracing API endpoints, analyzing headers and certificates. The picture we reconstruct is consistently larger than anyone expected.  

Active third-party connections run two to five times the number on the official vendor list. Not because organizations are careless. Because this is how digital supply chains grow: continuously, organically, faster than any manual process can track.

That gap between the declared vendor list and the live digital reality is not a compliance finding; it’s the real attack surface. It is where SolarWinds happened or MOVEit happened. Where the municipality in Tirana had its wifi, its traffic cameras, and its revenue systems taken down in the same attack, because they were all connected, and nobody had mapped the chain.

Why This Matters for How the Industry Thinks

I recently came across a government ministry working toward NIS2 compliance. Their compliance team was working through the requirement to assess third-party supplier security. They came back with a question that stopped the process: how do we know who our third-party suppliers are?

More than a maturity questionm this is a discovery question. The tooling the industry has built assumes the answer already exists:

• GRC platforms evaluate declared relationships.  

• Vendor questionnaires ask known suppliers about their security posture.  

• Compliance frameworks define what needs to be assessed.  

None of these tell you what is actually connected to your infrastructure right now, because they weren’t designed to.

Introducing the Supply Chain Intelligence Category

When I look at how industry awards programs categorize solutions, I understand the logic. NIST provides a functional framework where categories map to functions. The result is a coherent structure for evaluating most of what exists in the market.

But Supply Chain Intelligence, defined as the continuous discovery and mapping of the full digital supply chain, including subprocessors, hidden dependencies, infrastructure concentrations, and the relationships between all of the above, does not fit that structure because the function itself is missing.

Grouping it into GRC, TPRM, or vulnerability management forces comparisons between solutions that answer fundamentally different questions.

A platform that discovers unknown dependencies cannot be evaluated against one that scores known vendors.

What Makes Supply Chain Intelligence Different

Supply Chain Intelligence differs from adjacent disciplines in three ways that matter for how it should be evaluated.

1. In scope, it maps what exists, not what has been declared. The starting point is the live digital environment, not the vendor list or the compliance register.

2. In method, it operates continuously, not on audit cycles. Continuous monitoring is a prerequisite for the category to function.

3. In consequence, the failure mode is systemic. When a supply chain dependency fails, the impact does not stay contained. It propagates downstream across organizations that believed they were managing exposure independently. The scale of potential impact is categorically different from a missed vulnerability in a known asset.

This Is Bigger Than One Company

We built ThingsRecon because we believed there was a gap in how the industry understood digital supply chain risk, and we found a truly different approach to go about it (read more about it here.)

This is about recognizing that a new discipline has emerged, one that requires its own definitions, evaluation criteria, and understanding.

Buyers, regulators, and analysts need a shared way to answer:

• What does this category do?  

• How is it different?  

• How should it be evaluated?  

Until that exists, we will continue trying to fit a fundamentally new problem into outdated structures.

The industry already recognizes that supply chain risk is one of the defining challenges of the current threat landscape. Gartner and Forrester have both identified it as a primary emerging vector. NIS2 and DORA have written continuous supply chain visibility into law. The 2025 Verizon DBIR reported that third-party involvement in breaches doubled in a single year, reaching 30% of all confirmed incidents.

The infrastructure exists to recognize this as a distinct domain. The market activity exists. The regulatory demand exists. The only thing that does not yet exist is a category.

We are proposing that it should.

‍