Security is architectural,
not aspirational

LEAPWare maintains a single, non-negotiable cryptographic standard across the entire platform. There are no "legacy compatibility modes," no customer-configurable cipher suites, and no exceptions for internal services. Every data path — external API, internal service mesh, database connection, backup stream — adheres to the same standard.

Data at Rest: AES-256-GCM — All persistent data is encrypted using AES-256 in Galois/Counter Mode, which provides both confidentiality and authenticated integrity. Each tenant's data is encrypted with a unique Data Encryption Key (DEK) that is itself wrapped by a Key Encryption Key (KEK) stored in cloud KMS with HSM backing. This envelope encryption model means that even a full database export without the KMS yields only ciphertext. DEKs are derived using HKDF (HMAC-based Key Derivation Function) with the tenant's unique identity as a context parameter — ensuring cryptographic separation between tenants at the key material level, not just the access control level.

Data in Transit: TLS 1.3 Exclusively — All external connections require TLS 1.3. There is no fallback to TLS 1.2 or any earlier protocol version. Internal service-to-service communication uses mutual TLS (mTLS) with short-lived certificates rotated automatically. Cipher suites are restricted to AEAD constructions — AES-256-GCM and ChaCha20-Poly1305. No CBC mode. No RSA key exchange. Forward secrecy is mandatory on every connection.

Key Rotation — Encryption keys are rotated on a 90-day schedule, enforced by automated policy. Rotation is non-disruptive: new data is encrypted with the current key, and existing data is re-encrypted during scheduled maintenance windows. Key rotation events are logged, alerted on failure, and auditable. Emergency rotation can be triggered within minutes for incident response.

Credential Management — No plaintext credentials exist anywhere in the LEAPWare infrastructure. API keys, database credentials, service tokens, and signing keys are stored exclusively in cloud KMS or secret management vaults. Credentials are injected into containers at runtime via secure sidecar patterns — never baked into images, never written to environment variables that could appear in process listings or crash dumps. Credential access is logged and subject to Cedar policy evaluation.

LEAPWare's network architecture is designed on the principle that no single control prevents all attacks — every layer must independently resist compromise, and the failure of any one layer must not expose the layers beneath it.

DDoS Mitigation — All public-facing traffic routes through Cloudflare's global network, providing automatic DDoS mitigation at layers 3, 4, and 7. Volumetric attacks are absorbed at the edge before they reach origin infrastructure. Application-layer attacks are filtered by behavioral analysis and challenge mechanisms. Origin IP addresses are never exposed in DNS records, headers, or error messages.

Web Application Firewall — A WAF evaluates every inbound HTTP request against OWASP Core Rule Set signatures, custom rules tailored to the LEAPWare API surface, and behavioral anomaly detection. Requests matching known attack patterns — SQL injection, XSS, path traversal, command injection, SSRF — are blocked at the edge with full logging for forensic analysis. WAF rules are reviewed and updated on a weekly cadence.

Rate Limiting — API endpoints enforce per-tenant, per-endpoint rate limits calibrated to legitimate usage patterns. Authentication endpoints have aggressive rate limits with exponential backoff to prevent credential stuffing. Rate limit violations are logged and trigger automated alerting when patterns indicate coordinated abuse.

Egress Filtering — Outbound network traffic from application containers is restricted to an explicit allowlist of destinations. Containers cannot initiate connections to arbitrary internet hosts. VIRT containers have the most restrictive egress rules — only the destinations specified in their charter are permitted. All egress traffic is logged and subject to anomaly detection.

VPC Isolation — All LEAPWare infrastructure operates within Virtual Private Cloud boundaries. Databases, caches, and internal services are not accessible from the public internet — there is no direct database access path from any public network. Service-to-service communication occurs over private network interfaces with security group rules enforcing least-privilege connectivity. Bastion access for operations personnel requires MFA and is logged with session recording.

The software supply chain is the most underestimated attack surface in modern software. LEAPWare treats every external dependency as a trust decision that must be justified, monitored, and revocable.

Dependency Scanning — All project dependencies are continuously scanned by Dependabot and Snyk for known vulnerabilities. Scanning occurs on every pull request, on a daily schedule against the main branch, and against the National Vulnerability Database (NVD) as new CVEs are published. Vulnerabilities that meet severity thresholds automatically create issues with SLA-bound resolution timelines. No dependency with a known critical vulnerability ships to production.

SBOM Generation — A Software Bill of Materials is generated for every release, enumerating every direct and transitive dependency with exact version, license, and known vulnerability status. SBOMs are stored as release artifacts and are available to customers and auditors on request. The SBOM format follows CycloneDX specification for interoperability with enterprise vulnerability management tooling.

Container Image Security — All container images are built from minimal base images with no shell, no package manager, and no unnecessary utilities in production. Images are scanned for vulnerabilities before they enter the container registry. Only signed images from the LEAPWare build pipeline are accepted by the container orchestrator — unsigned or externally built images are rejected at admission. Image digests are pinned in deployment manifests; tags are never used as the sole reference.

Signed Builds — All release artifacts are cryptographically signed. Build provenance is recorded, linking every artifact to the specific source commit, build environment, and pipeline run that produced it. This allows customers and internal teams to verify that any deployed artifact was produced by the official LEAPWare build infrastructure and has not been tampered with in transit or storage.

Minimal Dependency Philosophy — LEAPWare maintains a deliberate bias toward fewer dependencies. Every new dependency requires a justification that the functionality cannot be reasonably implemented in-house, a license review confirming compatibility with LEAPWare's distribution model, a maintenance assessment evaluating the dependency's bus factor, release cadence, and security responsiveness, and an initial vulnerability scan. Dependencies that are abandoned, have unresponsive maintainers, or accumulate unpatched vulnerabilities are replaced proactively — not when an exploit appears.

Multi-Region Architecture — LEAPWare infrastructure is deployed across multiple geographic regions with automated failover. Primary and secondary regions maintain synchronized state through asynchronous replication with conflict resolution. DNS-based traffic management automatically routes requests away from degraded regions without manual intervention.

Backup Encryption and Isolation — All backups are encrypted with key material separate from production encryption keys. Backup storage is in a different cloud account from production infrastructure, preventing a single account compromise from affecting both live data and backup data. Backup integrity is verified daily through automated restore testing against a verification environment.

Geographic Redundancy — No single geographic event — natural disaster, power grid failure, network partition — can render LEAPWare unavailable. Data sovereignty requirements are respected: tenant data is stored in regions consistent with the customer's contractual and regulatory requirements, and geographic redundancy does not replicate data outside approved jurisdictions without explicit authorization.

Annual Third-Party Penetration Testing — An independent security firm conducts annual penetration testing covering the full LEAPWare attack surface: external APIs, web applications, infrastructure, cloud configuration, and social engineering vectors. The engagement scope includes authenticated and unauthenticated testing. Critical and high findings trigger immediate remediation under the vulnerability management SLA. The penetration testing report summary is available to enterprise customers under NDA.

Compliance Roadmap — LEAPWare maintains a public compliance roadmap reflecting certification targets and their status. Current trajectory: SOC 2 Type II (Q4 2026), ISO 27001 (evaluation for 2027), HIPAA (evaluated based on customer demand). Architecture decisions are made with future compliance requirements in mind — it is always cheaper to build compliant than to retrofit compliance.

Security monitoring at LEAPWare is not a dashboard that someone checks during business hours. It is a continuous, automated system that ingests security-relevant events from every layer of the infrastructure and surfaces actionable alerts in real time.

24/7 Log Monitoring — All security-relevant events — authentication attempts, authorization decisions, configuration changes, network anomalies, and error conditions — are collected into a centralized logging infrastructure. Logs are immutable, encrypted, and retained for a minimum of 90 days. Log analysis runs continuously, not in batch windows.

Anomaly Detection — Behavioral baselines are established for authentication patterns, API usage patterns, knowledge access patterns, and agent activity patterns. Deviations from baseline trigger automated investigation workflows. Anomaly detection covers impossible-travel authentication, unusual data access volumes, privilege escalation attempts, and abnormal egress traffic patterns.

SIEM Integration — Security events are correlated across sources in a Security Information and Event Management system. Correlation rules detect multi-stage attack patterns that would not be visible in any single log stream. Alert fatigue is managed through tuning, deduplication, and severity-based routing — critical alerts page on-call personnel, informational alerts queue for daily review.

Intrusion Detection — Network-level and host-level intrusion detection systems monitor for known attack signatures and anomalous behavior patterns. Detection covers the full kill chain: reconnaissance, initial access, lateral movement, privilege escalation, and data exfiltration. Alerts from intrusion detection systems feed into the SIEM for correlation and are triaged under the incident response process.

Automated Alerting and Response — Critical security events trigger automated responses before human review: suspicious authentication patterns trigger account lockout, anomalous network traffic triggers traffic isolation, and configuration drift triggers automated remediation. Human review follows automated containment — the system buys time for the security team to investigate without allowing the threat to progress.