# Approval flow

The gate is the point of the project, so it gets its own document.

## 1. Bundle generated

A pipeline run produces a candidate bundle and stages it under

`output/candidates/<bundle-id>/`:

```

lists/cti-malicious-ip

lists/cti-malicious-domain

lists/cti-malicious-url

lists/cti-malware-hash

lists/cti-leaked-email

local_cti_rules.xml

ttp_coverage.md

manifest.json

keys.json

```

`manifest.json` carries the counts, the technique list, and the diff against the

last approved bundle (added / removed / unchanged).

## 2. Analyst emailed

The email summarizes the bundle - new vs. aged-out indicators, counts by type, and

the extracted ATT&CK techniques - and links to the review page. The link embeds an

`itsdangerous` signed token:

```

URLSafeTimedSerializer(secret, salt="cti-rule-approval").dumps({"bundle_id": ...})

```

The token is signed with `CTI_APPROVAL_SECRET` and carries a TTL (`token_ttl`,

default 24h). It can't be forged without the secret and stops working once it

expires, so a stale email can't approve an old bundle.

The backend is pluggable: `file` (writes the rendered email to disk, used by the

demo), `console`, or `smtp` for a real inbox.

## 3. Review

The review page renders the manifest - the diff cards, indicators by type, the

generated CDB lists and their sizes, and the full ATT&CK coverage table. The analyst

has the whole picture without leaving the page.

## 4. Decision

- **Approve** → `promote` copies the candidate into `output/active/`, updates the

  baseline used for the next diff, and (when `wazuh_etc_dir` is set) writes the lists

  and rules into the Wazuh manager. A reload picks them up.

- **Reject** → a `REJECTED` marker with the optional reason is written to the

  candidate directory and nothing is deployed.

Either way the decision is recorded and the bundle's status shows on the dashboard.

## Token, not session

There's deliberately no login. The signed link is the authorization - it's what was

emailed to the analyst, it's scoped to one bundle, and it expires. That keeps the

service stateless and means it can sit behind a reverse proxy on the SOC network

without its own user store. For a multi-analyst setup you'd put SSO in front of it;

the token model doesn't change.