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

Security Roadmap

These mitigations are planned but not yet implemented:

Ed25519 signed manifests

Each ruleset's content_hash will be signed with an offline Ed25519 private key when published. The CLI will verify the signature using an embedded public key before comparing hashes. This eliminates the residual risk of a DB compromise that also updates the stored hash.

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.

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.