Why Vendor Risk No Longer Starts With a Contract

Vendor risk is still gets treated as separate line items in many security programs, with procurement owning the contract review and security owning access and controls. Yet the tool most likely to compromise an environment is often the one neither team ever formally reviewed.

Unvetted plugins and API connections have always fallen outside a strict, contract-based view of supply chain risk. What's changed is the pace, since AI tools have made those connections so easy to add that a vendor list alone won’t suffice. A plugin an engineer installed to save time or an API connection that wasn’t caught during review carries the same exposure as a fully vetted vendor. Closing that gap starts with defining supply chain risk around actual data access rather than contract status.

A security questionnaire completed once during onboarding no longer reflects how risk moves through a vendor ecosystem. Continuous vendor monitoring needs to replace the point-in-time review. Software Bill of Materials (SBOM) reviews, real-time attack surface monitoring, and contractual flow-down requirements that force vendors to disclose their own vendors all play a role. An organization that only maps the first layer of a critical vendor's supply chain still misses most of its real exposure, since the risk that matters usually sits two or three layers deeper.

The most common blind spot right now is development teams connecting AI tools directly to production data or systems without evaluating the vendor's own security posture or mapping where that data flows. Speed-to-market pressure usually means the access review and data flow mapping get skipped entirely rather than delayed.

A recent incident illustrates exactly how fast that exposure compounds. In mid-2026, a compromised version of an open-source AI development tool exposed credentials across roughly 2,500 organizations during a window of less than an hour. The tool itself was never directly procured by most of the affected organizations. It was a dependency inside a dependency, exactly the kind of nth-party exposure that a vendor-list-only view of risk overlooks entirely.

Aggressive credential revocation sounds straightforward until an organization tries to execute it. Some organizations haven’t mapped everywhere a given credential or secret is used, so revoking everything risks breaking production systems that weren’t documented in the first place. This is a discovery problem as much as an execution problem. An organization can't rotate what it hasn't inventoried.

That gap showed up in the aftermath of the mentioned incident. In at least one documented case, an organization that believed it had rotated every exposed credential later found, through a researcher's follow-up testing, that many of the old credentials still worked. Confirmation that remediation is complete could’ve caught what belief alone left standing.

For organizations with no real visibility into their downstream dependencies, the starting point isn't a new tool. It's a full inventory of every third party with system or data access, including what those vendors themselves rely on. Once that list is finally built, it's usually far less complete than leadership expected. Risk that hasn't been mapped can't be managed.

A vendor's breach that exposes an organization's own customer data still leaves that organization holding the fallout. 'It wasn't our system' isn't a legal defense. Vendor contracts need breach protections built in well before an incident ever happens."

A vendor's word that a breach has been fully remediated isn't sufficient on its own. Verification means asking for evidence, whether that's a third-party attestation, updated penetration test results, or a SOC 2 report covering the specific controls that were remediated. Until a vendor can produce that evidence, 'fully remediated' should be treated as unconfirmed.

Supply chain risk has moved beyond the vendors an organization formally signed. It now reaches every connected tool, every AI integration, and every hidden layer beneath a primary vendor's own supply chain. These layers are only found once something forces a closer look. Clark Schaefer Consulting helps organizations build third-party risk management programs that consider continuous monitoring, vendor inventory, and contractual protections to turn visibility into a robust security posture. Reach out today to talk through what an assessment of your third-party risk program would look like for your organization.

Source: Ars Technica, "Terabytes of credentials leaked in massive supply-chain attack," Aug. 12, 2026.