Pillar 07 of 12

Automation you can diff,
review and roll back.

A workflow is a YAML file, not a canvas whose meaning lives in a database. It goes through review like code, it is copied between environments as a file, and every run records the exact request and response of every step.

nullsoc.in / playbook / workflows
The NullSOC workflow list with trigger kind, last run and enable state per workflow.

Workflows as files. Trigger kind, last run and state, all in the list.

4
Trigger kinds
Finding, inbound webhook, cron schedule and manual.
21
Credential types
Each with a real connection test, and OAuth2 where it applies.
14
Step keywords
Including approval, script, loop and deduplicating memory.
1
Grammar
Workflow conditions use the detection operator registry.
Triggers

Four ways to start, one way to write it.

A workflow fires on a finding that matches a condition, on an inbound webhook, on a cron schedule evaluated in your timezone, or because somebody pressed run. The trigger is a few lines at the top of the same file.

  • Finding triggers match with the same operators as a detection rule, including correlation results.
  • Webhooks give each workflow a token URL and hand the whole nested body to the run context.
  • Schedules are five field cron, evaluated in the administrator timezone rather than UTC.
  • Manual runs are for the response you want a human to start and the platform to carry out.
ssh-brute-force-response.ymlworkflow 20001, shipped
id: 20001 name: SSH brute-force response description: On repeated SSH auth failures, raise an alert, open a case, and notify the SOC. enabled: true match: rule.id: 5720 steps: - case: raise-alert - case: open-case - send: it-team-email - send: soc-telegram

A real shipped workflow, unedited. The trigger is a match block, the rest is a step list.

Steps

Enrich, decide, remember, wait for a human.

Steps run in order and read each other results. Beyond calling connectors there are conditionals, loops, parsing, variables, a durable memory that stops a workflow acting twice on the same thing, and an approval step that pauses the run until a person agrees.

  • Approval pauses the run. It moves to awaiting approval and waits in an inbox. Approve to resume, reject to stop.
  • Memory prevents repeats. skip if seen and remember stop a beaconing host from being blocked hourly.
  • Scripts run where you decide. Shell, bash or Python steps with their output captured into the run record.
  • Parameters are plain keys. A field name fills itself in. Use $field only to place a value inside text.
nullsoc.in / playbook / runs
The workflow run list with status, trigger, duration and step count per run.

Every run, with status and duration. Open one for its step by step record.

Connect anything

The credential, the connector and the channel are separate on purpose.

A credential is only the login. A connector is one reusable operation that references it. A channel is a connector plus a preset message. Rotate a secret in one place and everything built on it keeps working, without a secret ever being readable again.

  • Write once, never read back. Secrets are encrypted at rest and shown as set, never returned to the browser.
  • Test every type. Each of the 21 credential types has a real connection test, not just a saved form.
  • OAuth2 where it belongs. Authorization code with PKCE, including refresh, for the services that require it.
  • One channel, every surface. The same channel serves playbook steps, alert routing and scheduled report delivery.
nullsoc.in / playbook / channels
The channel list showing the connector application and credential behind each delivery channel.

Channels are the shared delivery layer for playbooks, alerting and reports.

Every run, recorded

When it goes wrong, the evidence is already there.

Automation that fails silently is worse than none. Each run stores its outcome and, per step, the exact request sent, the response received and any error raised, so a broken integration is diagnosed from the record instead of reproduced by hand.

  • Per step request and response are kept, so a four hundred from a vendor API is visible immediately.
  • Sub workflows are real runs with their own inspectable record, not an opaque nested call.
  • Retention is a setting that drives the run history expiry, like every other table.
  • Approvals are auditable. Who approved, when, and what the run did next.
Workflow facts
FormatYAML, one file per workflow
Triggersfinding, webhook, cron, manual
Conditionsthe shared detection operator registry
Stepsuse, send, case, run, if, filter, for each
Controlapprove, wait, parse, set, respond
Memoryskip if seen, remember, cache, with a TTL
Scriptssh, bash and python, output captured
Credentials21 types, encrypted, test on each
Run recordper step request, response and error
Get started

Bring the response runbook
that lives in a wiki.

Show us the page your analysts follow by hand at two in the morning. We will turn the first three steps into a workflow on the call.

Powered by Codesecure Solutions. Self hosted, cloud or fully managed.