Use

SIEM and SOAR recipes

Akesis connects to a SIEM or SOAR in three ways. Most setups use the first two together:

Webhooks, pushed: Akesis posts an event as remediation happens: a finding arrives or is re-scored, a fix pull request opens, CI changes, Akesis merges, a regression is suspected, an accepted risk expires. Set them up under Integrations → Security operations. Each endpoint chooses a format: Akesis JSON, OCSF, or Splunk HEC. It can also send an authentication header its receiver needs. See Public API for the event format and the signature.
The public API, pulled or acted on: list findings, read remediation, and, with scoped tokens, ask for a fix, a revert or a lower tier, or attach your case ID. Akesis's policy still decides; a playbook can ask, never override.
OCSF: the same events as OCSF 1.3 Vulnerability Finding (class 2002), for SIEMs and data lakes that read OCSF.

Every event about a finding carries the same correlation_id, and your case ID as case_ref once you've set it. So a playbook can keep one case per finding.

Splunk

In Splunk, create an HTTP Event Collector token: Settings → Data inputs → HTTP Event Collector → New Token. Choose the index to send events to. You can leave the source type for Akesis to set.
In Akesis, add a webhook endpoint with the format Splunk HTTP Event Collector. Paste the collector URL, for example https://http-inputs-<stack>.splunkcloud.com/services/collector/event (Splunk Cloud) or https://splunk.example.com:8088/services/collector/event, and the token. Send a test event.
Events arrive with sourcetype=akesis:vulnerability. Their fields follow the Common Information Model's Vulnerabilities data model: dest (the repository), severity (critical, high, medium, low, informational), signature (the finding's title), signature_id (the CVE or advisory ID), cve, cvss, category (dependency or code), url (the finding in Akesis), xref (advisory IDs) and vendor_product (Akesis). Akesis's own fields start with akesis_: event type, correlation ID, case ID, status, priority, EPSS, KEV, reachability, package and versions, owners and the fix pull request.
To fill the Vulnerabilities data model, tag the events. In an app's eventtypes.conf and tags.conf:

# eventtypes.conf
[akesis_vulnerability]
search = sourcetype=akesis:vulnerability

# tags.conf
[eventtype=akesis_vulnerability]
vulnerability = enabled
report = enabled

Then, for example: | tstats count from datamodel=Vulnerabilities where Vulnerabilities.vendor_product="Akesis" by Vulnerabilities.severity, Vulnerabilities.dest.

The token is stored encrypted and never shown again. To change it, add a new endpoint and remove the old one.

Microsoft Sentinel

Sentinel takes custom data through a data collection rule (the Logs Ingestion API), which needs an Entra app to sign in. The simplest bridge is a Logic App:

Create a Logic App whose trigger is When an HTTP request is received. Its URL carries its own signature, so add it in Akesis as an endpoint with the OCSF format.
In the Logic App, send the request body to your custom table through the Azure Monitor Logs Ingestion connector (or an HTTP action to the data collection endpoint), using the data collection rule for that table.
Optionally, check Akesis-Signature in the Logic App before forwarding (see Public API for how it's computed).

Cortex XSIAM

In XSIAM, add a Custom - HTTP based Collector data source, with JSON logs and a vendor and product of your choice (for example akesis and remediation). It gives you a URL and an API key.
In Akesis, add an endpoint with that URL and the OCSF format. Under Authentication header, set the name Authorization and paste the API key as the value.
Events land in the dataset XSIAM names after the vendor and product (here akesis_remediation_raw). To map them into XDM, add a modeling rule. This example is a starting point to adapt to your tenant; it reads the OCSF fields Akesis sends:

[MODEL: dataset="akesis_remediation_raw"]
alter
  xdm.event.id = json_extract_scalar(metadata, "$.uid"),
  xdm.event.type = json_extract_scalar(metadata, "$.event_code"),
  xdm.event.description = json_extract_scalar(finding_info, "$.title"),
  xdm.alert.name = json_extract_scalar(finding_info, "$.title"),
  xdm.alert.severity = severity,
  xdm.target.resource.name = json_extract_scalar(resources, "$[0].name"),
  xdm.observer.vendor = "Valitura",
  xdm.observer.product = "Akesis";

Torq

Create a workflow with a Webhook trigger. Torq gives you its URL and an authentication header; add the URL in Akesis with the Akesis JSON format, and put Torq's header name and secret under Authentication header.
Branch on type. For example:
- finding.ingested where data.finding.kev is true: open a case in your case tool, then attach its ID with an HTTP step to PUT /api/public/v1/findings/{{ data.finding.id }}/case ({"case_ref": "<case ID>"}), and ask for a fix with POST /api/public/v1/findings/{{ data.finding.id }}/actions/generate-fix.
- fix_pr.auto_merged: update the case with the pull request link (data.finding.fix.pr_url).
- fix_pr.regression_suspected: page the repository's owners (data.finding.owners) and offer a revert with POST …/actions/revert.
Give the HTTP steps an Akesis API token with only the scopes they use (findings:case, fixes:generate, fixes:revert), and set Idempotency-Key to the Torq execution ID so a retried step does nothing twice.

Tines

Add a Webhook action in Tines; its URL includes a secret path. Add that URL in Akesis with the Akesis JSON format. Build the story the same way as the Torq recipe above, with HTTP Request actions to the Akesis API, each with an Idempotency-Key.

Any other SOAR

The same pattern works for any tool that receives webhooks and calls HTTP APIs:

Receive: an endpoint for the events you care about, in Akesis JSON or OCSF, with an authentication header if the receiver needs one. Check Akesis-Signature where the tool can, and deduplicate on the event ID: delivery is at least once.
Correlate: open one case per correlation_id, and write your case ID back with PUT /findings/{id}/case, so every later event carries it.
Act: ask for a fix, a revert or a lower tier through the API, with a scoped token and an Idempotency-Key. Akesis applies the repository's policy and every gate to the request, the same as its own decisions, and records the request in the audit log.