How to Evaluate a Vendor's External Attack Surface Before You Sign the Contract

You do thorough due diligence on a vendor's pricing, their SLAs, their support responsiveness. But how often do you look at what their infrastructure is actually exposing to the internet before you hand them access to your systems?

Vendor relationships are a two-way attack surface. When you connect a supplier to your environment - through a shared integration, an API key, a VPN tunnel, or even just ongoing email communication - their security posture becomes part of yours. A vendor with open ports, expired SSL certificates, or leaked credentials sitting on a dark-web forum can become your problem before you ever know there was an issue.

This guide walks through how to evaluate a vendor's external attack surface as part of supply chain risk assessment, and what signals actually matter.

Why the Vendor's Perimeter Is Your Risk

Supply chain attacks work because the attacker doesn't have to breach you directly. They find the softer target in your ecosystem - a small professional services firm, a SaaS tool you use for HR, a regional IT vendor - and they work inward from there.

The problem is that most vendor security questionnaires ask vendors to self-report. You get a PDF that says "we take security seriously." That tells you nothing about what their infrastructure actually looks like from the outside.

External attack surface assessment flips this. Instead of asking the vendor what they think their security looks like, you look at what an attacker would actually see.

What to Assess on a Vendor's External Attack Surface

Open Ports and Exposed Services

Every open port on a vendor's public infrastructure is a potential entry point. The question isn't whether they have open ports - they'll have some - but whether services are exposed that shouldn't be. Remote desktop protocol open to the internet, database ports visible outside the vendor's own network, or legacy admin panels are the kinds of findings that should give you pause.

A basic scan of a vendor's domain and IP ranges will surface this. You're looking for services that are either misconfigured, outdated, or simply shouldn't be public-facing.

SSL/TLS Certificate Health

Expired or misconfigured SSL certificates indicate one of two things: either the vendor's security hygiene is poor, or their asset inventory is incomplete and they're not tracking what they own. Both are concerning. A vendor that doesn't know what certificates they're running probably doesn't know the full scope of what they're exposing.

Check for expired certificates, weak cipher configurations, and certificates issued to subdomains you wouldn't expect.

DNS and Subdomain Exposure

Shadow infrastructure accumulates fast. Vendors spin up test environments, staging servers, and developer tools that get forgotten. Those subdomains often run older software, carry weaker configurations, and may hold real data. A vendor's main domain might be well-hardened while a forgotten subdomain runs an unpatched application server.

DNS enumeration - mapping what subdomains resolve, what they're running, and where they point - is a core part of any honest vendor surface assessment.

Security Headers

Security headers are a quick signal of web application hygiene. Missing headers like Content Security Policy, X-Frame-Options, or HTTP Strict Transport Security don't constitute a vulnerability by themselves, but they indicate whether a vendor is applying standard hardening practices. Vendors who skip the basics on their own properties often skip them elsewhere too.

CVE Exposure Against Discovered Services

Once you've mapped what a vendor is running, you can cross-reference against known CVEs. If a vendor's public-facing web server is running a version of software with a critical, publicly-disclosed vulnerability, that's not theoretical risk - that's an active condition that an attacker could exploit today. Continuous scanning matters here more than point-in-time assessments, because CVEs are published constantly and a clean scan today can be outdated in two weeks.

Dark-Web Credential Exposure

This is the one most vendor questionnaires miss entirely. Credentials associated with a vendor's domain that have appeared in data breach compilations or dark-web markets represent a direct path into their environment. If a vendor employee's corporate credentials are sitting in a leaked dataset, an attacker can potentially walk through the front door.

Monitoring for leaked credentials tied to a vendor's domain isn't paranoia - it's practical due diligence. A single set of exposed admin credentials can undo every other security control a vendor claims to have in place.

How to Build This Into Your Vendor Review Process

Most SMBs and growing companies don't have a dedicated security team running these assessments manually. The practical approach is to use a tool that automates continuous monitoring against vendor domains so you're not doing one-time spot checks.

For your own perimeter, Safe Intelligence runs exactly this kind of continuous assessment - mapping exposed assets through open ports, SSL certificates, DNS, and security headers, running CVE detection against discovered services, and monitoring the dark web for leaked credentials tied to your domain. It's agentless and domain-based, so setup doesn't require deploying anything. The same lens you'd use to evaluate a vendor's surface is the one you should apply to your own.

That matters for supply chain risk in both directions: understanding what your vendors expose is important, and understanding what YOU expose to your vendors is equally important. They're doing due diligence on you too, or they should be.

The Questions to Ask a Vendor After Your Assessment

Once you've run an external assessment, you have real data to work with. Use it to guide your vendor conversation:

A vendor who can answer these questions specifically, without defensiveness, is a different kind of partner than one who responds with a generic security policy document.

What Acceptable Looks Like

No vendor will have a perfect surface. The goal isn't zero findings - it's finding a vendor who knows their surface, monitors it continuously, and responds when something changes. A vendor with minor findings and a clear remediation process is far less risky than a vendor with a clean questionnaire and no visibility into their own exposure.

The same standard applies to your organization. Knowing your own attack surface is the starting point for credibly asking your vendors about theirs.

Safe Intelligence by Apona | safeintel.io

This post is about Safe Intelligence.

More on this