Documented Secure Development Process

Effective: March 17, 2026 · DCF-637

1. Purpose

This document defines H33.ai's Secure Development Lifecycle (SDLC) in accordance with ISO 27001 controls A.8.25 (Secure Development Life Cycle), A.8.26 (Application Security Requirements), A.8.27 (Secure System Architecture and Engineering Principles), A.8.28 (Secure Coding), and A.8.29 (Security Testing in Development and Acceptance). As a post-quantum cryptographic infrastructure provider, security is embedded at every phase of H33.ai's development process, from requirements through deployment and operations.

2. SDLC Phases

Phase 1: Requirements

• Security requirements are identified and documented alongside functional requirements for every feature and change.
• Cryptographic requirements specify the algorithms, key sizes, and security levels required (e.g., H33-128 uses BFV with N=4096, Q=56-bit, t=65537).
• Data classification is performed to determine handling requirements (PHI, PII, credentials, public data).
• Compliance requirements are mapped to relevant frameworks (SOC 2, HIPAA, ISO 27001) for each feature.

Phase 2: Design

• Threat modeling: New features and architectural changes undergo threat modeling to identify attack surfaces, trust boundaries, and potential vulnerabilities.
• Architecture review: System design is reviewed for adherence to security principles: defense in depth, least privilege, fail-secure defaults, and separation of concerns.
• Cryptographic design review: Any change to cryptographic operations (FHE parameters, NTT implementations, key management) requires review against known attacks and NIST guidelines.
• Domain conventions: BFV domain conventions (NTT form vs. coefficient form) are verified in the design phase to prevent correctness bugs that could compromise security.

Phase 3: Implementation

• All code is written following H33.ai's secure coding standards (see Section 3).
• Developers work on feature branches; direct commits to main or production branches are blocked by GitLab branch protection rules.
• Secrets are never included in source code. Pre-commit hooks enforce this automatically.
• unsafe Rust blocks require explicit justification in a code comment and dedicated review attention.

Phase 4: Testing

• Unit tests: All cryptographic operations have corresponding unit tests verifying correctness (encrypt/decrypt round-trip, NTT/INTT inverse, signature verify, ZKP verification).
• Integration tests: End-to-end authentication pipeline tests verify that the full FHE + Dilithium + STARK flow produces correct results.
• Security tests: Tests verify constant-time behavior for cryptographic paths, proper key zeroing on drop, and resistance to known attack patterns.
• Performance regression tests: Criterion benchmarks (benches/fhe_bench.rs) detect performance regressions that could indicate algorithmic issues.
• Fuzz testing: Critical parsing and deserialization code is fuzz-tested for crash resistance and memory safety.

Phase 5: Deployment

• All deployments go through the GitLab CI/CD pipeline. No manual deployments to production.
• Pipeline stages: lint (cargo clippy) → audit (cargo audit) → test (cargo test) → build (release mode) → deploy (staging first, then production).
• All pipeline stages must pass before code can be merged or deployed. Any failure blocks the pipeline.
• Auth1 deployments go through Elastic Beanstalk with health checks and automatic rollback on failure.

Phase 6: Operations

• Monitoring: DataDog monitors all production systems for anomalies, performance degradation, and security events.
• Incident response: Security incidents follow the Incident Response Plan with defined severity levels, escalation paths, and communication procedures.
• Patch management: Critical vulnerabilities (CVSS 9.0+) patched within 72 hours. High vulnerabilities (CVSS 7.0-8.9) patched within 30 days.

3. Secure Coding Standards

H33.ai's core engine is written in Rust, which provides inherent memory safety guarantees. The following coding standards augment Rust's safety with cryptographic-specific requirements:

Rust Memory Safety

• No null pointer dereferences: Rust's type system eliminates null pointers via the Option type.
• No buffer overflows: Array bounds are checked at runtime. Slice operations are bounds-safe by default.
• No data races: Rust's ownership system prevents concurrent mutable access at compile time. rayon parallel iterators enforce this for multi-threaded FHE operations.
• No use-after-free: The borrow checker prevents accessing deallocated memory at compile time.

Cryptographic Coding Standards

• Constant-time operations: All cryptographic comparison, key derivation, and signature operations use constant-time implementations to prevent timing side-channel attacks.
• No deprecated primitives: SHA-1, MD5, DES, 3DES, RC4, and other deprecated algorithms are prohibited. H33.ai uses SHA3-256, AES-256-GCM, ML-DSA (Dilithium), and ML-KEM (Kyber).
• CSPRNG only: All random number generation uses cryptographically secure pseudo-random number generators (rand crate with OS entropy).
• Key material zeroing: All key material is zeroed from memory when no longer needed via Drop trait implementations or zeroize patterns.
• unsafe restrictions: unsafe blocks are used only when absolutely necessary (e.g., NEON intrinsics for Galois rotation). Each unsafe block requires a safety comment explaining why the invariants are upheld and receives focused review attention.

4. Code Review

• All changes require a merge request (MR) in GitLab before merging to main or production branches.
• Minimum 1 reviewer must approve each MR. Cryptographic changes require a reviewer with cryptographic domain expertise.
• No self-merges: The author of a change cannot approve their own merge request for production deployments.
• Merge requests include: description of the change, security implications, test coverage, and performance impact (if applicable).
• GitLab branch protection rules enforce these requirements; they cannot be bypassed without administrative access.

5. Automated Security Checks

6. Dependency Management

• cargo audit runs on every pipeline execution, blocking merges if vulnerabilities are found.
• Dependabot is configured for the Auth1 Node.js codebase, creating automated merge requests for vulnerable dependencies.
• New dependency additions require: license compatibility review (MIT, Apache 2.0, BSD, ISC permitted), maintenance status verification, security track record assessment, and transitive dependency audit.
• Cargo.lock is committed to version control for reproducible builds. Dependency versions are pinned, not floating.

7. Environment Separation

• Development: Local developer environments with mock services. No access to production data or credentials.
• Staging: AWS environment with production-equivalent configuration but synthetic data. Used for integration testing and pre-deployment validation.
• Production: Isolated AWS VPC with strict security group rules. Accessed only through CI/CD pipeline deployments (no manual SSH for deployments).
• Each environment uses separate credentials stored in separate Secrets Manager instances. Cross-environment credential access is prohibited by IAM policies.

8. Secrets Management

• No secrets in code: Enforced via pre-commit hooks (regex patterns for keys/tokens/passwords) and GitLab CI secret detection stage.
• AWS Secrets Manager: Primary store for all long-lived credentials (database passwords, API keys, signing keys).
• Environment injection: Credentials are injected at deploy time via Elastic Beanstalk environment configuration or EC2 instance role, never embedded in artifacts.
• .gitignore enforcement: .env files, key files, and credential files are in .gitignore across all repositories.

9. Penetration Testing

H33.ai conducts annual third-party penetration testing of its production infrastructure, APIs, and web applications. The first pen test is scheduled for Q2 2026 and will cover:

• External network penetration testing of all public-facing endpoints
• API security testing of the H33 authentication API and Auth1 endpoints
• Web application testing of h33.ai, app.cachee.ai, and associated portals
• Cloud infrastructure configuration review (AWS)

Findings are remediated according to severity: Critical within 72 hours, High within 30 days, Medium within 90 days. All findings and remediation actions are tracked in Drata.

10. Review Schedule

• Continuous: Automated security checks (clippy, audit, tests, secret detection) run on every pipeline execution.
• Per change: Code review required for every merge request.
• Annual: Comprehensive SDLC review including coding standards, pipeline configuration, access controls, and penetration test results. Updates as needed based on threat landscape and technology evolution.