Security Practices

1. Overview

Sandworm Security builds defensive tooling for other security teams. Our customers trust us with sensitive telemetry, credentials, and findings about their environments. We take that responsibility seriously and treat security as a first-class engineering concern across the entire platform.

This page describes the controls we have in place today, the certifications we are pursuing, and how to report a vulnerability if you find one.

2. Encryption

• At rest — AES-256-GCM for all stored data, including primary databases, object storage, backups, message queues, and credential vaults.
• In transit — TLS 1.2 minimum, TLS 1.3 preferred. Weak ciphers and protocols (RC4, 3DES, SSLv3, TLS 1.0/1.1) are disabled.
• Inter-service — mutual TLS between agents and the Sandworm ingest tier.
• Secrets — managed in AWS KMS with separate keys per Enterprise customer; rotation on a fixed cadence.

3. Access controls

• Hardware MFA (WebAuthn / FIDO2) required for all Sandworm staff with access to production systems.
• RS256 JWT-based authentication with least-privilege IAM policies, reviewed quarterly.
• Just-in-time elevation for any production change; sessions are time-bounded and recorded.
• SSO integration available for customers (SAML 2.0 and OIDC).
• Role-based access control (RBAC) within the portal; granular permissions per product.

4. Infrastructure isolation

• Hosting — AWS in us-east-1 primary, us-west-2 for backups and failover.
• VPC isolation — services run in private subnets, with public exposure limited to load balancers and the API gateway.
• Web Application Firewall — AWS WAF in front of public endpoints, with managed rule sets and custom rules.
• DDoS mitigation — AWS Shield Standard, plus Cloudflare in front of the marketing site.
• Network segmentation — security groups and NACLs enforce zero-trust between services.
• Tenant isolation — partitioned at every layer (databases, object storage, indexes, queues).
• Backups — encrypted, multi-region, restore tested on a regular schedule.

5. Application security

• Secure SDLC — code review on every change, automated tests in CI, security gates before merge to main.
• OWASP Top 10 hardening — input validation, parameterized queries, output encoding, CSRF tokens, strict CSP, secure session cookies, and rate limiting.
• Dependency scanning — continuous SCA on every commit; critical CVEs patched within 48 hours, high within 7 days, moderate within 30 days.
• SAST and DAST — static analysis on every PR; periodic dynamic scanning of staging environments.
• Secret scanning — pre-commit and pre-push hooks plus repository-level scanning.
• Container hardening — minimal base images, non-root users, read-only filesystems, least-privilege capabilities, signed images.

6. Incident response

Sandworm maintains a documented incident response plan that covers identification, containment, eradication, recovery, and post-incident review. All admin actions in the portal are logged with actor, target, timestamp, and outcome. Customer-facing audit logs are available in the portal. Internal audit logs are forwarded to a separate, write-only logging tier with extended retention.

Sandworm commits to notifying affected customers within 72 hours of confirming a security incident that impacts their data.

7. Compliance certifications

Sandworm is currently pursuing the following certifications and attestations:

• SOC 2 Type II — In Progress. Observation period underway, expected report later this year.
• HIPAA — In Progress. Business Associate Agreement (BAA) available on request for healthcare customers (Enterprise tier).
• PCI DSS — In Progress. Sandworm uses Stripe for payment processing and never stores, processes, or transmits credit card data. Currently attested under SAQ A.
• ISO/IEC 27001 — Gap assessment complete, remediation in progress.
• GDPR — DPA available; Standard Contractual Clauses incorporated.

We will update this page as each certification is achieved. Customers with compliance questions or audit requests should email jacobhendrick@sandworm-security.com.

8. Penetration testing

Sandworm commits to at least one third-party penetration test per year conducted by a reputable independent firm. Scope rotates annually across the portal, agents, ingest tier, and infrastructure. Executive summaries are available to customers under NDA on request.

9. Responsible disclosure

Sandworm welcomes vulnerability reports from the security research community. If you discover a vulnerability in any Sandworm product or service, please report it to jacobhendrick@sandworm-security.com.

Please include in your report:

• A clear description of the vulnerability and its impact.
• Steps to reproduce, ideally with proof-of-concept code or screenshots.
• The affected URL, endpoint, or component.
• Your contact information and whether you wish to be credited.

Our commitments to researchers:

• No legal action against good-faith researchers who follow this policy.
• Acknowledgment of receipt within 48 hours.
• Triage and severity assessment within 5 business days.
• Status updates every 7 days until resolution.
• Coordinated disclosure within 90 days of report.

10. Contact

Security issues: jacobhendrick@sandworm-security.com

Trust and compliance: jacobhendrick@sandworm-security.com

Privacy: jacobhendrick@sandworm-security.com