Security services (CTEM / DAST / SAST / SPECT / VM / GRC / IR / DR)
The security-services suite (CTEM / DAST / SAST / SPECT / VM) is described by GET /v1/security/services — a public, unauthenticated edge that DESCRIBES only.
curl -s https://api.mithril.fund/v1/security/services | jq '.[] | {id, status}'
# ctem → "component-shipped"
# dast → "gated"
# sast → "gated"
# spect → "gated"
# vm → "component-shipped"
# grc → "component-shipped"
# ir → "component-shipped"
# dr → "component-shipped"CTEM — exposure management
CTEM continuously scans public endpoints, domains and certificates to enumerate the external attack surface and entry points, identifies reachable attack paths, attaches asset context (public routes, dependencies, owner) and feeds exposure events plus shared-schema findings to the VM ledger (status: component-shipped). It maps to ATT&CK T1190 (Exploit Public-Facing Application) and T1595 (Active Scanning).
# CTEM capabilities (from the catalog entry)
surface-inventory # continuous external attack-surface / asset inventory
attack-path # reachable attack-path identification
context # asset context (public routes, deps, owner)
exposure-feed # exposure events fed to the VM ledger
# inputs: assets, dns, certificates, open-endpoints
# outputs: attack-paths, exposure-findings, asset-context
# integration: feeds vm, emits :finding (shared finding-schema)SAST — static application security testing
SAST analyzes source code for vulnerable patterns and missing sanitization, and through static analysis and taint / data-flow inspection emits code findings with file and line to the VM ledger. It also inspects dependency manifests and emits dependency notes (status: gated).
# SAST capabilities (from the catalog entry)
code-analysis # static source-code analysis
taint-flow # taint / data-flow inspection
code-finding # code findings with file + line
dependency-notes # dependency-manifest inspection, emitting dependency notes
# inputs: source-code, dependency-manifests
# outputs: code-findings, taint-paths, dependency-notes
# integration: feeds vm, emits :finding (role: code-findings)DAST — dynamic application security testing
DAST probes running applications with dynamic inspection across scan scopes and authenticated scenarios (logged-in paths), and reports reproducible runtime vulnerability findings with request/response evidence to the VM ledger (status: gated).
# DAST capabilities (from the catalog entry)
runtime-probe # dynamic probing of running applications
auth-scenarios # probing with authenticated scenarios
runtime-finding # runtime vulnerability detection as findings
# inputs: running-apps, scan-scopes, auth-scenarios
# outputs: runtime-findings, request-response-evidence
# integration: feeds vm, emits :finding (role: runtime-findings)SPECT — spear-phishing detection
SPECT inspects received mail — header verification (SPF/DKIM/DMARC), domain-normalisation comparison (punycode / homoglyph / added characters) and URL rewrite targets vs the sender — and emits targeted-mail findings to the VM ledger (status: gated). Covers ATT&CK T1566 (Phishing).
# SPECT capabilities (from the catalog entry)
header-verify # SPF / DKIM / DMARC alignment on received mail
domain-normalise # punycode / homoglyph / added-char lookalikes
url-mismatch # URL rewrite target vs sender
mail-finding # targeted-mail findings with header/domain/URL evidence
# inputs: received-mail, domain-intel, mail-flow-records
# outputs: targeted-mail-findings, lookalike-domain-notes, impersonation-evidence
# integration: feeds vm, emits :finding (role: targeted-mail-findings)VM — vulnerability management
VM (vulnerability management, wvme) consumes the shared-schema findings emitted by the four upstream services, dedups and scores them by reachability × exploitability, and tracks the remediation lifecycle in a ledger keyed by CPE/CVE. It accepts CVE/CPE feed input (status: component-shipped).
# VM capabilities (from the catalog entry)
dedup # finding deduplication (asset × vulnerability key)
scoring # reachability × exploitability scoring
ledger # vulnerability ledger keyed by CPE/CVE
remediation # remediation lifecycle (detected → in progress → verified → closed)
cve-cpe-feed # CVE/CPE feed intake
# inputs: findings-from-ctem, findings-from-dast, findings-from-sast, findings-from-spear-phishing, cve-cpe-feeds
# outputs: vulnerability-ledger, remediation-status, exposure-reports
# integration: role aggregation-ledger (dedup, scoring: reachability + exploitability, ledger keys: cpe, cve)GRC / IR / DR — NIST CSF 2.0 GOVERN, RESPOND and RECOVER
All three are deterministic and stateless like the VM ledger: computed from the POSTed JSON alone, nothing stored, no model called. GET returns a worked example and the answer computed for it live. A field that cannot be read is a 400 naming the field and the reason (e.g. {"field": "incident.category", "reason": "not-an-allowed-value"}).
GRC — POST /v1/security/govern
Send any of profile (current and target tier 0–4 per CSF 2.0 subcategory), risks (likelihood and impact 1–5, treatment, owner) and suppliers (criticality, dataAccess, contract clauses, lastAssessed). suppliers needs asOf.
curl -s https://api.mithril.fund/v1/security/govern \
-H 'content-type: application/json' \
-d '{"riskAppetite": 9, "risks": [{"id": "R-2", "likelihood": 4, "impact": 3, "treatment": "accept"}]}' \
| jq '.risks.register[0] | {score, level, findings: [.findings[].code]}'
# → {"score": 12, "level": "high",
# "findings": ["no-owner", "acceptance-exceeds-appetite"]}IR — POST /v1/security/respond
Send incident (id, category, awareAt, ongoing, criticalSystemAffected, personalData, jurisdictions: jp / eu / other, nis2Entity, significant) to get the priority, a playbook with RS subcategories and the notification deadlines. Deadlines are the statutory outer limits, not legal advice; the APPI final report rolls over weekends only, not public holidays (the answer says so).
curl -s https://api.mithril.fund/v1/security/respond \
-H 'content-type: application/json' \
-d '{"incident": {"id": "I-1", "category": "ransomware", "awareAt": "2026-09-24T01:30:00Z",
"ongoing": true, "personalData": {"records": 12000}, "jurisdictions": ["jp", "eu"]}}' \
| jq '{priority: .triage.priority, deadlines: [.notifications[] | {regime, stage, deadline}]}'DR — POST /v1/security/recover
Send asOf and assets (id, criticality, rtoHours, rpoHours, dependsOn, backups: lastSuccessAt, lastRestoreTestAt, offsite, immutable) to get dependency-ordered restore waves and per-asset checks. A dependency cycle is a 400 dependency-cycle naming the assets.
curl -s https://api.mithril.fund/v1/security/recover | jq '.example.response.waves'
# → [{"wave": 1, "assets": ["db"]},
# {"wave": 2, "assets": ["api", "reporting"]}]Spear-phishing defence (solution)
The canonical def of the defence — lookalike discovery (CTEM) → impersonated-mail inspection (SPECT) → takeover ledger (VM) — is served by GET /v1/security/solutions/spear-phishing, and the /security/services/#spear-phishing-solution section renders from the same data. Mail gateway, training and post-compromise monitoring are the catalog's partner categories (email-sec / awareness / siem / itdr).
curl -s https://api.mithril.fund/v1/security/solutions/spear-phishing | jq '{id, components: [.components[].id]}'
# → {"id": "spear-phishing",
# "components": ["ctem", "spear-phishing", "vm"]}DAST / SAST / SPECT are gated (behind the private authority). The four upstream services emit findings in the shared finding-schema; VM dedups, scores (reachability × exploitability) and tracks remediation keyed by CPE/CVE.