Compliance & Standards Mapping
How to read this page: Implemented means the control exists in shipped code and is covered by our engineering design records; Partial means meaningful coverage exists with a named remainder; Roadmap means published as planned, not claimed. SignVerse does not claim third-party certifications (e.g., SOC 2, ISO 27001) it has not undergone; this mapping shows technical control alignment to support your own vendor assessment.
1.OWASP Top 10 (2021)
| Risk | SignVerse controls | Status |
|---|---|---|
| A01 — Broken Access Control | Server-side RBAC on every protected operation (69 permissions / 10 roles); organization-scoped queries everywhere; cross-tenant references rejected and regression-tested; public tokens scoped to a single resource | Implemented |
| A02 — Cryptographic Failures | Argon2 for one-time codes; SHA-256/HMAC-SHA256 (peppered, versioned) for keys, tokens, and secrets; authenticated symmetric encryption for stored secrets with envelope encryption and a rotation ledger; constant-time comparisons | Implemented |
| A03 — Injection | Parameterized ORM for all database access; allowlist HTML sanitization; text-context rendering of user data in the UI; bounded pagination and search parameters | Implemented |
| A04 — Insecure Design | Purpose-bound authentication challenges; tombstoned token lifecycle (honest 410 vs blank 404); deterministic, explainable forensics; fail-closed vault and decryption behavior; mandatory threat-model checklist per change | Implemented |
| A05 — Security Misconfiguration | Production startup refuses unsafe configuration (weak/default secrets, unvalidated token issuers); strict security headers with per-request CSP nonces; no debug modes in production paths | Implemented |
| A06 — Vulnerable & Outdated Components | Mandatory dependency-justification ladder before any new dependency; vetted parsers for hostile input | Implemented |
| A07 — Identification & Authentication Failures | Passwordless OTP with rate limits, attempt caps, lockouts; anti-enumeration (generic responses, no lookup-before-send); recipient password lockout; environment-gated development credentials | Implemented |
| A08 — Software & Data Integrity Failures | Per-stage SHA-256 hash chain over document/signature state; detached CMS/PKCS#7 seals bound to the chain head; append-only audit and forensic ledgers | Implemented |
| A09 — Security Logging & Monitoring Failures | Append-only audit trail across lifecycle, ceremonies, auth events, admin actions; PII masked in logs; secrets and codes never logged | Implemented |
| A10 — Server-Side Request Forgery | Render-time URL safety: scheme blocking, cloud-metadata blocking, numeric private-range blocking, enforced on both rendering engines | Implemented |
2.OWASP ASVS 4.0 — chapter-level alignment
| ASVS chapter | Alignment | Notes |
|---|---|---|
| V1 Architecture & Design | Aligned | Documented threat-driven design rationale; single reusable security components by policy |
| V2 Authentication | Aligned | Passwordless OTP (hashed, expiring, attempt-capped, purpose-bound); generic responses; admin path separately gated |
| V3 Session Management | Aligned | HttpOnly/Secure/SameSite JWT session cookie, 24 h expiry, server-side CSRF pairing |
| V4 Access Control | Aligned | Per-route permission declarations; tenant scoping at query layer; deny-by-default guards |
| V5 Validation, Sanitization & Encoding | Aligned | Schema validation, allowlist sanitizer, output encoding, upload hardening |
| V6 Stored Cryptography | Partial | Secrets encrypted with rotation; document blobs rely on storage-layer encryption today (application-level blob encryption on roadmap) |
| V7 Error Handling & Logging | Aligned | Generic errors on auth surfaces; masked, secret-free, append-only logging |
| V8 Data Protection | Partial | Minimization is structural; DSAR tooling and default-KMS residency on roadmap |
| V9 Communications | Aligned | TLS mandated; HSTS/edge hardening are deployment controls in self-hosted installs |
| V10 Malicious Code | Aligned | Supply-chain ladder; no dynamic code execution paths for user input |
| V11 Business Logic | Aligned | Ceremony ordering enforced server-side; rate/abuse budgets on sensitive flows; quarantine human-review gate |
| V12 Files & Resources | Aligned | Multi-layer upload validation, active-content PDF rejection, optional fail-closed malware scanning |
| V13 API & Web Services | Aligned | Uniform auth on API surfaces; hashed machine credentials; bounded queries; idempotency keys on roadmap for envelope-creating calls |
| V14 Configuration | Aligned | Startup configuration guardrails; environment-gated development shortcuts; documented headers |
3.OWASP Cheat Sheet practices adopted
- Authentication Cheat Sheet — generic authentication responses; no user enumeration via content or timing.
- Forgot Password Cheat Sheet — identical responses for existing/non-existing accounts; the mailbox is the only truth channel.
- Password Storage guidance — Argon2 for the only user-facing secrets we hold (one-time codes); no user passwords stored at all.
- Session Management Cheat Sheet — HttpOnly, Secure, SameSite cookies; server-issued CSRF tokens with constant-time comparison.
- File Upload Cheat Sheet — extension + MIME + magic-byte consistency, size caps, content inspection, malware scanning hooks.
- SSRF Prevention Cheat Sheet — deny-by-default scheme/host validation with numeric private-range checks at the fetching layer.
4.Electronic-signature framework support
SignVerse's evidence model (verified ceremonies, per-signer hash chain, cryptographic seals with attributable keys, append-only audit, forensic scoring) is engineered to support the core requirements of ESIGN/UETA and the advanced electronic signature principles of eIDAS: signatures uniquely linked to and capable of identifying the signer, and bound to the document so any later change is detectable. SignVerse is not a Qualified Trust Service Provider; qualified-signature scenarios can be supported through the external trust-provider attestation integration. Legal sufficiency for a specific use case and jurisdiction should be confirmed with your counsel.
5.Secure development lifecycle
Every change to SignVerse is developed under a mandatory 17-control guardrail catalog covering the OWASP baseline plus brute-force, abuse/DoS, injection, XSS, CSRF, authorization/tenancy, secrets, PII, cryptography standards, transport, public-link safety, HTTPS hardening, uploads, headers, logging/monitoring, and supply chain. Each feature merges only with a completed security review and security test report. This process is itself part of the compliance story: controls stay true because the process re-verifies them on every change.
6.Published roadmap items (not claimed as current)
Database row-level security beneath app-layer tenancy · external KMS as default secret store · application-level document-blob encryption · embedded PAdES-LTV seals · per-tenant rate budgets · explicit origin validation on mobile ceremonies · packaged DSAR export/erasure tooling · idempotency keys on envelope-creating API calls.