Encryption
Every connection to Siege runs over TLS, terminated at Cloudflare in front of the application. Account passwords are never stored in plain form - they're hashed with scrypt (via Werkzeug), a memory-hard algorithm chosen specifically to resist offline cracking if a database were ever exposed.
Target credentials you configure for authenticated scanning - login passwords, session cookies, auth headers, a second identity for access-control testing - are encrypted at rest with Fernet (AES-128 in CBC mode with HMAC authentication), using a key kept outside the application database, separate from the data it protects.
Access control
- Two-factor authentication (TOTP) is available on every account and strongly recommended - once enabled, every login requires a fresh code from your authenticator app, not just a password.
- Account lockout after repeated failed login attempts, independent of any IP-based rate limiting, closes the gap a distributed attempt from many source IPs would otherwise leave open.
- Role-based access within your organization (operator vs. admin), separate from Shieldome's own platform-admin access, which is a distinct permission with no path into your data beyond what account administration itself requires.
- Tenant isolation - every engagement, finding, and credential is scoped to one organization at the database level. An engagement belonging to a different organization than the one making the request behaves exactly like one that doesn't exist: a 404, not a permission error that would confirm it exists at all.
- Optional SSO (OpenID Connect) lets your own identity provider govern who can authenticate - it only ever links an existing Siege account by email, never creates one on its own.
Tamper-evident audit log
Every action in an engagement - a scan starting, a finding recorded, an approval decided, an exploit executed - is written to an append-only log where each entry is cryptographically chained to the one before it. Altering or deleting an entry after the fact breaks the chain in a way that's mathematically detectable, not just logged elsewhere and trusted. A Verify Audit Chain button in the app re-derives every hash on demand and reports the first point of divergence if anything doesn't match.
Human approval before anything exploits a target
Detection - recon, vulnerability identification, and every active-testing scanner - runs automatically within whatever scope you've authorized. Confirming a SQL injection finding or running a Metasploit module never happens on its own: a person has to look at the exact request, module, payload, and proof command about to run, and approve it. This isn't a configuration option to turn off - it's how the exploitation path is built.
Backups
The database is backed up daily and retained for 14 days. Backups are taken with Postgres's own consistent-snapshot mechanism, safe to run against a live database with no downtime or locking. We test that a backup actually restores, not just that the backup job exits successfully - those are not the same claim, and we've learned that the hard way once already.
Infrastructure & subprocessors
A short list, kept short deliberately - each one has a specific, limited job:
| Provider | Purpose |
|---|---|
| OVHcloud | Application hosting and database infrastructure. |
| Cloudflare | TLS termination, CDN, and DDoS protection in front of the application. |
| Titan | Transactional email (account and notification messages). |
| Domio | Payment processing for paid plans - Siege never stores card details itself. |
Scope enforcement
Every scan and every exploit attempt independently checks the target against your engagement's authorized scope and testing window before doing anything - not just once when the engagement was created. An exclusion always wins over an inclusion. Nothing runs before the window opens or after it closes, even for an approval that's been sitting pending since before it did.
Compliance mapping vs. compliance certification
Siege maps findings in your reports to OWASP Top 10, PCI-DSS, GDPR, and SOC 2 references, and assists with the penetration-testing requirement several of those frameworks call for. That is a reporting feature for your compliance work, not a claim that Shieldome Siege itself holds a SOC 2 or ISO 27001 certification - it doesn't, and we're not going to imply otherwise on a page whose entire point is being straight with you.
Data retention & deletion
Your organization's data is retained for as long as your account is active. If you close an account or need data deleted, contact [email protected] and we'll handle it directly - this is a manual, human-confirmed process today, not an automated self-service deletion flow, and we'd rather say that plainly than describe a button that doesn't exist yet.
Vulnerability disclosure
If you've found a security issue in shieldomesiege.com or the Siege platform itself, we'd genuinely like to hear about it before anyone else does - that's kind of the whole business. Email [email protected], or see our security.txt for the machine-readable version.