Writing workflows

... or how to integrate new workflows with secator.

New secator workflows should be easy to write to promote contributions from the community.

Eventually we aim for our workflow library to become a reference in cyber-security much like Nuclei templates have become a reference for vulnerability searching.

---

Basic YAML definition

secator workflows are defined through YAML configs:

secator/configs/workflows/url_finder.yaml

type: workflow
name: url_finder
alias: ufind
description: URL finder and tagger
tags: [http]
input_types:
  - url
tasks:
  katana:
    description: Find URLs
    rate_limit: 100
    timeout: 1
  gf:
    description: Tag URLs
    pattern: xss

---

Dynamic targets

You can specify dynamic targets for tasks from current run results, by using the targets_ key in your template like:

...
tasks:
  ...
  gf:
    description: Tag URLs found by the previous task
    targets_:  # use previously found URLs
    - type: url
      field: url
      condition: item.status_code == 200

The dynamic format keys are:

• type is the output type, lower-case (see for the whole list)

• field is the JSON field to use as target

• condition is the filtering condition.

---

Concurrent tasks

You can specify tasks that run in parallel using the _group key:

...
tasks:
  ...
  katana:
  _group:
    gf:
      ...
    another_task:
      description: Runs concurrently with the `gf` task

In this configuration, the katanatask will begin the run, followed by a grouped execution of gf and another_task.

Concurrent tasks requiresecator to be setup in worker mode (see Distributed runs with Celery).

---

Result filtering

You can customize which results you want to keep for workflows and scans by adding the results key to the respective runner YAML configuration:

...
results:
- type: ip
  condition: item.alive
- type: url
  condition: item.status_code == 200

Filters apply to final run results sent to Exporters, but do not apply to real-time results sent to Drivers.

---