Third-Party and Supply Chain Risk: What a Vendor Security Review Actually Checks

Every vendor, SaaS integration, and open-source dependency an organization relies on is also, functionally, part of its attack surface, and it's usually the least-tested part. NIST's SP 800-161 formalizes this as cybersecurity supply chain risk management, treating vendor and third-party risk as a genuine discipline rather than a checkbox on a procurement form, because the pattern behind real incidents keeps repeating: the direct target had good security, and the compromise came in through something they trusted.

Why this is a real, not theoretical, category of risk

A vendor with access to your systems or data inherits your risk profile whether or not their own security matches yours, a well-defended organization can still be compromised through a poorly-secured vendor holding legitimate credentials or API access into their environment. This isn't limited to software vendors either: managed service providers, payment processors, marketing platforms with a pixel or script embedded on your site, and open-source packages your application depends on all carry the same fundamental exposure, just through different mechanisms.

Where third-party risk concentrates

• Vendors and MSPs with standing administrative or remote access into your environment, not just occasional project-based access
• SaaS integrations granted broad OAuth scopes far beyond what the integration actually needs to function
• Open-source dependencies with no process for tracking known vulnerabilities as they're disclosed
• Client-side scripts and pixels from third-party marketing or analytics tools, which run with the same trust as your own first-party code
• Vendors who subcontract to their own fourth parties, extending the chain of trust further than most reviews ever actually look

Why a questionnaire alone doesn't catch this

A vendor security questionnaire measures what a vendor says about their controls, not what's actually configured and enforced, and it almost never covers the specific access your integration with them actually has, which is the part that determines your real exposure. The two most useful questions a questionnaire alone can't answer are exactly the ones that matter most: what can this vendor's compromise actually reach in our environment, and would we even know if it happened?

What a real vendor security review checks

• The specific scope of access each vendor and integration genuinely has, not what was originally requested, but what's actually configured today
• Whether access follows least privilege, and whether unused or over-provisioned access has ever been revisited since initial setup
• Dependency and open-source component tracking against known vulnerability disclosures, not a one-time audit
• Incident notification terms in vendor contracts, whether you'd actually be told promptly if they were compromised

This ties directly into our Security Consulting engagements, where reviewing third-party access and integration scope is standard practice, not an add-on. For the DORA-specific third-party risk obligations financial entities face on top of this, see our piece on DORA and threat-led penetration testing. For the specific, automatable slice of this problem that applies to every container image an organization deploys, see container image scanning and software supply chain security.