Security Controls Matrix

​

Controls Matrix

​

API Endpoints for Evidence Collection

• GET /api/v2/organizations/{organization}/permission-matrix
• GET /api/v2/organizations/{organization}/audit-webhooks
• GET /api/v2/organizations/{organization}/audit-webhooks/metrics?window=24h|7d|30d
• POST /api/v2/organizations/{organization}/audit-webhooks
• POST /api/v2/organizations/{organization}/audit-webhooks/{auditWebhook}/rotate-secret
• POST /api/v2/organizations/{organization}/audit-webhooks/{auditWebhook}/disable
• POST /api/v2/organizations/{organization}/audit-webhooks/{auditWebhook}/test
• GET /api/v2/organizations/{organization}/audit-webhooks/metrics

​

Dashboard UI: Audit Webhooks

1. Open your organization in Ghostable.
2. Go to Settings.
3. Open the Notifications tab.
4. Use the Audit Webhooks section.

​

What You Can Do in the UI

• Create a webhook with:
  • a friendly name (for example, Security SIEM)
  • an endpoint URL (https://...)
• Copy the signing secret shown once at creation/rotation time.
• Review delivery health fields:
  • status (active, disabled, dead_letter)
  • consecutive failures
  • last delivery/error details
• Open the delivery metrics popover for a webhook to see attempt rates and latency buckets.
• Use the action dropdown per webhook row:
  • Send test event
  • Rotate signing secret
  • Disable webhook
• Review delivery metrics:
  • selected time window (24h, 7d, 30d)
  • attempts, successes, failures, and success rate
  • p50/p95/p99 latency + latency bucket distribution

​

API Contract Examples

​

Version conflict payload (409)

{
    "error": {
        "code": "version_conflict",
        "message": "Version conflict detected for one or more keys.",
        "status": 409
    },
    "conflicts": [
        {
            "key": "APP_KEY",
            "server_version": 12,
            "client_if_version": 11
        }
    ]
}

​

Audit webhook metrics payload (200)

{
    "window": "24h",
    "summary": {
        "attempted": 320,
        "succeeded": 315,
        "failed": 5,
        "success_rate": 98.44,
        "dead_lettered_webhooks": 0,
        "latency": {
            "p50_ms": 81,
            "p95_ms": 403,
            "p99_ms": 844
        }
    },
    "webhooks": [
        {
            "id": "01H...",
            "name": "Security SIEM",
            "status": "active",
            "attempted": 160,
            "succeeded": 158,
            "failed": 2,
            "success_rate": 98.75,
            "latency": {
                "p50_ms": 79,
                "p95_ms": 390,
                "p99_ms": 801
            },
            "latency_buckets": {
                "0_100_ms": 112,
                "101_300_ms": 35,
                "301_1000_ms": 13,
                "1001_3000_ms": 0,
                "3001_plus_ms": 0
            },
            "last_error": null
        }
    ]
}

​

Webhook Signature Verification

• X-Ghostable-Timestamp: unix timestamp in seconds.
• X-Ghostable-Signature: HMAC in the format sha256=<hex_digest>.

1. Read the raw request body exactly as received.
2. Build the signed message as <timestamp>.<raw_body>.
3. Compute HMAC-SHA256(message, signing_secret).
4. Compare the result to X-Ghostable-Signature using constant-time comparison.
5. Reject the request if abs(now - timestamp) > 300 seconds.

​

Notes

• push_force_overwrite activity events are emitted when optimistic locking is intentionally bypassed.
• Teams with strict change control should require --conflict-mode strict in CI workflows.