Partner and Vendor Due Diligence
How do you vet a SaaS vendor's security posture?
You vet a SaaS vendor's security posture externally by grading its HTTP security headers, TLS configuration, email authentication (SPF, DKIM, DMARC), and certificate hygiene. Those signals triage a vendor fast, before you send a questionnaire. Bassethound returns all of them, correlated with the vendor's stack and subprocessors, in one keyless call.
Best move: read the vendor’s externally observable controls (security headers, TLS, email auth, certificate hygiene) before you send a questionnaire.
Why it works: a vendor that neglects the free, public controls rarely nails the hard internal ones. External hygiene is a cheap proxy for where to dig.
Key takeaways
- External vetting grades six security headers (HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy) plus TLS configuration into one A-F letter.
- Email authentication (SPF, DKIM, DMARC) is public and tells you whether a vendor’s domain can be spoofed to phish your team.
- Certificate hygiene (issuer, expiry, days remaining) surfaces operational sloppiness before it becomes an outage or a trust warning.
- External signals triage a vendor. They cannot see internal controls (encryption at rest, access management, SOC 2), so they never replace a questionnaire.
- Bassethound returns the security grade, TLS detail, email-auth booleans, and the vendor’s subprocessors in one correlated dossier.
What security signals can you read without the vendor’s cooperation?
Everything the vendor serves to the public. That is more than most buyers check.
The HTTP response on the main site carries the security headers. The TLS handshake exposes protocol versions, the cipher, and the full certificate chain (issuer, SANs, expiry). DNS carries the MX records, the SPF and DMARC policies in TXT records, and the DKIM selectors. Certificate transparency and the SANs list show you which other hostnames share the vendor’s cert.
None of this requires an account, an API key, or the vendor’s permission. You are reading what their own servers hand to any client. Each signal maps to a control you would otherwise ask about in a questionnaire, so you can pre-fill half the form before you send it.
The honest limit: you see the edge, not the origin. A CDN or reverse proxy can add headers the application itself never sets, or strip ones it does. A clean edge does not prove a clean origin. Read the external grade as evidence about the vendor’s operational discipline, then confirm the internal reality through the contract and the audit report.
How do external signals become a security grade?
Through a rubric, not a vibe.
The header grade starts high and deducts. HSTS with a long max-age, a CSP that goes beyond a bare default-src, X-Content-Type-Options set to nosniff, frame protections against clickjacking, a Referrer-Policy that does not leak URLs, and a Permissions-Policy that locks down device APIs. Each present and configured header holds the grade. Each missing or weak one pulls it down. Six checks collapse into a single letter you can sort a vendor list by.
The TLS grade runs parallel. A modern protocol floor (TLS 1.2 or higher), no deprecated ciphers, a valid and trusted chain, and a healthy days_remaining on the certificate. Mozilla’s SSL configuration generator is the public baseline most teams grade against, so the rubric is not proprietary opinion.
The letter is a triage sort, not a verdict. An A tells you the vendor invests in the free wins. An F tells you to open the conversation with harder questions. Neither letter certifies the code behind the header. Use the grade to rank where your limited review time goes.
What can’t you learn from the outside?
The controls that matter most.
Encryption at rest, key management, role-based access control, audit logging, incident response maturity, penetration-test cadence, and formal attestations like SOC 2 Type II or ISO 27001 stay invisible from the edge. A static crawl plus optional JS render can also miss components that run server-side or sit behind a proxy, so the dossier reports what it could not reach rather than guessing.
The failure modes cut both ways. A vendor can post a spotless external grade and run a weak internal program. A vendor can neglect a header and still hold a rigorous SOC 2. External posture correlates with internal discipline; it does not equal it.
Use it to filter. The external grade tells you which vendors deserve the long questionnaire, which claims to challenge, and which “we take security seriously” lines to test against the observable record. It compresses the top of your funnel. It does not close the deal. Pair it with the vendor’s audit report and a real security review before data changes hands.
How does email authentication factor into vendor risk?
Directly, and it is public.
SPF, DKIM, and DMARC govern whether someone can send mail that appears to come from the vendor’s domain. A vendor with no DMARC record, or one set to p=none, can be spoofed. Vendor-impersonation phishing is a live supply-chain vector: an attacker mails your team as your trusted vendor and harvests credentials or redirects an invoice. The DMARC standard (IETF RFC 7489) defines these policy levels.
Bassethound returns these as booleans in the infrastructure layer: SPF present, DKIM present, DMARC present. Presence is not enforcement. A DMARC record at p=none publishes intent and collects reports without rejecting a single spoofed message. Quarantine and reject are the policies that stop mail. So read the boolean, then read the policy.
Weigh this against how you use the vendor. A vendor that emails your customers on your behalf, or triggers financial actions by email, carries more spoofing risk than one you only log into. Email auth is one of the cheapest tells of operational maturity, because setting it up is free and well documented, and skipping it signals where else corners get cut.
How do you vet the vendor’s subprocessors and fourth parties?
This is where fusion beats five separate scans.
Your vendor’s risk is not only their controls. It is who they are built on. The tech-stack and infrastructure layers reveal the downstream vendors: the analytics they load, the payment processor, the CDN, the email provider, and the DNS TXT records that name other SaaS tools. Each is a fourth party that now touches your data through the contract you are about to sign.
The AI-readiness layer extends this to the axis most vetting misses. Deep backend fingerprinting surfaces model providers (Anthropic, OpenAI, and others), AI SDKs, and vector stores. If your vendor pipes customer data to an LLM provider you never approved, that is fourth-party exposure a standard questionnaire rarely catches, because the vendor may not think to disclose it.
A single dossier correlates all of this. You see the security grade next to the subprocessor list next to the AI stack, from one call. An agent cannot cheaply reconstruct that correlation by querying a header scanner, a DNS tool, and a tech-stack API and stitching the outputs. Correlation is the point of due diligence, and it is what one fused call delivers.
Bassethound perspective
External security scanning is a commodity when it ships as a single layer. Censys and Shodan index the internet. DomainTools maps registration. Each is strong at one axis. For vendor vetting, one axis is the wrong shape, because vendor risk is a correlation problem, not a checklist. A header grade means little on its own. It means a lot next to the vendor’s subprocessors and the AI providers they quietly send your data to.
That is the conviction a single-layer scanner would dispute: breadth of corpus is not the moat for due diligence, fusion is. The buyer’s question is never “is this one header set.” It is “given who this vendor is, what they run, and who they depend on, where is my exposure.” Five separate tools cannot answer that without a human stitching them, and the stitch is where mistakes hide.
Bassethound reads the security posture, the infrastructure, the firmographics, the AI stack, and the header grade in one keyless, stateless, correlated call. We are honest about the edge: external checks triage, they do not audit. But triage from a fused dossier beats triage from five tabs.
Sources
- MDN, Web security: https://developer.mozilla.org/en-US/docs/Web/Security
- Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org
- IETF RFC 6797, HTTP Strict Transport Security: https://datatracker.ietf.org/doc/html/rfc6797
- IETF RFC 7489, DMARC: https://datatracker.ietf.org/doc/html/rfc7489
- MDN, Content Security Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
Frequently asked questions
Can external checks replace a security questionnaire or SOC 2 report?
No. External checks read what the vendor serves the public: headers, TLS, DNS, certificates. They never see internal controls like encryption at rest, access management, or logging. Treat the external grade as a triage filter that tells you which vendors to challenge hardest, not as an audit.
What does a security header grade measure?
Presence and configuration of six response headers: HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy. Each covers a known browser-side attack class. The A-F letter compresses six checks into one sortable signal.
Does a missing DMARC record mean the vendor is insecure?
It means the vendor's domain can be spoofed, which raises your phishing surface. It is one data point, not a verdict. A record set to p=none publishes intent without enforcing it, so presence and enforcement are separate questions.
Can you vet a vendor without an API key or an account?
Yes. Every signal here is public: HTTP headers, the TLS handshake, and DNS records. Bassethound runs the crawl itself, so the free tier needs no key and no bring-your-own credentials.
How current is the security data?
It reflects the moment of the call. A cert that expires next week reads as expiring next week, not as it looked in some prior scan.