A FINDING cannot carry the port it was found on

Ask: a supported way to say "this CVE is on port 443", so event.port and event.netloc are populated on a FINDING.

Modules that read a service banner — Shodan, and anything parsing nmap-like output — know exactly which service a finding belongs to. There is currently nowhere to put it:

• FINDING._data_validator accepts a fixed field set (host, severity, name, description, confidence, url, full_url, path, cves, archive_url) and silently drops anything else, so a port in event data disappears without a warning.
• Neither make_event() nor BaseEvent.__init__() takes a port.
• ClosestHostEvent is documented to inherit host and port from the closest parent, but does not — see issue 2.

The workaround is to emit the finding with the banner's OPEN_TCP_PORT / OPEN_UDP_PORT as its parent and have consumers walk the parent chain or regex discovery_path. It works, but every consumer pays for it — including BBOT's own output/nmap_xml.py, which reads getattr(event, "port", None) and therefore records such findings without a port.

Setting finding._port after make_event() does produce finding.port == 53 and netloc == "8.8.8.8:53", so the machinery is there; it is reaching into event internals, which no module does, so it seems worth a supported path.