The previous command returned the alerts as its result rows, which quietly changed the unit: an investigation holding three alerts would have become three incidents. The investigation is what an analyst opens and what the SOC tracks — it stays the incident, and the alerts are its content. get_investigations_full walks the same three hops and inverts the shape: investigations under `data`, each carrying its alerts under `alerts` plus an alert_count. results_path=data and dedup_key=rrn, so it is a drop-in replacement for list_investigations in an existing ingestion rule — only the command name and the mapper change. A few first-alert values are also lifted to the top level, and that is not cosmetic. MapFields resolves dotted paths only and cannot index an array, so `alerts[0].ai_suggested_disposition` in a field_mappings entry reads as nothing — silently, leaving the custom field empty with no error anywhere. Three custom fields were empty for exactly that reason until an end-to-end run showed it. The ocsf section has no such limit: it is evaluated by full JSONata and indexes freely, which is why the host and process mappings worked while the custom fields did not. The mapper maps the investigation first and the first alert after, so the alert wins wherever the container says nothing. It also lands every alert — not just alerts[0] — as OCSF-shaped objects under `evidences`, because the extractor walks arrays and classifies on the path suffix: an investigation aggregating two alerts on two machines now indexes both hosts, where reading alerts[0] alone would have indexed one and silently dropped the other. Verified end to end against the investigation that started this, with a second alert added on another host: field mapping, OCSF mapping and entity extraction. Both hosts are indexed. With the incident type's extraction policy set to selected/host,ip,user, the entity set is exactly those two — the alert RRN's 32-hex suffix, which the IOC regex cannot tell from an MD5, is filtered out there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Riposte Marketplace
Official catalog of integrations for the 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.yamlis 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*.pyfile becomes a command implementation, keyed by filename without the extension. So a command withid: get_ip_reportis backed byget_ip_report.py. - Files not named
manifest.yamlare ignored as integration roots, so templates likemanifest.example.yamlare 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)
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.
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.
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.
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
- Create
integrations/<id>/manifest.yaml(one directory per integration). - Add
scripts/<command-id>.pyonly for script-based commands. - Bump
version(semver) on every change — Riposte tracks versions per source. - Validate the YAML parses and
id/nameare set. - Open a merge request.
See templates/manifest.example.yaml for a
fully-commented starting point (that file is intentionally not ingested).