Absolute DB implements every layer of security natively - no OpenSSL, no external TLS libraries, no third-party cryptographic dependencies. Your data is protected by code we wrote and control completely.
From data at rest on disk to data in transit across the network, every byte is encrypted with algorithms we implemented in pure C11 - no third-party cryptographic library touches your data.
AES-256-GCM column-level encryption with hardware-backed key management. Every sensitive column is encrypted independently with a unique data-encryption key. Compromising one column's key exposes nothing else.
Native TLS 1.3 with no external TLS libraries - we implemented TLS ourselves, eliminating third-party cryptographic supply chain risk entirely. Supports both AES-256-GCM and ChaCha20-Poly1305 cipher suites. SNI, ALPN, and session resumption all included.
First-class post-quantum cryptography under FIPS 203/204/205: ML-KEM-768 key encapsulation, ML-DSA-65 digital signatures, SLH-DSA hash-based signatures. Hybrid classical + post-quantum key exchange for TLS connections defeats "harvest now, decrypt later" attacks - data captured today cannot be decrypted by future quantum computers.
The DM Data Vault is the integrated authentication, licensing, and recovery subsystem that gates every production capability. Post-quantum key encapsulation, hardware binding, a threshold recovery protocol, and the Fortress Lock work together as one protective envelope around the database.
ML-KEM-768 (Kyber-768) wraps every DM Data Vault session key per FIPS 203. Authority unlock tokens are RSA-2048 signed and bound to the installation, the client identity, and a fresh 512-bit challenge - replay, forgery, and cloning are all rejected.
Each vault is cryptographically bound to the host through platform fingerprinting (machine-id, CPUID, hostname, boot identity) with a TPM 2.0 PCR-7 style measurement. Moving a vault file to foreign hardware automatically trips the Fortress Lock.
Every vault context runs a strict state machine: LOCKED →
UNLOCKED on successful mutual auth, FAILED on an attempted
bypass, BRICKED once the failure threshold is exhausted. Brute-force,
credential stuffing, and token replay all converge on the bricked state.
Rotating the master signing key or any individual recovery credential requires a multiple threshold of DM Recovery Keys. Passwords are never stored in plaintext - only SHA3-512 digests compared in constant time. No single custodian can seize, rotate, or lock out the vault alone.
The Fortress Lock is a continuous tripwire across the running database. When it fires,
the vault transitions out of UNLOCKED and blocks access until the operator
explicitly re-authorises - the database does not silently limp along after a compromise.
Filesystem-anomaly signals characteristic of ransomware campaigns (mass encrypt/rename
patterns on data files) raise LOCK_FS_ANOMALY and freeze the vault before
the attacker can complete their sweep. The immutable hash-chained audit log captures
the full event sequence for forensic review.
Binary and data-file integrity are measured against the vault-bound baseline; any
modification raises LOCK_TAMPER. Combined with the zero-dependency single
binary - no shared libraries to inject, no interpreters to hook, no plugins to swap -
the attack surface for traditional malware and supply-chain implants is collapsed.
Hardware-ID drift (LOCK_HWID_MISMATCH), unauthorised filesystem access
(LOCK_FS_BREACH), authentication exhaustion (LOCK_AUTH_EXHAUST),
bounds-check failures (LOCK_BOUNDS_FAIL), and root-of-trust provider
failures (LOCK_ROT_FAIL) all feed the same Fortress Lock bus.
AI-assisted attackers automate credential stuffing, injection fuzzing, and prompt exploitation. The vault's bricking threshold defeats automated guessing; the PostgreSQL wire parser and prepared-statement plan cache eliminate SQL-injection classes by construction; the NL2SQL path is schema-constrained and never executes free-form code.
Every release must pass AddressSanitizer, UndefinedBehaviorSanitizer, and ThreadSanitizer with zero findings before it can ship. Bounds-checked memory access, secure-zero clearing of all sensitive buffers, and arena-managed allocation close the memory-corruption primitives attackers rely on.
Every Fortress Lock event is written to the SHA-256 hash-chained audit log in WORM mode with Merkle-tree verification. Attackers cannot erase or rewrite their trail without invalidating every subsequent record - tamper is mathematically evident.
Multiple access-control models stack on top of each other, so you can start simple and add sophistication without rearchitecting.
Fine-grained permissions at database, schema, table, and column level. Grant and revoke
with standard SQL GRANT / REVOKE statements. Works natively
with every PostgreSQL-compatible ORM and driver.
Policy-driven access based on user attributes and resource properties. Enforce rules like "analysts can only read data tagged for their cost centre" without custom application logic.
Per-row access policies - users see only the rows they're authorised to see. Defined once in the database, enforced on every query path, invisible to application code.
Sensitive fields - PAN, SSN, PHI, email addresses - automatically masked based on user role. Production data stays safe in lower environments without ETL pipelines or application changes.
JWT-based SSO integration with configurable session expiry. Users authenticate once through your identity provider; Absolute DB validates tokens on every connection - no password sync required.
Enterprise tier includes a FIPS 140-3 Level 4 HSM path for hardware-backed key operations. Data-encryption keys never leave the HSM boundary in plaintext.
The Enterprise tier ships a full zero-trust networking stack. Trust is never implied by network location - every peer must prove its identity on every operation.
Every connection requires client certificate verification - no anonymous connections are accepted. Certificates are issued, rotated, and revoked automatically without downtime.
Each database node issues X.509 SVIDs per the SPIFFE standard; peer identity is verified cryptographically on every operation. Works across Kubernetes pods, VMs, and bare-metal nodes in multi-region clusters.
Fine-grained access control keyed on client SPIFFE identity - not just role. Restrict which services can write to which tables down to a single microservice identity without touching application code.
Zero-downtime certificate rotation with post-quantum signed handshakes. Rotate the cluster CA and all leaf certificates in a rolling window - live traffic continues uninterrupted throughout.
Automated compliance tooling for every major framework. Generate audit reports, evidence packages, and lineage maps in seconds - not audit-week scrambles.
Every database event is logged with a SHA-256 hash chain - tamper-evident by construction. WORM mode prevents any retrospective modification. Merkle tree validation lets auditors verify log integrity without reading every entry.
Automated right-to-erasure, Subject Access Reports, consent ledger, and right-to-portability - all via standard SQL calls. Column-level data lineage maps which fields contain personal data across every table and view.
CALL absdb_gdpr_erase('users', 'email', 'alice@example.com');
SELECT * FROM absdb_gdpr_report('alice@example.com');PHI column tagging with automatic audit trail on every read and write operation. Access reports can be generated for any date range in seconds. Row-level security ensures clinicians see only their patients' records.
ALTER TABLE patients ALTER COLUMN ssn SET (hipaa_phi = true);
SELECT * FROM absdb_hipaa_access_report('2026-01-01', '2026-03-31');FF3-1 format-preserving tokenisation for PAN data - tokens look like card numbers so downstream systems need no changes. Annual DEK rotation enforced automatically. PAN never stored or logged in plaintext anywhere in the system.
SELECT absdb_pci_tokenise('4111111111111111');
SELECT absdb_pci_detokenise(token); -- role-restrictedContinuous evidence collection across all five Trust Service Criteria. Generate an auditor-ready evidence package for any date range with a single SQL call. No spreadsheet-gathering required.
SELECT * FROM absdb_soc2_evidence('2026-01-01', '2026-03-31');Built-in asset register, control mapping, and automated compliance reporting aligned to Annex A controls. Maintain ISO 27001 certification evidence continuously rather than preparing for annual audits.
SELECT * FROM absdb_iso27001_controls();All compliance tooling is built into the database binary - no third-party agents, no compliance sidecars.
In March 2026, the developer community was reminded how severely npm-based supply chains can fail. Absolute DB is architecturally not subject to this entire class of vulnerability - by design, not by patch.
Absolute DB is written entirely in pure C11 and compiled to a single ~154 KB native binary.
There is no npm package, no node_modules directory, no JavaScript runtime, and no
bundler involved at any stage - not in the product, not in the build system, not in the toolchain.
npm supply chain attacks simply have no attack surface here.
Source map files (.map) are a JavaScript bundler artefact that can accidentally
expose full application source code in production packages. Absolute DB has no source maps -
ever. A compiled C binary does not produce them. What ships is a stripped native binary.
No source reconstruction is possible from the release artefact.
The Absolute DB binary links only against libc, libm,
libpthread, and libdl - standard system libraries present on every
POSIX platform. No OpenSSL. No libcurl. No protobuf-c. No gRPC-c. No liburing.
Every protocol, every cryptographic primitive, every I/O path is original C11 code.
There is no third-party dependency to be compromised, backdoored, or typosquatted.
make release builds the complete Absolute DB binary from ~120,000 lines of
C11 source in under 7 seconds on a standard workstation. Every line of code that runs in
production is visible, reviewable, and reproducible. Security auditors can read the full
source, verify every cryptographic implementation against its specification, and reproduce
the build independently - no proprietary build system, no binary blobs, no obfuscation.
Supply chain vulnerabilities in npm-based tools are patched reactively - someone discovers the problem, files a CVE, and a patch is released. Absolute DB's approach is different: the entire class of npm, JavaScript runtime, source map, and bundler vulnerabilities does not exist because the architecture that would enable them was never built. Pure C11 + single binary = a fundamentally smaller and simpler attack surface than any multi-runtime, multi-package-manager toolchain.
No. Absolute DB implements TLS 1.3 natively in pure C11 with no external cryptographic libraries. This eliminates the entire OpenSSL supply chain attack surface - Heartbleed, BEAST, and similar vulnerabilities cannot exist in our TLS implementation because we do not share a single line of code with OpenSSL.
Quantum computers will break classical public-key cryptography (RSA, elliptic curve) within 10–15 years at scale. FIPS 203, 204, and 205 specify quantum-resistant algorithms standardised by NIST. Absolute DB implements all three natively, future-proofing your data against "harvest now, decrypt later" attacks - where adversaries store encrypted traffic today and decrypt it once quantum hardware matures.
Each encrypted column has its own unique data-encryption key (DEK), managed through the built-in key management system or an external HSM (Enterprise tier). Encrypting and decrypting happens transparently at the storage layer - queries run normally, SQL stays the same, and DEKs are rotated without downtime.
Email contact us with a detailed description of the vulnerability, steps to reproduce, and any proof-of-concept code. We acknowledge within 24 hours and aim to patch confirmed vulnerabilities within 30 days. We do not operate a public bug bounty program at this time but do credit researchers in our release notes with their consent.
Every release must pass AddressSanitizer, UndefinedBehaviorSanitizer, and ThreadSanitizer
with zero errors - this is a hard gate on merging to main. Bounds-checked
memory references and secure zeroing of sensitive buffers are enforced via mandatory
code standards across every security-critical path.
Yes. Absolute DB v9.5.1 "Project ZENITH" ships a hardware-TEE integration module
that detects Intel SGX and AMD SEV-SNP at runtime and, where
available, places sensitive enclave regions behind mprotect + mlock
with in-place AES-256-CTR encryption. On CPUs without a TEE, a portable software
AES-CTR fallback is used. AES-NI acceleration is enabled automatically when present.
External TEE-module attestation is a customer-environment concern.
Fortress mode keeps an append-only WORM log and hash-chains every audit entry with SHA-256. A Merkle tree over the log provides compact state proofs so that any verifier can check the integrity of a single entry without replaying the entire log. This is used by our SOC 2 / ISO 27001 evidence-collection pipelines and by the DM Data Vault recovery process.
Yes. The native TLS 1.3 stack advertises a hybrid X25519 ‖ ML-KEM-768 key-exchange
group, combining classical elliptic-curve and lattice-based key encapsulation under
HKDF-SHA-256. ML-DSA-65 (FIPS 204) signs node identity certificates and audit entries;
SLH-DSA (FIPS 205) is used for long-term CA roots and release signing. All three KATs
pass in CI via make pqc-kat.