Vulnerability scanners are good at what they do. They’ll find that unpatched Apache instance, the open S3 bucket, the misconfigured TLS cipher suite. They crawl your attack surface, match CVEs, score severity, file tickets.
But they all share the same blind spot: they scan infrastructure you control. The moment a risk originates in a system owned by someone else, your scanner has nothing to probe. No target, no finding, no ticket.
This isn’t a feature gap in any one product. It’s a structural limitation of how scanning works. A scanner needs a host, a port, a certificate, a codebase. Third-party availability and trust failures don’t present themselves that way. They surface as behavioral anomalies in services your organization consumes but cannot instrument.
Here are five categories of third-party risk that live entirely outside the scanner’s field of view.
Vendor DNS hijacking and subdomain takeover
Your scanner checks your DNS records. Maybe it flags dangling CNAMEs pointing to deprovisioned cloud resources. Good. But your payment processor’s DNS? Your identity provider’s subdomain? Your CDN’s origin-pull domain? Those aren’t in scope.
DNS hijacking against a vendor you depend on doesn’t trip your scanner because the domain isn’t yours. The attacker takes over auth.vendor.com, stands up a credential-harvesting page, and your SSO integration happily redirects users to it. From your infrastructure’s perspective, nothing changed. The CNAME still resolves. The TLS handshake completes (the attacker provisions a cert via an ACME challenge on the hijacked domain). Your logs show successful redirects.
The detection window here is minutes, not days. If you’re not monitoring the DNS resolution chain for your critical third-party endpoints, including CNAME targets, NS delegations, and SOA records, you’re relying entirely on the vendor to notice first.
What actually works: continuous DNS record monitoring against a known-good baseline for every third-party domain your application integrates with. When auth.vendor.com suddenly resolves to a new IP or its NS records change, that’s a signal worth waking someone for. The record types that matter most are A/AAAA, CNAME targets, NS delegations, and SOA serials. Any unexpected change in these is worth an alert.
Third-party certificate expiry cascading into your auth chain
Your scanner verifies your certificates. It knows when api.yourcompany.com expires in 30 days and files the renewal ticket. But the cert on login.identityprovider.com? On api.paymentgateway.io? On the CDN edge node serving your customer-facing JavaScript bundle?
When a third-party cert expires, the failure mode is deceptive. Your systems didn’t change. Your monitoring sees your endpoints returning errors, but the root cause is an expired cert three hops upstream in a service you don’t own. Worse, some failure modes are partial: mobile clients with stricter cert pinning fail, while desktop browsers show degraded warnings that users click through.
This happened to a major identity provider in 2024. Their intermediate cert expired on a Saturday. Every downstream SaaS application relying on their OIDC flow started returning 502s to end users. The SaaS vendors’ own scanners showed green. Their own certs were fine. The scanners had no concept of “the cert at the other end of my HTTPS call to the IDP.” Incident response teams spent hours tracing 502s through their own load balancers and application code before someone thought to check the upstream cert chain.
The fix is to monitor certificate expiry for every TLS endpoint in your dependency chain, not just your own. Monitor the leaf cert, the intermediates, and the root. Alert at 14 days, not 7. And track intermediate CA expiry separately, because that’s the one vendors themselves forget about.
Payment and auth provider degradation that returns 200 OK
This one is subtle and expensive.
Your uptime checks send a request to api.paymentprovider.com/v1/health. They get back a 200. Green. But behind that health endpoint, the provider’s transaction processing queue is backed up by 40 seconds. Real charges are timing out. Your checkout flow technically works: it sends the request, gets a response (eventually), and the response says “pending.” Your scanner sees a 200. Your synthetic monitor sees a 200. Your users see a spinning wheel for 45 seconds and abandon the purchase.
Vulnerability scanners fundamentally cannot model this. They test binary reachability: can I connect, does the service respond with a non-error code? But degraded third-party performance is a risk to your business that manifests as loss rather than breach. Revenue loss, user trust loss, and SLA violation against your own customers who expect sub-second checkout.
Detecting this requires measuring response time and response body semantics against third-party endpoints under real conditions. Not “is it up” but “is it performing within the bounds my application assumes.” If your payment API has historically responded in 400ms and today it’s taking 12 seconds, that’s an operational incident, whether or not the status code is 200.
Vendor status page incidents your SOC never reads
Every major SaaS vendor publishes a status page. AWS has one. Okta has one. Cloudflare, Stripe, Datadog, PagerDuty. They post incidents, mark components degraded, and (eventually) publish post-mortems.
Almost no SOCs have these in their monitoring loop.
The information is public, machine-readable (most expose JSON or RSS feeds), and directly relevant to your environment’s risk posture. If your log shipper’s vendor posts “Ingest pipeline degraded in US-East,” that explains the gap in your SIEM. If your auth provider posts “Elevated error rates on /authorize endpoint,” that’s the root cause of the 4xx spike your own alerting just fired on.
The gap is organizational, not technical. Security teams don’t watch status pages because it feels like an ops concern. Ops teams might watch them for their top 2-3 providers but not the long tail. The result: your SOC spends 30 minutes investigating a log gap that the vendor had announced 20 minutes earlier, when you noticed it.
Operationalizing this is straightforward. Subscribe to the status page feeds of every vendor in your supply chain. Ingest incidents into your alerting pipeline. Correlate inbound vendor incidents with your own alert timeline. This isn’t a scan. It’s a subscription and correlation engine.
Scheduled security jobs that silently fail against a provider endpoint
Your backup agent pushes encrypted snapshots to a cloud storage endpoint every 6 hours. Your log shipper forwards to your SIEM vendor’s ingest API. Your vulnerability scanner itself reports findings to a central SaaS console. Your certificate renewal bot calls the ACME provider’s API.
All of these are scheduled jobs that depend on a third-party endpoint being reachable and functional. When that endpoint goes down, the job fails silently. No snapshot uploaded. No logs forwarded. No scan results reported. No cert renewed.
The security implications compound over time. Miss one backup window and you’re probably fine. Miss a week because the storage provider quietly deprecated an API version and your agent’s requests started returning 403? Now your RPO is blown and nobody knows until the restore test (if you run restore tests). Your compliance posture assumes continuous backup. The reality is a week-long gap that only surfaces during audit or, worse, during an actual recovery scenario.
Detecting silent job failure requires monitoring the job’s output artifacts, not just the job’s process. Did the snapshot actually land? Did the log shipper’s destination acknowledge receipt? Did the cert renewal produce a new cert file with an updated expiry? If the answer is “we check the job’s exit code,” that’s insufficient. A job can exit 0 and still have accomplished nothing if the remote endpoint rejected the payload with a 200-level response and an error body.
Operationalizing third-party risk monitoring
The pattern across all five risks is the same: your scanner can’t find what it can’t reach, and it can’t reach systems you don’t own.
Closing these gaps requires a different class of instrumentation. Not scanning, but continuous external monitoring of the services you depend on. DNS resolution chains, TLS certificates on upstream endpoints, response latency and body validation against third-party APIs, status page feeds, and synthetic checks that confirm scheduled jobs produced their expected output.
You can assemble this yourself with a combination of scripted checks, cron jobs, and alert routing. Some teams do. The complexity isn’t in any single check. It’s in maintaining coverage as your vendor list grows and correlating signals across providers.
Tools like DevHelm treat this as a first-class problem: monitor the external services your application depends on, alert when their behavior changes, and give your SOC the correlation between “vendor X degraded” and “our own alerts fired 3 minutes later.” But whether you build or buy, the architectural point is the same: third-party risk monitoring is a distinct capability from vulnerability scanning. It belongs in your security program, but it won’t come from your scanner.
The gap is structural, not accidental
Vulnerability scanners aren’t broken. They’re scoped to a different problem. They find weaknesses in systems you control so you can fix them before an attacker exploits them. That’s valuable and necessary.
But your actual risk surface includes every external system your application trusts. Every DNS delegation, every upstream TLS cert, every payment API, every status page, every cloud endpoint your cron jobs depend on. These are trust relationships, and trust relationships degrade in ways that don’t produce CVEs.
If your security program only instruments what it owns, it’s blind to half the failure modes that will actually hit your users. The five risks above aren’t exotic. They happen weekly across the industry. The question is whether your team finds out from their own monitoring or from a customer support ticket 45 minutes later.