secopsctl:~$ docs█

secopsctl docs

secopsctl operates Google SecOps (Chronicle SIEM + Siemplify SOAR) as code — the way Terraform operates cloud infra. Two products, two planes, one CLI. These docs are the contract: read them before changing the surface.

The model in one screen

Two products (SIEM · SOAR), each split across two planes — control (config as code) and operational (live data). One CLI; the two planes are two loops:

flowchart LR
  SIEM["SIEM · Chronicle<br/>ADC / OAuth token"]
  SOAR["SOAR · Siemplify<br/>AppKey · reliable path"]

  subgraph CONTROL["CONTROL plane — config as code"]
    direction LR
    live[("live<br/>instance")] -- "pull · read" --> files[("local files<br/>git")]
    files -- "git diff → push · reconcile" --> live
  end

  subgraph OPS["OPERATIONAL plane — live data"]
    direction LR
    query["query<br/>list · search · udm"] --> review{"review<br/>subset"} --> act["act<br/>dry-run → --yes"]
  end

  SIEM --> CONTROL
  SIEM --> OPS
  SOAR --> CONTROL
  SOAR --> OPS

The four quadrants — which surfaces live where (status in CATALOG.md):

  SIEM · Chronicle SOAR · Siemplify
Control
pull → push		 rules · reference_lists · data_tables · feeds · parsers · dashboards · curated* webhooks · environments · networks · idp · soc-roles · blacklists · case-stages · case-tags · playbooks · visual-families · …
Operational
query → act		 events (read-only) · alerts · cases (UUID) soar case list/get (read) · soar case (per-case verbs) · bulk-close

* curated = Google-managed: read + enable/disable/alerting, not full CUD. The SOAR list is representative (14 surfaces total) — the authoritative set + live status is in CATALOG.md.

How these docs are organized

Doc What it is Read it to…
README.md (this) The map: model, diagram, index get oriented
ARCHITECTURE.md The cross-cutting design — engine, lanes, planes, auth, safety, reliability understand how it works (any surface)
CATALOG.md Every surface & command + a status matrix (designed / built / validated) see what exists and its maturity — the tracker
SOAR-DESIGN.md SOAR specifics (3 tiers, gotchas, per-surface notes) work on SOAR
SIEM-DESIGN.md SIEM specifics (two planes, cases/alerts model) work on SIEM
ROADMAP.md Waves / sequencing see what’s next

Doc schema (the rules these follow). One concept per doc; short prose, dense content (no filler). The CATALOG is the source of truth for status — every surface carries a designed / built / validated state, so design and implementation never drift. A surface is not “done” until it’s live-validated (read round-trips clean; a write smoke ran on an inert throwaway). Design changes land in the design docs with the code in the same change; CATALOG status updates in the same commit that moves a surface forward.

Conventions (apply everywhere)