Vendor risk programs ask the wrong questions and get the wrong answers. Here is how to apply a CTI lens to the suppliers most likely to bring an adversary into your network.
Most vendor risk programs were built for a world where the bad outcome was an outage or a data leak from a single negligent supplier. They ask vendors to fill in long questionnaires once a year, collect SOC 2 reports, file the answers, and call it governance.
That world still exists. It is not the world threat actors are operating in. The actors who matter have learned that the easiest way past a hardened enterprise perimeter is a small software vendor with one engineer, no signing pipeline, and an update channel that runs as SYSTEM on every customer host. The questions on the annual questionnaire do not detect that.
A CTI lens on supply chain is not a replacement for the existing program. It is a layer on top that asks a different question. Which of our vendors are most likely to bring an adversary into our network in the next six months, and what would we see when it happens.
The three vendor categories that actually matter
Most vendor lists are long, mixed, and unprioritized. The first job is to sort them into three categories that map to adversary opportunity.
The first category is software vendors with privileged code execution. These are the EDR agents, the monitoring agents, the patch management clients, the remote access tools, and the build pipeline integrations. Their code runs with high privileges across the fleet. If the vendor's update channel is compromised, the adversary inherits those privileges everywhere. This is the SolarWinds shape. There are usually fewer than twenty of these vendors in a typical enterprise. Treat them with the most attention.
The second category is service providers with persistent access. These are the managed service providers, the helpdesk outsourcers, the consultants with VPN credentials, the cloud administration partners, and the SaaS integrations with broad OAuth scopes. They do not run code on every host, but they have legitimate identity inside your environment. If the service provider is compromised, the adversary inherits a trusted identity. This is the Kaseya and the MSP breach shape. There are usually a few dozen of these. Treat them with the second most attention.
The third category is everything else. The marketing tools, the productivity SaaS, the procurement portals, the niche analytics platforms. They process data, sometimes sensitive data, but they do not have code execution or persistent identity inside your perimeter. The standard vendor risk program is mostly the right tool for this group. The CTI lens does not add much.
A small spreadsheet that sorts every vendor into one of these three buckets is more useful than a five thousand row vendor registry.
What to ask about category one vendors
For software vendors with privileged code execution, the annual questionnaire is the wrong instrument. The CTI lens asks operational questions about the things an adversary would have to do.
How is the update channel signed and verified on the endpoint. Specifically, does the agent verify signatures against a pinned public key or does it trust the OS certificate store. Pinned is better.
What is the build pipeline. Where is the source code stored. Who has commit rights. How is the build environment isolated. Are build artifacts reproducible. The answers tell you how hard the compromise would be.
What is the vendor's own detection posture. Do they monitor their own pipeline for unexpected commits or builds. Do they monitor outbound traffic from their build environment. Would they notice a foreign push.
What is the vendor's history of disclosure. When they have had a security event, did they disclose it in time, with technical detail, and with customer specific impact analysis. Vendors who disclose well in the past tend to do so in the future.
What telemetry does the agent emit that the customer can ingest. The most resilient supply chain control on the customer side is being able to see the agent's behavior. If the EDR agent emits its own update events, the customer can detect a foreign update before it spreads.
The answers do not have to be perfect. The point is to know where the gaps are and to weight the vendor's risk accordingly.
What to ask about category two vendors
For service providers with persistent access, the question is about identity hygiene on both sides.
How are the credentials provisioned. Are they per individual, scoped, and rotated. Or are they shared accounts that have been in use for years. Per individual and scoped is the only acceptable answer for a privileged partner.
What MFA do they enforce on their end. Phishing resistant is the goal. Push notification MFA is better than nothing but it has known bypass paths. SMS is a liability.
What is their joiner mover leaver process for accounts that have access to your environment. When someone leaves the vendor, when does your access removal happen. Measure in hours, not days.
What logging do they retain about their own actions inside your environment. If the partner is compromised, the partner's audit trail may be your fastest forensic source. If they retain logs for thirty days and the adversary dwells for ninety, the trail is gone.
Do they segment customers. Specifically, do the operators who touch your environment touch other customers from the same workstations and the same accounts. Segmentation reduces the blast radius.
Continuous monitoring, not annual snapshots
The annual questionnaire captures a moment. The CTI lens captures change.
Three signals are worth investing in.
External attack surface change on category one and category two vendors. A vendor whose internet exposed footprint suddenly grows new services, new subdomains, or new open ports may be in the middle of a project, or may have been compromised. The signal is not conclusive. It is a prompt to ask.
Mention in actor leak data and dark web markets. Many ransomware actors publish victim lists on leak sites. If a vendor of yours appears, you have a clock running. Even if the actor never touches you, the vendor's incident response capacity is about to be consumed and your support quality will degrade.
Public CVE and incident disclosure. Subscribe to each category one vendor's security advisory channel directly. Do not rely on the vendor sales contact to forward it.
Each signal has a defined response. Surface change goes to the vendor manager for a question. Leak site mention triggers an internal alert and a check on what data the vendor holds. Public CVE on a category one vendor triggers a same day patch decision instead of waiting for the next maintenance window.
A small annual exercise that beats a long questionnaire
Once a year, the security team picks the top three category one vendors and the top three category two vendors and writes a one page intrusion scenario for each. The scenario answers four questions.
What would the adversary do at this vendor to gain access.
What would the first detectable signal be on our side.
How long would dwell be before we noticed under our current controls.
What two controls, if added, would cut that dwell time the most.
Six one page scenarios. Six concrete control proposals. That exercise produces more useful change than a thousand questionnaire answers.
The point
A CTI lens on supply chain is not a new framework. It is a sorting exercise that focuses scarce attention on the vendors that can actually carry an adversary into your network. Sort vendors into software with privileged code execution, service providers with persistent access, and everything else. Ask operational questions of the first two. Monitor change continuously instead of annually. Run a small scenario exercise on the top six. The result is a vendor program that maps to how adversaries actually move and not to how auditors fill out forms.