Skip to main content
Use this matrix to assess where Ghostable controls align with common security concerns and what evidence is available to reviewers.

​
Controls Matrix

ConcernGhostable ControlEvidence
Client supply-chain tamperingRelease checksums + signed build provenance + SBOM publicationRelease assets: SHA256SUMS, SBOM, and attestation evidence (public for CLI; internal for desktop)
In-transit confidentialityTLS transport and signed client payloads for secret updatesAPI request signatures (client_sig)
Push race conditions / lost updatesOptimistic concurrency via if_version, strict conflict mode, explicit force overrideAPI 409 conflict payloads (conflicts[]), CLI --conflict-mode and --force-overwrite
Unauthorized push attemptsDevice ownership validation and revocation checksPush API rejects unknown/revoked devices
Least-privilege accessRole + permission model with scoped project/environment operationsOrganization roles/permissions and permission matrix endpoint
External monitoring visibilityAudit webhook destinations with signed event delivery, retries, and dead-letter stateAudit webhook API + delivery status fields
AuditabilityStructured activity logging across org/project/environment actionsOrganization/project/environment history endpoints and activity export
SaaS dependency resilienceEncrypted backup + restore workflowsbackup create / backup restore command flow

​
API Endpoints for Evidence Collection

  • GET /api/v2/organizations/{organization}/permission-matrix
  • GET /api/v2/organizations/{organization}/audit-webhooks
  • 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

​
Dashboard UI: Audit Webhooks

Audit webhooks can be managed in the Ghostable dashboard:
  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
  • Use the action dropdown per webhook row:
    • Send test event
    • Rotate signing secret
    • Disable webhook
Only organization admins can create or manage audit webhooks in the dashboard UI.

​
Webhook Signature Verification

Ghostable audit webhooks include the following headers:
  • X-Ghostable-Timestamp: unix timestamp in seconds.
  • X-Ghostable-Signature: HMAC in the format sha256=<hex_digest>.
To verify a delivery:
  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.
For replay protection, cache each webhook event id for at least 5-10 minutes and reject duplicates.

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