f3nris
45e9cbd269
467 of the 1592 commands carried no `risk:`. An unset risk is read as
destructive by the agent approval gate, so half the catalog's write side sat
behind the same prompt — and, in HarfangLab's case, 39 pure lookups did too.
A gate that stops everything stops being read as a signal, which is the
argument already made for the toolkit and for sentinelone (df27876).
The catalog is now 1027 read, 261 safe_write, 304 destructive, with nothing
defaulted. The line follows the one sentinelone drew: impact on the estate,
not reversibility — isolate-agent is reversible and is the canonical
destructive example.
read only queries; changes nothing outside Riposte
safe_write additive or reversible inside the tool's own case/enrichment
plane: comments, tickets, tags, alert statuses, threat-intel
records, sandbox submissions, collection jobs, outbound messages
destructive changes the estate or weakens a control: containment, blocklists
and allowlists, exclusions and detection rules, every delete,
identity and credential operations, code on a host, generic
API escape hatches
Three calls that were not obvious, and are now applied throughout:
- Undoing a containment is tiered like the containment it lifts. Un-isolating
a host or un-banning an IP mid-incident is its own decision, not a return to
a neutral state. The catalog contradicted itself here — crowdstrike's
lift_containment was destructive while harfanglab's deisolate_from_threat
was safe_write — so deisolate_from_threat and unquarantine_file are
re-tiered to destructive, the only two existing tiers this pass changes.
- Retrieving a live secret is destructive: cyberark get_password, delinea
get_secret, vault read_secret, beyondtrust get_credential. It is a GET, but
the tier describes the stake, not the HTTP verb.
- Sending outward to humans stays safe_write — slack, teams, twilio, telegram,
mail. Irreversible, but it is the collaboration plane, not the estate.
An object created but not yet referenced by a rule is safe_write; editing one
a rule already reads is destructive. That is why fortigate create_address and
panos create_custom_url_category are safe_write while update_address_group and
edit_custom_url_category are not.
The template and README never documented the field, which is how 467 commands
came to omit it. Both now carry the tier table and these rules, so the next
integration declares a tier instead of inheriting one.
111 packages get a MINOR bump and a changelog entry: an instance compares
versions to offer an update, so an unbumped manifest would leave the tiers
sitting in the catalog and never reaching the estates that need them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
161 lines
6.3 KiB
Markdown
161 lines
6.3 KiB
Markdown
# Riposte Marketplace
|
|
|
|
Official catalog of **integrations** for the [Riposte](https://gitea.riposte-labs.com/f3nris/riposte) SOAR platform.
|
|
|
|
Riposte syncs this repository (a "git source") and lists every integration it
|
|
finds so operators can install them in one click. Nothing here is executed at
|
|
sync time — Riposte only reads manifests and scripts.
|
|
|
|
---
|
|
|
|
## How discovery works
|
|
|
|
When Riposte syncs a source it does a shallow `git clone` of the selected branch
|
|
and walks the whole tree looking for files named exactly **`manifest.yaml`**.
|
|
|
|
- **Each `manifest.yaml` is one integration.** Its containing directory is the
|
|
package root. Put one integration per directory.
|
|
- **Scripts** are collected from the package directory **and** its `scripts/`
|
|
subdirectory: every `*.py` file becomes a command implementation, keyed by
|
|
filename without the extension. So a command with `id: get_ip_report` is backed
|
|
by `get_ip_report.py`.
|
|
- Files **not** named `manifest.yaml` are ignored as integration roots, so
|
|
templates like `manifest.example.yaml` are never ingested.
|
|
|
|
```
|
|
integrations/
|
|
└── <integration-id>/
|
|
├── manifest.yaml # required — the integration definition
|
|
└── scripts/ # optional — only for script-based commands
|
|
└── <command-id>.py
|
|
```
|
|
|
|
---
|
|
|
|
## Manifest schema (`manifest.yaml`)
|
|
|
|
```yaml
|
|
id: my_integration # required, unique, slug
|
|
name: My Integration # required, human name
|
|
version: 1.0.0 # semver
|
|
description: What it does.
|
|
changelog: "1.1.0 — notes" # optional: shown on update so operators can assess risk
|
|
category: enrichment # free text (enrichment, containment, ticketing…)
|
|
|
|
# Per-instance configuration the operator fills when creating an instance.
|
|
# JSON-Schema shape: { properties: {...}, required: [...] }.
|
|
config_schema:
|
|
properties:
|
|
base_url:
|
|
type: string # string | number | boolean
|
|
description: API base URL
|
|
default: https://api.example.com/v1
|
|
api_key:
|
|
type: string
|
|
description: API key
|
|
x-soar-sensitive: true # stored encrypted in the vault, never returned
|
|
required:
|
|
- api_key
|
|
|
|
# Authentication methods, referenced by commands via `auth_ref`.
|
|
auth:
|
|
- id: apikey
|
|
type: api_key # api_key | bearer | basic | oauth2_client_credentials
|
|
in: header # header | query
|
|
name: x-apikey # header/query parameter name
|
|
value_template: "{{secret}}" # {{secret}} is replaced by the secret_field value
|
|
secret_field: api_key # which config_schema field holds the secret
|
|
|
|
commands:
|
|
# --- Request-based command (recommended, no code) -----------------------
|
|
- id: get_ip_report
|
|
name: Get IP report
|
|
description: Reputation for an IP address.
|
|
risk: read # read | safe_write | destructive — see below
|
|
inputs_schema:
|
|
properties:
|
|
ip:
|
|
type: string
|
|
description: IP address to look up
|
|
required:
|
|
- ip
|
|
outputs_schema:
|
|
properties: {}
|
|
request:
|
|
method: GET # GET | POST | PUT | PATCH | DELETE
|
|
path: /ip/{ip} # {ip} is filled from inputs
|
|
query: [] # input names sent as query params
|
|
body: [] # input names sent as JSON body fields
|
|
auth_ref: apikey
|
|
|
|
# --- Script-based command -----------------------------------------------
|
|
# Omit `request` and provide scripts/<id>.py instead. The script receives the
|
|
# resolved inputs + instance config and MUST print one JSON object to stdout.
|
|
- id: enrich_custom
|
|
name: Custom enrichment
|
|
description: Runs scripts/enrich_custom.py in a sandbox.
|
|
risk: read
|
|
inputs_schema:
|
|
properties:
|
|
indicator:
|
|
type: string
|
|
required:
|
|
- indicator
|
|
outputs_schema:
|
|
properties: {}
|
|
```
|
|
|
|
A command is **request-based** when it has a `request:` block, or
|
|
**script-based** when a matching `scripts/<command-id>.py` exists. Prefer
|
|
request-based commands: they need no sandbox and are easier to audit.
|
|
|
|
### `risk:` — the agent approval gate
|
|
|
|
Every command declares a tier. It is what Riposte's agent approval gate reads:
|
|
`read` runs unattended, `safe_write` and `destructive` sit behind the operator's
|
|
configured threshold. An omitted `risk` is treated as **destructive** — safe, but
|
|
it makes a lookup as noisy as an isolation, so declare it rather than default it.
|
|
|
|
| Tier | What belongs there |
|
|
|------|--------------------|
|
|
| `read` | Only queries. Changes nothing outside Riposte: lookups, searches, telemetry, fetching a job's result. |
|
|
| `safe_write` | Additive or reversible, inside the tool's own case/enrichment plane: comments, notes, tags, tickets, alert statuses, threat-intel records, sandbox submissions, collection jobs, outbound messages. |
|
|
| `destructive` | Changes the estate or weakens a control: containment **and its removal**, blocklists and allowlists, exclusions and detection rules, every delete, identity and credential operations, running code on a host, generic API escape hatches. |
|
|
|
|
Two rules the catalog applies consistently, because they are not obvious:
|
|
|
|
- **Undoing a containment is tiered like the containment it lifts.** Un-isolating
|
|
a host or un-banning an IP mid-incident is its own decision, not a return to a
|
|
neutral state.
|
|
- **Retrieving a live secret is `destructive`.** It is a `GET`, but the tier
|
|
describes the stake, not the HTTP verb.
|
|
|
|
---
|
|
|
|
## Adding this catalog to Riposte
|
|
|
|
In Riposte → **Integrations → Marketplace → Add source**:
|
|
|
|
| Field | Value |
|
|
|-------|-------|
|
|
| Name | Official marketplace |
|
|
| Git URL | `https://gitea.riposte-labs.com/f3nris/riposte-marketplace.git` |
|
|
| Branch | `main` |
|
|
| Provider | **Gitea** (sets the right auth scheme for private repos) |
|
|
| Token | a read-only token if the repo is private; leave empty if public |
|
|
|
|
Then **Sync**. Discovered integrations appear in the marketplace, ready to install.
|
|
|
|
---
|
|
|
|
## Contributing an integration
|
|
|
|
1. Create `integrations/<id>/manifest.yaml` (one directory per integration).
|
|
2. Add `scripts/<command-id>.py` only for script-based commands.
|
|
3. Bump `version` (semver) on every change — Riposte tracks versions per source.
|
|
4. Validate the YAML parses and `id`/`name` are set.
|
|
5. Open a merge request.
|
|
|
|
See [`templates/manifest.example.yaml`](templates/manifest.example.yaml) for a
|
|
fully-commented starting point (that file is intentionally **not** ingested).
|