سیکیورٹی سروسز

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).

• ان پٹس: assets, dns, certificates, open-endpoints
• آؤٹ پٹس: attack-paths, exposure-findings, asset-context
• Integration: CTEM حملے کے راستے اور اثاثہ سیاق و سباق VM لیجر کو فراہم کرتا ہے؛ یہ رسائی کے اسکور کی بنیاد ہیں۔

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.

• ان پٹس: running-apps, scan-scopes, auth-scenarios
• آؤٹ پٹس: runtime-findings, request-response-evidence
• Integration: DAST دوبارہ پیدا کیے جا سکنے والے رن ٹائم نتائج (request/response شہادت) VM لیجر کو بھیجتا ہے۔

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.

• ان پٹس: source-code, dependency-manifests
• آؤٹ پٹس: code-findings, taint-paths, dependency-notes
• Integration: SAST فائل اور لائن کے ساتھ کوڈ کے نتائج VM لیجر کو بھیجتا ہے، جس سے فکس کا ہدف تیزی سے مل جاتا ہے۔

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).

• ان پٹس: received-mail, domain-intel, mail-flow-records
• آؤٹ پٹس: 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.

• ان پٹس: findings-from-ctem, findings-from-dast, findings-from-sast, findings-from-spear-phishing, cve-cpe-feeds
• آؤٹ پٹس: 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.

• ان پٹس: csf-profile, risk-register, supplier-register
• آؤٹ پٹس: 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.

• ان پٹس: incident-report, vm-findings
• آؤٹ پٹس: 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.

• ان پٹس: assets, rto-rpo, dependencies, backup-records
• آؤٹ پٹس: 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