> ## Documentation Index > Fetch the complete documentation index at: https://docs.coverbase.com/llms.txt > Use this file to discover all available pages before exploring further. # Black Kite monitoring guide > How to connect your Black Kite portfolio to Radar, choose which vendors are watched, and turn known exploited vulnerabilities and focus tags into alerts.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](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](/user-guides/overview) collection. It assumes your organization already has a Black Kite subscription. For what Radar does generally, see [Supplier Radar](/products/supplier-radar). If you already pay Black Kite to rate your suppliers, this connects that rating work to the rest of your risk program. Coverbase sweeps your Black Kite portfolio on a schedule, matches each company back to the vendor record you already hold, and raises a Radar alert when a vendor you care about picks up an exploited vulnerability or an incident write-up. Two things shape the choices on the setup page. **Black Kite limits how fast anyone can read it.** Your Black Kite tenant is capped at 60 API requests a minute, and there is no single call that returns every finding in your portfolio. Findings are fetched one company at a time. The settings below are therefore not only a filter on what you see. They also decide how far Coverbase can get through your portfolio in a day, so narrowing the scope is what lets monitoring keep up. **A source collects; a detector alerts.** These are two separate steps. Doing only the first is the usual reason nothing appears to happen, so the configuration page walks you through both. ## Before you start You need: * A Black Kite **client ID and client secret** with API access. Your Black Kite administrator generates these. * Permission to manage integrations in Coverbase (**Integrations: update**). * Vendors in Coverbase whose website matches the domain Black Kite monitors. That match is how a Black Kite company becomes one of your vendors, and it is exact, so read [how matching works](#how-black-kite-companies-become-your-vendors) before you start. ## Step 1. Connect your credentials Go to **API** in the left navigation, open the **Integrations** tab, and choose **Black Kite**. Paste your client ID and client secret and click **Save**. Then click **Test connection**, which makes one harmless call to Black Kite and confirms the credentials work. Do it now rather than finding out from a week of failed overnight runs. Black Kite configuration page showing API credentials and Radar monitoring settings Your client secret is stored encrypted and is never shown again. If you lose it, generate a new one in Black Kite rather than trying to recover it here. ## Step 2. Choose what gets collected Once credentials are saved, the **Radar monitoring** section appears on the same page. Coverbase can collect two kinds of signal from Black Kite. Turn on either or both. **Known exploited vulnerabilities.** CVEs from the CISA Known Exploited Vulnerabilities catalog that Black Kite found on a vendor's internet-facing infrastructure. "Known exploited" means attackers are using the flaw now, not that it is theoretically severe. These merge with the vulnerability intelligence Coverbase already collects from NVD and CISA, so you get one view of a CVE rather than two. **Focus tags.** The incident write-ups Black Kite's research team attaches to a company, such as a reported ransomware attack, a data breach, or a supply-chain compromise. You get their headline and evidence, not only a label. Leave the focus tag list empty to collect every tag. If you name specific tags, Black Kite's newly published ones are ignored until you come back and add them, and the newest tags are usually the ones about a campaign that is currently running. Black Kite monitoring settings with signal toggles and thresholds ## Step 3. Decide which vendors are watched Spend the most time on this setting. **Ransomware Susceptibility Index threshold.** Black Kite scores every company from 0 to 1 on how likely it is to suffer a ransomware attack. Set a threshold and Coverbase only looks closely at vendors above it. The default is 0.5. Turning this off means examining every vendor in scope, which uses considerably more of your daily request budget. **Technical grades.** Optionally also examine vendors carrying particular Black Kite letter grades, regardless of their susceptibility score. Leave it empty to apply no grade rule. **Vendor scope.** A filter over your own vendor records. Only vendors matching it are monitored at all. This is where you encode your policy. A common shape is *inherent risk is significant or high*, **and** *the vendor handles regulated data*. Both are ordinary vendor filters: * **Risk ranking** uses your own **Inherent risk level**, whatever you have named your levels. * **Regulated data access** (PHI, PCI, SSN) uses a vendor field you control. If you do not already track this, create a multi-select custom field on vendors, for example *Regulated data* with options *PHI*, *PCI* and *SSN*, and populate it. Vendor tags work too. Either becomes filterable here immediately. Coverbase does not infer PHI or PCI access for you here. The data types recorded on a vendor's risk profile are extracted from assessment text as free-form wording, so "PHI", "Protected Health Information" and "PHI (HIPAA)" all appear as different values. That is precise enough to read, but not precise enough to decide who gets monitored. A field with a fixed option list is. **Vendors examined per run.** A ceiling on how many vendors get a detailed look in a single pass. The most ransomware-susceptible go first, and anything past the ceiling is picked up on the next run rather than dropped. Raise it if your portfolio is large and you would rather trade run time for coverage. Click **Save monitoring settings**. ## How Black Kite companies become your vendors Read this before you troubleshoot, because most "why is nothing happening" questions come down to matching. The nightly run matches on **domain**. Black Kite reports a domain for each company it monitors, and Coverbase compares it against the **vendor's own website**, the website on the **company record** the vendor is linked to, and any **domains you have added by hand** (see below). Any one of them matching is enough, which helps when you have recorded the product domain and Black Kite monitors the corporate one. Before comparing, both sides are tidied up the same way. Capitals are lowered, `https://` and any path are dropped, and a leading `www.` is removed. Coverbase then tries three things in order, stopping at the first that works: 1. A **company already pinned** to the vendor by an on-demand check. This is the most reliable, because it is Black Kite's own company id rather than a string comparison. 2. An **exact host match**. 3. The Black Kite host's **parent domain**, walked one label at a time. | Black Kite monitors | Your vendor's website | Match | | ------------------------ | --------------------------------------- | ---------------------------------------------------------- | | `northwind.example` | `northwind.example` | Yes | | `northwind.example` | `https://www.northwind.example/careers` | Yes | | `mail.northwind.example` | `northwind.example` | Yes. The parent is tried after the exact host. | | `northwind.example` | `app.northwind.example` | **No.** Step 3 only ever climbs, never descends. | | `halden.example` | `haldenmedical.example` | **No.** A near-identical name is still a different domain. | | `orbitline.example` | (no website recorded) | **No.** Nothing to compare. | Step 3 climbs but stops before the registrable domain, so `aws.amazon.com` never reaches a vendor recorded as `amazon.com`. Those are different suppliers, as are Opsgenie and Atlassian. A vendor with no website recorded can never match, no matter how it is scoped or which detector is watching. If you are testing this and seeing nothing, check the website field first. Two more things follow from matching this way: * **Matching only ever climbs.** Coverbase would rather miss a match than quietly file one supplier's exploited vulnerability under another. * **If two vendors share a domain, only one of them gets the findings.** Which one is stable between runs, but it is arbitrary. That is a sign of a duplicate vendor record to merge, not something to configure around. For alerts to attribute correctly, a vendor should also be linked to a company record, which happens on its own when you create the vendor by picking it from the directory rather than typing a bare name. Exploited vulnerabilities are recorded against the CVE, so one CVE can affect several of your vendors at once. The company link is how Coverbase keeps each vendor's alert to that vendor's own findings. ## Fixing a vendor that will not match Every vendor page carries a **Black Kite** card in its Radar section, in both the current and the previous vendor layout. It shows which portfolio company the vendor is pinned to and gives you the two ways to correct it. Vendor Black Kite card showing the matched company, its ransomware index and technical grade **Check Black Kite now** searches your portfolio for this one vendor, by its recorded domains first and then by name. Name search is what makes it useful when the domain never matched. Finding a company **pins it by id**, so every later run matches on that id instead of guessing, and any findings it collects are ingested immediately. Vendor Black Kite card reporting that no portfolio company matched **Domain matching** holds the domains Black Kite records for the company, and below them the domains your team has added. A scan never overwrites what you added by hand. Use it when Black Kite monitors a domain you do not have recorded anywhere. Two states look like a broken integration and are not: Vendor Black Kite card warning the vendor is outside the monitoring scope Vendor Black Kite card showing no ransomware index or grade for an unrated company The card only appears once Black Kite credentials are saved. Editing domains needs permission to update vendors; the check button needs permission to run integrations. ## Seeing what did not match A nightly run records the portfolio companies it could not attribute to any vendor, as `black_kite_companies_unmatched` with a sample list on the run. These are usually companies you monitor in Black Kite but have not created as vendors in Coverbase, or vendors whose recorded website never lined up. Review this list after a run. ## Step 4. Create a detector Saving the settings above starts collection. It does not raise any alerts on its own. A **detector** decides which collected findings are worth someone's attention. The monitoring section shows a **Detectors** panel with a **Create detector** button. Click it and Coverbase creates a detector wired to your Black Kite source, then opens it for editing. You can also start from the detector library under **Radar → Detectors → Add detector**. Search for *Black Kite* and you will find five ready-made policies, each marked with a Black Kite badge. They are already wired to your source. Detector library filtered to the five Black Kite templates, each showing a Black Kite badge | Template | Use it when | | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Exploited Vulnerabilities** | You want broad coverage. KEV only, with no susceptibility threshold, because an exploited flaw on a supplier's own infrastructure is urgent regardless of their ransomware score. | | **Critical Exploitable CVEs** | The broad one is too noisy. CVSS 9.0 and above, with at least a 50% predicted chance of exploitation. | | **Vulnerability Campaign Exposure** | You want early warning. Focus tags only, which usually arrive before a supplier confirms anything. | | **Ransomware-Susceptible Vendor Exposure** | The usual starting policy. Both signals, limited to vendors scoring above 0.5. | | **Highest Susceptibility Watch** | You want a short list. Both signals above 0.8. | A detector keeps the name it was created with. If you adopted these templates before the names were shortened, your existing detectors still read "(Black Kite)" at the end. They keep working. Rename them if you prefer. The detector has its own criteria, and every one of them is a requirement rather than a preference. A finding raises an alert only when its signal is switched on **and** it clears every threshold you have enabled: | Setting | What it does | | --------------------------------------------------- | ---------------------------------------------------------------------- | | **Alert on known exploited vulnerabilities** | Whether KEV findings can alert at all | | **Alert on focus tags** | Whether focus tags can alert at all, optionally narrowed to named tags | | **Require a Ransomware Susceptibility Index above** | Suppresses alerts for vendors at or below the score | | **Require a CVSS score of at least** | Suppresses lower-severity vulnerabilities | | **Require an EPSS probability of at least** | Suppresses vulnerabilities unlikely to be exploited | Each threshold has its own switch. Switching one off means **no constraint on that criterion**, which is different from setting it to zero. A vendor Black Kite has not scored does **not** clear a susceptibility threshold. "Above 0.5" cannot be satisfied by a blank. If you want unscored vendors to alert, turn that requirement off rather than setting it to 0. You also choose which vendors the detector applies to and who reviews its alerts, exactly as with any other Radar detector. Set **Enabled** when you are ready, and save. Start narrow. Turn on KEV only, keep the susceptibility threshold at 0.5, and watch a week of alerts before widening. Adding a signal later is easier than recovering your team's attention after a noisy first week. ## What an alert looks like A Black Kite detector's findings reach you as signals in **Radar → Signals**, like any other detector's. Open the signal, and the **Detectors** tab names the vendor, the finding, and the criteria it met, so you can see which rule fired rather than guessing. A known-exploited vulnerability is always **High**, because it is being exploited in the wild and it was found on that vendor's own infrastructure. A focus tag is **High** when the vendor is also ransomware-susceptible, and **Medium** otherwise. Vulnerability alerts carry the CVE, the CVSS and EPSS scores, the affected asset Black Kite saw it on, and whether the vulnerability is known to be used in ransomware campaigns. Because the CVE is recorded properly, the alert joins up with everything else Coverbase knows about that vulnerability instead of sitting on its own. ## Checking it is working The monitoring section shows **Last successful run**. If that says *Not yet run* more than a day after you saved, or the date stops advancing: | What you see | Usually means | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Not yet run** after a day | The first scheduled pass has not happened yet, or credentials were saved after the source. Re-run **Test connection**. | | Runs succeed, no alerts | Collection is on but no detector is enabled, or every finding is being suppressed by a threshold. Check the **Detectors** panel first. | | Fewer vendors than expected | Vendor websites do not match the domains Black Kite monitors, or your vendor scope is narrower than you intended. | | Alerts stopped suddenly | Black Kite credentials may have been rotated or revoked. **Test connection** will say so. | Black Kite monitoring panel warning that no detector is watching the source Most shortfalls come back to matching. If Black Kite monitors `acme-corp.com` and your vendor record says `acme.io`, they will not connect. Correct the vendor's website and it will match on the next run, with no need to re-save anything here. Timing details: * **The first run does not wait a day.** A newly connected source is due immediately and gets picked up on the next scheduled pass, not 24 hours later. * **Vendors past the per-run ceiling are deferred, not dropped.** The most ransomware-susceptible are examined first, and the rest are picked up by the following run. A run that looks short is usually this rather than a failure. * **A vendor Black Kite has not scored will not clear a susceptibility threshold.** That is a suppressed alert, not a missing finding. * **KEV is also one of Black Kite's focus tags.** When you have exploited vulnerabilities switched on, Coverbase does not also collect the KEV tag as a write-up, so the same exposure is not filed twice in two shapes. If credentials fail partway through a pass, **Last successful run** does not advance. It reflects the last pass that completed, so a stale date means a run has been failing. ## Turning it off Removing the credentials on this page stops everything: no further runs, and no further alerts. Existing alerts and their history are kept. To pause alerting while keeping collection, disable the detector instead. To stop collecting while keeping your settings, archive the Black Kite source under **Radar → Sources**. ## Related What Radar does, and how sources and detectors fit together. The ready-made detector policies, including the Black Kite ones. Coverbase's own outside-in security rating on the same vendor.