Five Cisco 10.0s, and no advisory: what the supplied documents actually say

A perfect CVSS score is a claim about reachability and impact, and it becomes work only when it arrives with an identifier and a list of affected release trains. Neither is here. The Cisco document supplied to this desk explains how automatic policy discovery groups workloads into clusters from signals observed in a timeframe set by the run configuration ^[2], not what an attacker can do to the product.

That guide is still worth an hour in a week when patching is blocked, for one detail. Cluster queries are dynamic unless you pin them to specific IP addresses, so a query written against a hostname substring takes in matching hosts as they are added ^[3]. Segmentation that enrols new machines on its own is a containment boundary; segmentation pinned to addresses is a snapshot of the day you wrote it.

On the GitLab side, the runbook enumerates what tends to leak: passwords, personal, group and project access tokens, runner tokens, pipeline trigger tokens and SSH keys ^[8]. Its response steps are clerical and that is the point. Record the time the credential was exposed and the time it was revoked, then work the audit log for newly created users, new tokens, malicious pipelines and changes to code or project settings ^[10].

The figure at the top of the card is not in either document ^[13]. We are not going to reconstruct five CVE numbers from memory. A citation to an advisory nobody supplied is worse than a blank, because a blank does not send anyone patching the wrong train.