An incident built from a Rapid7 investigation indexed zero entities. Nothing to
pivot on, nothing to correlate, and an AI analysis with nothing to read. The
reason turned out not to be the mapper but the feed: an investigation is an
envelope, and neither it nor its /alerts list carries a host, an account, a
process or a MITRE code.
The Alert Triage API does, in rule_keys_of_interest. On the alert behind the
investigation that started this, that field holds:
hostname NBSGIT01-26
process.name bcdedit.exe
process.cmd_line bcdedit /set {default} recoveryenabled No
process.exe_path C:\WINDOWS\System32\bcdedit.exe
parent_process.name cmd.exe
parent_process.cmd_line "C:\WINDOWS\system32\cmd.exe"
parent_process.exe_file.hashes.md5 e463e36104d22a2479046a7d4f620816
with rule.mitre_tcodes ["TA0040", "T1490"] — Impact / Inhibit System Recovery,
which is what disabling Windows recovery actually is. None of it was reachable
before.
It is a list of {key, values} pairs rather than an object, so every entry reads
through a JSONata predicate — rule_keys_of_interest[key='hostname'].values[0].
A key a rule does not emit resolves to nothing and is skipped, so one file
covers every detection rule.
Two details worth keeping:
- mitre_tcodes mixes tactics and techniques in one array ("TA0040" beside
"T1490"). They are split on the "TA" prefix so a tactic never lands in the
technique field, where it would name a technique that does not exist.
- rule.name is documented but absent from live ABA alerts, so the analytic
name falls back to `type`, which repeats the rule's display name.
Rapid7's own status, disposition and AI-suggested disposition ride as custom
fields. They cannot reach the incident's status and verdict columns — MapFields
accepts only title, severity, source, description and custom:* — but an analyst
can at least see that the source already closed the alert and what it decided.
The AI suggestion is exposed as a fact, never as a verdict.
Validated end to end against a live alert: field mapping, OCSF mapping and
entity extraction, which now yields the host and the parent process hash where
it previously yielded nothing.
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).