Skip to main content
For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt. This page is also available in markdown by appending .md to the URL.
Security Intelligence rates a vendor’s external security posture without asking the vendor anything, without an agent, and without a questionnaire. Coverbase queries the vendor’s own public infrastructure (its DNS records, its TLS certificate, the headers its web server returns) and scores what it finds. The distinction that matters: this is measured, not reported. A rating built from feed subscriptions tells you what someone said about a vendor. This tells you what the vendor’s systems are actually configured to do, today, and shows you the record it read.
This is an optional feature currently in beta. Let your Coverbase representative know if you’d like it turned on for your organization.

​
What it does

Reads policy, not presence

A domain that publishes SPF and DMARC but sets ~all and p=none blocks nothing. A presence check scores it identically to a domain enforcing -all and p=reject. Coverbase parses the policy and scores what it would actually do to a forged message.

Every deduction has a receipt

Each factor lists the specific findings behind its grade: what was observed, on which host or selector, and how many points it cost. Open the rationale on any factor to see the arithmetic.

Findings keep their history

A finding carries the date it was first seen. A weak DKIM key that has been open for eleven months is a different conversation than one that appeared last week.

Unmeasured is not the same as failing

When a probe cannot reach a conclusion, that factor is excluded from the rating rather than scored as a failure. A timeout is not evidence about the vendor.

Every finding carries its fix

Each finding names the step that resolves it, written for whoever operates the asset. Forwarding one hands the provider a specific change to make rather than a problem to research.

You correct the attribution

Attribution is worked out from domain names, so it is sometimes wrong in both directions. Dispute an asset that is not the vendor’s and it leaves the scan and the rating. Add one the scan cannot discover and it is probed and scored like any other.

The scan tells you what to do

Every profile carries a ranked list of next steps, each resting on a named observation: an actively exploited CVE, a database port open to the internet, a DMARC record that does not enforce. Each one copies a question ready to send to the vendor. The list is the same on the page, in a report and through MCP.

Every scan says what changed

A refresh records what it found that the previous one did not, and the reverse: findings that appeared or were resolved, factors that moved, assets that arrived or left. A returning reader learns what is new in two lines rather than by rereading the page.

​
What gets measured

Four probes read the vendor’s live infrastructure on each Vendor Intelligence refresh. All four are passive: they read published records and make ordinary client requests, the same way any browser or mail server would. Nothing is scanned, brute-forced, or authenticated against. These sit alongside the feed-based factors Coverbase already scored (vulnerability exposure, network posture, IP and web reputation, and credential leaks), so the rating covers both what the vendor’s infrastructure does and what public sources report about it.

​
How the score works

The overall score runs 0-100 with a letter grade, computed as a weighted mean across eleven factors. Weights reflect how directly each factor bears on a compromise: Two deliberate constraints on that arithmetic:

A factor with no data is excluded, not zeroed

If a probe times out, gets rate-limited, or the vendor’s infrastructure simply doesn’t answer, that factor drops out of the weighted mean. It is never scored as a failure. A vendor is not penalized for a query that failed on our side, and a clean-looking score is never manufactured from a request that didn’t complete.The same rule applies in the other direction. HTTPS enforcement is credited only when a plain-HTTP connection is actually refused. A request that merely timed out proves nothing, so it earns nothing.
Uncapped, this factor measures brand recognition rather than security. Every large brand has dozens of parked typo domains it never registered and cannot remove. Before the cap, GitHub scored 0/100 on it. The cap keeps a real signal (a mail-capable lookalike is worth knowing about) from turning into a penalty for being well known.

​
Reading a finding

Every factor’s rationale lists the individual findings behind its grade. Each one carries:
  • What was observed: the actual value, such as p=none, 1024-bit, or TLSv1.0
  • Where: the host, DKIM selector, or cookie name it applies to
  • What it cost: the points deducted from that factor
  • How long it has been open: the date the finding was first seen, once it has survived a refresh
That last field is the one worth watching. A finding that persists across months has been seen by the vendor’s own team too. It has stopped being an oversight and become a decision. Opening a finding also shows the remediation step for its code, and whether the finding actually cost the rating points. Raise a tracked finding from it directly, or use Generate findings to raise them for every scored issue at once, which is the case a sweep across a wide estate creates.
Take a finding to the vendor as an observation, not an accusation: “your DMARC record is p=none, so mail forged from your domain still gets delivered. Is enforcement on the roadmap?” It is a verifiable fact about a public record, and it converts a security review into a specific, answerable question.

​
Next steps and the change log

Two things sit between the rating and the evidence, and both are derived from the scan rather than written by a model. Next steps is a fixed set of rules over the profile, ranked urgent, soon and routine. Urgent rules fire on evidence of active exploitation or an open door: a CVE in CISA’s Known Exploited Vulnerabilities catalog, a CVE tied to ransomware campaigns, an administrative or database service reachable from the internet, a failing certificate. Soon rules fire on policy gaps: DMARC at p=none, SPF ending in +all, TLS 1.0 or 1.1, a certificate within three weeks of expiry, a lookalike domain that accepts mail, staff credentials in a breach within a year of the scan. Routine rules fire on what weakens the rating itself: findings open for six months or more, an estate nobody has reviewed, and a rating that rests on less than 60% of the model’s weight. The rules are evaluated when the page, a report or an MCP client reads the profile, not when the scan ran. A rule added or tightened applies to every vendor on the next read, and every vendor scanned before the rules existed gets a list without a rescan. Since last scan is stored by each refresh against the profile it replaces, because the replaced profile is the only place a resolved finding can be found. It records the score and factor movement, findings that appeared or closed, CVEs that appeared or are no longer observed, and assets that arrived or left. A finding counts as resolved only if its factor was measured in both scans, and CVEs are compared only if both scans reached the vulnerability source, so a skipped credential never reads as a fix. The same two blocks reach assessment reports as {{intelligence::security next steps}} and {{intelligence::security change since last scan}}, and the security posture section an agent reads carries them in full.

​
Standing among your vendors

With at least five rated vendors, the rating shows where this vendor sits among them: the share of the other rated vendors the viewer can open that it scores at or above. Someone restricted to assigned vendors is ranked among those, never against vendors they cannot see. It is computed when the page opens, from the ratings as they stand, so a vendor archived this morning is out of the cohort this morning. Below five rated vendors it is not shown, because two vendors make one of them “top 50%”.

​
The predictive index

Alongside the rating, Coverbase publishes a forward-looking index of exploitation likelihood. It is driven by membership in CISA’s Known Exploited Vulnerabilities catalog, peak EPSS probability, known ransomware association, and how much attack surface is externally exposed. The rating answers “how well is this vendor configured?” The predictive index answers “how likely is something to happen soon?” They can diverge, and the divergence is informative: a well-configured vendor running one product with an actively exploited CVE deserves attention that its letter grade alone won’t prompt.

​
What this does not tell you

A clean external profile is not evidence of good internal security. Everything here is visible from outside the perimeter. It says nothing about access control, key management, secure development, incident response, or how the vendor treats your data once it’s inside their systems. Use it to prioritize and to interrogate, never as a substitute for an assessment.
Three more limits worth stating plainly:
  • DKIM absence is inconclusive. DKIM has no discovery mechanism; a verifier learns the selector from a message it received. Coverbase probes the selectors major senders publish, so a domain signing with a private selector reads as unsigned. Absence is therefore scored as unknown with a small deduction, never as a failure.
  • The rating describes the domain we scanned. A vendor with a well-configured marketing domain and a neglected application domain will rate on whichever one is on file. Scan a different domain, beside the verdict on the Security page, points the scan at another one for every organization that monitors the vendor.
  • Attribution is heuristic, and correcting it is manual. Disputing an asset fixes one vendor’s estate; it does not make the attribution better for the next vendor. Adding the assets the scan cannot discover is the same trade in the other direction, and although they go in as one list against one rescan, someone still has to know they exist.

​
Where it appears

Vendor Intelligence

The External Security Intelligence card carries the score, grade, factor breakdown, and per-factor findings, refreshed on the regular Vendor Intelligence cadence. The Security tab opens the same data full width, with rating history, every factor expanded to its findings, the reviewable estate, and a section per evidence class.

Assessments

Measured posture is supplied to control evaluations as authoritative evidence, ranked ahead of web results. A control asking about email authentication is answered from the vendor’s actual DNS records rather than from a marketing page claiming compliance.

Intake and inherent risk

A new vendor request is scored against measured posture before the web is consulted.

MCP

Ask conversationally: “What’s the security posture for Acme?” or “Which of my vendors have DMARC set to none?”

​
Availability

Security Intelligence is an optional feature in beta, enabled per organization. Contact your Coverbase representative to have it turned on. Organizations without it keep the security rating exactly as it was before this feature shipped: the same seven factors at the same weights. Enabling it adds the four measured factors and re-weights accordingly, so expect ratings to move once it’s on. That movement is the point: the new rating distinguishes vendors the old one scored alike.
See also Vendor Intelligence for corporate identity validation and the Financial Health Score, both enabled alongside this feature and following the same beta arrangement.