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.
This guide is part of the User Guides collection. For what the capability is and where it stops, see Security intelligence.
This page rates a vendor’s internet-facing security from the outside, by querying their own infrastructure. Nobody at the vendor is contacted, and nothing here depends on their cooperation.

​
Finding it

Open a vendor, go to Vendor Intelligence, and pick the Security tab.
The Security tab for a vendor, showing an overall rating of 78, a rating history chart, and a factor breakdown covering patching, network exposure, TLS, email authentication and reputation.

1 Overall rating and grade. 2 Rating over time. 3 Per-factor breakdown, with the findings behind each score.

​
The rating is a floor, not a verdict

Everything measured here is visible from the public internet. That is its strength and its limit in one. A strong rating means the things an attacker can see from outside are in order. It says nothing about what happens inside the vendor’s network, how they manage access, or whether they have a working incident process. Those questions need an assessment. A weak rating is more actionable in the other direction. A monitor-only DMARC policy or an expired certificate is a fact, not an inference, and you can raise it with the vendor immediately.

​
Read the factors, then the number

The overall rating is a weighted roll-up. The factor breakdown underneath it is where the decisions live. Each factor expands to show the specific observations behind its score, so a low number always resolves to something concrete: a hostname, a header, a certificate, a CVE.
A factor marked not measured was excluded from the rating. It is not evidence that the control is in place, and it is not evidence that it is missing. It means we could not observe it.
That distinction matters when you are writing up an assessment. “Not measured” belongs in the questions you ask the vendor, not in the findings you record against them.

​
Open a finding to get the fix

Click any finding in a factor to open it.
A panel titled DMARC reports forged mail but still delivers it, marked High, with Impacts rating Yes minus 24, first and last seen dates, an observed value of p=none, and a remediation step.

A finding opened from the Email authentication factor, showing what was observed and the step that resolves it.

The panel answers the four questions you need before you can raise it with anyone:
  • Impacts rating tells you whether this finding actually cost points, and how many. A finding recorded for completeness that moved nothing says No, which saves you chasing a number that never changed.
  • First seen and Last seen tell you how long it has been open. A finding that has survived months has been seen by the vendor’s own team too.
  • Observed is the raw value the scan read, such as p=none or TLSv1.0.
  • Remediation is the step that resolves it, written for whoever operates the asset rather than for you.
That last field is why the panel exists. When you forward a finding to a vendor, “TLS 1.0 is enabled” hands them the problem and the research together. The remediation step means they can act on it without a round trip.

​
Raise findings from what the scan found

Raise finding on an open finding creates a tracked finding against the vendor, pre-filled with the asset, the observed value and the scan date, so it stands on its own once it leaves Coverbase. When a sweep turns up the same problem across a dozen hosts, use Generate findings at the top of the page instead.
A dialog titled Generate Findings for Northwind Data listing eight scored issues with severity badges, each with a checkbox, and a Generate 8 findings button.

Every scored issue, ticked by default, ordered by severity.

Only issues that actually cost the rating points are listed, because a zero-penalty observation is not something a provider needs to action. Untick anything the provider already owns before you generate.

​
Rating over time

Each point is a restatement of the whole rating. A step change usually means a scan found something new rather than the vendor changing overnight, so read the factors before drawing a trend.

​
Attack surface

What is reachable from the internet under the vendor’s domains: hosts, exposed services and open ports. A large surface is not automatically a finding; it is context for the rest of the page. Transport checks run per host rather than only against the vendor’s main domain, so one neglected server does not hide behind a well-configured front door.
A certificates-by-host table listing two hosts with their trusted-chain status, negotiated protocol, days to expiry and issuer.

Each attributed host handshaken separately, with its own chain, protocol and expiry.

​
Attributed estate

The scan works out which domains and addresses belong to the vendor from certificate transparency logs and public scan data, then measures each one. Attributed Estate is that list, and it is where you correct what the scan got wrong.
A table titled Attributed Estate listing nine domains and addresses with status badges reading Unreviewed, Confirmed and Disputed, plus first and last seen dates and a row actions menu.

Every asset the scan attributes to this vendor, filtered by what still needs a decision.

Attribution is worked out from domain names, so two kinds of mistake are normal and both are yours to fix.

​
Something is listed that is not theirs

Shared hosting, a reseller, or a product the vendor buys rather than runs. Open the row’s actions menu and choose Dispute. The next scan skips that asset entirely, and its findings leave the rating. Choose Confirm when you have checked an asset and it is theirs. That records the decision so nobody re-reviews it, and it does not change the rating.

​
Something they run is missing

The scan only finds hosts that appear in a public certificate, so an internal host, or one the vendor never published a certificate for, never shows up on its own.
A dialog titled Add Assets with a Hostnames or IP addresses box holding three entries on separate lines and an Add 3 and rescan button.

Adding the hosts the scan cannot discover on its own, in one go.

Click Add asset, then enter the hostnames or IP addresses, one per line or separated by commas. The next scan probes and scores them like any other asset. Assets you added are marked Added by hand and survive a scan that cannot see them, because they are your assertion rather than an observation. Add the whole list in one go rather than one at a time. Each submission starts a single rescan covering everything in it, so ten hosts added together cost one scan, where ten separate additions cost ten. If a line is not a hostname or an IP address, the rest are still added and the dialog stays open holding only the lines that failed, so you fix those rather than retyping the list. A mistyped address such as 999.1.1.1 is rejected rather than accepted as a hostname, which would otherwise put an asset in the estate that can never resolve.
Disputing an asset starts a rescan, and so does withdrawing a dispute. A verdict only reaches the rating once the scan has run again, and withdrawing one is what puts the asset back into the score.
Each row carries when the asset was first and last seen. An asset the scan can no longer find is kept and marked No longer seen rather than deleted, because an asset leaving the estate is as worth knowing about as one arriving.

​
Email authentication

SPF, DKIM and DMARC as actually published. What matters is the policy, not merely the presence of a record: a DMARC record set to none monitors and enforces nothing, and an SPF record ending in +all authorizes the entire internet to send as that domain.

​
Web hardening

Transport and browser-facing protections on the vendor’s public sites: TLS configuration and the security headers a browser acts on.

​
Breaches and exposed credentials

Known breach records and credential exposures associated with the vendor’s domains, with dates. Age matters: a decade-old breach and one from last quarter are different conversations.

​
Reputation and blocklists

Whether the vendor’s domains or hosts appear on public blocklists or threat feeds.

​
Security disclosures

Whether the vendor publishes a vulnerability disclosure policy or security contact. Its absence is a maturity signal, not a vulnerability.

​
What was scanned

Which checks ran, when, and which did not resolve. A factor that could not be scanned is reported as such rather than scored as a pass.

​
Known vulnerabilities

Vulnerabilities are matched against software observed on the vendor’s estate, and ordered by how likely they are to be exploited rather than by severity alone. A vulnerability on CISA’s Known Exploited Vulnerabilities list is called out separately. Those are being used against real targets now, and they are worth a same-week conversation rather than a note in a report.

​
Lookalike domains

The page lists domains built to resemble the vendor’s own, and marks which of them resolve and which can receive mail. A mail-capable lookalike is the one to care about. It can host a page and receive replies, which is the shape of a supplier-invoice fraud attempt against you rather than against them.

​
Troubleshooting

Financial health guide

The other outside-in score on the same vendor.

Zero Touch Assessments

Security posture as a scored component.