BOSSS is built with defense-in-depth from the architecture up. Every layer — infrastructure, network, application, and data — is independently hardened. Tenant data is cryptographically isolated at the PostgreSQL schema level. Every action is permanently recorded.
BOSSS uses PostgreSQL schema-per-tenant isolation — not row-level filtering. Each customer's data lives in a completely separate database schema. No query from one tenant can access another tenant's schema, enforced at the database engine level.
Each tenant is a fully separate PostgreSQL schema. The database engine itself, not application code, enforces the boundary.
All querysets are evaluated inside the tenant's schema context. Lazy queries that might drift to the public schema are caught and rejected by CI tests.
Celery workers run all background tasks within an explicitly declared schema context — no background job can accidentally read cross-tenant data.
Each module (GRC, IAM, CMDB, etc.) must be explicitly activated per tenant. Unactivated modules return 404 — not empty data.
Encryption is applied at rest, in transit, and at the individual field level — not just at the database boundary.
| Layer | Mechanism | Implementation Detail |
|---|---|---|
| Data in Transit | TLS 1.3 | ECDHE/CHACHA20 ciphers, HSTS enforced, forward secrecy mandatory |
| Data at Rest | AES-256 | Database storage, file storage, and backup archives |
| Field-Level Encryption | AES-256 + Key Vault | Sensitive fields (secrets, credentials, PII) encrypted individually |
| Key Management | HashiCorp Vault + Azure Key Vault | Production secrets managed in dedicated vault infrastructure; BYOK supported |
| Password Hashing | Argon2id | Industry-strongest password hashing algorithm with per-user salting |
| Certificate Management | DNSSEC + PKIX | DNSSEC-enabled domains; TLS certificates auto-renewed with private-only connectivity |
Platform controls mapped to NIST 800-53, SOC 2, ISO 27001, HIPAA, and GDPR requirements.
| Control Domain | BOSSS Implementation | NIST 800-53 | SOC 2 | ISO 27001 | HIPAA | GDPR |
|---|---|---|---|---|---|---|
| Access Control (AC) | Per-tenant DB schemas, RBAC/ABAC, mandatory MFA, session TTL | AC-2, AC-3 | CC6.1 | A.9 | 164.312(a) | Art. 32 |
| Audit & Accountability (AU) | HistoricalBaseModel on all 30+ domains; SIEM logging; blockchain ledger on People, Identity, Risk | AU-2, AU-9 | CC7.2 | A.12.4 | 164.312(b) | Art. 5(f) |
| System & Comms Protection (SC) | TLS 1.3, AES-256, field-level encryption via Key Vault, HSTS | SC-8, SC-28 | CC6.7 | A.10, A.13 | 164.312(e) | Art. 32 |
| System & Info Integrity (SI) | Input validation, rate limiting, SSRF two-tier trust model, ClamAV antivirus on uploads | SI-10, SI-3 | CC7.1 | A.12.2 | 164.312(c) | Art. 25 |
| Contingency Planning (CP) | Azure immutable backups (effective ransomware defense), BCP/DR module, RTO/RPO tracking | CP-2, CP-9 | CC9.1 | A.17 | 164.308(a)(7) | Art. 32 |
| Config Management (CM) | Infrastructure-as-Code (Docker Compose/Terraform), SBOM scanning, dependency pinning | CM-3, CM-7 | CC8.1 | A.12.1 | 164.308(a)(1) | Art. 25 |
| Identification & Auth (IA) | JWT with short TTL, Argon2id passwords, MFA enforced for all roles, SCIM provisioning | IA-2, IA-5 | CC6.1 | A.9.4 | 164.312(d) | Art. 32 |
| Supply Chain Security | Trivy, Bandit, pip-audit, Gitleaks, CodeQL in CI/CD; no unapproved dependencies | SR-3, SR-11 | CC8.1 | A.15 | 164.308(a)(1) | Art. 32 |
Four independent security layers — each hardened separately so no single failure exposes data.
Every code commit runs a full security gate. Vulnerable code cannot reach production.
Python SAST — finds security anti-patterns and unsafe calls in source code
Container & dependency vulnerability scanning — blocks known CVEs from reaching production
Secret detection in commits — prevents API keys, tokens, and credentials from entering the repository
Python package vulnerability audit — cross-references PyPI packages against advisory databases
Semantic code analysis — identifies complex vulnerability patterns like injection and XSS
Fast Python linter catching code quality issues that can introduce security regressions
We believe trust is earned through transparency, not paperwork. Our approach to due diligence reflects a security-first philosophy — one that protects both our customers and ourselves from the risks that conventional audit processes introduce.
What we offer: Prospective customers and partners are welcome to have technical discussions with our engineering and security leadership. We will walk you through our architecture, controls, and engineering practices in detail.
This page: Everything documented here is verifiable evidence of our security posture — architecture decisions, encryption standards, DevSecOps tooling, and control mappings — provided openly as a substitute for certificate theater.
What we do not grant: We do not provide system access, configuration files, network credentials, or internal audit data to external parties under any circumstances. This protects you as much as it protects us — your data lives in our platform, and we take that responsibility seriously.
We use strictly necessary cookies to run this site. With your permission we would also use analytics and marketing cookies, including session recording. Cookie Policy