Credential Management and Control of Audit Activities

Effective: March 17, 2026 · DCF-707/760

1. Purpose

This document establishes H33.ai's policies for credential management (DCF-707) and control of audit activities (DCF-760). Credential management ensures that no hard-coded credentials exist in source code or artifacts, and that all secrets are properly stored, rotated, and monitored. Audit activity controls ensure that compliance testing and verification activities are conducted without disrupting production operations or compromising system integrity.

2. No Hard-Coded Credentials Policy

H33.ai maintains a strict zero-tolerance policy for hard-coded credentials. No passwords, API keys, tokens, private keys, or other secrets are permitted in source code, build artifacts, container images, or configuration files committed to version control.

• All credentials are stored in AWS Secrets Manager or injected as environment variables at deploy time via Elastic Beanstalk configuration.
• Pre-commit hooks scan all staged files for credential patterns (regex matching for API keys, passwords, tokens, private key headers, and connection strings) before allowing commits.
• GitLab CI pipeline includes a dedicated secret detection stage that scans all changes in every merge request. The pipeline fails if any credential patterns are detected.
• .env files are listed in .gitignore across all repositories. Developers use .env.example files with placeholder values for local development.
• .env.production is maintained separately and never committed to version control. Production environment variables are managed through AWS Secrets Manager and Elastic Beanstalk configuration.

3. Credential Types and Storage

4. Detection Controls

H33.ai implements multiple layers of detection to prevent credential exposure:

Pre-Commit Hooks

• Regex patterns scan for common credential formats: AWS access keys (AKIA[0-9A-Z]{16}), private key headers (-----BEGIN.*PRIVATE KEY-----), generic passwords (password\s*=\s*['"][^'"]+['"]), API keys with common prefixes, and connection strings with embedded credentials.
• Hooks are installed automatically as part of the repository setup. Developers cannot bypass hooks without explicit --no-verify (which is flagged in GitLab audit logs).

GitLab Secret Detection CI Stage

• Runs on every merge request as a mandatory pipeline stage.
• Uses GitLab's built-in secret detection analyzer with H33-specific custom rules for Auth1 API key patterns and internal credential formats.
• Pipeline fails on detection, blocking the merge until the finding is resolved.

Cargo Audit

• cargo audit checks for known vulnerable credential handling patterns in Rust dependencies (e.g., libraries that log secrets, store keys in predictable locations, or use weak key derivation).

Periodic Manual Code Review

• Quarterly manual review of the full codebase for any credential patterns that may have evaded automated detection, including obfuscated credentials, base64-encoded secrets, or credentials in test fixtures.

5. Control of Audit Activities (DCF-760)

Compliance audit activities are conducted with the following controls to minimize impact on production operations and maintain system integrity:

Scheduling and Coordination

• Audit testing is scheduled to minimize disruption: Compliance evidence collection is automated via Drata wherever possible, eliminating the need for manual production access during audit periods.
• Penetration test windows are coordinated with the development schedule to avoid conflicts with major releases or customer-impacting maintenance windows.
• External auditor access is scheduled in advance with defined start and end dates. All access is time-limited and revoked automatically upon audit completion.

Access Controls for Audit Activities

• Read-only access: All audit tools and auditor accounts have read-only permissions. No audit activity can modify, delete, or create production resources.
• Drata automated evidence collection: Drata's integration with AWS, GitLab, and other services collects compliance evidence automatically through read-only API connections. No manual production access is required for routine evidence collection.
• Scoped access: External auditors receive temporary credentials scoped to only the systems and data necessary for the audit. Access is granted per the principle of least privilege.

Monitoring of Audit Activities

• All audit activities are logged in CloudTrail and DataDog, providing a complete record of what was accessed, when, and by whom.
• Anomalous audit access patterns (e.g., access to systems outside the defined audit scope) trigger alerts to the CISO.
• Audit activity logs are retained for the same period as other audit logs (see Audit Log Retention Policy).

6. Incident Response for Credential Exposure

If a credential exposure is detected through any channel (pre-commit hook, CI detection, manual review, external report, or monitoring alert), the following response procedure is executed:

1. Immediate rotation: The exposed credential is rotated within 1 hour of detection. For API keys and passwords, this means generating a new credential and updating all systems that depend on it.
2. Impact assessment: Determine the scope of exposure: when the credential was exposed, where it was exposed (public repo, log file, etc.), and whether it was accessed by unauthorized parties.
3. Access review: Review CloudTrail and application logs for any unauthorized use of the exposed credential during the exposure window.
4. Notification: If the exposure involves customer data or meets the threshold defined in the Breach Notification Policy, affected parties are notified within the required timeframe (72 hours for HIPAA).
5. Root cause analysis: Determine how the credential was exposed and implement controls to prevent recurrence (e.g., updated pre-commit hook patterns, additional training).
6. Documentation: The incident, response actions, and root cause analysis are documented in the incident register (Drata) and retained per the audit log retention policy.

7. Review Schedule

• Continuous: Pre-commit hooks and CI secret detection run on every commit and merge request.
• Quarterly: Manual codebase review for credential patterns. Credential rotation compliance check (verify all credentials are within their rotation schedule). Review of detection rule effectiveness.
• Annual: Comprehensive credential management policy review. Audit activity controls review. Update detection patterns based on new credential formats and threat intelligence.