Security & Compliance Overview

Mockarty helps teams create API mocks and run functional, load, security, chaos, and contract tests. It can be deployed in your own infrastructure. This page helps administrators assess the data they put into Mockarty, the controls they can configure, and the responsibilities that remain with their organisation.

Mockarty can hold user accounts, test payloads, recorded traffic, and credentials for configured integrations. Some tests can also reach systems that contain real data. Classify the data in your workspace and decide which legal or regulatory requirements apply to your deployment with your security and legal teams.

The control mapping below is a starting point for a vendor questionnaire. It does not establish certification or compliance by itself.

Deployment model & data scope

Built-in security controls

Identity & access

• Authentication: local users, OAuth2/OIDC, LDAP/AD, SAML 2.0.
• MFA: TOTP (RFC 6238) with recovery codes.
• RBAC: system and namespace roles control who can view or change resources. Review the role assigned to each user and API token before granting access.
• API tokens: scoped to namespace + role + optional expiration; revocable; shown once at creation.
• Session management: Redis-backed sessions (when configured), idempotent logout, distinguishable “expired” vs “invalid” session errors.

Namespace isolation (multi-tenancy)

• Every mock, test run, webhook, audit entry is scoped to a namespace.
• Handler layer enforces load → check namespace → 404 on mismatch — cross-namespace ID probes are indistinguishable from not-found.
• Support role can view across namespaces but cannot hard-delete or purge trash.

Data protection

• In transit: TLS 1.2+ for all HTTP endpoints, gRPC with mTLS optional.
• At rest — database: encryption delegated to the DBMS (PostgreSQL / SQLite — operator choice).
• At rest — personal data (user email, user agent, and the login search index): optional field-level AES-256-GCM envelope encryption. Off by default; opt-in by setting MOCKARTY_PII_ENCRYPTION_KEY + MOCKARTY_PII_HMAC_PEPPER.
• Key custody: by default keys are read from environment variables; an optional PKCS#11 HSM backend (in a dedicated build variant) is available for FSTEC/FIPS deployments. Customer chooses per risk profile.
• Secrets in logs: redacted by the logging layer; password and token fields never reach the structured logs.

Audit trail

• Every write action (create / update / delete / login / role change / policy change / token issue / cascade purge) emits an audit row with actor, namespace, resource, IP, user-agent, request path.
• Immutability enforced by database triggers: once written, audit rows cannot be modified or deleted; a legal-hold flag prevents retention-based cleanup.
• Graceful shutdown drains in-flight audit writes before closing the database connection — no audit loss on SIGTERM.
• Export: CSV, JSON, Syslog (RFC 5424), CEF 0 (ArcSight). Pipe directly into Splunk / QRadar / KUMA / MaxPatrol.

Alerting on the audit trail

Exporting to a SIEM answers “what happened” after the fact. Alert rules answer it
while it is happening: a rule watches the audit stream and notifies over an HTTP
webhook or by email the moment a matching entry is written.

A rule narrows the stream in whichever ways you need:

A rule must narrow the stream by at least one action or one trigger flag. One
that does neither would fire on every audited action in the product, so it is
rejected when you save it rather than after it floods your on-call channel.

Manage rules at /api/v1/admin/alert-rules (administrator only — rules read the
audit trail, which spans namespaces):

curl -X POST http://localhost:5770/api/v1/admin/alert-rules \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "name": "namespace deletions",
    "action_filter": ["namespace.delete"],
    "notification_type": "webhook",
    "notification_config": {"url": "https://hooks.example.com/oncall"},
    "enabled": true
  }'

GET /api/v1/admin/alert-logs lists what actually fired, newest first. Each row
carries notification_sent and, when delivery failed, notification_error — so
a rule that matched but could not reach its endpoint is visible rather than
silently lost. The row links to its audit entry and names the affected resource;
it does not include the rule’s delivery credentials or the audit entry’s free-form
details. A failed webhook reports a safe destination and error category, not a
credential-bearing URL.
The MCP rule-list and create results omit delivery settings and rule metadata;
use the administrator API to manage those settings.

Routing an alert through your notification channels

notification_type: "channel" sends the alert through the notification channels
you already configured (Slack, Teams, Telegram, Discord, Rocket.Chat, Pachca,
VK Teams, Opsgenie, PagerDuty, Webex, email, webhook) instead of pinning one
destination inside the rule. The alert reaches the channels your namespace has
BOUND and the channels SUBSCRIBED to the alert’s event type (default
alert.triggered) — the event subscriptions described in
Notification channels, with their quiet hours,
digests, deduplication, rate limits, circuit breaker and per-delivery log. So an
operator who wants an alert to respect quiet hours subscribes a channel to
alert.triggered instead of binding it. Delivery is recorded twice, on purpose:
notification_sent and the reason on the alert row (see
alert_logs_list / the Alerts log page), and a delivery row in the subscribed
channel’s own log. A rule that matched and reached nobody is visible in both:

curl -X POST http://localhost:5770/api/v1/admin/alert-rules \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "name": "namespace deletions",
    "action_filter": ["namespace.delete"],
    "notification_type": "channel",
    "notification_config": {"eventType": "alert.triggered", "actionLabel": "Open the audit entry"},
    "enabled": true
  }'

Keep eventType stable across rule edits: that is the string an operator binds a
channel to, and renaming it silently stops the delivery. actionLabel is optional
and only used when the alert’s entity has a page to open — a mission alert opens
its mission card, and entity types with no page get the correlation fields and no
button (a button leading nowhere is worse than none). An alert that cannot be
routed — no channel bound, no namespace, a failing transport — records the reason
in notification_error rather than reporting success.

Threat-model defences

• Input validation at every handler boundary; parameterised SQL throughout (no string concatenation).
• CEF/Syslog export escapes injection vectors (|, =, backslash, space, newline) so attacker-controlled User-Agent / email cannot smuggle fake extension pairs into SIEM dashboards.
• Soft-delete with bounded retention + recycle bin: reversible, auditable, rate-limited.
• Advisory locks on cascade operations to prevent race-induced partial deletes.
• Worker pools sized from the available CPU cores; back-pressure auto-stops a run when the error rate stays high, to prevent run-away resource use.

Availability & resilience

• Cluster mode: leader election for scheduled jobs, NOTIFY-based cache invalidation, cross-node SSE fan-out.
• K8s-ready: liveness/readiness probes reflect real dependencies (DB, Redis, license server), CPU-quota-aware binaries, bounded graceful shutdown.
• Air-gapped: all frontend assets embedded (no CDN), offline license activation flow.

Framework mapping

The matrix below is a claims map — it documents which Mockarty controls are relevant to each framework’s technical requirements. It is not a certification, audit opinion, or attestation. Customers pursuing formal audits inherit these controls but remain responsible for their own organisational controls.

Shared responsibility

Data residency

For a self-hosted deployment, choose where the Mockarty services and storage run. Check every enabled integration and test target when planning network egress: SMTP, webhooks, payment and LLM providers, and tests may send data to configured external systems. Offline licence activation is available for isolated installations.

Incident response hooks

• Every exceptional outcome (failed login, MFA failure, RBAC denial, token misuse, cascade purge) is a distinct audit verb — SIEMs can alert on the exact cause.
• Use the audit log’s action and time filters to investigate relevant activity; corroborate it with the target system and infrastructure logs.
• Legal hold: any auditor can freeze a log segment and prevent retention-based purge; attempted modifications raise database-level triggers.

Requesting artefacts

On request (usually as part of a vendor questionnaire), we can provide:

• SBOM (CycloneDX) for the deployed binaries
• CVE scan report (Trivy) against the latest release
• This page as a signed PDF
• DPA (Data Processing Agreement) template — EN / RU
• BAA template for HIPAA engagements
• Architecture diagram for security review

Contact your account manager or the Mockarty security team for the current versions.