Vendor Risk Assessment Is Not Supply-Chain Intelligence

A vendor risk assessment will tell you what a supplier has agreed to be on paper. It will not tell you what they are.

Most organizations cannot tell the difference. They run the questionnaire, file the SOC 2, sign the master service agreement, and then operate as if the relationship has been understood. It has not been understood. It has been documented.

That gap is where the compromises live.

We have written before about when public records search is not enough on its own and how public records search supports intelligence-led investigations. The argument was that surface-level records produce false certainty, and that the file is the start of the investigation, not the end. This article is the enterprise version of the same point. Procurement and security teams are running the corporate equivalent of the records-only investigation, and calling it third-party risk management.

Why vendor risk assessments create false confidence

The standard vendor risk assessment is a documentation exercise. The vendor fills in the questionnaire. They attach the SOC 2 Type II, the ISO 27001 certificate, the most recent penetration test summary. Procurement scores the response. Security signs off. The relationship is approved.

What the process actually evaluates is the vendor's willingness and ability to produce evidence of controls at a specific point in time. That is useful. It is not what the question was.

The question was: can this supplier compromise our environment, our customers, or our operations?

The answer to that question is not in the questionnaire.

It is not in the questionnaire because the questionnaire is structurally backward-looking, self-reported, and pre-incident. The vendor's threat surface is shaped by who they hire, who their suppliers are, which open-source components their developers pull from, which credentials sit in which CI/CD pipelines, and how their engineers behave at 2 a.m. on a Saturday when something breaks. None of that is in the response. None of that is in the SOC 2.

Compliance is evidence that the vendor passed a controls audit. It is not evidence that the vendor is uncompromised. Those are different claims. Most third-party risk programs are still confusing them.

The difference between compliance evidence and live intelligence

Compliance evidence is historical and contractual. Live intelligence is current and observational.

Compliance evidence answers: did the controls exist at audit time, and did the vendor produce documentation that they did?

Live intelligence answers: is anything happening, right now, in or around this vendor that materially changes their risk to us?

The two are not substitutes. A clean SOC 2 from January tells you nothing about a credential compromise in March. A signed ISO certificate tells you nothing about a contributor who quietly took over maintainership of a dependency your vendor ships with their product. A passed questionnaire tells you nothing about the lawsuit filed against the parent holding company last week.

This is the part that gets confused in most third-party risk programs. The compliance artifact is treated as a state of being rather than a snapshot.

The vendor was secure on the day they were audited. They have not, and cannot, be audited every day.

Intelligence-led supply chain risk intelligence is the work of filling that gap with what the audit cannot see.

What a static questionnaire misses

Six things, at minimum, all of which can quietly end a deal or a quarter.

Ownership and control. Who actually owns the vendor. Not the directors on the registry. The beneficial owners. The parent's parent. The investors with kill rights. If the vendor is owned, in whole or in part, by an entity in a sanctioned jurisdiction, or by a person on a watchlist, or by a competitor of one of your other vendors, the questionnaire will not tell you. The questionnaire was not designed to ask.

Litigation and regulatory exposure. Active suits, regulatory enforcement actions, settled-but-not-disclosed disputes, judgments against principals. A vendor under financial pressure from litigation has different incentives than one without. Those incentives change behavior.

Dependency chains. The vendor is one node. They have their own vendors. Those vendors have their own vendors. The questionnaire stops at the first hop. The compromise does not.

Personnel and access. Who can touch your data inside the vendor. Whether they are the people on the org chart, or whether the actual administrators are contractors, offshore subsidiaries, or recent hires with no track record. Whether anyone with privileged access has shown behavioral red flags. Whether the vendor's HR process has any way to catch synthetic identities or credential fraud at hiring.

Operational integrity. Whether the vendor is operationally what they claim to be. Whether their offices exist. Whether their stated headcount matches their actual footprint. Whether their referenceable customers actually use the product at the depth they claim.

Post-onboarding drift. Whether anything has changed since the assessment. Vendors do not stay the same shape. They get acquired. They lose staff. They pivot. They reduce their security investment. The assessment captured one moment. Everything since then is unmeasured.

A questionnaire-driven program treats each of these as someone else's problem. A serious one treats them as the program's job.

How supply-chain compromises actually propagate in 2026

The reason the gap matters is that attackers are no longer attacking targets directly. They are attacking the trust relationships between targets.

On March 24, 2026, Microsoft published guidance on the Trivy supply chain compromise. The attacker, identifying as TeamPCP, force-pushed 76 of 77 version tags in the trusted aquasecurity/trivy-action repository, redirecting existing version references to malicious commits. Downstream workflows executed attacker-controlled code with no visible change to release metadata. Stolen GitHub tokens were then used to enumerate repositories, extract Actions secrets, and inject malicious workflows. Stolen NPM tokens were used to download legitimate packages, inject malicious preinstall hooks, bump the patch version, and republish. Each compromised pipeline became the next supply chain vector.

Read what that means. A vendor risk assessment of Aqua Security, conducted before March 19, would have returned a clean profile. SOC 2 in place. Reputable open-source maintainer. Widely adopted scanner. There was nothing for the questionnaire to find. The compromise happened upstream of the vendor's own controls, propagated through trusted distribution channels, and surfaced as malicious activity inside the customer environment with no signal at the perimeter.

The same pattern shows up in social engineering. On May 4, 2026, Microsoft Defender Research disclosed a phishing campaign that ran in waves between April 14 and 16, targeting more than 35,000 users across 13,000 organizations in 26 countries. The lure was a fake "code of conduct" investigation, sent through legitimate email delivery infrastructure from attacker-controlled domains. The emails were fully authenticated. Users clicking "Sign in with Microsoft" landed in an adversary-in-the-middle session that proxied the real Microsoft sign-in, captured tokens after authentication completed, and bypassed non-phishing-resistant MFA. The attackers used compliance language as the attack surface. The trust your employees place in your own compliance program was the lever.

And edge devices. On April 7, 2026, the UK's NCSC published an advisory on APT28's exploitation of routers for DNS hijacking, supporting adversary-in-the-middle operations to intercept web and email traffic. The NCSC's assessment was specific: the activity is opportunistic at first, casting a wide net across exposed devices, then filtering down to users of likely intelligence value as the intrusion develops. Microsoft's parallel analysis confirmed APT28 compromising routers upstream of larger targets, to pivot into enterprise environments through less-monitored edge assets.

All three attack patterns share a single property. They exploit relationships that look clean from the inside. The vendor passed the audit. The email was authenticated. The router was operational. Nothing in the documentation flagged any of it.

The minimum intelligence layers serious teams should add

A third-party risk program that wants to actually reduce exposure has to do more than score questionnaires. The minimum additions are these.

• Public-record analysis on the vendor and its principals. Court filings, sanctions screens, regulatory enforcement, professional licensing, beneficial ownership where retrievable. This is the spine of the file. Done properly, it surfaces the contradictions worth investigating.
• Ownership and corporate structure mapping. Beyond the registered entity. Trace the holding companies, the silent partners, the cross-border ownership. Identify whether the vendor's incentives are what you think they are.
• Access-path analysis. Map exactly what the vendor can touch in your environment, and what their vendors can touch through them. Document the dependency chain to the depth that matters for the business risk.
• Behavioral and reputational monitoring. Source-based intelligence on how the vendor operates. What former employees say. What customers say off-record. Whether the company is what its marketing claims it is.
• Continuous monitoring after onboarding. New litigation. Changes in beneficial ownership. Personnel turnover at the principal level. Public-incident disclosures. Adverse media surfaced through automated screening, then triaged by an analyst. The assessment is a starting position, not a permanent state.
• Technical telemetry correlated against intelligence. Anomalous activity from the vendor's IP space, unusual API behavior, sudden changes in operational patterns. Telemetry on its own produces alerts nobody can prioritize. Pair it with the intelligence layers above and the alerts start to mean something.

None of this requires reinventing the third-party risk function. It requires accepting that the function as currently designed only covers part of the surface, and adding the layers that cover the rest. The work is investigative. The product is operational confidence rather than documentation.

Indicators that a "clean" vendor profile still deserves scrutiny

Some signals are subtle enough to be missed and load-bearing enough that missing them changes the call.

• The vendor's corporate structure includes shell entities in jurisdictions known for opacity, with no documented commercial reason
• Senior leadership has recently and quietly changed, and the change was not announced
• The vendor's stated customer references cannot be independently corroborated
• The audit firm that signed the SOC 2 has been recently retained, with no prior relationship
• Filings show beneficial ownership has shifted, and the vendor did not disclose it
• The vendor has a presence on developer-focused dark-pool forums under personas linked back through OSINT
• A principal at the vendor has prior involvement in a company that experienced a similar compromise

Any one of these on its own is not disqualifying. Two or three of them in combination are. The point of intelligence-led assessment is to make those combinations visible before they become incidents.

When to escalate from vendor review to investigative assessment

Not every vendor needs a full investigation. The cost of going deeper has to be proportionate to the risk. The escalation criteria are these.

The vendor will handle regulated data, source code, customer PII, financial transaction infrastructure, or production access. The vendor sits in a category where one of your peers has recently been compromised through a similar third party. The vendor's ownership structure crosses a sanctioned or high-risk jurisdiction. The vendor's principals have prior involvement in a security incident, a regulatory action, or a litigation outcome that suggests judgment problems. The vendor is being onboarded under time pressure that does not allow a full review cycle. The vendor was previously rejected and is being reconsidered.

When any of these are true, the standard questionnaire is not the answer. Investigative due diligence investigations, combined with corporate intelligence services and ongoing supply chain monitoring, is. The cost of that work is small relative to the cost of being wrong.

What executives should ask security and procurement this quarter

If you sit at the executive level, the questions you ask determine what your teams treat as important. These are the ones that matter.

• How many of our top 50 vendors have we assessed beyond a questionnaire in the last 12 months?
• For our most sensitive third parties, do we know who actually owns them, not just who is registered?
• If a vendor's CI/CD pipeline were compromised tomorrow, what is the blast radius into our environment? Have we measured it?
• What is our process for detecting that a vendor has changed shape since onboarding?
• Who at this company owns the relationship between third-party risk and threat intelligence? If the answer is "nobody," that is the answer.

If the answers are uncomfortable, the program is working as intended. The job is to find out what you do not know before someone else finds out for you.

Legal and ethical boundaries

Intelligence-led vendor assessment is only useful if it stays lawful. Pretext-based access to non-public records, social engineering of vendor employees, unauthorized network reconnaissance, and any activity that crosses into computer-misuse statutes have no place in third-party risk work. The work has to be proportionate to a legitimate business risk decision, conducted through public records, lawful OSINT, source networks operating within their own legal scope, and contractually agreed monitoring of the commercial relationship. Where the assessment escalates into investigation, the engagement letter sets the scope, the methods, and the deliverables, and the work is documented for review.

That is the floor. Anything below it is not intelligence. It is liability.

Frequently Asked Questions

What is the difference between a vendor risk assessment and supply chain intelligence?

A vendor risk assessment evaluates a supplier's documented controls at a point in time, typically through questionnaires and compliance evidence. Supply chain intelligence is the ongoing analysis of a vendor's actual risk profile, including ownership, litigation, behavioral indicators, dependency chains, and post-onboarding changes. Assessments are static and self-reported. Intelligence is current and externally verified.

Why is a SOC 2 or ISO 27001 certification not enough for high-trust vendors?

Because both certifications evaluate whether documented controls existed at audit time. Neither speaks to the vendor's current security posture, its dependency chain, its ownership, or its behavior between audits. A clean certification is a useful baseline. It is not a substitute for ongoing intelligence on a vendor that can compromise your environment.

How do supply-chain attacks bypass vendor risk assessments?

By exploiting trusted relationships rather than attacking documented controls. The Trivy compromise of March 2026 is a clear example: attackers took over distribution channels of a reputable vendor and pushed malicious code through legitimate update mechanisms. Customer questionnaires of that vendor would have returned clean results immediately before the compromise. The attack surface was upstream of the assessed controls.

When should a vendor review become an investigation?

When the vendor will handle regulated data, source code, customer PII, financial infrastructure, or production access; when ownership crosses a high-risk jurisdiction; when principals have prior involvement in security incidents or regulatory actions; when onboarding pressure does not allow full review; or when a previously rejected vendor is being reconsidered. Any one of these justifies escalating beyond a questionnaire.

What does intelligence-led vendor assessment add to existing third-party risk programs?

Six layers: public-record analysis on the vendor and its principals, ownership and corporate structure mapping, access-path analysis to and through the vendor, behavioral and reputational monitoring, continuous post-onboarding monitoring, and correlation of technical telemetry with external intelligence. The questionnaire stays. The intelligence layers cover what the questionnaire cannot reach.