Syslog substrate (Vector-backed)

The SyslogSubstrate is the engine that means CyberCLI ingests almost anything that emits a log line without bespoke per-product Python code. Vector handles the transport (file-tail, syslog TCP/UDP, journald), the substrate's VRL configs handle the parse, and the engine sees uniform NDJSON regardless of source. A new log source becomes a connector by writing one VRL config + one connector manifest, not a parser + a transport + a poller.

Other AI security products either ship a heavy in-tree ingest (Wazuh's manager process) or assume you'll wire your own log pipeline (the Sentinel + Splunk forwarder dance). CyberCLI ships the substrate inline — the binary includes Vector, configures it from the operator's connector choices, and runs it as a sibling service. The buyer never edits a Vector config by hand; the operator runs `cybercli setup add-syslog-source <slug>` and the engine writes the right conf.d/ entry.

The substrate is also what makes the breadth catalog (nginx, apache, pfSense, Suricata, Zeek, osquery, Falco, Coraza, Keycloak, OpenVPN, Proxmox, Traefik, HAProxy, ClamAV, WireGuard, and the rest) cheap to add. Each connector is a one-page VRL parser + a connector manifest + a setup verb. The marketing-breadth roster grew from 1 to 27 connectors in three weeks because the substrate carries the heavy work.

On `cybercli setup install-syslog`, the engine drops a Vector unit file + a Vector binary + the base config under `/etc/cybercli/vector/`. The base config wires a single Unix-socket sink that the syslog-ingest-consumer drains. Each subsequent `cybercli setup add-syslog-source <slug>` appends a per-source `conf.d/<slug>.toml` carrying the source-specific transform + the VRL parser block for that log shape.

Vector runs as `cybercli-vector.service` (systemd). It reads each conf.d/ file, builds the transform graph, parses every line through the matching VRL config, stamps the canonical `cybercli_connector` + `event_type` fields, and writes the resulting NDJSON to the Unix socket. The substrate's VRL configs use typed parsers (`parse_apache_log`, `parse_regex`, `parse_syslog`) that return TYPED objects, not unknown blobs — the `??` fallback operator is unnecessary on these.

The syslog-ingest-consumer (a sibling engine) reads the Unix socket, decodes each NDJSON line, and hands the result to the appropriate per-connector IngestPipeline based on the `cybercli_connector` field. From there the SocPipeline takes over. The substrate-to-pipeline boundary is the Unix socket + the NDJSON shape; everything before the socket is Vector territory, everything after is engine territory.

Per-source VRL configs are render-validated before deploy. The setup verb runs `vector validate <config>` on the rendered file; a syntax error fails the setup call cleanly, no half-installed source. This pattern is the reusable harness chris's [[reference_cybercli_syslog_substrate_truth]] memory points at — the install/migration/systemd hardening is real backlog work, but the validation gate keeps the per-source surface honest.

Stable — Vector is on its third stable release in the substrate; the conf.d/ render+validate pattern has handled 27 connector packs without a single mis-deployed config making it past validation.

Known limit: Vector is the only transport substrate today. A direct-API substrate (Wazuh REST, M365 Graph, Unifi cloud API) lives outside this engine — those connectors run their own polling code. Unifying all substrates under one abstraction is a v1.5 architecture item.

Known limit: VRL parser updates require a Vector restart (systemctl restart cybercli-vector). Hot-reload of conf.d/ entries is a Vector roadmap item upstream; until then operators see a ~2s gap on parser-change deploys.