Security & Trust

SigmaShake Hub is a community registry for governance rules that control AI agent behaviour. Because installing a third-party ruleset gives it influence over your AI toolchain, we take the integrity of downloaded content seriously.

This document covers the threat model, current mitigations, known limitations, and our security roadmap.

Content Integrity

Every ruleset indexed on the Hub has a SHA-256 content hash computed at publish time. When ssg hub pull downloads a ruleset, it recomputes this hash locally and refuses to install if there is any discrepancy.

Algorithm

The hash is deterministic and order-independent:

hash = SHA-256( join(sorted_by_name(rules).map(r => r.raw_text), '\n---\n') )

1. Take all rule bodies (raw_text)
2. Sort by rule name (alphabetically)
3. Join with the separator \n---\n
4. SHA-256 the resulting UTF-8 string

This means the same rules always produce the same hash regardless of insertion order.

Verification flow

Publish → Hub stores hash
Install → CLI recomputes hash → Compare → Match: install / Mismatch: abort

Example install output (happy path):

Fetching ruleset 550e8400-e29b-41d4-a716-446655440000...
  TypeScript v3 by @sigmashakeinc — 12 rules
Verifying integrity... OK (sha256:4a9f3c1b8e2d7f05...)

Installed: TypeScript v3
  Integrity: sha256:4a9f3c1b8e2d7f05... VERIFIED

Example install output (failed integrity):

Verifying integrity... FAILED

ssg hub pull: INTEGRITY CHECK FAILED
  expected: 4a9f3c1b8e2d7f05...
  computed:  7b1e94f2a630c891...

The downloaded content does not match the hub-stored hash.
This may indicate tampering or data corruption in transit.
Do NOT install this ruleset. Report to security@sigmashake.com

Threat Model

Threat	Attack	Mitigation	Residual risk
Hub DB compromise	Attacker modifies rule bodies in Cloudflare D1	SHA-256 stored at publish. Tampered rules → hash mismatch → install rejected	Attacker who also updates content_hash bypasses this. Future: Ed25519 signing
TLS / MITM	Attacker intercepts download in transit	HTTPS enforced by Cloudflare; hash verification detects payload modification	Compromised CA could bypass TLS. Hash is a second layer
Malicious ruleset	Author publishes permissive rules to weaken governance	GitHub OAuth ties identity to real account; hub shows author + repo link prominently	Users must review rules before installing
Typosquatting	Fake ruleset named to resemble a popular one	Hub displays GitHub repo and author on every card and detail page	Users should verify author identity
Download inflation	Bots inflate download counts to boost ranking	Rate limit: 1 increment per IP per ruleset per 60 s	Distributed bots across many IPs can still inflate
ReDoS	Malicious REGEX pattern causes catastrophic backtracking	MAX_REGEX_PATTERN_LENGTH = 500; rejected at load time	Some complex-but-short patterns may still be slow
Org/account takeover	sigmashakeinc org compromised → seeded rulesets poisoned	2FA on all maintainer accounts; hashes stored independently	Attacker who re-seeds + updates hashes bypasses verification
Stale rules	User installs outdated ruleset with known gaps	Content-driven versioning; CLI shows version on install	Users must re-pull to get updates

Author Identity

Every submission is tied to a verified GitHub account:

• Browser OAuth flow (/submit) validates the GitHub session before indexing
• Programmatic API (POST /api/submit) validates the Bearer token via GET https://api.github.com/user
• Authors can only update rulesets they own (GitHub login must match)
• All rulesets link directly to their source repository

Author identity establishes accountability, not code review. You should always inspect rule logic before installing any third-party ruleset.

Content Policy

Rulesets on the Hub must comply with our content policy:

• No deceptive rules — rules that claim to enforce safety while allowing dangerous operations
• No exfiltration rules — rules designed to silently log sensitive data to external services
• No impersonation — do not imply official origin unless you maintain the referenced project
• Public repositories only — ruleset source must be publicly accessible on GitHub

To report a violation: security@sigmashake.com

Full Threat Model

A comprehensive threat model covering all SigmaShake platforms (Hub, CLI, MCP, Dashboard) is maintained at THREAT_MODEL.md in the monorepo root. It covers:

• OWASP Top 10 for Web, API, and LLM Applications
• STRIDE analysis for each component
• SOC 2 / SLSA self-assessment mapping (not a certification — see the threat model for details)
• Security architecture decisions and residual risks

Ed25519 Content Signing

The ssg CLI includes an Ed25519 signing module for ruleset content integrity. Key pairs are generated locally and stored at ~/.sigmashake/keys/.

ssg keys generate    # Create Ed25519 key pair
ssg keys show        # Display public key
ssg keys sign        # Sign content from stdin
ssg keys verify      # Verify signature

Private keys are stored with 0600 permissions. The public key can be shared for out-of-band verification. Full integration with ssg hub pull signature verification is a planned enhancement.

Dashboard Authentication

The governance dashboard (ssg serve) requires token-based authentication by default. When the dashboard starts, it generates a random UUID token stored at ~/.sigmashake/dashboard.token (mode 0600).

• The token is appended to the dashboard URL shown in terminal output
• On first visit, the token sets an HttpOnly; SameSite=Strict cookie
• Subsequent requests authenticate via cookie (no token in URL)
• Disable with SSG_DASHBOARD_TOKEN=disable (not recommended)

Fleet SIEM Log Forwarding

Enterprise customers can forward Fleet audit events to their own SIEM. The feature is opt-in, per-org, and per-destination — no audit data leaves the Fleet perimeter unless an operator explicitly configures a destination and enables it.

Supported destinations: Splunk HEC, Cribl HTTP-in, Confluent Cloud Kafka REST v3, and generic HMAC-signed webhook. See the Fleet SIEM Log Forwarding guide for full configuration details.

Security controls applied to every adapter:

• Credentials at rest. Tokens, API keys, and HMAC secrets are stored as an AES-GCM ciphertext blob (12-byte random IV, rotatable master key). Plaintext is never persisted, logged, or included in error messages.
• Credentials in transit. HTTPS-only; redirect: 'manual' prevents 3xx downgrades; CRLF-injection check on any value placed in an Authorization header.
• SSRF prevention. Endpoint hostnames are validated against private IPv4 and IPv6 ranges at both config-write time and delivery time (DNS-rebind defence). Port allowlists are enforced per adapter kind.
• Tamper evidence. Archive deliveries include a Merkle root over the batch, written alongside the R2 object key in the delivery log.
• Idempotent delivery. The fleet_siem_delivery_log table enforces UNIQUE(destination_id, r2_key), preventing duplicate archive deliveries across worker restarts.
• PII redaction. An optional redact_fields_json dotted-path list replaces matching fields with [REDACTED] before the adapter serializes events. Redaction runs before chunking, so the wire format never contains the original value.
• Strict error handling. Confluent's streaming-produce response is parsed per-record; any per-record error_code ≥ 400 fails the whole batch. This avoids silent data loss on partial failures.

Security Roadmap

These mitigations are planned but not yet implemented:

TOFU (Trust On First Use)

The CLI will store the first-seen hash of each installed ruleset in ~/.sigmashake/. On subsequent pulls, if the hash changes in a way that is not explained by a version bump, the CLI will warn before installing.

Transparency log

An append-only public log of all content_hash changes for every ruleset. Any modification — even by maintainers — is permanently recorded and publicly auditable.

Automated rule vetting

Static analysis at submit time to flag obviously dangerous rule patterns (e.g., broad ALLOW execution decisions without conditions) before they are indexed.

SOC 2 Type II Self-Service Audit

SigmaShake is actively building towards SOC 2 Type II readiness. The compliance mapping in our Threat Model is a self-assessment against trust service criteria — not a third-party audit. A formal SOC 2 Type II audit is targeted for Q4 2026.

Responsible Disclosure

If you discover a security vulnerability in the Hub, the ssg CLI, or any SigmaShake service:

1. Email security@sigmashake.com with a description and reproduction steps
2. Do not publicly disclose until we have had 90 days to respond
3. We acknowledge receipt within 48 hours

We credit researchers in security advisories unless you prefer anonymity.