Security services

Continuous Threat Exposure Management: 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. Maps to ATT&CK T1190 (Exploit Public-Facing Application) and T1595 (Active Scanning).

• inputs: assets, dns, certificates, open-endpoints
• outputs: attack-paths, exposure-findings, asset-context
• Integration: CTEM hands attack paths and asset context to the VM ledger; they are the basis of the reachability score.

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.

• inputs: running-apps, scan-scopes, auth-scenarios
• outputs: runtime-findings, request-response-evidence
• Integration: DAST emits reproducible runtime findings (request/response evidence) to the VM ledger.

Static application security testing: analyzes source code for vulnerable patterns and missing sanitization, and through static analysis and taint / data-flow inspection reports code findings with file and line to the VM ledger. Also inspects dependency manifests and emits dependency notes.

• inputs: source-code, dependency-manifests
• outputs: code-findings, taint-paths, dependency-notes
• Integration: SAST emits code findings with file and line to the VM ledger, so the fix target is found faster.

Spear-phishing detection (SPECT): detects impersonation in received mail — header verification (SPF/DKIM/DMARC) against domain-normalisation comparison (punycode / homoglyph / added characters), URL rewrite targets against the sender — and reports targeted-mail findings to the VM ledger. Covers ATT&CK T1566 (Phishing).

• inputs: received-mail, domain-intel, mail-flow-records
• outputs: targeted-mail-findings, lookalike-domain-notes, impersonation-evidence
• Integration: SPECT emits findings with header, domain-normalisation and URL-mismatch evidence to the VM ledger, starting the takeover tracking.

Vulnerability management (wvme): consumes the shared-schema findings emitted by the four upstream services, dedups and scores them by reachability and exploitability, and tracks the remediation lifecycle in a ledger keyed by CPE/CVE. Accepts CVE/CPE feed input.

• 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: VM is the ledger service: it receives the upstream services' findings in the shared schema and dedups, scores and tracks remediation.

Governance (NIST CSF 2.0 GOVERN): turns a CSF 2.0 organizational profile (current and target tier per subcategory) into gaps, scores a risk register by likelihood × impact against a risk appetite, and tiers a supplier register by criticality, listing the missing requirements (security clause, incident-notification clause, reassessment, exit plan). POST /v1/security/govern computes deterministically from the body alone and stores nothing.

• inputs: csf-profile, risk-register, supplier-register
• outputs: profile-gaps, scored-risk-register, supplier-findings
• Integration: GRC can take VM-ledger findings as risk-register input. Its output carries CSF subcategory ids, the same id space IR and DR use.
• POST /v1/security/govern · GET /v1/security/govern returns a worked example

Incident response (NIST CSF 2.0 RESPOND): from one incident report, returns its category, priority and escalation, a playbook whose every step names its RS subcategory, the notification deadlines the stated facts trigger (Japan APPI preliminary and final reports, GDPR Art. 33, NIS2 Art. 23) and the criteria for moving to recovery. POST /v1/security/respond is deterministic and stores nothing.

• inputs: incident-report, vm-findings
• outputs: triage, playbook, notification-deadlines, recovery-criteria
• Integration: IR opens an incident from VM-ledger or SPECT findings and hands off to DR once the recovery criteria hold.
• POST /v1/security/respond · GET /v1/security/respond returns a worked example

Recovery (NIST CSF 2.0 RECOVER): from assets' criticality, RTO, RPO, dependencies and backups (last success, last restore test, offsite, immutable), returns dependency-ordered restore waves, RPO checks, 3-2-1-1-0 checks, RTO inversions, verification steps and end-of-recovery criteria, and stakeholder and public communication milestones. POST /v1/security/recover is deterministic and stores nothing.

• inputs: assets, rto-rpo, dependencies, backup-records
• outputs: restore-waves, backup-findings, end-criteria, communications
• Integration: DR is the recovery plan used once IR's recovery criteria hold; in steady state it runs as a backup and RTO/RPO check.
• POST /v1/security/recover · GET /v1/security/recover returns a worked example